Cách sửa lỗi do-release-upgrade không tìm thấy bản mới

Vì sao do-release-upgrade báo không tìm thấy bản phát hành mới

do-release-upgrade kết thúc bằng No new release found. hầu như không bao giờ là do công cụ bị hỏng. Đường nâng cấp bạn yêu cầu đang bị đóng tại thời điểm đó, và công cụ báo lại theo cách ngắn gọn nhất. Có 5 nguyên nhân khiến đường này bị đóng: thiết lập Prompt trong /etc/update-manager/release-upgrades, điều kiện point release khi nâng cấp LTS (long term support), các repository bên thứ ba, package bị giữ hoặc cấu hình chưa hoàn tất, và bản phát hành đã hết thời hạn hỗ trợ.

Hãy kiểm tra theo đúng thứ tự đó. Mỗi nguyên nhân đều có một command để xác nhận nó có áp dụng cho server của bạn hay không, vì vậy bạn không phải đoán mình đang gặp nguyên nhân nào trong 5 nguyên nhân trên.

Cờ chỉ kiểm tra thực sự báo cáo gì

sudo do-release-upgrade -c
echo $?

-c chỉ thực hiện kiểm tra. Nó đọc metadata bản phát hành của Canonical qua HTTPS (hypertext transfer protocol secure) rồi in kết quả. Nó không tải công cụ nâng cấp và không ghi đè tệp source. Có 2 kết quả cần chú ý:

Checking for a new Ubuntu release
No new release found.

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

Exit code cũng chứa cùng kết quả để script sử dụng. Giá trị là 0 khi có bản phát hành mới và 1 khi không có, ngược với quy ước shell thông thường. Vì vậy, hãy đọc kỹ trước khi dùng nó để xây dựng một bước kiểm tra.

Nếu banner đăng nhập vẫn hiển thị kết quả cũ thì kết quả đó đã được cache. Dòng này lấy từ /etc/update-motd.d/91-release-upgrade, lệnh này in kết quả đã lưu thay vì truy vấn network. Làm mới kết quả bằng sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, hoặc chỉ cần tin vào -c. Banner chỉ lặp lại kết quả của lần kiểm tra gần nhất.

Lệnh kiểm tra cũng cần kết nối đến changelogs.ubuntu.com. Nếu server nằm sau outbound firewall nghiêm ngặt hoặc proxy mà tool không thể truy cập, nó sẽ không thể hỏi và không tìm thấy bản phát hành mới.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Dòng HTTP/2 200 có nghĩa là server đã đọc được metadata. Dòng curl: (28) Connection timed out có nghĩa là nguyên nhân thực sự nằm ở các quy tắc egress. Không chỉnh sửa bao nhiêu tệp APT (advanced package tool) cũng không thay đổi được kết quả.

Nếu không tìm thấy command này, nó nằm trong ubuntu-release-upgrader-core. Một số cloud image tối giản đôi khi không cài package đó.

sudo apt install ubuntu-release-upgrader-core

Đọc /etc/update-manager/release-upgrades trước khi thay đổi bất cứ điều gì

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

File này có phần tài liệu riêng trong các comment. Có 3 giá trị hợp lệ:

• never: không bao giờ kiểm tra và không bao giờ cho phép nâng cấp lên bản phát hành mới.
• normal: đề xuất bản phát hành được hỗ trợ ngay sau bản đang chạy.
• lts: đề xuất bản phát hành LTS đầu tiên sau bản đang chạy.

Prompt=never là trường hợp dễ chẩn đoán nhất trong 3 trường hợp, vì công cụ sẽ nêu cả file và setting trong output:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Nhà cung cấp hosting và các công cụ quản lý cấu hình đặt never một cách có chủ đích để ngăn cả fleet tự chuyển sang các bản phát hành khác nhau. Nếu thấy giá trị này ở đó, nghĩa là đã có người chọn nó. Đổi thành lts cho server cần theo track long-term support, rồi khôi phục lại sau đó nếu automation của bạn yêu cầu giá trị cũ.

Có một chi tiết trong các comment này thường khiến người dùng nhầm lẫn. Khi đặt Prompt=lts và bản phát hành đang chạy không phải LTS, upgrader sẽ xử lý setting này như normal. Trên máy chạy 25.10, hai giá trị này hoạt động giống hệt nhau. Trên máy chạy 24.04, chúng không giống nhau, và khác biệt đó là toàn bộ nội dung của section tiếp theo.

