Cách nâng cấp Ubuntu 24.04 lên 26.04 trên VPS an toàn

Khi nào bạn 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 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. Cho đến lúc đó, máy chủ 24.04 sẽ không thấy bản phát hành mới, đây là thiết lập có chủ đích. 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 dẫn nâng cấp LTS lên LTS tại bản point release đầu tiên, vì bản này đã tổng 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 tiên. 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 phiên bản Ubuntu khác mà chính là 26.04 với bốn tháng sửa lỗi được tích hợp vào bộ cài, đây chính là lý do tại sao đó là phiên bản đầu tiên mà Canonical cung cấp cho một máy chủ đang hoạt động.

Chạy kiểm tra trên máy chủ 24.04 vào đầu tháng 8 năm 2026 và bạn sẽ nhận được kết quả này:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Đó không phải là lỗi trên máy chủ của bạn. /etc/update-manager/release-upgrades chứa Prompt=lts trên Ubuntu Server, nghĩa là công cụ này chỉ cung cấp phiên bản hỗ trợ dài hạn (LTS) tiếp theo, và chỉ khi bản point release .1 của nó đã tồn tại. Việc thiết lập Prompt=normal sẽ buộc bạn phải nâng cấp lần lượt qua 24.10, 25.04 và 25.10, các bản phát hành tạm thời đã kết thúc vòng đời. Hãy để nguyên lts và chờ đợi. Các ngày trong lịch trình của Canonical có thể thay đổi, vì vậy hãy kiểm tra lại nếu ngày đó trôi qua mà không có thông báo gì.

Mọi lệnh dưới đây đều do bạn tự chạy trên máy chủ của mình, theo đúng thứ tự được đưa ra. Việc nâng cấp phiên bản không thể thực hiện thử trên chính máy chủ bạn đang nâng cấp. Quá trình này thay thế kernel và thư viện C, đồng thời cần khởi động lại để 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 bản sao lưu mà bạn có thể khôi phục

Hãy sử dụng hai lớp sao lưu, vì chúng có các kiểu lỗi khác nhau. Snapshot từ nhà cung cấp bao phủ toàn bộ ổ đĩa và khôi phục trong vài phút, nhưng nó được thực hiện trong khi database đang ghi dữ liệu, nên nó chỉ đảm bảo tính nhất quán khi crash chứ không đảm bảo tính nhất quán ở cấp ứng dụng. Sao lưu cấp độ file với restic, lưu trữ bên ngoài máy chủ cho phép bạn lấy từng file riêng lẻ và có một bản sao an toàn ngay cả khi 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 duy nhất của database mà bạn có thể tin tưởng mà không cần dừng dịch vụ.

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 ra bản dump nhất quán cho các bảng InnoDB. Các bảng MyISAM cần phải dừng database mới sao lưu được. File tarball /etc là thứ bạn sẽ thực sự cần đế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 xác nhận.

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

Bước 2: patch hoàn toàn 24.04 trước

do-release-upgrade từ chối chạy trên hệ thống có trạng thái gói bị lỗi, và một bản 24.04 chưa patch hoàn chỉnh sẽ khiến mọi lỗi sau đó khó đọc hơn.

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

dpkg --audit nếu không in ra gì nghĩa là không có gói nào bị cấu hình dở dang. apt-mark showhold nếu không in ra gì nghĩa là không có gói nào bị ghim (pin) ở một phiên bản có thể chặn quá trình nâng cấp. Hãy giải phóng bất kỳ gói nào được liệt kê bằng sudo apt-mark unhold kèm tên gói, hoặc chấp nhận rằng việc giữ phiên bản đó là có lý do và dừng lại tại đây.

Reboot nếu kernel đã thay đổi, để bạn nâng cấp từ một máy đang chạy đúng mã nguồn mà nó nhận diện.

