SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 已更新 2026-08-30

Ubuntu 24.04 升級至 26.04 的時間與步驟

Ubuntu 24.04 在 26.04.1 於 2026 年 8 月 27 日發布前不會提供升級。了解安全升級順序,以及 SSH、網路與伺服器服務可能中斷的原因。

何時可以將 Ubuntu 24.04 升級至 26.04?

VPS 上的 Ubuntu 24.04 必須等到 26.04.1 點次要版本發布後,才能升級至 Ubuntu 26.04。該版本預定於 27 August 2026 發布。在此之前,24.04 伺服器不會看到新版本,這是預期行為。Ubuntu 26.04 LTS (Resolute Raccoon) 已於 23 April 2026 發布,但 Canonical 只會在第一個點次要版本發布後開放 LTS 至 LTS 的升級路徑,因為該版本會整合前幾個月發現的安裝與升級錯誤。如果你不熟悉這種編號方式,26.04.1 不是不同的 Ubuntu,而是將四個月的修正整合至安裝媒體中的相同 26.04,這正是 Canonical 首次提供給現有伺服器的版本。

在 2026 年 8 月初於 24.04 伺服器上執行檢查時,會得到以下結果:

sudo do-release-upgrade
Checking for a new Ubuntu release
No new release found.

這不是伺服器發生故障。/etc/update-manager/release-upgrades 在 Ubuntu Server 上包含 Prompt=lts,表示該工具只會提供下一個長期支援版本,而且必須等到 .1 點次要版本發布後才會提供。若設定 Prompt=normal,系統則會依序引導你升級至 24.10、25.04 和 25.10;這些中期版本目前都已終止支援。請保留 lts 設定並等待。Canonical 的時程可能變動,因此若預定日期過後仍沒有變化,請再次檢查。

以下每個命令都必須由你依照所列順序,在自己的伺服器上執行。無法在正在升級的機器上預演版本升級。升級程序會替換 kernel 和 C library,並需要重新開機才能完成。

是否真的要升級?

Ubuntu 24.04 會持續提供標準安全更新至 2029 年,因此正常運作的正式環境伺服器沒有期限壓力。只有在需要 26.04 提供的功能時才升級,例如 PHP 8.5、PostgreSQL 18、MySQL 8.4 LTS、OpenSSH 10.2 或 7.0 kernel。「版本號變大了」不是修改服務客戶之伺服器的理由。

符合下列任一情況時,不要直接進行原地升級:

  • 你從未開啟供應商的主控台(VNC 或 serial)並透過主控台登入。SSH 故障時,該主控台是重新存取伺服器的唯一方式。等到被鎖在外面才發現主控台無法使用,就已經太晚。
  • 你無法負擔 1 小時的停機時間,而且沒有 rollback。
  • 你的軟體堆疊依賴尚未針對 resolute 發布套件的第三方 repository。
  • 這台伺服器是超過 2 年前手動建置的,而且沒有人知道其中有哪些設定或軟體。

通常更好的做法是建立全新的 26.04 VPS,安裝軟體堆疊並還原資料,確認新伺服器正常回應後再切換 DNS。你可以讓舊伺服器持續運作,直到新伺服器證實穩定為止;需要 rollback 時,只要變更 DNS,不必還原備份。若採用這種方式,請先從新 VPS 的前 10 分鐘開始,正確建置新的伺服器。

步驟 1:先建立可還原的備份

使用兩層備份,因為它們可能以不同方式失效。供應商快照涵蓋整個磁碟,可在幾分鐘內還原,但建立快照時資料庫仍可能正在寫入,因此它只能確保當機一致性,不能確保應用程式一致性。使用 儲存在伺服器外部的 restic 建立檔案層級備份,可取得單一檔案,也能保留一份在帳戶遭鎖定後仍可存取的副本。

先手動傾印資料庫。未停止資料庫時,只有傾印檔是你可以信任的資料庫備份。

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction 只有在資料表使用 InnoDB 時,才能建立一致的傾印。MyISAM 資料表則需要先停止資料庫。/etc tarball 才是你實際會使用的檔案,因為它包含升級程序即將要求你確認的所有設定檔。

從未還原過的備份只是一個猜測。現在就從備份中取出一個檔案,避免日後在壓力下才需要測試。

先完整修補 24.04

do-release-upgrade 不會在套件狀態損壞的系統上執行,而尚未完成修補的 24.04 會讓後續所有錯誤更難判讀。

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit 沒有輸出表示沒有套件處於半設定狀態。apt-mark showhold 沒有輸出表示沒有套件被鎖定在會阻止升級的版本。使用 sudo apt-mark unhold 和套件名稱解除列出的鎖定;或者確認該鎖定有其原因,然後停在這裡。

