Ubuntu 伺服器該選 LTS 還是 interim release？

Ubuntu LTS 與 interim release：簡短結論

在伺服器上選擇 Ubuntu LTS 或 interim release，關鍵在於只有一個數字：該版本會持續取得安全性更新多久。LTS 會提供 5 年的標準安全性維護。interim release 會提供 9 個月，之後便停止更新，因此你必須升級或重新建置。凡是其他人所依賴的服務，都應執行 LTS。只有在不需徵求他人同意即可重新建置的環境，才應執行 interim release。

LTS 代表 long term support。Canonical 每 2 年發布 1 個 LTS，時間在偶數年的 4 月；兩次 LTS 之間每 6 個月發布 1 個 interim release。26.04 LTS 已於 23 April 2026 發布，其標準安全性維護將持續至 2031 年。26.10 預定於 15 October 2026 發布，且屬於 interim release，因此其支援期限將於 July 2027 結束。

Ubuntu 各版本的支援期限

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

以上是 Canonical 截至 2026 年 8 月公布的政策數據，不是從測試主機測得的結果。LTS 版本提供 60 個月的標準安全性維護，換算下來，5 年內需進行 1 次計畫中的版本升級。非 LTS 的 interim release 提供 9 個月的支援。在相同的 5 年期間持續使用 interim release，需進行 10 次版本升級，因為不能跳過版本，而 5 年內會有 10 個版本。

Ubuntu Pro 訂閱會將 LTS 的支援期限延長至 120 個月，也就是 10 年，並將涵蓋範圍從 main 元件擴大至整個套件庫。截至 2026 年 8 月，個人使用者可在最多 5 台機器上免費使用 Pro，這已涵蓋多數小型 VPS 叢集。interim release 沒有對等方案。完整支援期限只有 9 個月，任何訂閱都無法延長期限。

實際伺服器在 9 個月內的成本

以 26.10 為例。它於 15 October 2026 發布，安全維護於 July 2027 結束，與 25.10 於 July 2026 結束的相同 9 個月模式一致。若按照月曆計算，看起來像是每 3 季有 1 個維護窗口。這種計算方式是錯的，而且會導致較高的成本。

版本升級會直接取代現有的作業系統。do-release-upgrade 會改寫 apt sources、停用第三方套件庫、變更幾乎所有已安裝套件的版本、暫停以詢問你如何處理曾編輯的設定檔，最後重新開機。因此，這是需要事先規劃的維護窗口，不是背景工作。

透過 ssh 執行時，該工具會防止連線中斷造成問題。它會建立自己的 screen 工作階段，並開啟第 2 個 sshd，而且會先通知你：

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

讓它這樣做。如果防火牆或供應商另外提供的網路防火牆封鎖 1022，這個備援連線就不存在。此時連線中斷會留下只完成部分升級的套件集合。在任何主機上自行於 tmux 或 screen 內執行，也能取得相同的保護。

設定檔提示會讓原本 15 分鐘的升級變成 1 小時：

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

保留你的檔案，代表你會錯過新預設值中的變更。採用維護者提供的檔案，代表你的強化設定會消失，直到你重新套用為止。在不知道該版本變更內容的情況下，兩個選項都不安全。因此，閱讀版本說明是維護窗口的一部分，不是可有可無的課外作業。

接著將這些成本乘以主機數量。在 5 年內，1 台採用 interim track 的 VPS 需要 10 個升級窗口。5 台 VPS 就是 50 個，除非每台主機都可直接捨棄，並從映像檔重新建立。在相同期間，5 台採用 LTS track 的主機只需升級 5 次，而且你可以自行選擇每次升級的月份。

為什麼不能跳過 Ubuntu 版本

升級路徑是固定的。中期版本只能升級到下一個版本。LTS 可直接升級到下一個 LTS，也可在明確要求時升級到下一個中期版本。任何版本都不能一次跨越兩個版本。從 26.10 升級到 28.04 LTS，必須依序經過 27.04 和 27.10，或重新安裝這台機器。

了解其機制很重要，因為這能說明規則不會放寬。do-release-upgrade 會從 changelogs.ubuntu.com 取得 meta-release 檔案，接著下載專為某一個特定轉換所建立的升級工具。Canonical 一次只建立並測試一個轉換，因此跳過版本的升級沒有可用工具，也沒有對應測試。升級程式拒絕執行，不是出於謹慎。它沒有可提供的升級路徑。