Vì sao quá trình nâng cấp từ một bản LTS lên bản LTS tiếp theo phải chờ bản point release đầu tiên

Prompt quyết định trình nâng cấp đọc file metadata nào. Các địa chỉ nằm trong /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts đọc meta-release-lts. Prompt=normal đọc meta-release. Cả hai file đều mô tả mọi bản release bằng một nhóm key nhỏ, và trình nâng cấp chỉ đề xuất một bản release khi cờ Supported: của bản đó là 1. Bạn có thể tự đọc các file này từ chính server đó:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Kiểm tra vào ngày 13 tháng 8 năm 2026 cho thấy hai file có thông tin khác nhau về Ubuntu 26.04. File LTS ghi:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

File thông thường ghi:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Giá trị Supported: 0 trong file LTS là điều kiện chặn. Server 24.04 dùng Prompt=lts mặc định sẽ đọc file đó, không tìm thấy bản LTS mới hơn được đánh dấu là khả dụng, rồi hiển thị No new release found. Máy của bạn không có lỗi. Canonical chưa mở đường nâng cấp này.

Cờ này sẽ đổi thành 1 khi bản point release đầu tiên được phát hành. Ubuntu 26.04.1 dự kiến phát hành vào ngày 27 tháng 8 năm 2026, nhưng lịch phát hành có thể thay đổi, vì vậy hãy kiểm tra metadata thay vì chỉ dựa vào lịch. Việc trì hoãn là có chủ ý: những người nâng cấp sớm sẽ phát hiện các lỗi chặn, rồi các lỗi đó được sửa trước khi số lượng lớn server LTS thực hiện nâng cấp.

Bạn có hai lựa chọn phù hợp. Chờ bản point release, đây là lựa chọn đúng cho mọi server mà bạn không muốn phải theo dõi sát. Hoặc đặt Prompt=normal để công cụ này đọc meta-release, nơi Ubuntu 26.04 đã được đánh dấu là được hỗ trợ. Cách thứ hai sẽ nâng cấp lên Ubuntu 26.04 đã phát hành, không phải bản development, nên có thể chấp nhận trên một máy mà bạn có thể khôi phục từ snapshot. Đặt giá trị về lts sau khi hoàn tất. Quy trình từng bước nằm trong hướng dẫn đầy đủ về nâng cấp server từ 24.04 lên 26.04.

Các repository bên thứ ba và PPA chặn quá trình nâng cấp

Trình nâng cấp viết lại các nguồn APT để trỏ đến bản phát hành mới. Nó chỉ làm được việc này với repository có phát hành gói cho bản phát hành mới, nên mọi nguồn khác sẽ bị comment out. Lý do được in thành một dòng cho mỗi mục và nêu cụ thể: was disabled (unknown mirror), was disabled (unknown dist) và was disabled (no Release file).

PPA (personal package archive) được build cho noble không có thư mục resolute trên server. Vì vậy, trình nâng cấp không thể tải file Release cho series mới và sẽ vô hiệu hóa mục này. Thông thường, đây chỉ là cảnh báo mà bạn có thể chấp nhận. Vấn đề trở thành lỗi chặn khi một repository bên thứ ba cung cấp package mà bản phát hành mới cũng có, vì khi đó quá trình tính toán nâng cấp có hai candidate và không thể thỏa mãn cả hai.

Hãy tự quyết định việc này trước khi bắt đầu, thay vì để tool tự quyết định trong một lần chạy dài không cần giám sát.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy trên tên package sẽ in ra repository cung cấp từng phiên bản đã cài, để bạn biết chính xác package nào phụ thuộc vào source sắp bị vô hiệu hóa. Xóa source không downgrade package, nên package được cài từ PPA vẫn giữ phiên bản từ PPA và có thể mới hơn phiên bản mà bản phát hành mới cung cấp. Nếu điều này gây vấn đề, hãy xóa package đó rồi cài lại từ archive sau khi nâng cấp. Với repository dự định bật lại, chẳng hạn repository của Tailscale, bạn cần cập nhật codename sang bản phát hành mới trước khi package có thể cài lại. Đây là nguyên nhân của phần lớn lỗi cài đặt Tailscale trên Ubuntu.

Có một flag cho lựa chọn ngược lại. Trang manual mô tả --allow-third-party là "Thử nâng cấp với các mirror và repository bên thứ ba được bật thay vì comment out chúng." Chỉ dùng flag này sau khi xác nhận repository đã phát hành package cho bản phát hành đích. Nếu chưa, bạn đang yêu cầu APT giải quyết dependency graph cho một series mà repository đó chưa từng build package.