如果核心有變更,請重新開機。這樣升級時,系統會執行其認為目前正在執行的程式碼。

[ -f /var/run/reboot-required ] && sudo reboot

接著檢查磁碟空間。升級程式會先下載整套新套件,再開始安裝。如果空間不足,便會中止,並在訊息中指出不足的檔案系統。

df -h / /boot

/ 可用空間低於約 5 GB 時,通常會在這裡失敗。/boot 小於 300 MB 時,稍後安裝核心會失敗,並顯示 No space left on device。通常原因是舊核心;使用 sudo apt --purge autoremove 可清除舊核心。

開始前還要先停止另一項工作:如果 自動安全性更新 在升級過程中執行,會持有 dpkg 鎖定,導致版本升級程式以 Could not get lock /var/lib/dpkg/lock-frontend 中止。先執行 sudo systemctl stop unattended-upgrades,完成後再重新啟動升級。

步驟 3:檢查第三方套件庫與鎖定套件

do-release-upgrade 會停用所有非 Ubuntu 的 apt 來源,因為為 noble 建置的套件可能會使 resolute 系統故障。之後,它會重新啟用能辨識的來源,並將其餘來源保留為註解狀態。在工具替你決定之前,先了解目前系統中有哪些外加內容。

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 在該目錄中使用兩種格式:舊式單行 .list 檔案,以及含有 Types:Suites: 欄位的 deb822 .sources 檔案。升級程序會停用這兩種格式。ubuntu-security-status --thirdparty 會列出沒有任何 Ubuntu 封存庫提供的已安裝套件,這是你額外安裝內容的實際數量。/etc/apt/preferences.d/ 中的任何項目都是 pin,而針對 noble 撰寫的 pin 會在新版本上持續選用舊套件。

對每個第三方套件庫,請先確認供應商已針對新的代號發布套件,再開始升級。Docker 的套件組位於 https://download.docker.com/linux/ubuntu/dists/,其他供應商也會提供相同的目錄。若來源指向不存在的套件組,升級後第一次執行 apt update 時會出現以下訊息:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

在供應商發布套件之前,請保持該來源停用。將代號修改為供應商確實建置過的其他代號,會導致你安裝到連結錯誤系統函式庫的套件。

步驟 4:在 tmux 中執行升級,不要使用一般的 SSH shell

如果 do-release-upgrade 在一般登入 shell 中執行時連線中斷,該程序會收到 SIGHUP,並在解包過程中途終止。這會使 dpkg 僅完成部分設定,也可能導致伺服器的網路堆疊無法正常運作,讓您無法重新連線。請改在終端機多工器中執行,這樣即使用戶端中斷連線,程序仍會在伺服器上繼續執行。

sudo apt install -y tmux
tmux new -s upgrade

在該工作階段中:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

升級程式會先在變更任何內容前,於 port 1022 啟動第二個 SSH daemon,並顯示相關訊息:

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.

它不會替您在防火牆中開啟該 port,因為未經詢問就修改防火牆規則可能造成問題。開始前,請自行開啟 1022;完成 sudo ufw delete allow 1022/tcp 後再關閉該 port。請注意,您的供應商可能會在控制面板中另外執行第二層防火牆,該防火牆位於伺服器之外。

如果連線仍然中斷,請重新登入並執行 tmux attach -t upgrade。升級程序會在您離線期間持續執行。

步驟 5:審慎回答設定檔提示

dpkg 只會針對你或腳本修改過的檔案提出提示。因此,每個提示都代表你曾刻意編輯過的檔案。按下 Enter 讓提示消失,可能會讓已強化的伺服器在無聲無息間恢復成預設設定。

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 ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

每次都先按下 D。查看變更內容,然後使用 N 保留你的版本。預設選項已是 N,這是安全的答案,因為你的檔案目前可正常運作,而套件提供的版本從未在這台機器上執行過。

保留你的檔案也有代價:你不會取得新的預設設定。等系統恢復運作後,再進行比對與整合,不要在時間壓力下處理。

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

每個列出的檔案都是維護者版本,會儲存在你的檔案旁邊。逐一比較差異,並將重要設定複製過去。以下兩項需要特別謹慎:/etc/ssh/sshd_config,因為選錯會中斷你的工作階段;以及 Web 伺服器設定,因為選錯會使網站停止運作。

升級程序也會透過 needrestart 詢問要重新啟動哪些服務。接受完整清單。若 daemon 仍使用已從磁碟刪除的共用函式庫檔案,稍後處理某個請求時可能會當機,而那時你可能沒有監控系統。

步驟 6:重新開機,然後檢查機器

sudo reboot

機器重新啟動後:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a 應回報 Release: 26.04Codename: resoluteuname -r 應顯示 7.0 核心。systemctl --failed 應列出 0 個單元;若列出任何項目,請將其作為下一個處理項目。最後執行 apt update,以取得發行映像檔建立後發布的更新。

