Nâng cấp Ubuntu 24.04 lên 26.04 trên VPS

Khi nào có thể nâng cấp Ubuntu 24.04 lên 26.04?

Bạn có thể nâng cấp Ubuntu 24.04 lên 26.04 trên VPS ngay bây giờ. Từ ngày 29 September 2026, khi Canonical bật nâng cấp từ 24.04 LTS, do-release-upgrade trên server 24.04 sẽ cung cấp 26.04.1. Ubuntu 26.04 LTS (Resolute Raccoon) được phát hành vào ngày 23 April 2026, nhưng Canonical chỉ mở đường nâng cấp từ LTS lên LTS sau khi bản point release đầu tiên xuất hiện. Bản đó tích hợp các lỗi cài đặt và nâng cấp được phát hiện trong những tháng đầu. Lần này, thời gian chờ kéo dài quá thời điểm phát hành point release: 26.04.1 được phát hành vào ngày 27 August 2026, và Canonical giữ nâng cấp lại thêm vài tuần để đưa vào các backport dự kiến sửa lỗi hồi quy trong phiên bản gần đây của rust-coreutils. Nếu cách đánh số này còn mới với bạn, 26.04.1 không phải là một Ubuntu khác mà là cùng bản 26.04 với bốn tháng bản sửa lỗi được tích hợp vào media, và đó chính là lý do đây là phiên bản đầu tiên Canonical cung cấp cho server hiện có.

Trước ngày 29 September, chạy lệnh kiểm tra trên một máy 24.04 sẽ cho kết quả như sau:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Đó không phải là lỗi trên server. Nếu hôm nay bạn vẫn thấy thông báo này, hãy kiểm tra setting mà nó phụ thuộc vào. /etc/update-manager/release-upgrades chứa Prompt=lts trên Ubuntu Server. Điều này có nghĩa là tool chỉ cung cấp bản long term support tiếp theo, và chỉ khi Canonical đã mở đường nâng cấp đến bản đó. Dù vậy, hãy giữ setting này ở lts, vì trên một bản phát hành mới hơn, normal cũng sẽ cung cấp các phiên bản interim có thời gian hỗ trợ ngắn. Trong thời gian chờ, Canonical cung cấp do-release-upgrade -d cho những ai không muốn chờ; giờ đây đường nâng cấp đã mở, command không có tùy chọn bổ sung là command được nêu trong thông báo dành cho server. Hãy đọc những thay đổi trong 26.04.1 và thời điểm đường nâng cấp được mở trước khi bắt đầu. Server vẫn chạy 22.04 không thể nâng cấp trực tiếp lên bản này, vì upgrader chỉ cung cấp LTS tiếp theo. Do đó, nâng cấp 22.04 lên 26.04 thông qua 24.04 trình bày bước nâng cấp đầu tiên và snapshot cần tạo trước bước thứ hai.

Mỗi command bên dưới đều do bạn tự chạy trên server của mình, theo đúng thứ tự được nêu. Không thể diễn tập release upgrade trên chính máy đang được nâng cấp. Quá trình này thay kernel và C library, đồng thời cần reboot để hoàn tất.

Bạn có thực sự cần nâng cấp không?

Ubuntu 24.04 nhận các bản cập nhật bảo mật tiêu chuẩn đến năm 2029, vì vậy một máy chủ production đang hoạt động ổn định không chịu áp lực về thời hạn. Hãy nâng cấp nếu bạn cần các tính năng mà 26.04 mang lại: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 hoặc kernel 7.0. "Số phiên bản tăng lên" không phải là lý do để can thiệp vào một máy chủ đang phục vụ khách hàng.

Đừng thực hiện nâng cấp tại chỗ (in-place upgrade) nếu có bất kỳ điều kiện nào sau đây:

• Bạn chưa từng mở console của nhà cung cấp (VNC hoặc serial) và đăng nhập qua đó. Console đó là cách duy nhất để truy cập lại máy chủ nếu SSH bị hỏng, và việc phát hiện nó không hoạt động khi bạn đã bị khóa bên ngoài là quá muộn.
• Bạn không thể chấp nhận một giờ downtime và không có phương án rollback.
• Stack của bạn phụ thuộc vào một repository của bên thứ ba chưa phát hành phiên bản cho resolute.
• Máy chủ được cấu hình thủ công trong hơn hai năm và không ai nắm rõ những gì đang chạy trên đó.

