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

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

do-release-upgrade 結尾為 No new release found. 幾乎從來不是工具本身故障。你要求的升級路徑當下未開放，因此工具以最簡短的方式回報此狀況。共有 5 個原因會關閉這條路徑：/etc/update-manager/release-upgrades 中的 Prompt 設定、LTS（長期支援）升級的點版本門檻、第三方套件庫、遭到保留或處於半設定狀態的套件，以及已超過支援期限的版本。

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

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。精簡的雲端映像檔有時會省略該套件。

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 最容易診斷，因為工具會在輸出中同時指出檔案與設定值：

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

代管服務商與組態管理工具會刻意設定 never，以避免整個伺服器群組在不同版本間逐漸分歧。如果你在檔案中找到這個值，表示有人刻意這樣設定。若伺服器要使用長期支援版本，請將它改為 lts；如果自動化流程預期原本的值，完成後再改回去。

註解中的一項細節容易造成誤解。當設定為 Prompt=lts，且目前執行的版本本身不是 LTS 版本時，升級工具會將此設定視為 normal。在 25.10 主機上，這兩個值的行為相同。在 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 發布，但版本時程可能變更，因此請檢查中繼資料，不要只依照行事曆。point release 不是新的 Ubuntu 版本，而是將發布後的所有更新整合到全新安裝媒體中的同一個版本。因此，對執行中的伺服器而言，重要的是它開啟的閘門，而不是安裝媒體本身。這項延遲是刻意安排的：先升級的人會找出阻礙因素，問題修正後，數量大得多的 LTS 伺服器才會跟進。

您有兩個合理選項。等待 point release。對任何您不希望持續監看的伺服器而言，這是正確選擇。或者設定 Prompt=normal，讓同一個工具改用 meta-release；其中 26.04 已標記為受支援。第二條路徑會將您升級至已發布的 26.04，而不是開發版本，因此對於可以從 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 及更新版本中，大多數來源都以 deb822 格式放在 /etc/apt/sources.list.d/ubuntu.sources。同一個套件庫同時以舊格式與新格式寫入，會產生另一個具有獨立錯誤訊息的問題；詳見 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，不要修改您的 codename。只有主機名稱需要變更。

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 一次只支援升級一個版本，因此落後 2 或 3 個已停止支援版本的伺服器，必須逐一完成每個升級步驟；每個步驟都可能因不同的第三方 repository 或不同的保留套件而失敗。在 VPS 上，通常直接以目前的 LTS 建立新伺服器、遷移服務，並保留舊伺服器直到確認一切正常，會更快。這也能提供 rollback，而就地升級永遠無法提供這項保障。如果您要決定之後採用哪條版本路線，建議先閱讀伺服器上的 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）工作階段中斷，程序會遭到終止，套件也會處於已解包但尚未設定的狀態。這正是導致下一次嘗試失敗的狀態。如果你已經遇到這種情況，復原中途停止的升級 是另一項工作，必須先完成後才能再次嘗試。每次都應在 terminal multiplexer 中啟動升級程序。

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 的程序。在 tmux 或 screen 中，這項檢查會找到多工器 server，因此不會顯示該提示；pid 檔案 /var/run/release-upgrader-sshd.pid 也只會在額外 daemon 確實啟動時建立。未看到提示並不代表有問題。你已經具備更好的保護機制。

如果你接受該選項，工具不會替你開啟連接埠。工具會明確說明這一點，因為開啟連接埠是安全性決策，不應由工具代替你做出。請在升級期間開啟該連接埠，完成後再關閉。

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

多數 VPS 提供者會在控制面板中另外執行防火牆，且位於作業系統之外。該處也必須開放連接埠 1022，否則 fallback listener 雖在執行，卻無法連線，這是最糟的情況。

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

• 建立 snapshot 或完整備份。就地版本升級無法復原，而這是你唯一擁有的復原點。
• 確認你能在需要前開啟提供者的 console。如果伺服器重新開機後未恢復，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 的首個點版本發布前，該版本會在這個檔案中使用 Supported: 0。升級工具找不到標記為可用的更新 LTS 版本，因此停止。請使用 curl -s https://changelogs.ubuntu.com/meta-release-lts 自行檢查檔案，並查看最後一個區塊。截至 13 August 2026，該旗標仍為 0，而 Ubuntu 26.04.1 預定於 27 August 2026 發布。

將 Prompt=normal 設為等待點版本發布的替代方案，是否安全？

這會將系統升級到已發布的 26.04，而不是開發版本，因為 Prompt=normal 會讀取 meta-release，其中 26.04 已標示為 Supported: 1。風險在於升級時機。你會在早期升級者發現的問題修正前進行升級。請在可從快照還原的伺服器上執行，並確保重新開機失敗時仍能連線到供應商主控台。完成後，將值改回 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 官方伺服器文件指出，不建議在正式環境使用開發版本。因此，若要提早升級到已發布的 26.04，請使用 Prompt=normal。

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

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

執行 do-release-upgrade 前，是否需要移除 PPA？

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