Khi nào 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 sau khi bản point release 26.04.1 được phát hành, dự kiến vào ngày 27 tháng 8 năm 2026. Trước thời điểm đó, server 24.04 sẽ không nhận bản release mới, theo đúng thiết kế. Ubuntu 26.04 LTS (Resolute Raccoon) được phát hành vào ngày 23 tháng 4 năm 2026, nhưng Canonical chỉ mở đường nâng cấp từ LTS lên LTS ở bản point release đầu tiên. Bản release này 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.

Chạy kiểm tra trên máy 24.04 vào đầu tháng 8 năm 2026 sẽ cho kết quả sau:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Đây không phải là lỗi trên server của bạn. /etc/update-manager/release-upgrades chứa Prompt=lts trên Ubuntu Server. Điều này có nghĩa là công cụ chỉ cung cấp bản long term support tiếp theo, và chỉ sau khi bản point release .1 của bản đó tồn tại. Nếu đặt Prompt=normal, công cụ sẽ lần lượt hướng dẫn bạn qua 24.10, 25.04 và 25.10. Đây là các bản interim release đã hết vòng đời. Hãy giữ nguyên lts và chờ. Lịch của Canonical có thể thay đổi, vì vậy hãy kiểm tra lại nếu ngày dự kiến đã qua mà không có thông báo nào.

Bạn phải tự chạy từng command bên dưới trên server của mình, theo đúng thứ tự đã cho. Không thể diễn tập một lần nâng cấp release trên chính máy đang được nâng cấp. Quá trình này thay thế kernel và C library, đồng thời cần reboot để hoàn tất.

Có nên nâng cấp không?

Ubuntu 24.04 vẫn 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áy chủ production đang hoạt động không bị hạn chót nào. Hãy nâng cấp vì bạn cần một tính năng có trong 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 hoặc kernel 7.0. “Phiên bản tăng” không phải là lý do để can thiệp vào một máy đang phục vụ khách hàng.

Không nâng cấp tại chỗ 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 nếu SSH bị lỗi. Nếu đến lúc bị khóa ngoài máy mới phát hiện console không hoạt động thì đã 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 bên thứ ba chưa phát hành cho resolute.
• Máy chủ được cài thủ công từ hơn hai năm trước và không ai biết trên đó đang có những gì.

Giải pháp thay thế thường tốt hơn: tạo một VPS 26.04 mới, cài stack và khôi phục dữ liệu, sau đó chuyển DNS khi máy mới trả lời chính xác. Bạn giữ máy chủ cũ chạy cho đến khi máy mới hoạt động ổn định. Khi đó, rollback chỉ là thay đổi DNS thay vì khôi phục máy chủ. 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à cài đặt máy mới đúng cách.

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

Dùng hai lớp sao lưu vì chúng có cách lỗi 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 vẫn đang ghi dữ liệu. Vì vậy, snapshot chỉ nhất quán theo sự cố, 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à cung cấp một bản sao vẫn còn dùng được nếu tài khoản của bạn bị khóa.

Trước tiên, hãy dump database thủ công. Dump là bản sao lưu database duy nhất có thể tin cậy mà không cần dừng database.

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. Với bảng MyISAM, bạn phải dừng database. Tarball /etc là thứ bạn sẽ thực sự cần dùng, 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 kiểm tra và trả lời.

Một bản sao lưu chưa từng được khôi phục chỉ là phỏng đoán. Hãy lấy thử một file từ bản sao lưu ngay bây giờ, trước khi bạn cần đến nó trong tình huống khẩn cấp.

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

do-release-upgrade từ chối chạy trên hệ thống có trạng thái package bị lỗi, còn 24.04 được cập nhật dở dang sẽ khiến mọi lỗi về 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ị ghim vào một version khiến quá trình nâng cấp bị chặn. Gỡ hold cho mọi package được liệt kê bằng sudo apt-mark unhold và tên package, hoặc chấp nhận rằng hold đó tồn tại vì có lý do rồi dừng tại đây.

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

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

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

df -h / /boot

Khi dung lượng trống trên / còn dưới khoảng 5 GB, lỗi này thường xảy ra. /boot dưới 300 MB sẽ khiến quá trình cài kernel thất bại về sau với No space left on device. Kernel cũ thường là nguyên nhân, và sudo apt --purge autoremove sẽ xóa chúng.

Còn một việc cần dừng trước khi bắt đầu: 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 release sẽ dừng với Could not get lock /var/lib/dpkg/lock-frontend. Trước tiên hãy chạy sudo systemctl stop unattended-upgrades, sau đó khởi động lại quá trình khi lệnh hoàn tất.

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

