Oracle Cloud 不重建 Instance 直接重灌系統

2026-07-15
Oracle Cloud 不重建 Instance 直接重灌系統

OCI Console 上沒有「重灌」按鈕，這件事困擾我很久。一般雲端環境要重灌就 terminate 再開一台，沒什麼大不了。但 OCI Always Free 不一樣：免費額度有限，ARM instance 尤其容量難搶，terminate 之後不一定開得回來，很多人就是卡在 "Out of capacity" 反覆刷好幾天都搶不到。就算搶到了，IP 會變、環境要重弄，等於白費。所以能不 terminate 就不 terminate。

後來發現 OCI 其實有個 Replace Boot Volume 功能，可以直接換掉開機磁碟（boot volume），instance 不用終止，OCI 層的網路設定也會保留。整個過程在 Console 上點幾下就搞定。不管是想乾淨重灌 Ubuntu、升級到新版 image，還是先把系統弄乾淨再轉 Debian，第一步都是 Replace Boot Volume。

Replace Boot Volume

這個功能在 instance 詳情頁的 More Actions → Replace Boot Volume。原理很簡單：OCI 會把 instance 停掉，換掉 boot volume，再開機回來。

這裡要先分清楚兩件事，不然很容易誤會：

會保留不會保留
instance 本身（不用 terminate，OCID 不變）舊 boot volume 裡的作業系統
Public / Private IP、VNIC、VCN、subnet、security list你在系統裡裝的套件、改過的設定檔
shape（CPU / RAM 配置）使用者帳號、SSH port 等自訂內容
Block Volume 等額外掛載的磁碟存在 boot volume 上的資料

OCI 資源與網路層設定會保留，但舊 boot volume 裡的作業系統設定與資料不會保留。 開機回來是一個全新的系統，該備份的東西請先備份。

官方文件寫了一堆限制，其中一條是只能換成同一個 Linux 發行版（distro）。Windows 和 Marketplace image 則是真的換不了。

實測上只要拿到目標 image 的 OCID 填進去，跨發行版也可行，但這不在官方支援範圍內。能不能順利開機依 image 與架構而定，有相容性風險，請自行評估。

查 Image OCID

Replace Boot Volume 最關鍵的一步是拿到目標 image 的 OCID。最簡單的方式是直接去 OCI 的 Image 目錄頁，這頁列出所有 platform image，每個 image 點進去下方都有各 region 對應的 OCID 表格，找到你 instance 所在的 region 複製就行，不用裝任何東西。

挑 image 前先確認 CPU 架構對得上。 OCI 的 Ampere A1 是 ARM64（aarch64），E2 / E3 / E4 這類是 x86_64，兩者的 image 不能互換。同一個發行版在目錄頁通常會分開列出 aarch64 與 x86_64 版本，複製 OCID 之前先看清楚是哪一個，架構不符會直接開不起來。

如果習慣用 CLI，也可以查：

oci compute image list \
  --compartment-id <compartment_ocid> \
  --operating-system "Canonical Ubuntu" \
  --all \
  --query "data[*].{name:\"display-name\", id:id}" \
  --output table

想換其他發行版就把 --operating-system 改掉。compartment OCID 在 Console 的 Identity → Compartments 裡找。

Console 操作

  1. 進入 instance 詳情頁，點 More Actions → Replace Boot Volume
  2. Replace by 選 Image，Apply image by 選 Input OCID，貼上剛查到的 OCID
  3. Preserve Boot Volume 建議先開 Enabled，舊 boot volume 會保留下來，萬一新系統有問題還能掛回去救資料
  4. 點 Replace

第 3 步要留意成本：Preserve 起來的舊 boot volume 會繼續以 Block Volume 的形式占用容量。Always Free 的 Block Volume 總額度有限（含 boot volume 在內），留著兩顆可能就超出額度，超出的部分會開始計費。確認新系統沒問題之後，記得回 Console 把舊的 boot volume 刪掉。

OCI 會自動停機、換 volume、再開機，大概 5 到 10 分鐘。開完之後 cloud-init 會自動設定好 SSH 金鑰和網路，用原本的 key 就能連回去。

CLI 操作

不想點介面的話，CLI 也行。先 oci setup config 設好，然後準備一個 JSON：

cat > replace.json << 'EOF'
{
  "sourceDetails": {
    "sourceType": "image",
    "imageId": "ocid1.image.oc1.ap-tokyo-1.yyyyy",
    "bootVolumeVpusPerGB": 10
  }
}
EOF

