Ubuntu 22.04 升級至 26.04：先升級 24.04

Ubuntu 22.04 無法直接升級至 26.04

Ubuntu 22.04 LTS 無法直接升級至 26.04 LTS。do-release-upgrade 每次只能跨越一個 LTS 版本，因此升級路徑是 22.04 至 24.04，再由 24.04 至 26.04，兩次升級之間都必須重新開機並完成完整檢查。26.04 的發行說明已清楚載明：「如果目前使用較舊的 Ubuntu LTS 或 interim release，例如 Ubuntu 22.04 LTS 或 25.04，必須先升級至 Ubuntu 24.04 LTS 或 25.10，才能繼續升級至 26.04 LTS。」

第二個階段有一項閘門，目前已經開放。Canonical 只有在目標版本的第一個 point release 推出，且其 meta-release 項目標記為 supported 後，才提供 LTS-to-LTS 升級。26.04.1 已於 27 August 2026 發行；截至 27 October 2026，檔案 do-release-upgrade 的內容為 https://changelogs.ubuntu.com/meta-release-lts，其中列出 26.04.1 LTS 及 Supported: 1。因此，完整更新的 24.04 主機會透過一般的 do-release-upgrade 提供 26.04.1，不再顯示 No new release found。先前開放升級的時間取決於 rust-coreutils 中回歸問題的 backport；相關修正已經納入，因此 26.04.1 公告提到的 -d 旗標已不再需要。不過，仍應使用 do-release-upgrade -c 在自己的主機上確認，不要只依賴日期判斷。LTS 升級為何要等待 .1 point release 說明這項閘門背後的原因。

兩個階段代表兩次重新開機，也代表兩輪停用第三方儲存庫；PHP、Python、PostgreSQL 與 kernel 都會在同一台伺服器上跨越四年的主要版本變更。本指南大部分篇幅都用於處理這些變更。第二個階段本身已在24.04 至 26.04 升級指南中逐步說明，因此本節不再重複。現在開始的原因是：22.04 的標準支援將於 2027 年結束；此後只有Ubuntu Pro 的擴充安全維護或付費的第三方延伸支援服務會繼續提供修補程式。

為何升級程式拒絕跳過版本

do-release-upgrade 本身不包含升級邏輯。它會下載 meta-release 檔案 UpgradeTool 行所指定的 tarball：24.04 使用 noble.tar.gz，26.04 使用 resolute.tar.gz。該 tarball 包含的指令碼只支援固定的來源版本清單。這份清單位於升級程式的 DistUpgrade.cfg 中，即 From= 行。2026 年 10 月 20 日最後檢查時，26.04 的清單內容為 noble,oracular,plucky,questing：24.04 LTS，以及其後的 3 個 interim 版本 24.10、25.04 和 25.10。這些 interim 版本都已終止支援，但升級程式仍接受它們作為起始版本。jammy 不在清單中，因此 26.04 升級程式在 22.04 系統上會直接回報錯誤並停止，不會開始升級。每個套件的 maintainer scripts，以及負責遷移設定檔的 preinst 和 postinst hooks，都只針對這些升級路徑進行測試。從 22.04 直接跳到 26.04，會讓 26.04 的指令碼處理從未見過的設定狀態，dpkg 可能在中途停止，導致系統損壞。

在 /etc/update-manager/release-upgrades 中切換為 Prompt=normal 也無法繞過這項限制。Ubuntu 在該檔案中的註解指出，normal 的目標是「緊接在目前執行版本之後的受支援版本」。升級檢查也會跳過 meta-release 檔案標示為不受支援的所有版本。22.10、23.04 和 23.10 在該檔案中都標示為 Supported: 0（2026 年 10 月 27 日檢查），因此從 22.04 執行 normal 時，提供的目標版本仍是 24.04，與 lts 提供的相同。保留 Prompt=lts。現在閘門已開啟，如果 24.04 系統仍顯示 No new release found，原因幾乎一定是本機設定；請參閱do-release-upgrade 找不到升級版本的原因，通常問題出在該檔案或被 hold 的 metapackage。

就地升級，還是建立全新的 26.04 VPS？

就地升級會保留資料與設定，但需要兩個維護時段。全新的 26.04 VPS 加上遷移作業，前期需要更多工作，但最後會得到乾淨的系統。符合以下任一情況時，請選擇遷移。