系統提供哪個版本，取決於設定中的一行：

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts 只提供下一個 LTS。Prompt=normal 提供下一個版本，不論是否為 LTS。Prompt=never 不提供任何版本；如果你不希望同事擅自開始未規劃的升級，便可使用此設定。在非 LTS 版本上，lts 的行為與 normal 完全相同，因為在這兩種設定下，26.10 的下一個版本都是 27.04。檢查會輸出 Checking for a new Ubuntu release，接著輸出 New release ... available. 行或 No new release found.

另一項排程規則也經常造成誤解。新的 LTS 發行當天，不會立即提供 LTS 到 LTS 的升級。升級會在第一個 point release 發布後開放，而 26.04.1 排定於 27 August 2026 發布。某台 24.04 機器在 2026 年夏季期間使用 Prompt=lts，並對 No new release found. 回應，並不是故障。它只是遵循政策。升級路徑開放後，24.04 到 26.04 LTS 的升級就是應規劃並演練的執行工作。

適合選擇 interim release 的情況

以下 4 種情況確實適合選擇 interim release：

• 您現在就需要某個 kernel 或 userspace 版本，但 LTS archive 沒有為這台機器提供該版本。
• 這台機器是 build host、CI runner 或測試機，會從 image 重新建立，因此升級等同於建立新執行個體，而不是安排維護時段。
• 硬體或 hypervisor 功能是在 LTS 凍結後才加入，且沒有 backport。
• 您正在確認下一個 LTS 會包含哪些內容。28.04 是由 26.10、27.04 和 27.10 組成，在備用 VPS 上發現 breaking change，成本低於在重要伺服器上才發現。

大多數選擇 interim release 的人，其實只需要較新的某個套件，而不是較新的整個發行版。還有 2 個成本較低的做法。hardware enablement stack 能將較新發行版的 kernel 帶入 LTS：在 24.04 中為 sudo apt install linux-generic-hwe-24.04，並會在每次 point release 時向前更新，從第 2 個 point release 開始。若只需要單一應用程式，使用 container image 或該廠商自己的 repository，即可只更新其中一個元件，而不必更新整個作業系統。

不適合選擇 interim release 的情況

• 任何有付費使用者或採用 on-call 輪值的環境。您必須每半年進行一次強制升級，換來的可能只是永遠用不到的套件版本。
• 任何由 unattended-upgrades 負責套用安全性修補的主機。這項自動化機制的效果，完全取決於它所使用的 security pocket 是否可靠。
• 任何需要手動升級的主機群組，因為實際成本是單次維護時段乘以主機數量。
• 任何安裝後一年都不再檢查的系統。被遺忘的 interim release，9 個月後就可能成為未套用修補、直接連線至網際網路的伺服器。

最後一種故障不易察覺，因此更加危險。release 終止支援後，其套件會移至 old-releases.ubuntu.com，因此 sudo apt update 對 archive.ubuntu.com 執行時會因 404 錯誤而失敗。儲存在磁碟上的套件清單會逐漸過期。unattended-upgrades 仍會依排程執行，並持續將類似以下的行寫入 /var/log/unattended-upgrades/unattended-upgrades.log：

No packages found that can be upgraded unattended and no pending auto-removals

在已完整套用修補的伺服器上，以及 release 已在 4 個月前終止支援的伺服器上，這一行看起來完全相同。除非有人讀取 apt 錯誤，或追蹤終止支援日期，否則主機上沒有任何資訊能告訴您目前看到的是哪一種情況。

首先進入 interim track 的變更類型

2026 年 3 月，Canonical 工程師在 Ubuntu discourse 提議，移除 Ubuntu 26.10 中為 secure boot 提供的簽署版 GRUB bootloader。這項提案會移除 btrfs、hfsplus、xfs 與 zfs 的 filesystem driver、JPEG 與 PNG 圖片解析器、Apple partition table、LVM 上的 /boot、RAID 1 以外的 software RAID，以及 LUKS 加密的 /boot。提出的理由是，bootloader 內的解析器經常成為安全性錯誤的來源；儲存與加密邏輯則應放在 initramfs 中，也就是 kernel 在掛載真正的 root 前所掛載的小型初始 RAM filesystem。截至 2026 年 8 月，這仍是討論中的提案，尚未成為已發布的變更。

對大多數 VPS instance 而言，這不會造成任何影響，因為它們通常未使用 secure boot，而是從 GPT partition table 上的普通 ext4 /boot 啟動。請檢查自己的環境，不要直接假設。如果 root 是 ZFS，或 /boot 位於 btrfs 上或 LUKS 內，這正是會先在 interim track 遇到的變更類型；該討論串對受影響使用者的建議，也是改用 LTS。這項建議用一句話就完整說明了原因：interim release 用來試行變更；LTS 則是在兩年的 interim release 找出這些變更會破壞什麼之後，才納入這些變更。

