Ubuntu 26.04 LTS「Resolute Raccoon」在 2026 年 4 月 23 日就發布了，但如果你的伺服器跑著 24.04 LTS，這四個月裡 do-release-upgrade 一直告訴你「沒有可用的新版本」。原因不是 bug：Canonical 不在發布當天開放 LTS 到 LTS 的升級通道，而是等到第一個點版本。按官方發布計畫，那個點版本 26.04.1 定在 2026 年 8 月 27 日。

為什麼要等 .1

這四個月是留給升級路徑本身的。使用者在 26.04 首發後遇到的升級阻斷問題（套件相依衝突、設定檔遷移出錯、驅動程式退步）會被逐一修掉，並彙整進 26.04.1 的安裝映像檔與升級程式。等 .1 不是保守，而是這條路徑被真正測過的第一天。

時間帳也值得算清楚：24.04 LTS 的標準安全維護到 2029 年 5 月結束，並不緊迫；26.04 LTS 的標準維護到 2031 年 5 月，延伸安全維護（ESM）到 2036 年 5 月。如果你還停在 22.04，情況相反——它的標準支援 2027 年 4 月就到期，而且不能直接跳到 26.04，必須先升到 24.04 再升 26.04，中間要留出兩次升級的時間。

VPS 上升級的五個注意點

  • 先做可回復的快照：升級一旦在半路失敗，最快的復原方式是回復整台機器，而不是手工修套件。沒有快照能力就先做一次完整備份並驗證能還原——沒驗證過的備份不算備份。
  • SSH 升級要留後路：do-release-upgrade 會在 1022 連接埠另開一個 sshd 作為主連線斷掉時的備援入口。防火牆與雲端安全群組要事先放行這個連接埠，否則一旦斷線你就進不去了。同時務必在 tmux 或 screen 裡執行，網路抖一下不至於讓升級行程被砍掉。
  • 先處理第三方來源：升級程式會停用大部分 PPA 與第三方 apt 來源，但自己加的 Docker、Node、PHP、資料庫倉庫最好事先手動確認它們已經有對應 26.04 的分支，否則升完會有一批套件卡在舊版本。
  • 事先查主版本躍遷：跨兩個 LTS 意味著 PHP、MySQL/MariaDB、Python、Node 都可能跨大版本。先在一台按小時計費的臨時執行個體上把同樣的環境升一遍，把錯誤清單摸清楚，再動正式機。
  • 別在流量尖峰做：設定檔衝突提示（保留舊版還是用維護者版本）需要人工判斷，nginx、sshd、postfix 的設定尤其要看清楚。升級完成後重新開機並逐一驗證服務，別只看「機器起來了」。

還有個 -d，但別在正式環境用

管理員可以用 do-release-upgrade -d 強行提前升級到尚未開放的版本。這是給測試用的路徑，Canonical 不建議用於正式系統；既然 8 月 27 日之後正式通道就開了，也沒必要冒這個險。

把升級當成例行演練

LTS 之間的升級兩年才做一次，正因為稀少，才更容易在第一次做的時候踩坑。合理的做法是先在一台便宜的小執行個體上完整走一遍：裝同樣的環境、跑同樣的升級指令、記錄每一處需要人工決策的地方，然後再對正式機執行。SharkCloud 在日本、新加坡、香港、美國均有節點，開一台臨時執行個體做升級演練的成本，遠低於正式機在升級中途卡住的代價。