• 伺服器曾經從 20.04 或更早版本進行過就地升級。每次升級都會留下過時套件與陳舊設定，累積 3 次升級後的遺留項目很難除錯。
• 已啟用超過 2 或 3 個第三方套件庫或 PPA。每次升級都會停用這些套件庫，且必須逐一確認是否有針對新 codename 建置的套件。
• 已安裝控制面板或 out-of-tree kernel module。這些元件會在 kernel 跨版本升級時失效，且不在 do-release-upgrade 能修復的範圍內。
• 無法建立 snapshot。沒有 rollback point 時，對 production box 進行就地升級會形成無法復原的風險。

將伺服器移至新的 VPS 說明複製資料與切換服務的流程。本指南其餘內容皆假設你選擇就地升級。

升級前準備：快照、磁碟空間與乾淨的 22.04

先將 22.04 完整更新至最新狀態。否則升級程式會拒絕啟動，並顯示 Please install all available updates for your release before upgrading.

lsb_release -a
sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove --purge -y
sudo reboot

重新開機後，lsb_release -rs 應輸出 22.04，而 uname -r 應顯示預期的 kernel：GA 系列為 5.15.x，HWE 系列為 6.8.x。如果不確定目前使用哪個系列，請參閱GA 與 HWE kernel 說明，了解如何辨識，以及這對升級為何重要。

檢查磁碟空間。升級程式會先下載所有套件，再開始安裝；最常見的空間不足位置，是存放多個舊 kernel 的獨立 /boot partition。

df -h / /boot
dpkg -l 'linux-image-*' | grep ^ii

請在 / 上至少保留 5 GB 可用空間。如果 /boot 的可用空間少於 200 MB，請在開始前移除舊 kernel，不要等升級程式中止後才處理。

現在在服務商的控制面板中建立 snapshot，並等待其完成。snapshot 是整個磁碟的回復點，正好適合處理 release upgrade 失敗的情況。它不是 backup；此處snapshot 與 backup 的差異很重要：也請繼續執行平常的 backup。接著記錄目前準備離開的系統狀態。

apt-mark showmanual > ~/manual-packages-22.04.txt
apt-cache policy | grep -oE 'https?://[^ ]+' | sort -u > ~/apt-sources-22.04.txt
ls /etc/apt/sources.list.d/
php -v; python3 --version; node -v; psql --version; mysql --version
sudo iptables-save > ~/iptables-22.04.rules
sudo cp -a /etc/netplan ~/netplan-22.04

如果該 stack 尚未安裝，部分指令會輸出 command not found。這是正常的。重點是留下 22.04 上已執行項目的書面紀錄，因為完成兩次升級後，你不會記得舊網站需要哪個 PHP 版本。

最後確認 /etc/update-manager/release-upgrades 顯示 Prompt=lts，並另外開啟一個 SSH 工作階段連線至該主機。整個升級期間都不要關閉它。

第 1 步：從 22.04 升級至 24.04

sudo do-release-upgrade -c

預期輸出：

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

先執行 sudo do-release-upgrade。透過 SSH 連線時，第一個提示會是：

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

回答 yes，然後從第二個工作階段開放該連接埠，因為升級程式會告知你它不會代為處理：

sudo ufw allow 1022/tcp

如果你使用 nftables 或原始 iptables，而不是 ufw，請加入相同效果的規則。如果供應商提供網路防火牆，也請在其中開放連接埠 1022，因為那是與伺服器本機不同的控制層。

升級程式會在 screen 工作階段中執行，因此連線中斷不會終止升級。重新連線後，使用 sudo screen -ls 接著 sudo screen -r 重新附加至工作階段。接著，升級程式會讀取套件清單並顯示摘要，包括將安裝和移除的套件數量，以及下載所需時間。請查看「remove」數量。在一般伺服器上，如果數量超過幾十個，請先按 d 查看詳細資訊，再繼續操作。

升級過程中有 3 個提示需要注意。

停用第三方來源。 升級程式會註解掉所有它無法識別為 Ubuntu 官方來源的 apt 來源，並將每一行標記為 # disabled on upgrade to noble。這是必要的，因為寫有 jammy 的來源會提供為舊版本建置的套件。你會在檢查點逐一重新啟用這些來源。