oci compute instance update \
  --instance-id <instance_ocid> \
  --from-json file://replace.json

instance OCID 在 instance 詳情頁的 Overview 裡。

重灌後

系統是全新的，cloud-init 會把 SSH 金鑰和網路設好，連上去第一件事先更新：

sudo apt update && sudo apt upgrade -y

之前改過的 SSH port 或其他自訂設定，因為都在舊的 boot volume 上，全部會還原成 image 預設值，要重新設。到這裡如果只是要重灌 Ubuntu 或升級 image，就搞定了。但如果目標是 Debian，OCI 沒提供 Debian platform image，Replace Boot Volume 換不上去，接下來要靠 debi。

用 debi 轉 Debian

OCI 的 platform image 只有 Ubuntu、Oracle Linux、CentOS 這些，偏偏沒有 Debian。想裝 Debian 的話，先用 Replace Boot Volume 灌一個乾淨的 Ubuntu（或任何 OCI 有的 Linux image），再用 debi 把它轉成 Debian。debi 的原理是把 Debian installer 注入 GRUB，重開機後全自動安裝成 minimal Debian，README 直接寫了「Perfect for converting Oracle Cloud's Ubuntu images to Debian」。

debi 是第三方腳本，不是 OCI 官方支援的 Debian 安裝方式，OCI 也不保證轉換後的系統可以正常運作。下面的步驟是實測上可行的做法，但成功與否依 image、架構與 debi 版本而定，請當成有風險的操作來看待。

來源 OS 不限 Ubuntu，只要是 KVM 環境、有 GRUB 2、有 root 權限就能跑。

curl -fLO https://raw.githubusercontent.com/bohanwood/debi/master/debi.sh
chmod +x debi.sh
sudo ./debi.sh --cloudflare --authorized-keys-url https://github.com/yourusername.keys
sudo reboot

重開機後 GRUB 自動進入 Debian installer，全自動跑完大概 5 到 10 分鐘。預設裝 Debian 13 (trixie)，建一個 debian 帶 sudo 的使用者。想改版本或設定就加參數：

sudo ./debi.sh --version 12 --user root --bbr --ssh-port 2222

安裝過程想看進度的話加 --network-console，重開機後等兩三分鐘用 ssh installer@your-ip 連進去看。跑出去想取消也行，重開機前把 GRUB 改回來就好：

sudo rm -rf /etc/default/grub.d/zz-debi.cfg /boot/debian-*
sudo update-grub

debi 在 OCI 上的坑

debi 能用，但在 OCI 上踩過不少坑，用的時候要有心理準備：

UEFI 是最大的問題。debi 官方把 AWS EC2 標為「BIOS only，UEFI 尚未支援」，而 OCI 是 UEFI 開機，AMD 和 ARM 的 shape 都是。雖然有 --efi 參數可以強制 EFI，但 UEFI 環境下翻車的機率比 BIOS 高不少。

Serial Console 裝完可能會壞掉（Issue #152，截至撰文時尚未修復）。instance 本身正常，SSH 能連，但 OCI 的 Console Connection 看不到開機輸出，等於失去一條救援管道。解法是手動改 GRUB：

# /etc/default/grub
GRUB_TERMINAL_INPUT="console serial"
GRUB_TERMINAL_OUTPUT="gfxterm serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="splash console=tty0 console=ttyS0,115200"

改完跑 sudo update-grub。

上面那組設定是 x86_64 的寫法。serial device 的名稱依架構與平台而定，ttyS0 不是 ARM 與 x86 通用的裝置名稱，ARM64 平台上也可能是 ttyAMA0 之類的其他名稱。動手改之前，先在還能開機的系統上確認實際的 serial device（例如看 dmesg 或 /proc/consoles），填錯等於白改，也可能把原本還能用的 Console 輸出弄丟。

AMD micro（VM.Standard.E2.1.Micro，1GB RAM）上也多人回報 debootstrap 報錯（Issue #97），作者在較大規格上無法重現，可能跟低資源有關，可以試 --force-lowmem 1。

ARM 以前也有過裝完重開機黑屏的問題（#7、#14），部分已修，但 ARM + UEFI 的組合仍不算穩定。另外 IPv6 可能要額外處理（Issue #88），LVM/RAID 不支援（Issue #134）。

跑 debi 之前先開 --network-console，出問題至少還能 SSH 進去救。第一步的 Replace Boot Volume 記得開 Preserve Boot Volume，萬一 debi 失敗了還能換回乾淨的 Ubuntu 重新來過。

https://blog.2ac.io/posts/feed.xml