[ -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ộ tập hợp gói mới về trước khi cài đặt bất cứ thứ gì, và nó sẽ hủy bỏ với thông báo chỉ rõ filesystem nếu không đủ chỗ trống.

df -h / /boot

Dưới khoảng 5 GB trống trên / là ngưỡng dễ xảy ra lỗi. Một /boot dưới 300 MB sẽ gây lỗi sau đó, trong quá trình cài đặt kernel, với No space left on device. Các kernel cũ thường là nguyên nhân, và sudo apt --purge autoremove sẽ xóa chúng.

Một việc nữa cần dừng trước khi bắt đầu: nếu cập nhật bảo mật tự động chạy giữa chừng, chúng sẽ giữ khóa dpkg, và trình nâng cấp phiên bản sẽ dừng lại với Could not get lock /var/lib/dpkg/lock-frontend. Hãy chạy sudo systemctl stop unattended-upgrades trước và bắt đầu lại khi đã hoàn tất.

Bước 3: kiểm tra các repository của bên thứ ba và các gói đã được ghim (pinned)

do-release-upgrade vô hiệu hóa mọi nguồn apt không phải của Ubuntu, vì một gói được build cho noble có thể làm hỏng hệ thống resolute. Công cụ này sẽ kích hoạt lại các nguồn mà nó nhận diện được sau đó và để các nguồn còn lại ở trạng thái comment. Hãy biết rõ những gì bạn đang sử dụng trước khi công cụ tự quyết định thay cho bạn.

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 hai định dạng trong thư mục đó: định dạng một dòng .list cũ, và định dạng deb822 .sources với các trường Types: và Suites:. Cả hai đều bị vô hiệu hóa bởi quá trình nâng cấp. ubuntu-security-status --thirdparty liệt kê các gói đã cài đặt không thuộc kho lưu trữ nào của Ubuntu, đây là con số chính xác về những gì bạn đã thêm vào hệ thống. Bất kỳ thứ gì trong /etc/apt/preferences.d/ đều là một pin, và một pin được viết cho noble sẽ tiếp tục chọn một gói cũ trên bản phát hành mới.

Đối với mỗi repository của bên thứ ba, hãy xác nhận nhà cung cấp đã phát hành phiên bản cho codename mới trước khi bạn bắt đầu. Các suite của Docker được liệt kê tại https://download.docker.com/linux/ubuntu/dists/, và các nhà cung cấp khác cũng hiển thị thư mục tương tự. Một nguồn trỏ đến một suite không tồn tại sẽ gây ra lỗi này 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 để nguồn đó ở trạng thái vô hiệu hóa cho đến khi nhà cung cấp phát hành phiên bản mới. Việc sửa codename thành phiên bản mà nhà cung cấp đã build là cách bạn cài đặt các gói được liên kết với các thư viện hệ thống không phù hợp.

Bước 4: chạy nâng cấp trong tmux, không dùng SSH shell thông thường

Nếu kết nối của bạn bị ngắt trong khi do-release-upgrade đang chạy trong một login shell thông thường, tiến trình sẽ nhận tín hiệu SIGHUP và bị dừng đột ngột ngay trong quá trình giải nén. Điều này khiến dpkg bị cấu hình dở dang, và máy chủ có thể mất khả năng kết nối mạng để bạn truy cập lại. Hãy chạy lệnh trong một terminal multiplexer để tiến trình vẫn duy trì trên server ngay cả khi client của bạn bị ngắt kết nối.

sudo apt install -y tmux
tmux new -s upgrade

Bên trong phiên làm việc đó:

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

Trình nâng cấp sẽ khởi chạy một SSH daemon thứ hai trên cổng 1022 trước khi thực hiện bất kỳ thay đổi nào, và sẽ thông báo cho bạn:

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.

Nó không tự mở firewall cho cổng này, vì việc tự ý mở cổng trên firewall mà không hỏi trước là một hành động không an toàn. Hãy tự mở cổng 1022 trước khi bắt đầu, và đóng nó lại khi bạn đã hoàn tất với sudo ufw delete allow 1022/tcp. Lưu ý rằng nhà cung cấp VPS của bạn có thể có một lớp firewall thứ hai trong bảng điều khiển, nằm ngoài tầm kiểm soát của 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 lúc bạn mất kết nối. Nếu không, và khi quay lại bạn thấy dpkg đang ở trạng thái cấu hình dở dang hoặc các apt sources vừa ở noble vừa ở resolute, khôi phục sau khi nâng cấp bản phát hành thất bại sẽ 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ác prompt của file cấu hình một cách thận trọng

dpkg chỉ hiển thị prompt cho các file mà bạn hoặc một script đã thay đổi. Do đó, mỗi prompt đều là một file bạn đã chủ đích chỉnh sửa, và việc nhấn Enter để bỏ qua là cách khiến một server đã được hardening âm thầm trở về trạng thái 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] ?

Luôn nhấn D trước, mỗi lần như vậy. Hãy đọc những gì đã thay đổi, sau đó giữ lại phiên bản của bạn bằng N. Mặc định đã là N, đây là câu trả lời an toàn, vì file của bạn đang hoạt động tốt còn file từ package thì chưa từng chạy trên máy này.