do-release-upgrade vô hiệu hóa mọi apt source không thuộc Ubuntu, vì package được build cho noble có thể làm hỏng hệ thống resolute. Sau đó, công cụ bật lại các source mà nó nhận diện được và để các source còn lại ở trạng thái comment. Hãy biết rõ những gì bạn đang mang theo 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 đó: các file .list dạng một dòng kiểu cũ và các file .sources deb822 có các trường Types: và Suites:. Cả 2 loại đều bị vô hiệu hóa trong quá trình nâng cấp. 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ố chính xác về những package bạn đã tự thêm vào. Mọi mục trong /etc/apt/preferences.d/ đều là một pin, và pin được viết cho noble sẽ tiếp tục chọn package cũ trên bản release mới.

Với mỗi repository bên thứ ba, hãy xác nhận vendor đã publish 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 thư mục tương tự. Một source trỏ đến suite không tồn tại sẽ tạo ra lỗi sau trong 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.

Hãy để source đó ở trạng thái vô hiệu hóa cho đến khi vendor publish. Sửa codename thành một codename mà vendor đã build sẽ khiến bạn cài các package liên kết với những system library không đúng.

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

Nếu kết nối bị ngắt khi do-release-upgrade đang chạy trong shell login thông thường, tiến trình sẽ nhận SIGHUP và dừng giữa chừng trong lúc giải nén. Khi đó dpkg ở trạng thái cấu hình dở dang, đồng thời máy chủ có thể không còn network stack hoạt động để bạn kết nối lại. Thay vào đó, hãy chạy lệnh bên trong một terminal multiplexer để tiến trình vẫn tiếp tục trên server khi client của bạn bị ngắt kết nối.

sudo apt install -y tmux
tmux new -s upgrade

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 đó, vì tự ý mở một lỗ trên firewall mà không hỏi sẽ gây rủi ro không cần thiết. Hãy tự mở port 1022 trước khi bắt đầu và đóng port này sau 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 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 trong thời gian bạn không kết nối.

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 tương ứng với một file bạn đã chủ động chỉnh sửa. Nhấn Enter để bỏ qua prompt là cách khiến một server đã harden âm thầm trở về cấu hình 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 đều nhấn D trước. Đọc các thay đổi, sau đó giữ phiên bản của bạn bằng N. Mặc định đã là N, đây là lựa chọn an toàn vì file của bạn đang hoạt động và file trong package chưa từng chạy trên máy này.

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

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

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

Bản nâng cấp cũng hỏi cần restart service nào thông qua needrestart. Chấp nhận toàn bộ danh sách. Một daemon vẫn chạy với shared library đã bị xóa khỏi disk có thể crash ở một request sau đó, đúng lúc bạn không monitor nó.

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 hiển thị 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 nào được liệt kê thì đó là việc tiếp theo bạn cần xử lý. apt update cuối cùng sẽ tải các bản cập nhật được phát hành sau khi các image bản phát hành được build.

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

Ubuntu 24.04 phát hành PostgreSQL 16, còn 26.04 phát hành PostgreSQL 18. Bản nâng cấp cài PostgreSQL 18 cùng với 16 nhưng không di chuyển dữ liệu. Lớp postgresql-common của Debian tạo một cluster mới, rỗng, cho major version mới trên cổng còn trống tiếp theo. Vì vậy, PostgreSQL 16 vẫn dùng cổng 5432 với toàn bộ dữ liệu, còn PostgreSQL 18 chạy rỗng trên cổng 5433. Ứng dụng của bạn vẫn kết nối đến cổng 5432 và không có dấu hiệu bất thường. Vì thế nhiều người chỉ phát hiện ra việc này sau vài tháng.

pg_lsclusters

Nếu danh sách có hai cluster thì bạn chưa migrate. Hãy thực hiện khi có thể dừng ứng dụng:

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

Trước tiên, hãy xóa cluster 18 đang rỗng, vì pg_upgradecluster sẽ không ghi vào target cluster đã tồn tại. Phương thức mặc định dump cluster 16 rồi reload vào cluster 18, nên bạn cần dung lượng đĩa trống xấp xỉ kích thước database. -m upgrade dùng pg_upgrade thay cho phương thức đó 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 sẽ tiếp quản cổng 5432, còn cluster cũ sẽ được để ở trạng thái stopped. Hãy tự chạy bước analyze, vì cluster vừa được load chưa có statistics và các query đầu tiên sẽ chậm.

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ị loại bỏ khiến server không khởi động

26.04 nâng MySQL từ 8.0 lên 8.4 LTS, và có hai thay đổi thường khiến server gặp sự cố.

Thứ nhất, mysqld sẽ không khởi động nếu file cấu hình chứa một tùy chọn đã bị phiên bản mới loại bỏ. 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 ghi rõ tên biến không xác định. Xóa dòng đó khỏi file trong /etc/mysql/mysql.conf.d/, sau đó sudo systemctl start mysql.

Thứ hai, plugin mysql_native_password không còn được enable 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 vẫn đang chạy 8.0:

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