Trên Ubuntu 24.04 trở lên, phần lớn source nằm trong /etc/apt/sources.list.d/ubuntu.sources và dùng định dạng deb822. Cùng một repository được khai báo ở cả định dạng cũ và mới sẽ tạo ra một lỗi riêng với thông báo riêng, được trình bày trong lỗi khai báo source trùng lặp ở định dạng deb822.

Các package bị giữ và cấu hình dở dang sẽ làm phép tính thất bại

Một lần nâng cấp bản phát hành phải di chuyển gần như mọi package trên hệ thống. Nếu một package không thể di chuyển, phép tính sẽ thất bại. Trình nâng cấp sẽ dừng sớm thay vì để hệ thống ở trạng thái nâng cấp dở dang. Hai lệnh sau giúp tìm nguyên nhân.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold in các package bị giữ, mỗi package một dòng, và không in gì trên hệ thống sạch. Hold là chỉ thị thủ công yêu cầu không bao giờ thay đổi package đó. Có thể ai đó đã pin một phiên bản kernel hoặc database rồi quên bỏ pin. Bỏ hold cho những package không còn cần giữ bằng sudo apt-mark unhold theo sau là tên package.

dpkg --audit liệt kê các package đã được unpack nhưng chưa được cấu hình. Trạng thái này thường do một lần cài đặt bị gián đoạn, phổ biến nhất là khi session bị ngắt. Trình nâng cấp sẽ cố sửa trạng thái đó và in dpkg interrupted, calling dpkg --configure -a, nhưng tự chạy bước sửa trước giúp bạn đọc được lỗi thay vì để lỗi trôi qua trên màn hình. Nếu công cụ không thể sửa một package, nó sẽ in thông báo Package in inconsistent state. Package đó cần được xử lý trước khi thử lại.

Hãy cập nhật đầy đủ bản phát hành đang chạy trước khi nâng cấp.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

Tùy chọn phased updates quan trọng hơn bạn nghĩ. Ubuntu triển khai một số bản cập nhật cho từng phần trăm máy chủ theo từng đợt, vì vậy apt upgrade thông thường có thể để lại một số package chưa được cập nhật. Khi đó, server kém mới hơn bạn tưởng. Tùy chọn này sẽ cài tất cả các bản cập nhật đó. Sau đó hãy reboot nếu trong số đó có kernel, để quá trình nâng cấp chạy trên kernel mà hệ thống thực sự đang sử dụng. Một máy đã tự duy trì bản vá thông qua các bản nâng cấp bảo mật không cần giám sát sẽ có ít việc hơn ở bước này, dù cơ chế đó cố ý không vượt qua ranh giới giữa các bản phát hành.

Khi bản release đã quá thời hạn hỗ trợ tiêu chuẩn

Một bản release interim của Ubuntu được hỗ trợ trong chín tháng. Khi thời hạn hỗ trợ kết thúc, cờ Supported: của bản đó chuyển thành 0, và quy trình thông thường không cung cấp đường nâng cấp từ bản này. Được kiểm tra vào ngày 13 tháng 8 năm 2026, meta-release ghi như sau về 25.10:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

Archive cũng được chuyển cùng lúc. Các package của bản release đã hết vòng đời bị xóa khỏi archive.ubuntu.com và được giữ tại old-releases.ubuntu.com. Vì vậy apt update bắt đầu trả về 404 Not Found, hệ thống không thể được cập nhật lên trạng thái hiện tại, và vì upgrader yêu cầu hệ thống phải đang ở trạng thái hiện tại nên không có gì tiếp tục được. Trước tiên, hãy sửa các source.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Trỏ cả archive.ubuntu.com và security.ubuntu.com đến old-releases.ubuntu.com, đồng thời giữ nguyên codename. Chỉ hostname thay đổi.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Thay vào đó, hãy chạy cùng command với /etc/apt/sources.list nếu server của bạn vẫn lưu các source trong file duy nhất đó. Tùy chọn -i.bak ghi một bản backup cạnh file gốc, để bạn có thể khôi phục nếu chỉnh sửa nhầm file. Nếu apt update sau đó chạy thành công, archive đã có thể truy cập trở lại và do-release-upgrade sẽ có thể hoạt động.