Phương án thay thế thường tốt hơn: dựng một VPS 26.04 mới, cài đặt stack và khôi phục dữ liệu, sau đó trỏ lại DNS khi máy chủ mới phản hồi chính xác. Bạn vẫn giữ máy chủ cũ chạy cho đến khi máy chủ mới chứng minh được sự ổn định, và việc rollback chỉ đơn giản là thay đổi DNS thay vì phải khôi phục dữ liệu. Nếu chọn cách này, hãy bắt đầu với mười phút đầu tiên trên một VPS mới và xây dựng máy chủ mới một cách bài bản.

Bước 1: tạo một bản sao lưu có thể khôi phục

Dùng hai lớp sao lưu vì chúng có các cách hỏng khác nhau. Snapshot của nhà cung cấp bao phủ toàn bộ disk và khôi phục trong vài phút, nhưng được tạo khi database đang ghi dữ liệu. Vì vậy, snapshot chỉ nhất quán theo crash, không nhất quán theo ứng dụng. Bản sao lưu cấp file bằng restic, lưu ngoài server cho phép khôi phục từng file và có một bản sao vẫn tồn tại nếu account của bạn bị khóa.

Trước tiên, hãy tự dump các database. Dump là một cách sao lưu database đang chạy.

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 chỉ tạo dump nhất quán cho các bảng InnoDB. Các bảng MyISAM cần được lock để tạo dump nhất quán. Tarball /etc là thứ bạn sẽ thực sự dùng đến, vì nó chứa mọi file cấu hình mà quá trình nâng cấp sắp yêu cầu bạn trả lời.

Bản sao lưu mà bạn chưa từng khôi phục chỉ là một phỏng đoán. Hãy lấy ngay một file ra khỏi bản sao lưu đó, trước khi bạn cần nó trong lúc xử lý sự cố gấp.

Bước 2: cập nhật 24.04 hoàn toàn trước

do-release-upgrade từ chối chạy trên hệ thống có trạng thái package bị lỗi. Một hệ thống 24.04 mới được cập nhật dở dang sẽ khiến mọi lỗi phát sinh sau đó khó đọc hơn.

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

dpkg --audit không in gì nghĩa là không có package nào đang ở trạng thái cấu hình dở dang. apt-mark showhold không in gì nghĩa là không có package nào bị dpkg hold. Lệnh này không hiển thị các APT preference pin. Đây là cơ chế riêng và cũng có thể giữ package lại; Bước 3 sẽ kiểm tra chúng. Gỡ mọi hold được showhold liệt kê bằng sudo apt-mark unhold và tên package. Hoặc chấp nhận rằng hold đó có lý do và dừng tại đây.

Nếu kernel đã thay đổi, hãy reboot. Như vậy, quá trình nâng cấp chạy trên máy đang thực sự chạy code mà máy cho rằng nó đang chạy.

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

Tiếp theo, kiểm tra dung lượng đĩa. Trình nâng cấp sẽ tải toàn bộ bộ package mới trước khi cài đặt bất kỳ package nào. Nếu không đủ dung lượng, nó sẽ dừng và nêu tên filesystem bị thiếu chỗ.

df -h / /boot

Kernel cũ thường là nguyên nhân. sudo apt --purge autoremove sẽ xóa chúng.

Trước khi bắt đầu, cần dừng thêm một thứ: nếu các bản cập nhật bảo mật tự động chạy giữa chừng, chúng sẽ giữ dpkg lock, và trình nâng cấp bản phát hành sẽ dừng với Could not get lock /var/lib/dpkg/lock-frontend. Chạy sudo systemctl stop unattended-upgrades trước, rồi khởi động lại quá trình sau khi lệnh hoàn tất.

Bước 3: kiểm tra repository bên thứ ba và các package được pin

Mặc định, do-release-upgrade sẽ comment mọi apt source không phải của Ubuntu, vì package được build cho noble có thể làm hỏng hệ thống resolute. Tùy chọn --allow-third-party của lệnh này giữ các source đó ở trạng thái bật, nên mang đúng rủi ro đó. Hãy biết mình đang giữ lại những gì trước khi để công cụ tự quyết định.

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 sử dụng 2 định dạng trong thư mục đó: file .list dạng một dòng kiểu cũ và file .sources deb822 có các trường Types: và Suites:. Nâng cấp mặc định sẽ vô hiệu hóa cả 2 loại. ubuntu-security-status --thirdparty liệt kê các package đã cài mà không có archive Ubuntu nào cung cấp. Đây là con số thực tế về những package bạn đã cài thêm. File trong /etc/apt/preferences.d/ chỉ được đọc như một pin nếu tên file không có extension hoặc kết thúc bằng .pref, đồng thời chỉ chứa chữ cái, chữ số, dấu gạch ngang, dấu gạch dưới và dấu chấm. APT sẽ bỏ qua mọi file khác, thường kèm theo một thông báo. Pin chỉ định noble có thể giữ package ở phiên bản cũ sau khi nâng cấp. Điều này phụ thuộc vào những phiên bản còn khả dụng và priority mà pin đặt ra. Vì vậy, hãy đọc từng file và quyết định xem nó còn cần thiết hay không.