Di chuyển mọi account hiển thị mysql_native_password trước khi upgrade, 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ỉ nên xem đây là giải pháp tạm thời và đặt thời hạn loại bỏ, vì plugin này sẽ bị loại bỏ hoàn toàn.

PHP 8.3 lên 8.5: vhost của bạn trỏ đến socket đã không còn

24.04 phát hành kèm PHP 8.3 và 26.04 phát hành kèm PHP 8.5. Các package được cài vào các path có version 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 ra, nên mọi request PHP đều trả về 502 và nginx error log ghi:

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

Trỏ vhost đế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 sẽ không khởi động, và sudo apache2ctl -t báo không thể load libphp8.3.so vì file không tồn tại. Module được enable là symlink đến một package đã bị gỡ.

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 path này, vì hướng dẫn để lại cho bạn tên module có version và socket có version.

Thiết lập tuning trong 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 cây thư mục mới bắt đầu với các giá trị mặc định. Diff hai file rồi chép các giá trị cần thiết sang bằng tay. 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 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 bị thiếu.

Certificate cần được kiểm tra riêng. Chạy sudo certbot renew --dry-run sau khi nâng cấp. Lệnh này kiểm tra toàn bộ quy trình gia hạn, bao gồm hook reload web server, nhưng không tác động đến certificate đang được sử dụng. Nếu hook gọi một service name hoặc binary đã thay đổi, lỗi sẽ xuất hiện ngay tại đây thay vì âm thầm xảy ra sau 60 ngày. Certbot với Let's Encrypt trên nginx mô tả hook cầ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 tự khóa mình khỏi hệ thống. Trả lời Y sẽ cài file của maintainer, xóa PermitRootLogin, PasswordAuthentication, AllowUsers, Port của bạn 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 còn 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à OpenSSH giữ giá trị đầu tiên đọc được cho mỗi setting. Vì vậy, drop-in được include ở đầu sẽ được ưu tiên hơn mọi nội dung bên dưới. Chuyển các setting của bạn vào một file không do dpkg quản lý:

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 nội dung nào trong /etc/ssh/sshd_config do bạn tạo, prompt đó không còn quan trọng: chọn câu trả lời nào cũng giữ được setting của bạn vì chúng nằm trong file khác.

Nếu dùng port tùy chỉnh, cần kiểm tra thêm một bước vì port có thể không nằm ở nơi bạn nghĩ:

systemctl is-enabled ssh.socket

Nếu lệnh đó in ra enabled, systemd quản lý port đang listen và dòng Port trong sshd_config bị bỏ qua. Ubuntu đã dùng socket activation cho sshd từ 22.10. Đây là lý do việc sửa Port 2222 có vẻ không có tác dụng. Hãy đặt port trên socket unit bằng sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

ListenStream= để trống là bắt buộc. Nó xóa giá trị 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 việc này. Hardening SSH trên VPS trình bày các setting nên giữ trong 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 cần SSH. Đăng nhập tại đó, sửa config, chạy sudo sshd -t rồi restart service. Console đó chính là lý do bạn phải kiểm tra quyền truy cập console trước khi upgrade, thay vì đợi đế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?

Vì /etc/update-manager/release-upgrades chứa Prompt=lts trên Ubuntu Server, và thiết lập đó chỉ cung cấp bản phát hành long term support tiếp theo sau khi bản point release đầu tiên của nó đã có. Ubuntu 26.04 LTS được phát hành vào 23 April 2026, còn 26.04.1 dự kiến phát hành vào 27 August 2026. Trước ngày đó, server 24.04 sẽ không thấy bản phát hành nào. Giữ nguyên thiết lập này thay vì chuyển sang Prompt=normal, vì lựa chọn đó sẽ đưa hệ thống đi qua các bản phát hành interim.

Tôi có phải reboot server để hoàn tất quá trình 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 được restart. do-release-upgrade yêu cầu reboot khi kết thúc. Máy tiếp tục chạy đến "later" sẽ 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, 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 tạo server 26.04 mới?

Nếu có thể, hãy tạo server mới. VPS mới cho phép bạn cài stack, restore 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ì restore từ backup. Nâng cấp tại chỗ phù hợp 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à đã kiểm chứng quyền truy cập console. 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 chạy nâng cấp, bạn không thể quay lại dễ dàng.

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

Trong một login shell thông thường, process sẽ nhận SIGHUP và dừng giữa chừng, khiến dpkg bị cấu hình dở dang. Hãy chạy quy trình bên trong tmux hoặc screen để process tiếp tục chạy. Sau đó bạn 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 bạn phải tự allow port 1022 trước và close port này sau đó.

Website PHP của tôi trả về 502 sau khi nâng cấp. Thành phần nào bị lỗi?

Đườ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 sẽ 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à chạy sudo a2dismod php8.3, sau đó chạy sudo a2enmod php8.5 và restart Apache.