do-release-upgrade 找不到新版本怎麼辦？

do-release-upgrade 顯示找不到新版本的原因

do-release-upgrade 結尾為 No new release found. 的訊息幾乎從來不是工具故障。你要求的升級路徑當下無法使用，因此工具以最簡短的方式回報。造成路徑關閉的原因有 5 種：/etc/update-manager/release-upgrades 中的 Prompt 設定、LTS（long term support）升級的 point release gate、第三方套件庫、被 hold 或尚未完成設定的套件，以及已超過支援期限的版本。

請依照上述順序逐一檢查。每個原因都有對應的指令，可確認它是否適用於你的伺服器，因此不必猜測目前遇到的是哪一種情況。

check-only 旗標實際回報的內容

sudo do-release-upgrade -c
echo $?

-c 僅執行檢查。它會透過 HTTPS（hypertext transfer protocol secure）讀取 Canonical 的版本中繼資料，並輸出結果。不會下載升級工具，也不會改寫任何來源檔案。需要注意的輸出有兩項：

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

結束代碼也會為指令碼提供相同結果。可用版本時為 0，沒有可用版本時為 1。這與一般 shell 慣例相反，因此在據此建立檢查機制前，請先確認其含義。

如果登入橫幅仍顯示舊結果，表示該結果已被快取。這一行來自 /etc/update-motd.d/91-release-upgrade；它會輸出已儲存的結果，而不是查詢網路。請使用 sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd 更新，或直接信任 -c。橫幅只會重複上次執行檢查時的結果。

此檢查也必須能連線至 changelogs.ubuntu.com。如果伺服器位於嚴格限制對外連線的防火牆後方，或使用工具無法通過的 proxy，工具就無法查詢，因此也找不到任何版本。

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

HTTP/2 200 行表示伺服器可以讀取中繼資料。curl: (28) Connection timed out 表示真正原因是對外連線規則；無論修改多少 APT（advanced package tool）檔案，都不會改變結果。

如果完全找不到此指令，它位於 ubuntu-release-upgrader-core。精簡的 cloud image 有時不會包含該套件。

sudo apt install ubuntu-release-upgrader-core

變更任何設定前，先閱讀 /etc/update-manager/release-upgrades

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

此檔案的註解中包含說明。有效值有 3 種：

• never：永不檢查，也永不允許升級到新版本。
• normal：提供緊接在目前執行版本之後的受支援版本。
• lts：提供目前執行版本之後的第一個 LTS 版本。

Prompt=never 是 3 種設定中最容易診斷的，因為工具輸出會同時指出檔案與設定值：

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Hosting provider 與 configuration management tool 會刻意設定 never，避免整個伺服器群組在不同版本間逐漸分歧。如果在此發現這個值，表示有人明確選擇了它。若要讓伺服器使用 long term support 軌道，請將它改為 lts；如果自動化流程預期原本的值，之後再改回去。

註解中有一項細節容易造成誤解。當設定為 Prompt=lts，且目前執行的版本本身不是 LTS release 時，upgrader 會將此設定視為 normal。在 25.10 機器上，這 2 個值的行為相同。在 24.04 機器上則不同，而這項差異正是下一節的全部內容。

為何 LTS 到 LTS 的升級要等到第一個 point release

Prompt 決定升級程式讀取哪個中繼資料檔案。這些位址位於 /etc/update-manager/meta-release：

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts 讀取 meta-release-lts。Prompt=normal 讀取 meta-release。這兩個檔案都會以一小段鍵值描述每個版本，且只有當版本的 Supported: 旗標為 1 時，升級程式才會提供該版本。請從同一台伺服器自行讀取這些檔案：

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

截至 13 August 2026，這兩個檔案對 Ubuntu 26.04 的狀態並不一致。LTS 檔案顯示：

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

一般檔案顯示：

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

LTS 檔案中的 Supported: 0 就是開關。使用預設 Prompt=lts 的 24.04 伺服器會讀取該檔案，找不到標記為可用的較新 LTS 版本，並顯示 No new release found.。你的機器沒有問題。Canonical 尚未開放這條升級路徑。