Hãy thực tế về mức độ mà cách này có thể đưa bạn đi. Ubuntu chỉ hỗ trợ nâng cấp từng release một, vì vậy server chậm hơn hai hoặc ba release đã hết vòng đời sẽ phải đi qua từng bước, và mỗi bước có thể tự thất bại do repository bên thứ ba riêng hoặc package bị giữ riêng. Trên VPS, thường nhanh hơn nếu dựng server mới trên LTS hiện tại, chuyển service sang đó và giữ server cũ cho đến khi bạn chắc chắn mọi thứ hoạt động. Cách này cũng cung cấp rollback, điều mà nâng cấp in-place không bao giờ có. Nếu sau đó bạn đang chọn nên sử dụng track nào, sự khác nhau giữa LTS và release interim trên server đáng để đọc trước khi quyết định.

Flag development release thực sự làm gì

-d hoặc --devel-release khiến trình nâng cấp đọc meta-release-development thay vì file mà Prompt đã chọn. Trang hướng dẫn mô tả flag này như sau: "Nếu đang dùng release được hỗ trợ mới nhất, hãy nâng cấp lên development release."

Kiểm tra vào ngày 13 August 2026, entry mới nhất trong file đó không phải là 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Vì vậy, -d không nâng cấp server 24.04 lên bản 26.04 đã phát hành. Nó nhắm đến 26.10, một release vẫn đang được xây dựng. Khuyến cáo cũ về việc "chỉ cần thêm -d" được viết cho khoảng thời gian trước khi một LTS được phát hành. Lặp lại khuyến cáo đó hiện nay sẽ trỏ server của bạn đến một release không đúng với mục đích. Khi Prompt=lts vẫn còn, flag sẽ dừng và hiển thị thông báo riêng:

There is no development version of an LTS available.

Tài liệu server của Ubuntu nêu rõ về flag này: "không nên dùng development release (hoặc flag -d) trong môi trường production". Development release thay đổi mỗi ngày và không có cam kết hỗ trợ bảo mật. Vì vậy, một package hoạt động vào buổi sáng có thể làm hỏng service vào buổi chiều. Hãy dùng nó trên một virtual machine tạm thời được tạo riêng để kiểm thử cấu hình của bạn. Không dùng nó trên server mà người khác phụ thuộc vào. Khi cần bản 26.04 đã phát hành trước khi LTS gate mở, Prompt=normal là cách đúng.

Chạy nâng cấp trong môi trường mà việc mất kết nối SSH không thể làm gián đoạn

Nâng cấp release thay thế phần lớn hệ thống, bao gồm openssh-server và systemd. Nếu phiên SSH (secure shell) bị ngắt trong khi dpkg đang chạy, tiến trình sẽ bị kill khi các package mới chỉ được giải nén nhưng chưa được cấu hình. Đây chính là trạng thái khiến lần thử tiếp theo bị dừng. Luôn bắt đầu quá trình nâng cấp bên trong một terminal multiplexer.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Nếu kết nối bị ngắt, hãy đăng nhập lại rồi chạy tmux attach -t upgrade. Quá trình nâng cấp vẫn tiếp tục vì nó là tiến trình con của tmux server, không phải của phiên SSH. screen -S upgrade và screen -r upgrade cũng làm việc tương tự nếu bạn thích dùng screen.

Tool nâng cấp có cơ chế an toàn riêng cho những người không dùng multiplexer. Khi phát hiện đang chạy bên trong SSH, nó đề nghị khởi động một sshd thứ hai trên port 1022, để phiên chính bị hỏng vẫn còn một đường truy cập. Nó xác định điều này bằng cách duyệt các tiến trình cha của chính nó để tìm một tiến trình tên sshd. Bên trong tmux hoặc screen, quá trình tìm kiếm đó gặp multiplexer server thay thế, nên đề nghị này không xuất hiện. File pid /var/run/release-upgrader-sshd.pid chỉ được ghi khi daemon bổ sung thực sự khởi động. Nếu bạn không thấy prompt thì không có gì sai. Bạn đã có cơ chế bảo vệ tốt hơn.

Nếu bạn chấp nhận đề nghị này, port sẽ không tự động được mở. Tool thông báo rõ điều đó vì việc mở một port là quyết định bảo mật mà nó không được phép tự ý thực hiện thay bạn. Hãy mở port trong thời gian nâng cấp, rồi đóng lại sau đó.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

Hầu hết nhà cung cấp VPS chạy thêm một firewall trong control panel, nằm bên ngoài hệ điều hành. Port 1022 cũng phải được mở ở đó. Nếu không, fallback listener đang chạy nhưng không thể truy cập được, là tình huống tệ nhất.