設定檔提示。 對於由 dpkg 追蹤的已修改設定檔，也就是 conffile，dpkg 會詢問是否安裝套件維護者提供的版本；預設選項 N 會保留你的版本。/etc/ssh/sshd_config 是最可能由你修改的檔案，但其處理方式不同：openssh-server 會透過 ucf 管理該檔案，而不是使用 dpkg 的 conffile 機制，因此提示會顯示 What do you want to do about modified configuration file sshd_config?，並提供 install the package maintainer's version 或 keep the local version currently installed。除非你確定有其他理由，否則請保留本機版本；這是 ucf 的預設選項，因為維護者版本會重設 PasswordAuthentication 和 Port，而你目前正是透過該 daemon 連線。

移除過時套件？ 這會移除存在於 22.04、但不存在於 24.04 的套件。如果你執行 PostgreSQL，postgresql-14 不在該清單中：升級程式的移除拒絕清單會保護所有有版本號的 PostgreSQL 套件，因為清除其中一個套件可能會刪除其叢集，而 pg_upgradecluster 需要這些二進位檔來遷移資料。如果清單中的其他項目仍有用途，請回答 N。完成檢查點後，可以使用 sudo apt autoremove --purge 移除過時套件；此指令會保留仍有叢集的 PostgreSQL 版本。

小型 VPS 通常需要 30 到 60 分鐘，其中大部分時間會花在 dpkg 解包，而不是下載。完成後，系統會詢問是否重新開機。回答 yes。

兩個版本之間的檢查點

清單全部確認無誤前，不要開始第二個版本的升級。兩輪故障疊加在一起，會比一次只處理一輪更難除錯。24.04 的標準支援期限到 2029 年，因此在這裡暫停一週不會造成損失。

lsb_release -rs
uname -r
systemctl --failed
sudo apt update && sudo apt full-upgrade -y

lsb_release -rs 必須輸出 24.04。uname -r 也應以 6.8 開頭；這是 24.04 的 GA kernel，除非該主機使用選用的 24.04 HWE kernel 系列，而目前版本為 7.0。systemctl --failed 應輸出 0 loaded units listed。其中列出的任何 unit 都是你首先要處理的項目。

接著檢查 apt 來源。noble 升級工具會將 /etc/apt/sources.list 轉換為 /etc/apt/sources.list.d/ubuntu.sources，也就是 deb822 格式，並在舊檔案中留下指向新檔案的註解。如果之後又將相同 archive、suite 和 component 的舊格式 deb http://... 行貼回 sources.list，apt 會在兩個檔案中看到相同的 repository，並輸出 is configured multiple times。刪除舊格式的行，或將其註解掉，即可排除 這項重複來源錯誤。

grep -r 'disabled on upgrade' /etc/apt/sources.list /etc/apt/sources.list.d/

對每個停用的行逐一判斷。如果 vendor 發布 noble suite，請將 jammy 改為 noble、移除註解標記，然後執行 sudo apt update。如果輸出 E: The repository '... noble Release' does not have a Release file.，表示 vendor 沒有適用於 24.04 的 build；此時保留該行停用，或尋找其他來源。PPAs 也要採用相同處理方式。接著處理下一節中所有適用於該伺服器的項目，再重新開機一次，確認所有重要服務都能回應，並建立一份新的 snapshot。請為它命名，確保能與 22.04 的 snapshot 區分；在確認 26.04 正常前，兩份 snapshot 都要保留。

兩次升級之間會發生什麼問題

其中每一項單獨來看，都是一般的 24.04 或 26.04 問題。連續執行兩次升級時，問題會同時出現。因此，請在檢查點先修正各項問題，再進行第二次升級，避免問題累積。

第三方軟體來源與 PPA 會停用兩次

第一次升級時，所有非 Ubuntu 軟體來源都會被註解掉；第二次升級時也會再次處理，對應的標記是 # disabled on upgrade to resolute。僅針對 jammy 和 noble 建置的 PPA，在第一天不會有 resolute 套件庫，因此會出現 does not have a Release file 錯誤。這就是確認問題的方法。

在 Web 伺服器上，最常遇到的來源包括 download.docker.com 的 Docker CE、NodeSource、ppa:ondrej/php，以及 Tailscale 套件庫。除了 NodeSource 之外，這些來源的 apt 設定列都會指定發行版本代號。目前 NodeSource 的設定會將 nodistro 寫為套件庫套件組，因此兩次升級都能原樣保留。Docker 的套件庫需要在兩次升級時各修改一次發行版本代號。