第一個 point release 發佈後，旗標會切換為 1。Ubuntu 26.04.1 預定於 27 August 2026 發佈，但版本時程可能變動，因此應檢查中繼資料，不要只依照行事曆。這項延遲是刻意安排的：先升級的使用者會找出阻礙，這些問題會在數量更多的 LTS 伺服器開始升級前修正。

你有兩個合理選項。等待 point release，這是任何你不想持續監看的伺服器都應採取的做法。或者設定 Prompt=normal，讓同一個工具改為讀取 meta-release；其中 26.04 已標記為受支援。第二條路徑會將系統升級至已發佈的 26.04，而不是 development build，因此若機器可從 snapshot 還原，這種做法仍然合理。完成後，將值改回 lts。完整的逐步操作流程請參閱 24.04 到 26.04 的完整伺服器升級指南。

會阻擋升級的第三方套件庫與 PPA

升級工具會改寫 APT 來源，將其指向新版本。只有已針對新版本發布套件的套件庫才能這樣處理，因此其他來源都會被註解停用。工具會針對每個項目各列出一行原因，而且原因各不相同：was disabled (unknown mirror)、was disabled (unknown dist) 和 was disabled (no Release file)。

針對 noble 建立的 PPA，在伺服器上沒有 resolute 的目錄，因此升級工具無法為新版本系列取得 Release 檔案，便會停用該來源。這通常只是警告，可以接受。但如果第三方套件庫提供的套件與新版本同時發布的套件發生衝突，問題就會阻止升級，因為升級計算會出現兩個候選版本，且無法同時滿足兩者。

開始升級前，請自行決定如何處理，不要讓工具在長時間無人值守的執行期間代為決定。

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

在套件名稱上執行 apt policy，會列出每個已安裝版本所屬的套件庫，讓你確實看出哪些套件依賴即將停用的來源。移除來源不會降級任何套件，因此從 PPA 安裝的套件會維持 PPA 版本，且可能比新版本所提供的版本更新。若這會造成問題，也請一併移除該套件，並在升級完成後從套件庫重新安裝。若計畫重新啟用某個套件庫，例如 Tailscale 的套件庫，必須先將其代號更新為新版本，套件才能再次安裝。Ubuntu 上大多數 Tailscale 安裝錯誤都源自這個問題。

也有一個旗標可選擇相反的處理方式。手冊頁將 --allow-third-party 說明為「啟用第三方鏡像站與套件庫來嘗試升級，而不是將其註解停用。」只有在確認該套件庫已針對目標版本發布套件時，才應使用此旗標。否則，你等於要求 APT 根據該套件庫從未建立過的版本系列來解析相依性圖。

在 Ubuntu 24.04 及後續版本中，大多數來源都位於 /etc/apt/sources.list.d/ubuntu.sources，並採用 deb822 格式。同一個套件庫若同時以舊格式與新格式寫入，會產生另一個具有獨立訊息的錯誤；相關內容請參閱 deb822 格式中的重複來源項目錯誤。

已保留及半設定的套件會使計算失敗

版本升級必須移動系統上的幾乎所有套件。如果有一個套件無法移動，計算就會失敗。升級程式會選擇提早停止，而不是讓系統停在半完成狀態。使用以下兩個命令即可找出原因。

apt-mark showhold
sudo dpkg --audit

apt-mark showhold 會每行列出一個已保留的套件。系統狀態正常時，則完全不會輸出內容。套件保留是手動指示，表示永遠不要變更該套件。有人可能固定了 kernel 或資料庫版本，之後卻忘記解除。對於不再需要保留的套件，請執行 sudo apt-mark unhold，並在後面指定套件名稱。

dpkg --audit 會列出已解包但尚未設定的套件。這種狀態通常源自安裝程序遭到中斷，最常見的原因是工作階段中斷。升級程式會嘗試修復這些套件，並輸出 dpkg interrupted, calling dpkg --configure -a。不過先自行執行修復程序，可以直接讀取錯誤，而不是看著訊息快速捲過。若工具無法修復某個套件，會顯示 Package in inconsistent state。重試前必須先處理該套件。

升級前，先將目前執行中的版本完整更新至最新狀態。

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