Với mỗi repository bên thứ ba, hãy xác nhận vendor đã phát hành repository cho codename mới trước khi bắt đầu. Các suite của Docker được liệt kê tại https://download.docker.com/linux/ubuntu/dists/. Các vendor khác cũng cung cấp cùng thư mục này. Source trỏ đến một suite không tồn tại sẽ tạo ra lỗi sau lần apt update đầu tiên sau khi nâng cấp:

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

Docker hiện đã phát hành suite resolute. Hãy giữ disabled mọi source có suite bị thiếu cho đến khi vendor phát hành suite đó. Sửa codename thành một suite mà vendor đã build là cách khiến bạn cài các package liên kết với system library không đúng.

Bước 4: chạy quá trình nâng cấp trong tmux, không chạy trực tiếp trong shell SSH

Trình nâng cấp server thường chạy bên trong GNU screen và hỗ trợ kết nối lại sau khi kết nối bị ngắt. Vì vậy, việc mất kết nối SSH không tự nó làm quá trình nâng cấp dừng lại. Hãy chạy trình nâng cấp bên trong một tmux session riêng của bạn. Như vậy, bạn có một session có tên để kết nối lại.

sudo apt install -y tmux
tmux new -s upgrade

Bên trong session đó:

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

Trình nâng cấp khởi động một SSH daemon thứ hai trên port 1022 trước khi thay đổi bất kỳ thứ gì, và thông báo điều này:

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.

Trình nâng cấp không tự mở firewall cho port đó. Tự ý mở một lỗ trên firewall mà không hỏi trước sẽ gây bất ngờ và không an toàn. Hãy tự mở port 1022 trước khi bắt đầu, rồi đóng port này khi hoàn tất với sudo ufw delete allow 1022/tcp. Lưu ý rằng nhà cung cấp có thể chạy thêm một firewall trong control panel, nằm bên ngoài server.

Nếu kết nối vẫn bị ngắt, hãy đăng nhập lại và chạy tmux attach -t upgrade. Quá trình nâng cấp vẫn tiếp tục chạy trong lúc bạn rời đi. Nếu quá trình này không tiếp tục và bạn quay lại với dpkg được cấu hình dở dang hoặc các apt sources chỉ được cấu hình một phần trong noble và một phần trong resolute, khôi phục sau khi nâng cấp release thất bại hướng dẫn cách sửa trạng thái package và xác định khi nào nên dừng sửa để khôi phục snapshot thay thế.

Bước 5: trả lời cẩn thận các prompt về file cấu hình

dpkg chỉ hỏi về những file mà bạn hoặc một script đã thay đổi. Vì vậy, mỗi prompt đều liên quan đến một file đã bị bạn hoặc một script thay đổi. Nhấn Enter sẽ giữ phiên bản hiện tại theo mặc định.

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] ?

Mỗi lần, hãy nhấn D trước. Đọc các thay đổi, sau đó quyết định giữ phiên bản của bạn bằng N hay cài phiên bản của maintainer. Mặc định đã là N, nhưng giữ file cũ không an toàn với mọi package: một số thay đổi cấu hình là bắt buộc để hệ thống sau khi nâng cấp hoạt động.

Giữ file của bạn có một cái giá: bạn không nhận được các giá trị mặc định mới. Hãy đối chiếu sau khi hệ thống đã hoạt động và bạn không còn chịu áp lực thời gian.

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

Mỗi file được liệt kê là phiên bản của maintainer và được lưu cạnh file của bạn. Hãy diff từng file một và chép các thiết lập cần thiết sang. Có 2 file cần đặc biệt cẩn thận: /etc/ssh/sshd_config, vì chọn sai sẽ kết thúc session của bạn, và file cấu hình web server, vì chọn sai sẽ làm các site ngừng hoạt động.