Bạn cần chuẩn bị 4 việc trước khi nhập lệnh:

• Tạo snapshot hoặc backup đầy đủ. Nâng cấp release tại chỗ không có thao tác undo, và đây là bản sao duy nhất bạn có.
• Xác nhận bạn có thể mở console của nhà cung cấp trước khi cần dùng. Nếu server không khởi động lại sau reboot, SSH chính là thứ bạn sẽ không có. Kernel không boot được là một vấn đề riêng và có các bước khôi phục riêng, được trình bày trong VPS không khởi động sau khi cập nhật kernel.
• Kiểm tra dung lượng trống bằng df -h / /boot. Quá trình nâng cấp tải xuống toàn bộ package, và phân vùng /boot chứa nhiều kernel cũ thường là nơi quá trình bị kẹt.
• Đọc release note của các service bạn đang chạy. Việc nhảy major version của PostgreSQL hoặc PHP sẽ đi kèm release, dù bạn có dự định nâng cấp hay không.

FAQ

Vì sao do-release-upgrade báo không tìm thấy bản phát hành mới trên Ubuntu 24.04?

Giá trị mặc định của Prompt=lts trong /etc/update-manager/release-upgrades khiến công cụ đọc https://changelogs.ubuntu.com/meta-release-lts, và Ubuntu 26.04 giữ giá trị Supported: 0 trong tệp đó cho đến khi phát hành bản point release đầu tiên. Trình nâng cấp không tìm thấy bản phát hành LTS mới hơn được đánh dấu là khả dụng nên dừng lại. Tự kiểm tra tệp bằng curl -s https://changelogs.ubuntu.com/meta-release-lts rồi đọc block cuối cùng. Tại thời điểm kiểm tra ngày 13 August 2026, flag này vẫn là 0 và Ubuntu 26.04.1 được lên lịch phát hành vào 27 August 2026.

Đặt Prompt=normal thay vì chờ point release có an toàn không?

Cách này nâng cấp hệ thống lên 26.04 đã phát hành, không phải bản development, vì Prompt=normal đọc meta-release, trong đó 26.04 đã có giá trị Supported: 1. Rủi ro nằm ở thời điểm nâng cấp. Bạn thực hiện trước khi các vấn đề được những người nâng cấp sớm phát hiện được khắc phục. Chỉ thực hiện trên server có thể khôi phục từ snapshot và có thể truy cập provider console nếu reboot gặp lỗi. Sau đó đặt giá trị này về lts.

Flag -d có nâng cấp tôi lên 26.04 không?

Không. -d đọc meta-release-development, trong đó entry mới nhất vào ngày 13 August 2026 là Ubuntu 26.10, một bản phát hành vẫn đang trong quá trình development. Trên máy LTS có Prompt=lts, flag này in There is no development version of an LTS available. rồi dừng. Tài liệu server chính thức của Ubuntu không khuyến nghị bản development cho production, vì vậy hãy dùng Prompt=normal khi muốn nâng cấp sớm lên 26.04 đã phát hành.

apt update trả về lỗi 404 trên một bản phát hành cũ. Tôi phải nâng cấp thế nào?

Bản phát hành đó đã hết vòng đời hỗ trợ, nên các package của nó đã được chuyển từ archive.ubuntu.com sang old-releases.ubuntu.com. Chỉ thay đổi hostname trong /etc/apt/sources.list.d/ubuntu.sources hoặc trong /etc/apt/sources.list trên các layout cũ hơn, và giữ nguyên codename. Sau đó chạy sudo apt update và sudo apt full-upgrade. Khi hệ thống đã cập nhật đầy đủ, do-release-upgrade có thể nâng cấp hệ thống lên từng bản phát hành kế tiếp.

Tôi có cần xóa các PPA trước khi chạy do-release-upgrade không?

Bạn không bắt buộc phải làm vậy, vì trình nâng cấp sẽ comment out mọi source không publish package cho bản phát hành mới và in một dòng như was disabled (no Release file) cho từng source. Tự xử lý trước vẫn tốt hơn vì bạn kiểm soát được thứ tự và thấy rõ kết quả. Chạy apt policy trên các package cần kiểm tra để xác định package nào đến từ từng PPA, sau đó cài lại chúng từ archive nếu phiên bản trong PPA mới hơn phiên bản mà bản phát hành mới cung cấp.