PostgreSQL 16 到 18:悄悄停留在舊版本的叢集

Ubuntu 24.04 隨附 PostgreSQL 16,26.04 隨附 PostgreSQL 18。升級程序會將 18 安裝在 16 旁邊,但不會搬移資料。Debian 的 postgresql-common 層會在下一個可用的埠上,為新的主要版本建立空白叢集,因此 16 會保留埠 5432 及所有資料,而 18 則位於 5433 且沒有資料。應用程式會繼續連線到 5432,表面上不會出現任何問題,因此許多人直到數個月後才發現。

pg_lsclusters

列出兩個叢集表示尚未完成遷移。請在可以停止應用程式時進行:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

先刪除空白的 18 叢集,因為 pg_upgradecluster 不會寫入已存在的目標叢集。預設方法會傾印 16,再將資料重新載入 18,因此需要約等同於資料庫大小的可用磁碟空間。-m upgrade 會改用 pg_upgrade,處理大型資料庫時速度快得多。完成後,查看 Port 欄位:新的叢集會接管 5432,而舊叢集則會維持停止狀態。請自行執行 analyze 階段,因為剛載入的叢集沒有統計資料,初次查詢會很慢。

讓應用程式連線到新的叢集進行幾天測試。之後才移除舊叢集:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

舊叢集的資料目錄是最快的復原方式。不要在升級當天刪除它。

MySQL 8.0 至 8.4:遭移除的選項會阻止伺服器啟動

26.04 將 MySQL 從 8.0 升級至 8.4 LTS,其中有兩項變更可能導致伺服器出問題。

首先,mysqld 的設定檔若包含新版已移除的選項,便會拒絕啟動。default_authentication_plugin 是常見選項,因為許多舊版指南都要求設定它。服務會啟動失敗,而 journalctl -u mysql -n 50 會直接指出未知的變數。請從 /etc/mysql/mysql.conf.d/ 下的檔案刪除該行,然後執行 sudo systemctl start mysql

其次,mysql_native_password plugin 在 8.4 中不再預設啟用,因此仍使用該 plugin 的帳戶完全無法登入。請在仍使用 8.0 時檢查:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

在升級前,先移轉所有顯示 mysql_native_password 的帳戶,然後更新應用程式設定中的密碼:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

如果 client library 太舊,無法使用 caching_sha2_password,可以在 8.4 中透過於 [mysqld] 下加入 mysql_native_password=ON,重新啟用舊版 plugin。這只能作為有期限的過渡措施,因為該 plugin 最終將會完全淘汰。

PHP 8.3 到 8.5:您的 vhost 指向已不存在的 socket

24.04 提供 PHP 8.3,26.04 提供 PHP 8.5。套件會安裝到包含版本號的路徑,而且不會改寫您的 Web 伺服器設定。若 nginx vhost 中的 fastcgi_pass unix:/run/php/php8.3-fpm.sock; 現在指向沒有任何程序建立的 socket,所有 PHP 請求都會回傳 502,nginx error log 會顯示:

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

將它改為指向新的 socket,測試設定後重新載入:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

使用 Apache 搭配 mod_php 時,症狀不同:Apache 完全無法啟動,sudo apache2ctl -t 會回報無法載入 libphp8.3.so,因為該檔案不存在。已啟用的模組是指向已移除套件的 symlink。

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

如果您是依照 在 Ubuntu 24.04 上建立 LAMP stack 建置伺服器,這兩個路徑都值得檢查,因為該指南會留下包含版本號的模組名稱與 socket。

您的 php.ini 調校設定也不會自動沿用。memory_limitupload_max_filesize 及其他設定都位於 /etc/php/8.3/,新的目錄樹會使用預設值。請比較兩個檔案,並手動複製所需值。若直接將整個舊檔案覆寫到新檔案,會把 8.3 的預設值帶入 8.5 安裝。接著執行 php -m 並進行比較:以 php8.3-redis 安裝的擴充功能需要其 php8.5- 套件;如果擴充功能來自 PPA,升級程式會停用該來源,擴充功能也就會直接缺少。

憑證需要另外檢查一次。升級後執行 sudo certbot renew --dry-run。這會測試完整的續期流程,包括 Web 伺服器重新載入 hook,但不會修改目前使用中的憑證。如果 hook 呼叫的服務名稱或 binary 已變更,問題會在這裡直接顯現,而不是在 60 天後無聲失敗。在 nginx 上使用 Certbot 搭配 Let's Encrypt 說明這些 hook 應如何設定。

SSH:導致目前工作階段中斷的故障