Từ Ubuntu 24.04, needrestart mặc định tự động restart các service bị ảnh hưởng. Nếu bạn đã khôi phục chế độ tương tác, hãy chấp nhận toàn bộ danh sách. Một daemon vẫn đang dùng shared library cũ sẽ tiếp tục có nguy cơ gặp các bug mà bản update đã sửa cho đến khi daemon được restart.

Bước 6: reboot, sau đó kiểm tra máy

sudo reboot

Khi máy khởi động lại:

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 phải báo cáo Release: 26.04 và Codename: resolute. uname -r phải hiển thị kernel 7.0. systemctl --failed phải liệt kê 0 unit. Nếu có unit được liệt kê, đó là việc tiếp theo bạn cần xử lý. apt update cuối cùng sẽ làm mới các package index, sau đó apt full-upgrade cài đặt mọi bản cập nhật được phát hành kể từ khi quá trình upgrade tải các package.

PostgreSQL 16 lên 18: cluster âm thầm bị bỏ lại phía sau

Ubuntu 24.04 đi kèm PostgreSQL 16 và 26.04 đi kèm PostgreSQL 18. Quá trình nâng cấp cài PostgreSQL 18 cạnh PostgreSQL 16 nhưng không di chuyển dữ liệu. Layer postgresql-common của Debian chỉ tạo cluster chính khi cài server package nếu chưa có cluster nào. Vì vậy, cluster PostgreSQL 16 hiện có không tự động có thêm một cluster PostgreSQL 18 rỗng trên port 5433. Ứng dụng vẫn tiếp tục kết nối đến 5432 và không có gì bất thường, nên nhiều người chỉ phát hiện ra sau vài tháng.

pg_lsclusters

Một entry cho version 16 có nghĩa là cluster đó vẫn đang chạy trên version 16. Nếu pg_lsclusters cũng liệt kê một cluster 18 main, hãy xác nhận cluster đó rỗng trước khi xóa bằng sudo pg_dropcluster --stop 18 main, vì pg_upgradecluster sẽ không ghi vào target cluster đã tồn tại. Hãy thực hiện quá trình migration khi bạn có thể dừng ứng dụng:

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

Phương thức mặc định dump cluster 16 rồi load lại vào cluster 18, nên bạn cần lượng disk space trống xấp xỉ kích thước database. -m upgrade dùng pg_upgrade thay thế và nhanh hơn nhiều với database lớn. Khi hoàn tất, hãy đọc cột Port: cluster mới tiếp quản port 5432 và cluster cũ được để ở trạng thái stopped. Upgrade hook đi kèm package tự động chạy một lượt analyze; command ở trên chạy lại bước này một cách tường minh.

Hãy test ứng dụng với cluster mới trong vài ngày. Chỉ sau đó mới xóa cluster cũ:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Data directory của cluster cũ là phương án rollback nhanh nhất bạn có. Không được xóa nó vào ngày nâng cấp.

MySQL 8.0 lên 8.4: tùy chọn bị xóa khiến server không khởi động

26.04 nâng MySQL từ 8.0 lên 8.4 LTS. Hai thay đổi có thể làm server gặp lỗi.

Đầu tiên, mysqld sẽ không khởi động nếu file cấu hình chứa tùy chọn đã bị phiên bản mới xóa. default_authentication_plugin là tùy chọn thường gặp nhất, vì nhiều hướng dẫn cũ yêu cầu đặt tùy chọn này. Service fail và journalctl -u mysql -n 50 sẽ ghi rõ biến không xác định. Xóa dòng đó khỏi file bên dưới /etc/mysql/mysql.conf.d/, rồi sudo systemctl start mysql.

Thứ hai, plugin mysql_native_password không còn được bật mặc định trong 8.4. Vì vậy, account vẫn sử dụng plugin này sẽ không thể đăng nhập. Hãy kiểm tra khi bạn vẫn đang dùng 8.0:

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

Chuyển mọi account hiển thị mysql_native_password trước khi nâng cấp. Sau đó cập nhật password trong cấu hình ứng dụng:

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

Nếu client library quá cũ và không hỗ trợ caching_sha2_password, bạn có thể bật lại plugin cũ trong 8.4 bằng cách thêm mysql_native_password=ON bên dưới [mysqld]. Chỉ xem đây là giải pháp tạm thời và phải có thời hạn kết thúc, vì MySQL đã xóa plugin này trong 9.0.

PHP 8.3 lên 8.5: vhost của bạn trỏ đến socket đã bị xóa