每次 interim release 也會以較小的形式呈現相同模式。database、language runtime 與 init 設定的預設版本會向前更新，因此原本可運作的設定檔可能停止運作。推進預設版本正是 interim release 存在的目的；因此，在這 10 次升級前逐一閱讀 release notes，就是你同意承擔的成本。

建置伺服器時選擇版本軌道

請在安裝時選擇版本軌道，因為之後變更通常需要重新安裝，或逐次升級。對於新伺服器，執行以下 4 個命令即可確認目前狀態：

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a 應顯示你原本要安裝的版本；如果是 LTS，描述列結尾應為 LTS。Prompt 列應符合你選擇的版本軌道，而不是供應商映像檔原本附帶的版本。使用中的 LTS 執行 do-release-upgrade -c 應回應 No new release found.。如果它提供的是 interim release，則 Prompt 會設為 normal；此時應確認這是否為刻意的選擇。pro security-status 會回報已安裝套件分別由哪些更新串流涵蓋，並在伺服器未連結訂閱時明確指出。

接著，將終止支援日期記錄在之後還能再次看到的位置，與該伺服器的其他建置備註放在一起。這項工作應與新 VPS 的前 10 分鐘一併完成，因為只存在某人記憶中的支援日期，最容易在無人注意時過期。如果你想徹底避開每 6 個月一次的版本更替，決定讓整個伺服器群組採用哪一種系統前，值得先花 1 小時閱讀FreeBSD 與 Linux 的版本發布模式比較。

FAQ

我應該在正式環境伺服器上執行 Ubuntu interim release 嗎？

幾乎所有情況下都不應該。interim release 在釋出 9 個月後便停止接收安全性更新，因此正式環境若採用這條支援路徑，就代表每年大約需要強制升級 2 次，而且會一直如此。真正的例外是本來就會從映像檔重建的機器，例如 CI runner 和 build host；對這些機器而言，升級代表建立新執行個體，而不是安排維護時段。如果伺服器有實際使用者依賴，請安裝 LTS，並將省下的維護時段用於其他工作。

Ubuntu interim release 支援多久？

9 個月。26.10 於 2026 年 10 月 15 日釋出，安全性維護於 2027 年 7 月結束；25.10 也是相同模式，於 2026 年 7 月結束支援。每個 interim release 都遵循這個週期：在 4 月或 10 月釋出，9 個月後結束支援。LTS 享有 5 年的標準安全性維護；使用 Ubuntu Pro 後可延長至 10 年。截至 2026 年 8 月，個人可免費在最多 5 台機器上使用 Ubuntu Pro。

升級時可以略過 Ubuntu release 嗎？

不行。do-release-upgrade 必須一次升級一個版本：interim release 會升級至下一個 release，而 LTS 可直接升級至下一個 LTS。若要從 26.10 升級至 28.04 LTS，必須先依序升級經過 27.04 和 27.10，或重新安裝該機器。Canonical 會逐一建立並測試每個版本轉換，升級工具也會下載專用於該次跳轉的工具。因此，兩步升級沒有對應工具，系統也永遠不會提供這個選項。

Ubuntu release 結束生命週期後會發生什麼事？

其套件會移至 old-releases.ubuntu.com，因此 sudo apt update 針對 archive.ubuntu.com 的請求會開始因 404 錯誤而失敗，而且該 release 不會再發布任何新的安全性更新。機器上不會顯示任何通知。伺服器仍會持續執行並提供網路流量服務，但其中每個新發現的漏洞都會持續暴露。復原方式是在時間壓力下執行 release upgrade，或重新建置機器。因此，請留意日期，不要等到症狀出現才處理。

LTS kernel 對新硬體而言是否太舊？

通常不是，因為 LTS 不會在 5 年內一直使用原始 kernel。硬體支援堆疊 HWE 會在 point release 中，將後續 release 的 kernel 帶入 LTS；伺服器安裝也可以透過 linux-generic-hwe-24.04 之類的套件選擇啟用 HWE。在假設 kernel 是阻礙之前，請先使用 uname -r 檢查目前執行的版本。如果缺少的部分是 userspace 版本而不是 kernel，使用 container 或 vendor repository，通常比將整台機器移至 interim track 所需的變更小得多。