Việc giữ lại file của bạn có một cái giá: bạn sẽ không nhận được các thiết lập mặc định mới. Hãy đối chiếu sau đó, khi hệ thống đã hoạt động ổn định và bạn không bị áp lực về 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 người duy trì package, được lưu cạnh file của bạn. Hãy diff từng file một và copy các thiết lập quan trọng sang. Có hai file cần đặc biệt lưu ý: /etc/ssh/sshd_config, vì câu trả lời sai sẽ kết thúc phiên làm việc của bạn, và cấu hình web server, vì câu trả lời sai sẽ làm các trang web ngừng hoạt động.

Quá trình nâng cấp cũng sẽ hỏi những service nào cần khởi động lại, thông qua needrestart. Hãy chấp nhận toàn bộ danh sách. Một daemon vẫn đang chạy dựa trên một file thư viện dùng chung đã bị xóa khỏi ổ đĩa sẽ crash ở một request nào đó sau này, vào lúc bạn không theo dõi.

Bước 6: khởi động lại, sau đó kiểm tra máy chủ

sudo reboot

Khi máy chủ khởi động xong:

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 sẽ báo Release: 26.04 và Codename: resolute. uname -r sẽ hiển thị kernel 7.0. systemctl --failed sẽ liệt kê zero unit, bất kỳ unit nào xuất hiện ở đây chính là việc bạn cần xử lý tiếp theo. Lệnh 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 release được build.

PostgreSQL 16 lên 18: cluster vẫn nằm lại phía sau

Ubuntu 24.04 cung cấp PostgreSQL 16 và 26.04 cung cấp PostgreSQL 18. Bản nâng cấp cài đặt phiên bản 18 bên cạnh phiên bản 16 và không di chuyển dữ liệu của bạn. Lớp postgresql-common của Debian tạo một cluster trống mới cho phiên bản major mới trên cổng trống tiếp theo, vì vậy phiên bản 16 vẫn giữ cổng 5432 với toàn bộ dữ liệu của bạn và phiên bản 18 nằm trống ở cổng 5433. Ứng dụng của bạn vẫn tiếp tục giao tiếp với cổng 5432 và không có gì bất thường, đó là lý do tại sao người dùng thường phát hiện ra điều này sau nhiều tháng.

pg_lsclusters

Việc liệt kê hai cluster nghĩa là bạn chưa thực hiện di chuyển. Hãy thực hiện việc này khi bạn 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 trống, vì pg_upgradecluster sẽ không ghi vào một cluster đích đã tồn tại. Phương pháp mặc định sẽ dump dữ liệu từ 16 và nạp lại vào 18, vì vậy bạn cần dung lượng đĩa trống xấp xỉ kích thước của cơ sở dữ liệu. -m upgrade sử dụng pg_upgrade thay thế và nhanh hơn nhiều trên các cơ sở dữ liệu lớn. Khi hoàn tất, hãy đọc cột Port: cluster mới sẽ tiếp quản cổng 5432 và cluster cũ sẽ bị dừng lại. Hãy tự chạy bước analyze, vì một cluster mới nạp dữ liệu chưa có thống kê và các truy vấn đầu tiên sẽ chạy chậm.

Kiểm tra ứ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

Thư mục dữ liệu của cluster cũ là phương án rollback nhanh nhất mà bạn có. Đừng xóa nó ngay trong 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 được

Bản 26.04 nâng cấp MySQL từ 8.0 lên 8.4 LTS, và có hai thay đổi thường gây lỗi cho server.

Đầu tiên, mysqld từ chối khởi động khi 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 phổ biến nhất, vì rất nhiều hướng dẫn cũ yêu cầu bạn thiết lập nó. Service sẽ bị lỗi, và journalctl -u mysql -n 50 sẽ chỉ đích danh biến không xác định đó. Hãy xóa dòng đó khỏi file nằm trong /etc/mysql/mysql.conf.d/, sau đó sudo systemctl start mysql.

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

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

Chuyển đổi mọi tài khoản hiển thị mysql_native_password trước khi nâng cấp, sau đó cập nhật mật khẩu trong cấu hình ứng dụng của bạn:

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

Nếu một thư viện client quá cũ không hỗ trợ caching_sha2_password, bạn có thể bật lại plugin cũ trong bản 8.4 bằng cách thêm mysql_native_password=ON vào dưới mục [mysqld]. Hãy coi đây là giải pháp tạm thời có thời hạn, vì plugin này đang dần bị loại bỏ hoàn toàn.