24.04 đi kèm PHP 8.3 và 26.04 đi kèm PHP 8.5. Các package được cài vào các đường dẫn theo phiên bản, và không có thành phần nào tự sửa cấu hình web server. Vhost nginx chứa fastcgi_pass unix:/run/php/php8.3-fpm.sock; giờ trỏ đến một socket mà không tiến trình nào tạo, nên mọi request PHP đều trả về 502 và error log của nginx ghi:

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

Trỏ nó đến socket mới, kiểm tra cấu hình rồi reload:

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

Với Apache dùng mod_php, triệu chứng khác: Apache hoàn toàn không khởi động, và sudo apache2ctl -t báo không thể load libphp8.3.so vì file này không tồn tại. Module đã enable là một symlink đến package đã bị xóa.

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

Nếu bạn dựng máy theo stack LAMP trên Ubuntu 24.04, cần kiểm tra cả hai đường dẫn trên, vì hướng dẫn để lại cho bạn tên module và socket theo phiên bản.

Các thiết lập php.ini cũng không được giữ lại. memory_limit, upload_max_filesize và mọi thiết lập khác bạn đặt nằm trong /etc/php/8.3/, còn tree mới bắt đầu với các giá trị mặc định. So sánh hai file bằng diff rồi chép các giá trị sang thủ công. Chép toàn bộ file cũ đè lên file mới sẽ đưa các giá trị mặc định của 8.3 vào bản cài đặt 8.5. Sau đó chạy php -m và so sánh: extension được cài dưới dạng php8.3-redis cần package php8.5- tương ứng, và nếu extension đến từ một PPA thì trình nâng cấp đã disable source đó, khiến extension đơn giản là bị thiếu.

Certificate cần được kiểm tra riêng. Chạy sudo certbot renew --dry-run --run-deploy-hooks sau khi nâng cấp. Lệnh này kiểm tra toàn bộ quy trình renewal, bao gồm cả hook reload web server, mà không tác động đến certificate đang dùng. Nếu hook gọi một service name hoặc binary đã thay đổi, lỗi sẽ xuất hiện ngay ở đây thay vì âm thầm xảy ra trong lần renewal tiếp theo. Certbot với Let's Encrypt trên nginx giải thích hook nên có dạng như thế nào.

SSH: lỗi làm kết thúc session bạn đang sử dụng

Prompt sshd_config là nơi người dùng thường tự khóa mình khỏi server. Trả lời Y sẽ cài file của maintainer, xóa PermitRootLogin, PasswordAuthentication, AllowUsers, Port và mọi dòng khác bạn đã thêm. Nếu firewall chỉ cho phép một port tùy chỉnh nhưng config được đóng gói lại listen trên 22, kết nối tiếp theo sẽ bị từ chối và session bạn đang sử dụng sẽ là session cuối cùng còn truy cập được.