分階段更新選項的重要性超出表面所見。Ubuntu 會一次將部分更新推出給一定比例的機器，因此單純執行 apt upgrade 可能會正確地留下部分套件未更新，導致伺服器的更新程度低於預期。指定該選項即可安裝所有更新。如果其中包含 kernel，請在之後重新開機，讓升級程序從實際正在執行的 kernel 開始。若伺服器已透過 自動無人值守安全性升級 持續套用修補程式，這裡需要處理的項目會較少。不過，該機制原本就不會跨越版本邊界。

發行版本超過標準支援期限時

Ubuntu interim release 的支援期限為 9 個月。支援結束後，其 Supported: 旗標會變更為 0，而一般升級流程不提供從該版本升級的路徑。於 2026 年 8 月 13 日查閱時，meta-release 對 25.10 的說明如下：

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

封存位置也會同時變更。已終止生命週期版本的套件會從 archive.ubuntu.com 移除，並保留在 old-releases.ubuntu.com。因此，apt update 會開始回傳 404 Not Found，系統無法再更新到目前狀態；由於升級程式要求系統必須是目前狀態，升級便無法繼續。請先修正套件來源。

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

將 archive.ubuntu.com 與 security.ubuntu.com 都指向 old-releases.ubuntu.com，不要修改代號。只有主機名稱需要變更。

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

如果伺服器仍將套件來源保存在單一檔案中，請改為對 /etc/apt/sources.list 執行相同的命令。-i.bak 選項會在原始檔案旁建立備份，因此若修改目標錯誤，可以還原原始檔案。之後執行乾淨的 apt update，表示已能再次連線至封存站，而 do-release-upgrade 現在也會回應。

請務實評估這樣做能解決多少問題。Ubuntu 一次只支援跨越 1 個版本升級，因此落後 2 或 3 個已終止支援版本的伺服器，必須逐一完成每個升級步驟；每個步驟都可能因不同的第三方套件庫或被保留的套件而失敗。對 VPS 而言，通常直接以目前的 LTS 建立新伺服器、遷移服務，並保留舊伺服器直到確認無誤，速度更快。這也能提供回復路徑，而原地升級永遠無法提供這種保障。若要決定之後採用哪一種版本路線，請先閱讀伺服器上的 LTS 與 interim release 差異，再做決定。

開發版本旗標實際上的作用

-d 或 --devel-release 會讓升級程式讀取 meta-release-development，而不是讀取 Prompt 所選取的檔案。手冊頁面將其描述為：「如果使用最新的受支援版本，則升級至開發版本。」

截至 13 August 2026，該檔案中的最新項目不是 26.04：

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

因此，-d 不會將 24.04 伺服器升級至已發布的 26.04。它的目標是 26.10，而該版本仍在開發中。過去「只要加入 -d」的建議，是針對 LTS 發布前的期間撰寫的。現在照做，會將伺服器指向你原本無意前往的版本。若仍設定 Prompt=lts，該旗標會停止執行，並顯示自身的訊息：

There is no development version of an LTS available.

Ubuntu 的伺服器文件明確說明此旗標：「不建議在正式環境中使用開發版本（或 -d 旗標）」。開發版本每天都可能變更，也不提供安全性支援承諾。因此，早上可正常運作的套件，下午可能就會導致服務失效。請在專門用來測試自有設定的暫存虛擬機器上使用。不要在任何人依賴的伺服器上使用。若要在 LTS 升級閘門開放前使用已發布的 26.04，Prompt=normal 才是正確途徑。

在 SSH 連線中斷也不會中斷升級的環境中執行升級

版本升級會替換大部分系統元件，包括 openssh-server 與 systemd。如果 dpkg 執行期間 SSH（secure shell）連線中斷，程序會遭到終止，套件則會停留在已解開但尚未完成設定的狀態。這正是導致下一次嘗試失敗的狀態。每次都應在終端機多工器中啟動升級。

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

如果連線中斷，重新登入後執行 tmux attach -t upgrade。升級程序仍會繼續執行，因為它是 tmux server 的子程序，而不是 SSH 工作階段的子程序。如果偏好使用 screen，screen -S upgrade 與 screen -r upgrade 也能執行相同工作。