PHP 8.3 lên 8.5: vhost của bạn trỏ vào một socket không còn tồn tại

24.04 phát hành PHP 8.3 và 26.04 phát hành PHP 8.5. Các gói cài đặt vào những đường dẫn có đánh số phiên bản và không có tiến trình nào tự động cập nhật cấu hình web server của bạn. Một vhost nginx đang giữ fastcgi_pass unix:/run/php/php8.3-fpm.sock; giờ đây trỏ vào một socket mà không tiến trình nào tạo ra, vì vậy mọi request PHP đều trả về lỗi 502 và log lỗi của nginx ghi:

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

Hãy trỏ nó vào socket mới, kiểm tra cấu hình, sau đó 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

Trên Apache với mod_php, triệu chứng sẽ khác: Apache sẽ không khởi động được, và sudo apache2ctl -t báo lỗi không thể load libphp8.3.so vì file không tồn tại. Module đang được enable là một symlink trỏ đến một gói đã bị gỡ bỏ.

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

Nếu bạn xây dựng máy chủ từ một LAMP stack trên Ubuntu 24.04, cả hai đường dẫn này đều cần được kiểm tra, vì hướng dẫn đó để lại cho bạn tên module và socket có kèm phiên bản.

Cấu hình php.ini của bạn cũng không tự động chuyển sang. memory_limit, upload_max_filesize và bất kỳ thông số nào khác bạn đã thiết lập đều nằm trong /etc/php/8.3/, và cây thư mục mới sẽ bắt đầu với các giá trị mặc định. Hãy dùng lệnh diff để so sánh hai file và copy thủ công các giá trị cần thiết. Việc ghi đè toàn bộ file cũ lên file mới sẽ mang các giá trị mặc định của bản 8.3 vào bản cài đặt 8.5. Sau đó chạy php -m và so sánh: một extension được cài đặt dưới dạng php8.3-redis cần gói php8.5- tương ứng, và nếu nó đến từ một PPA, trình nâng cấp đã vô hiệu hóa nguồn đó và extension sẽ bị thiếu.

Chứng chỉ TLS cần được kiểm tra riêng. Hãy chạy sudo certbot renew --dry-run sau khi nâng cấp. Lệnh này thực hiện toàn bộ quy trình gia hạn, bao gồm cả hook reload web server, mà không làm ảnh hưởng đến chứng chỉ đang hoạt động. Một hook gọi tên service hoặc binary đã thay đổi sẽ bị lỗi ngay tại đây, giúp bạn phát hiện thay vì để nó lỗi âm thầm sau 60 ngày. Certbot với Let's Encrypt trên nginx mô tả các hook này nên trông như thế nào.

SSH: lỗi khiến phiên làm việc hiện tại bị ngắt

Dòng sshd_config prompt là nơi người dùng thường tự khóa quyền truy cập của chính mình. Việc chọn Y sẽ cài đặt file của nhà phát hành, ghi đè lên PermitRootLogin, PasswordAuthentication, AllowUsers, Port và mọi dòng khác mà bạn đã thêm vào. Nếu firewall của bạn chỉ cho phép một cổng tùy chỉnh nhưng cấu hình mặc định lại lắng nghe trên cổng 22, kết nối tiếp theo sẽ bị từ chối và phiên làm việc bạn đang dùng sẽ là phiên cuối cùng.