Hãy ngăn lỗi này trước khi upgrade. /etc/ssh/sshd_config trên 24.04 bắt đầu bằng Include /etc/ssh/sshd_config.d/*.conf. Với hầu hết setting, OpenSSH giữ giá trị đầu tiên nó đọc được, nên file drop-in được include ở đầu sẽ có hiệu lực thay cho cùng setting ở phía dưới. Một số keyword là ngoại lệ: Port và ListenAddress chấp nhận nhiều giá trị. Vì vậy, một dòng Port trong drop-in sẽ thêm một port thay vì thay thế port được đặt ở phía dưới. Chuyển các setting của bạn vào một file không thuộc quyền sở hữu của 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

Khi không còn gì trong /etc/ssh/sshd_config thuộc về bạn, prompt đó không còn quan trọng: dù chọn câu trả lời nào, các setting của bạn vẫn được giữ nguyên vì chúng nằm trong một file khác.

Custom port cần thêm một bước kiểm tra vì nó có thể không nằm ở nơi bạn nghĩ:

systemctl is-enabled ssh.socket

Nếu lệnh đó in ra enabled, systemd sẽ mở listening port chứ không phải sshd. Ubuntu đã dùng socket activation cho sshd từ 22.10. Trên 24.04, một systemd generator đọc các setting Port và ListenAddress từ config của sshd rồi chuyển chúng thành các listen address của socket, nhưng chỉ khi systemd reload các unit. Vì vậy, chỉnh sửa Port 2222 có vẻ không có tác dụng: thay đổi chỉ có hiệu lực sau sudo systemctl daemon-reload && sudo systemctl restart ssh.socket, và file sshd_config được đóng gói hiện đã có ghi chú về điều này. Nếu muốn đặt port trực tiếp trên socket unit, hãy dùng sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Dòng ListenStream= trống là bắt buộc. Dòng này xóa giá trị được kế thừa. Nếu thiếu, socket sẽ listen trên cả 22 và 2222. Áp dụng thay đổi bằng sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Sau khi upgrade, trước khi đóng session hiện tại:

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

Sau đó mở terminal thứ hai trên máy của bạn và đăng nhập lại. Một shell hoạt động trong terminal thứ hai là bằng chứng duy nhất có giá trị. Giữ session đầu tiên mở cho đến khi xác nhận được điều này. Hardening SSH trên VPS trình bày các setting nên giữ trong file drop-in đó.

Nếu đã quá muộn, web console của nhà cung cấp cho phép bạn đăng nhập mà không dùng SSH. Đăng nhập tại đó, sửa config, chạy sudo sshd -t rồi restart service. Chính vì vậy, hãy kiểm tra quyền truy cập console trước khi upgrade, thay vì chờ đến lúc upgrade mới kiểm tra.

FAQ

Vì sao do-release-upgrade báo "No new release found" trên Ubuntu 24.04?

Từ ngày 29 September 2026 thì không nên còn như vậy, vì đó là ngày Canonical bật nâng cấp từ 24.04 LTS lên 26.04.1. Trước thời điểm đó, thông báo này là bình thường: Ubuntu 26.04 LTS được phát hành vào 23 April 2026, bản 26.04.1 tiếp theo vào 27 August, và đường nâng cấp vẫn bị đóng thêm vài tuần trong khi Canonical backport các bản sửa lỗi cho các hồi quy của rust-coreutils. Nếu vẫn thấy thông báo này, hãy kiểm tra /etc/update-manager/release-upgrades có chứa Prompt=lts hay không. Đây là giá trị mặc định của Ubuntu Server và chỉ cung cấp bản long term support tiếp theo. Giữ nguyên giá trị lts.

Tôi có phải reboot server để hoàn tất nâng cấp không?

Có. Quá trình nâng cấp cài kernel mới, C library mới và init system mới. Hệ thống đang chạy vẫn dùng các thành phần cũ cho đến khi restart. do-release-upgrade yêu cầu reboot ở cuối quá trình. Một máy vẫn chạy đến "sau" là một máy đang dùng lẫn các thành phần của hai bản phát hành. Sau khi máy hoạt động trở lại, hãy kiểm tra uname -r để xác nhận kernel mới và systemctl --failed để tìm các service không khởi động lại được.

Tôi nên nâng cấp tại chỗ hay dựng server 26.04 mới?

Khi có thể, hãy dựng mới. VPS mới cho phép bạn cài stack, khôi phục dữ liệu và kiểm tra mọi thứ trong khi server cũ vẫn phục vụ traffic. Khi đó, rollback chỉ cần đổi DNS thay vì khôi phục từ backup. Hãy nâng cấp tại chỗ khi server chứa state khó di chuyển, khi provider tính phí theo từng máy, hoặc khi bạn có snapshot và quyền truy cập console đã được kiểm tra. Quy trình nâng cấp tại chỗ đã được sử dụng rộng rãi, nhưng trong khoảng thời gian nó chạy, đây là thao tác một chiều.

Điều gì xảy ra nếu kết nối SSH bị ngắt trong lúc nâng cấp?

Trình nâng cấp server thường dùng GNU screen, nên việc kết nối SSH bị ngắt không tự nó làm dừng quá trình nâng cấp. Nếu bạn đã khởi chạy nó bên trong tmux session có tên ở trên, hãy kết nối lại và chạy tmux attach -t upgrade để tiếp tục. Trình nâng cấp cũng khởi động một SSH daemon dự phòng trên port 1022 để cung cấp cách truy cập thứ hai. Tuy nhiên, nó không mở firewall cho port này, nên trước tiên bạn phải tự cho phép port 1022 và đóng port này sau đó.

Site PHP của tôi trả về 502 sau khi nâng cấp. Thành phần nào đã hỏng?

Đường dẫn socket của PHP FPM đã thay đổi theo version. Ubuntu 24.04 chạy PHP 8.3, còn 26.04 chạy PHP 8.5, nên /run/php/php8.3-fpm.sock không còn tồn tại trong khi nginx vhost vẫn trỏ đến đường dẫn đó. Nginx error log hiển thị connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Cập nhật fastcgi_pass để dùng socket 8.5, chạy sudo nginx -t, rồi reload nginx. Với Apache dùng mod_php, cách sửa tương đương là sudo a2dismod php8.3, sau đó chạy sudo a2enmod php8.5 và restart.