對於未使用多工器的情況，升級工具本身提供了安全機制。偵測到程序在 SSH 下執行時，工具會詢問是否在連接埠 1022 上啟動第二個 sshd，讓主要工作階段中斷時仍保留登入管道。工具會逐層檢查自己的父程序，尋找名為 sshd 的程序，以此判斷是否在 SSH 下執行。在 tmux 或 screen 中，這項檢查會找到多工器 server，因此不會顯示該提示；pid 檔案 /var/run/release-upgrader-sshd.pid 也只會在額外 daemon 確實啟動時寫入。未看到提示並不表示發生問題。你已經具備更好的保護。

如果接受該選項，連接埠不會自動為你開放。工具會清楚說明這一點，因為開放連接埠屬於安全性決策，工具無權代替你執行。請在升級期間開放該連接埠，完成後再關閉。

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

大多數 VPS 供應商會在控制面板中另外執行防火牆，位於作業系統之外。該處也必須開放連接埠 1022，否則備援監聽器雖在執行中，卻無法連線，兩者同時存在是最糟的情況。

在輸入指令前，請先完成以下 4 件事：

• 建立 snapshot 或完整備份。原地執行版本升級無法復原，而這是你唯一可用的復原手段。
• 確認你能在需要時開啟供應商的主控台。若伺服器重新開機後未恢復，SSH 正是你無法使用的管道。無法開機的 kernel 是另一個問題，需要不同的復原步驟，詳見 kernel 更新後無法開機的 VPS。
• 使用 df -h / /boot 檢查可用空間。升級會下載完整的套件集合；而存放數個舊 kernel 的 /boot 分割區，是常見的停滯位置。
• 閱讀所執行服務的版本說明。PostgreSQL 或 PHP 的主要版本升級會隨版本一併到來，不論你是否已做好準備。

FAQ

為什麼在 Ubuntu 24.04 上執行 do-release-upgrade 會顯示找不到新版本？

/etc/update-manager/release-upgrades 中的預設 Prompt=lts 會讓工具讀取 https://changelogs.ubuntu.com/meta-release-lts。Ubuntu 26.04 在首次 point release 前，會在該檔案中使用 Supported: 0。升級工具找不到標示為可用的較新 LTS 版本，因此會停止。使用 curl -s https://changelogs.ubuntu.com/meta-release-lts 自行檢查該檔案，並查看最後一個區塊。截至 13 August 2026 檢查時，該旗標仍為 0；Ubuntu 26.04.1 預定於 27 August 2026 發布。

等待 point release 前，將 Prompt=normal 設定為其他值是否安全？

這會將系統升級至已發布的 26.04，而不是開發版本，因為 Prompt=normal 會讀取 meta-release，其中 26.04 已標示為 Supported: 1。風險在於升級時機。您會在早期升級者發現的阻礙問題修正前進行升級。請只在能從 snapshot 還原，且重新開機失敗時仍能連線至供應商主控台的伺服器上執行。完成後將該值改回 lts。

-d 旗標會將系統升級至 26.04 嗎？

不會。-d 會讀取 meta-release-development；截至 13 August 2026，該檔案中最新的項目是仍在開發中的 Ubuntu 26.10。在設有 Prompt=lts 的 LTS 機器上，該旗標會顯示 There is no development version of an LTS available.，然後停止。Ubuntu 官方伺服器文件指出，不建議在 production 環境使用開發版本。因此，若要提早使用已發布的 26.04，請使用 Prompt=normal。

apt update 在舊版本上回傳 404 錯誤。該如何升級？

該版本已到達 end of life，因此其套件已從 archive.ubuntu.com 移至 old-releases.ubuntu.com。只修改 /etc/apt/sources.list.d/ubuntu.sources 中的主機名稱；較舊的配置則修改 /etc/apt/sources.list 中的主機名稱，並保留原本的 codename。接著執行 sudo apt update 和 sudo apt full-upgrade。系統恢復為最新狀態後，do-release-upgrade 可讓系統一次升級一個版本。

執行 do-release-upgrade 前，需要移除 PPAs 嗎？

不需要，因為升級工具會將未針對新版本發布套件的來源註解掉，並為每個來源顯示類似 was disabled (no Release file) 的行。不過，先自行處理會更好，因為您可以決定順序，也能直接查看結果。對需要確認的套件執行 apt policy，找出各套件來自哪個 PPA；如果 PPA 版本較新版本所提供的套件更新，請改從 archive 重新安裝這些套件。