sshd_config 提示是最容易讓管理員失去連線的地方。回答 Y 會安裝維護者提供的檔案,並捨棄你的 PermitRootLoginPasswordAuthenticationAllowUsersPort 以及其他自行加入的每一行設定。如果防火牆只允許自訂連接埠,而套件提供的設定檔監聽 22,下一次連線就會遭到拒絕,而你目前使用的工作階段將成為最後一個可用的工作階段。

請在升級前預防這個問題。24.04 的 /etc/ssh/sshd_config 會先載入 Include /etc/ssh/sshd_config.d/*.conf,而 OpenSSH 對每項設定都採用第一次讀取到的值,因此,位於頂端的 drop-in 設定會覆寫下方的設定。請將設定移至 dpkg 不管理的檔案:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

只要 /etc/ssh/sshd_config 中不再有任何自訂內容,該提示就不再重要:無論選擇哪個回答,都會保留你的設定,因為設定已位於另一個檔案中。

自訂連接埠還需要進行另一項檢查,因為它可能不在你以為的位置:

systemctl is-enabled ssh.socket

如果輸出 enabled,表示 systemd 管理監聽連接埠,而 sshd_config 中的 Port 行會被忽略。自 22.10 起,Ubuntu 便對 sshd 使用 socket activation,這就是為何修改 Port 2222 後看似沒有作用。請改在 socket unit 上設定,使用 sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

空白的 ListenStream= 是必要設定。它會清除繼承的值;若缺少此設定,socket 會同時監聽 22 和 2222。請使用 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket 套用設定。

升級完成後,在關閉目前工作階段前:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

接著在自己的電腦上開啟第二個終端機,再次登入。第二個終端機中能正常取得 shell,才是唯一有效的確認方式。在確認前,請保持第一個工作階段開啟。VPS 上的 SSH 強化設定 會說明這個 drop-in 中值得保留的設定。

如果現在已經太晚,服務商提供的 Web console 可讓你使用完全不透過 SSH 的登入方式。請從該處登入、修正設定、執行 sudo sshd -t,再重新啟動服務。這正是要在升級前測試 console 存取權,而不是等到升級期間才測試的原因。

FAQ

為什麼在 Ubuntu 24.04 上執行 do-release-upgrade 會顯示「No new release found」?

因為在 Ubuntu Server 上,/etc/update-manager/release-upgrades 包含 Prompt=lts;此設定會等下一個長期支援版本的第一個 point release 發行後,才提供該版本。Ubuntu 26.04 LTS 已於 23 April 2026 發行,而 26.04.1 預定於 27 August 2026 發行。在該日期前,24.04 伺服器不會找到新版本。請保留原設定,不要切換為 Prompt=normal,否則系統會改經由 interim releases 升級。

我必須重新開機才能完成升級嗎?

是。升級會安裝新的 kernel、新的 C library 及新的 init system;執行中的系統在重新啟動前仍會使用舊版本。do-release-upgrade 會在結尾要求重新開機。如果讓機器持續執行到「稍後」,系統就會同時使用兩個版本的元件。重新開機後,請檢查 uname -r 以確認新的 kernel,並檢查 systemctl --failed 以找出未能正常啟動的服務。

我應該直接升級,還是建立全新的 26.04 伺服器?

可以的話,請建立全新的伺服器。新的 VPS 讓你能在舊伺服器仍持續處理網路流量時,安裝服務堆疊、還原資料並測試所有功能。因此,回復作業只需變更 DNS,不必從備份還原。若伺服器保存難以搬遷的狀態、供應商依機器數量計費,或你已有 snapshot 且確認能使用主控台存取,則可直接升級。直接升級的流程已有充分實務驗證,但在執行期間,這是一條無法回頭的路徑。

如果我的 SSH 連線在升級期間中斷,會發生什麼事?

在一般 login shell 中,程序會收到 SIGHUP 並在升級中途結束,導致 dpkg 只完成部分設定。請在 tmuxscreen 中啟動升級程序。這樣程序會持續執行,你重新連線後即可執行 tmux attach -t upgrade 繼續升級。升級程式也會在 port 1022 上啟動備用 SSH daemon,提供第二種存取方式;但它不會為該埠開放防火牆規則。因此,請先自行允許 1022,完成後再關閉該埠。

升級後我的 PHP 網站回傳 502。哪裡出問題?

PHP FPM socket 路徑會隨版本變更。Ubuntu 24.04 執行 PHP 8.3,而 26.04 執行 PHP 8.5,因此 /run/php/php8.3-fpm.sock 已不存在,但你的 nginx vhost 仍指定該路徑。nginx error log 會顯示 connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)。請將 fastcgi_pass 更新為 8.5 socket,執行 sudo nginx -t,然後重新載入 nginx。若使用 Apache 搭配 mod_php,對應的修正方式是執行 sudo a2dismod php8.3,接著執行 sudo a2enmod php8.5 並重新啟動 Apache。