Hãy phòng ngừa trước khi nâng cấp. /etc/ssh/sshd_config trên 24.04 bắt đầu bằng Include /etc/ssh/sshd_config.d/*.conf, và OpenSSH ưu tiên giá trị đầu tiên mà nó đọc được cho mỗi thiết lập, vì vậy file drop-in đặt ở đầu sẽ ghi đè lên mọi thứ bên dưới. Hãy chuyển các thiết lập của bạn sang một file mà dpkg không 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 thiết lập cá nhân nào nằm trong /etc/ssh/sshd_config, dòng prompt đó không còn quan trọng nữa: dù bạn chọn phương án nào, các thiết lập của bạn vẫn được giữ nguyên vì chúng nằm ở một file khác.

Cổng tùy chỉnh cần kiểm tra thêm một bước, 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 đang quản lý cổng lắng nghe và dòng Port trong sshd_config sẽ bị bỏ qua. Ubuntu đã sử dụng socket activation cho sshd từ bản 22.10, đây là lý do tại sao việc chỉnh sửa Port 2222 dường như không có tác dụng. Hãy thiết lập nó trên socket unit bằng sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

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

Sau khi nâng cấp, trước khi đóng phiên làm việc hiện tại:

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

Sau đó, mở một terminal thứ hai trên máy của bạn và đăng nhập lại. Một shell hoạt động được trong terminal thứ hai mới là bằng chứng xác thực duy nhất. Hãy giữ phiên làm việc đầu tiên mở cho đến khi bạn làm được điều đó. Tăng cường bảo mật SSH trên VPS sẽ hướng dẫn các thiết lập cần thiết để giữ lại trong file drop-in đó.

Nếu đã quá muộn, console web của nhà cung cấp VPS sẽ cho bạn một quyền truy cập không thông qua SSH. Hãy đăng nhập vào đó, sửa lại cấu hình, chạy sudo sshd -t và khởi động lại dịch vụ. Console đó chính là lý do tại sao bạn cần kiểm tra quyền truy cập console trước khi nâng cấp thay vì đợi đến lúc đó mới làm.

FAQ

Tại 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 hỗ trợ dài hạn (LTS) tiếp theo sau khi bản point release đầu tiên của nó xuất hiện. Ubuntu 26.04 LTS được phát hành vào ngày 23 tháng 4 năm 2026, và bản 26.04.1 dự kiến ra mắt vào ngày 27 tháng 8 năm 2026. Cho đến ngày đó, máy chủ 24.04 sẽ không thấy bản cập nhật nào. Hãy giữ nguyên thiết lập đó thay vì chuyển sang Prompt=normal, vì tùy chọn này sẽ điều hướng bạn qua các bản phát hành trung gian.

Tôi có bắt buộc phải reboot máy chủ để hoàn tất nâng cấp không?

Có. Quá trình nâng cấp cài đặt kernel mới, thư viện C mới và hệ thống init mới; hệ thống đang chạy vẫn tiếp tục sử dụng các thành phần cũ cho đến khi khởi động lại. do-release-upgrade sẽ yêu cầu reboot khi kết thúc, và một máy chủ để chạy đến "lúc khác" là một máy chủ đang chạy hỗn hợp hai bản phát hành. Sau khi máy khởi động lại, hãy kiểm tra uname -r để xác nhận kernel mới và systemctl --failed để xem các dịch vụ không tự khởi động lại.

Tôi nên nâng cấp tại chỗ (in-place) hay dựng một máy chủ 26.04 mới?

Hãy dựng mới nếu có thể. Một VPS mới cho phép bạn cài đặt stack, khôi phục dữ liệu và kiểm thử mọi thứ trong khi máy chủ cũ vẫn đang phục vụ traffic, vì vậy việc rollback chỉ là thay đổi DNS thay vì khôi phục từ backup. Hãy nâng cấp tại chỗ khi máy chủ chứa trạng thái khó di chuyển, khi nhà cung cấp tính phí theo từng máy, hoặc khi bạn có snapshot và quyền truy cập console đáng tin cậy. Con đường nâng cấp tại chỗ đã được kiểm chứng, nhưng nó là một quá trình một chiều trong suốt thời gian thực hiện.

Chuyện gì xảy ra nếu kết nối SSH của tôi bị ngắt trong khi nâng cấp?

Trong một login shell thông thường, tiến trình sẽ nhận tín hiệu SIGHUP và chết giữa chừng, khiến dpkg bị cấu hình dở dang. Hãy bắt đầu quá trình bên trong tmux hoặc screen để tiến trình vẫn tồn tại, khi đó bạn chỉ cầ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 chạy một SSH daemon dự phòng trên cổng 1022 như một lối vào thứ hai, nhưng nó không tự mở firewall cho cổng đó, vì vậy hãy tự mở cổng 1022 trước và đóng nó lại sau khi xong.

Trang web PHP của tôi trả về lỗi 502 sau khi nâng cấp. Cái gì đã hỏng?

Đường dẫn socket của PHP FPM đã thay đổi theo phiên bản. Ubuntu 24.04 chạy PHP 8.3 và 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 của bạn vẫn đang trỏ tới đó. Error log của nginx sẽ hiển thị connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Hãy cập nhật fastcgi_pass thành socket 8.5, chạy sudo nginx -t, sau đó reload nginx. Trên Apache với mod_php, cách sửa tương tự là sudo a2dismod php8.3, theo sau là sudo a2enmod php8.5 và khởi động lại dịch vụ.