另一個選擇是使用 26.04 套件庫中的 docker.io 套件。其版本為 29，已足以應付許多伺服器，因此不一定還需要廠商套件庫。如果你使用 Tailscale 套件庫，Ubuntu 上的 Tailscale 安裝錯誤正是過時發行版本代號會造成的問題。

PHP 連續跨越兩個主版本：8.1、8.3，再到 8.5

Ubuntu 22.04 提供 PHP 8.1，24.04 提供 8.3，26.04 提供 8.5。如果你透過未指定版本的中繼套件安裝 php-fpm，第一次升級會在 php8.1-fpm 旁安裝 php8.3-fpm，並同時啟動兩者。系統不會自動切換 Web 伺服器，因此 nginx 仍會連線到 8.1 socket，服務也會繼續運作。直到你移除過時套件後，錯誤日誌才會出現：

connect() to unix:/run/php/php8.1-fpm.sock failed (2: No such file or directory) while connecting to upstream

修正方式是讓 fastcgi_pass 指向 unix:/run/php/php8.3-fpm.sock，執行 sudo nginx -t，然後重新載入設定。在 Apache 搭配 mod_php 時，請執行 sudo a2dismod php8.1 && sudo a2enmod php8.3 && sudo systemctl restart apache2。在 8.3 的檢查點完成這項操作，執行應用程式測試；第二次升級後，再針對 8.5 重複相同步驟。

如果應用程式目前無法在 8.5 上執行，這是 26.04 上重新啟用 ppa:ondrej/php 的真正理由。該 PPA 為目前支援的每個 Ubuntu 發行版本提供所有 PHP 版本。同樣的步驟也適用於建置在 24.04 上的 LAMP stack，只是它只會遇到這次升級的後半段。

Python：從 3.10 到 3.12，再到 3.14，且 pip 不再寫入系統

系統 Python 在第一次升級時從 3.10 變為 3.12，第二次升級時再變為 3.14。這會造成兩項問題。

首先，所有在 22.04 建立的 virtualenv，其 bin/python 都是指向 /usr/bin/python3.10 的 symbolic link。移除過時套件時，該檔案也會被移除，因此 venv 會因 No such file or directory 而失效。請使用 python3 -m venv --clear .venv 重建每個 venv，並重新安裝其 requirements。

其次，從 24.04 開始，在 venv 之外執行 pip install 會拒絕寫入，並顯示：

error: externally-managed-environment

這是 PEP 668 的保護機制，用來避免覆寫由 apt 管理的 Python 套件。請使用 venv 或 apt install python3-<name>，不要使用錯誤訊息所提到的 --break-system-packages 旗標。

Node：從套件庫的 12 到 18，或使用 NodeSource

套件庫中的 nodejs 套件在 22.04 是 12.22，在 24.04 是 18.19。因此，使用 Node 12 建置的應用程式會一次遇到 4 年間移除的 API。多數正式環境伺服器改用 NodeSource，而 NodeSource 會固定特定主版本，因此兩次升級都不會變更版本。只需要重新啟用套件庫設定列。

資料庫：PostgreSQL 從 14 到 16，再到 18；MySQL 8.4 會鎖定帳戶

第一次升級會在現有的 PostgreSQL 14 cluster 旁安裝 PostgreSQL 16，並讓新的空白 cluster 使用 5433 埠。pg_lsclusters 會顯示兩個 cluster。你的資料仍位於 5432 埠上的 14。請在檢查點執行遷移：

pg_lsclusters
sudo pg_dropcluster --stop 16 main
sudo pg_upgradecluster 14 main
pg_lsclusters

pg_upgradecluster 會傾印 14 的資料，並將資料載入 5432 埠上的新 16 cluster，接著讓 14 停止並使用 5433 埠。確認應用程式正常後，再執行 sudo pg_dropcluster 14 main。第二次升級後，套件庫會提供 PostgreSQL 18；請使用 16 和 18 重複相同的 4 個指令。

這就是升級程式不會將 postgresql-14 視為過時套件而移除的原因，也是 apt autoremove 在其 cluster 存在時會保留它的原因：pg_upgradecluster 會使用舊伺服器的二進位檔讀取舊資料。

22.04 和 24.04 都使用 MySQL 8.0，因此第一次升級不會造成變更。第二次升級會移至 8.4，並停用 mysql_native_password plugin。發行說明指出，使用該 plugin 的帳戶「預設會被鎖定」。用戶端會看到 ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded。請在檢查點、仍使用 8.0 時找出這些帳戶：

SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';
ALTER USER 'app'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'the-same-password';

無法支援 caching_sha2_password 的舊版 PHP 和 Python driver 是這些帳戶存在的原因，因此每次 ALTER USER 後都要測試應用程式。

22.04 時期的 netplan 檔案

許多 22.04 時期的 VPS 映像檔會以 gateway4: 建立 /etc/netplan/50-cloud-init.yaml，而且權限允許所有使用者讀取。24.04 的 Netplan 1.0 與 26.04 的 1.2 仍接受這兩種設定，但會顯示警告。第一次執行 sudo netplan generate 時即可看到：

** (generate:1234): WARNING **: 10:21:07.512: Permissions for /etc/netplan/50-cloud-init.yaml are too open. Netplan configuration should NOT be accessible by others.
** (generate:1234): WARNING **: 10:21:07.513: `gateway4` has been deprecated, use default routes instead.

使用 sudo chmod 600 /etc/netplan/*.yaml 修正權限。將 gateway4: 203.0.113.1 替換為預設路由：

routes:
  - to: default
    via: 203.0.113.1

請使用 sudo netplan try 測試，不要使用 netplan apply。try 會套用變更；除非你按下 Enter，否則 120 秒後會自動還原。因此，即使錯誤設定中斷 SSH 工作階段，也會自行復原。

請在 24.04 的檢查點完成這項工作，因為第二次升級後才發現的 netplan 錯誤，看起來會與第二次升級本身的問題完全相同。

iptables-legacy 會在兩次升級後持續存在

自 20.10 起，Ubuntu 的 iptables 已使用 nftables backend。若 22.04 伺服器因舊版 Docker 或防火牆 script 而透過 update-alternatives --set iptables /usr/sbin/iptables-legacy 切換至 legacy，兩次升級都會保留該選擇，因為 update-alternatives 不會覆寫手動選取的 backend。請檢查：

sudo iptables -V
sudo update-alternatives --display iptables | head -3
sudo nft list ruleset | head

iptables v1.8.x (legacy) 表示使用 legacy backend。它仍會正常運作，問題也因此容易被忽略：透過 legacy 工具載入的規則與透過 nftables 載入的規則都在 kernel 中運作，但兩種工具都不會顯示另一方的規則。因此，nft list ruleset 幾乎沒有輸出，而 legacy 規則仍持續丟棄封包。

26.04 上的 Docker 29 可以切換至 nftables backend，ufw 則會使用目前選取的 alternative。因此，混合使用的伺服器會有兩套規則集，無法在同一處完整檢視。

請在檢查點使用 sudo update-alternatives --set iptables /usr/sbin/iptables-nft 切換至 iptables-nft，重新載入已儲存的規則，並確認 sudo nft list ruleset 現在能顯示這些規則。

Kernel 從 5.15 到 6.8，再到 7.0，以及新的 initramfs 工具

GA kernel 在第一次升級時從 5.15 變為 6.8，第二次升級時再變為 7.0。升級不會移除舊 kernel，因此 /boot 可能會被填滿。VPS 在 kernel 變更後無法開機，是保留 snapshot 的主要用途。Kernel 更新後無法開機的 VPS 復原方式說明如何使用主控台與 GRUB 選單。

全新安裝的 26.04 會使用 dracut 建立 initramfs，而不是 initramfs-tools。升級後的伺服器可能仍保留 initramfs-tools；請使用 dpkg -l initramfs-tools dracut 檢查，並保留目前已安裝的工具。

第二次升級還會帶來兩項 26.04 變更，開始前應先閱讀。sudo 現在是 sudo-rs；如果你有複雜的 sudoers，sudo-rs 的變更內容與你相關。coreutils 已改為 Rust 重寫版本，Rust coreutils 說明涵蓋有差異的旗標。

此外，systemd 259 不再支援 cgroup v1。如果 /proc/cmdline 含有舊版容器設定留下的 systemd.unified_cgroup_hierarchy=0，請在第二次升級前從 GRUB 移除。26.04 已無法執行它原本要達成的功能。

第二跳：24.04 至 26.04

請直接在該主機上確認閘門條件：

sudo do-release-upgrade -c

New release '26.04.1 LTS' available. 表示 meta-release 項目已標記為受支援。Canonical 自 2026 年 10 月 27 日開放升級後，該項目便一直處於此狀態。請完全依照第一跳的方式執行 sudo do-release-upgrade，將第二個 sshd 設為連接埠 1022，並使用相同的提示選項。這次的第三方標記為 # disabled on upgrade to resolute。如果已完整更新的 24.04 主機仍輸出 No new release found，原因便是本機狀態：尚有待安裝的更新、存在不是 lts 的 Prompt= 行，或有套件被保留。不要使用 do-release-upgrade -d。它會讀取開發版 meta-release 檔案；在 rust-coreutils backports 已納入且正常升級路徑已開放的情況下，伺服器沒有理由使用它。如需了解 point release 實際包含的內容，以及如何讀取控制閘門的 meta-release 項目，請參閱 26.04.1 版本更新摘要。完整程序以及 26.04 專用的提示與升級後檢查，請參閱 24.04 至 26.04 升級指南。由於您已經建立檢查點快照，請從快照步驟開始執行。

如果升級步驟失敗

升級程式會將日誌寫入 /var/log/dist-upgrade/。main.log 記錄升級程式本身的決策，term.log 記錄每一行 dpkg 輸出；apt.log 則呈現相依性解析器的判斷。升級步驟若在中途停止，通常會讓 apt 停留在可由 sudo dpkg --configure -a 接著 sudo apt -f install 完成的狀態。若仍無法完成，復原失敗的版本升級 會依序進入救援流程，而你在該步驟前建立的 snapshot 則是最後的復原手段。步驟二失敗後還原 24.04 snapshot，你只會損失處理時間。步驟一失敗後還原 22.04 snapshot，系統會回到開始升級前的狀態，並保留一份待修正項目清單，之後即可再次嘗試。

FAQ

我可以直接將 Ubuntu 22.04 升級到 26.04 嗎？

不可以。do-release-upgrade 每次只跨一個 LTS 版本，而 26.04 的發行說明指出，22.04 主機必須先升級到 24.04。上次於 2026 年 10 月 20 日檢查時，所下載的 26.04 升級程式只接受 24.04 LTS 及其後的中間版本（24.10、25.04 和 25.10）作為起始版本，清單中沒有 22.04。從 22.04 開始，唯一受支援的路徑是 22.04 到 24.04，再由 24.04 到 26.04。設定 Prompt=normal 不會改變升級路徑：升級程式會略過 meta-release 檔案標示為不受支援的版本，而 22.10、23.04 和 23.10 都屬於這類版本。因此從 22.04 開始，無論如何都只會提供 24.04。

為什麼 24.04 上的 do-release-upgrade 會顯示 "No new release found"？

Canonical 只有在目標版本推出第一個 point release 後，且 meta-release-lts 檔案將該版本標示為 Supported: 1 時，才會開放 LTS 到 LTS 的升級。Ubuntu 26.04.1 已於 2026 年 8 月 27 日推出。截至 2026 年 10 月 27 日，rust-coreutils 回歸問題的修正已回移，因此該項目顯示為 Supported: 1，完整更新的 24.04 主機應會看到 New release '26.04.1 LTS' available。如果你的主機沒有看到，先執行 sudo apt update && sudo apt full-upgrade，再確認 /etc/update-manager/release-upgrades 顯示 Prompt=lts，而不是 never。

我應該就地升級，還是建立全新的 26.04 VPS？

如果主機是單一用途伺服器、第三方儲存庫不多，而且每次升級前都能建立 snapshot，則可選擇就地升級。如果伺服器過去曾經就地升級、執行 control panel、使用 custom kernel，或依賴多個 PPA，則應建立全新的 26.04 VPS 後再進行遷移，因為這些因素都會增加兩次升級的處理工作。

22.04 升級到 26.04 需要多久？

小型 VPS 應規劃 2 個各 30 到 60 分鐘的維護時段，此外還要預留處理檢查點的時間。實際耗時通常在檢查點，因為此時需要遷移 PostgreSQL、切換 PHP socket、重建 Python virtualenv，以及重新啟用儲存庫。兩次升級之間間隔數週不會造成問題：24.04 的標準支援期限至 2029 年。

升級期間會如何處理我的 PPA？

升級程式會將每個非 Ubuntu 來源設為註解，並在每行標記 # disabled on upgrade to noble；第二次升級時會使用 resolute 再執行一次。PPA 行會指定版本 codename，因此請先修改 codename，再執行 sudo apt update 重新啟用。如果 apt 顯示 does not have a Release file，表示該 PPA 尚未提供此版本的組建；你可以等待，或尋找其他來源。