Sửa lỗi do-release-upgrade: no new release found

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ờ có nghĩa là công cụ bị lỗi. Đườ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 điều này theo cách ngắn gọn nhất. Có 5 nguyên nhân khiến đường nâng cấp 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 (hỗ trợ dài hạn), các repository bên thứ ba, package đang bị giữ hoặc chưa được cấu hình hoàn chỉnh, và bản phát hành đã hết thời hạn hỗ trợ.

Hãy kiểm tra theo đúng thứ tự này. 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. Lệnh này đọc metadata bản phát hành của Canonical qua HTTPS (hypertext transfer protocol secure) rồi in kết quả. Lệnh không tải công cụ nâng cấp và không ghi lại file source. Có 2 kết quả quan trọng:

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ả để dùng trong script. Giá trị là 0 khi có bản phát hành mới và 1 khi không có, trái với quy ước shell thông thường. Vì vậy, hãy đọc kỹ trước khi dùng kết quả này để xây dựng bước kiểm tra.

Nếu login banner 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. Hãy 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 truy cập được changelogs.ubuntu.com. Nếu server nằm sau outbound firewall nghiêm ngặt hoặc proxy mà tool không thể truy vấn, nó sẽ không tìm thấy bản phát hành nào.

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

Dòng HTTP/2 200 cho biết server có thể đọc metadata. Dòng curl: (28) Connection timed out cho biết nguyên nhân thực sự nằm ở các egress rule. Việc chỉnh sửa file APT (advanced package tool) sẽ không thay đổi kết quả.

Nếu hoàn toàn không có command này, nó nằm trong ubuntu-release-upgrader-core. Một số cloud image tối giản có thể 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 kỳ thứ gì

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

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

• never: không bao giờ kiểm tra hoặc 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 cố ý đặt never để ngăn cả fleet chuyển sang các bản phát hành khác nhau. Nếu bạn thấy giá trị này ở đó, nghĩa là đã có người chủ động chọn nó. Hãy đổi thành lts cho server cần sử dụng nhánh hỗ trợ dài hạn, rồi đổi 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 là bản LTS, công cụ nâng cấp 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 thì không, và khác biệt đó chính là nội dung của section tiếp theo.

Vì sao bản nâng cấp LTS lên LTS 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 phát hành bằng một nhóm nhỏ các key, và trình nâng cấp chỉ cung cấp bản phát hành khi cờ Supported: của bản đó là 1. Bạn có thể tự đọc các file này từ cùng 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 August 2026 cho thấy hai file không thống nhất 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 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. Không có lỗi gì trên máy của bạn. Canonical chưa mở đường nâng cấp này.

Flag chuyển sang 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 August 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. Point release không phải là một version mới của Ubuntu. Đây chỉ là cùng một bản phát hành, được tích hợp toàn bộ update kể từ khi ra mắt vào bộ install media mới, nên với server đang chạy, điều quan trọng là quyền chuyển tiếp mà nó mở ra, không phải chính bộ media. Việc trì hoãn là có chủ đích: những người upgrade sớm sẽ phát hiện các blocker, rồi các blocker đó được sửa trước khi số lượng lớn hơn nhiều các server LTS làm theo. Nếu thời điểm đó đã qua khi bạn đọc nội dung này, những gì có trong 26.04.1 khi phát hành và ý nghĩa của nó đối với server 24.04 sẽ tiếp tục phần nội dung này từ đó.

Vậy chỉ còn 2 lựa chọn rõ ràng. Chờ point release, đây là lựa chọn phù hợp cho mọi server mà bạn không muốn phải theo dõi liên tục. Hoặc đặt Prompt=normal để công cụ đó kiểm tra meta-release, nơi 26.04 đã được đánh dấu là được hỗ trợ. Cách thứ hai nâng cấp lên 26.04 đã phát hành, không phải bản development, nên có thể chấp nhận trên máy mà bạn có thể khôi phục từ snapshot. Đặt lại giá trị thành lts khi hoàn tất. Quy trình chi tiết từng bước có trong hướng dẫn đầy đủ về nâng cấp server từ 24.04 lên 26.04. Server vẫn đang chạy 22.04 cần thêm một bước trung gian, vì Prompt=lts chỉ cung cấp bản phát hành LTS kế tiếp. Do đó, lộ trình từ 22.04 lên 26.04 phải đi qua 24.04 trước.

Kho lưu trữ 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 kho lưu trữ 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ị ghi chú vô hiệu hóa. Lý do được in trên từng dòng cho mỗi mục và rất cụ thể: was disabled (unknown mirror), was disabled (unknown dist) và was disabled (no Release file).

PPA (personal package archive) được xây dựng cho noble không có thư mục dành cho 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 đó. Đây thường chỉ là cảnh báo bạn có thể chấp nhận. Vấn đề trở thành lỗi chặn khi kho lưu trữ bên thứ ba cung cấp một 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ó 2 ứng viên và không có cách nào đáp ứng cả 2.

Hãy tự quyết định việc này trước khi bắt đầu, thay vì để công cụ tự quyết định trong một lần chạy dài không có người 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 kho lưu trữ 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 nguồn mà bạn sắp vô hiệu hóa. Xóa nguồn không hạ cấp 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 việc 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 kho lưu trữ mà bạn dự định bật lại, chẳng hạn kho của Tailscale, 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à kho lưu trữ bên thứ ba được bật thay vì ghi chú vô hiệu hóa chúng." Chỉ dùng tùy chọn này sau khi xác nhận kho lưu trữ đã 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 xử lý dependency graph dựa trên một series mà kho đó chưa từng build.

Trên Ubuntu 24.04 trở lên, phần lớn nguồn nằm trong /etc/apt/sources.list.d/ubuntu.sources và dùng định dạng deb822. Cùng một kho lưu trữ đượ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. Lỗi này được đề cập trong lỗi khai báo nguồn trùng lặp ở định dạng deb822.

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

Một lần nâng cấp release 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 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 kernel hoặc một phiên bản database rồi quên gỡ. Gỡ 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 configure. Trạng thái này thường do quá trình 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 này và in dpkg interrupted, calling dpkg --configure -a, nhưng tự chạy 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 tool 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 bạn thử lại.

Hãy cập nhật đầy đủ release đang chạy trước khi nâng cấp release đó.

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 tại một thời điểm. 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ến server kém mới hơn bạn tưởng. Tùy chọn đó sẽ cài tất cả. Sau đó hãy reboot nếu các bản cập nhật có kernel, để bạn nâng cấp từ kernel thực sự đang chạy. Một máy đã tự cập nhật bản vá thông qua các bản nâng cấp bảo mật tự động sẽ còn ít việc phải làm hơn ở bước này, dù cơ chế đó cố ý không bao giờ vượt qua ranh giới giữa các release.

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

Một bản release tạm thời của Ubuntu được hỗ trợ trong chín tháng. Khi thời hạn hỗ trợ kết thúc, cờ Supported: 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 đó. 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ì trình nâng cấp yêu cầu hệ thống phải ở trạng thái hiện tại nên không có bước nào tiếp tục. Hãy sửa các source trước.

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 vào 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

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 tạo một bản backup cạnh file gốc, nên bạn có thể khôi phục nếu chỉnh nhầm file. Nếu apt update chạy sạch sau đó, archive đã có thể truy cập lại và do-release-upgrade sẽ hoạt động trở lại.

Hãy thực tế về mức độ mà cách này có thể đưa bạn tiến xa. Ubuntu chỉ hỗ trợ nâng cấp từng release một, nên server chậm hơn hai hoặc ba release đã hết vòng đời phải đi qua từng bước, và mỗi bước có thể tự fail do repository third-party riêng hoặc package bị hold riêng. Trên VPS, thường sẽ nhanh hơn nếu dựng server mới với 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ứ ổn định. Cách này cũng tạo cho bạn một phương án rollback, điều mà nâng cấp in-place không bao giờ có. Nếu sau đó bạn đang chọn track để sử dụng, sự khác biệt giữa LTS và release tạm thời trên server đáng để đọc trước khi quyết định.

Cờ bản phát hành development 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 manual mô tả tùy chọn này là: "Nếu đang dùng bản phát hành được hỗ trợ mới nhất, hãy nâng cấp lên bản phát hành development."

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 đưa server 24.04 lên bản 26.04 đã phát hành. Nó hướng đến 26.10, một bản phát hành vẫn đang được xây dựng. Hướng dẫn cũ “chỉ cần thêm -d” được viết cho khoảng thời gian trước khi một bản LTS được phát hành. Lặp lại cách này hiện nay sẽ trỏ server đến nơi bạn không dự định. Khi Prompt=lts vẫn còn hiệu lực, cờ này 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ói rõ về cờ này: "không khuyến nghị sử dụng bản phát hành development (hoặc cờ -d) trong môi trường production". Bản phát hành development thay đổi hằng 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 service lỗi vào buổi chiều. Chỉ sử dụng nó trên một virtual machine tạm thời được tạo để kiểm thử cấu hình của bạn. Không sử dụng nó trên server mà bất kỳ ai cũng phụ thuộc vào. Khi muốn dùng 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 phiên 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 hoạt động, tiến trình sẽ bị kill khi các package mới chỉ được giải nén và chưa được cấu hình. Đây chính là trạng thái khiến lần thử tiếp theo cũng dừng lại. Nếu việc này đã xảy ra, khôi phục bản nâng cấp bị dừng giữa chừng là một công việc riêng và phải thực hiện trước mọi lần thử lại. 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, đă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 thực hiện chức năng tương tự nếu bạn thích dùng screen.

Trình nâng cấp có cơ chế an toàn riêng cho người không dùng multiplexer. Khi phát hiện đang chạy trong SSH, nó đề nghị khởi động một sshd thứ hai trên cổng 1022, để phiên chính bị hỏng vẫn còn một cách 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ó và tìm một tiến trình có tên sshd. Khi chạy bên trong tmux hoặc screen, quá trình duyệt này sẽ tìm thấy multiplexer server thay thế, nên đề nghị đó 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 chấp nhận đề nghị này, cổng sẽ không tự mở cho bạn. Công cụ nói rõ điều đó vì việc mở một cổng là quyết định bảo mật mà nó không được phép tự quyết định thay bạn. Hãy mở cổng 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. Cổng 1022 cũng phải được mở tại đó. Nếu không, fallback listener đang chạy nhưng không thể truy cập, tức là bạn gặp tình huống tệ nhất trong cả hai trường hợp.

Trước khi nhập lệnh, hãy chuẩn bị đủ 4 việc sau:

• Tạo snapshot hoặc backup đầy đủ. Nâng cấp bản phát hành 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 đến nó. 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ới 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 đầy đủ các package, và phân vùng /boot chứa nhiều kernel cũ là một nơi thường bị đầy khiến quá trình bị dừng.
• Đọc release notes 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 bản phát hành, dù bạn có dự định nâng cấp hay không.

FAQ

Tại 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?

Prompt=lts mặc định trong /etc/update-manager/release-upgrades khiến công cụ đọc https://changelogs.ubuntu.com/meta-release-lts, và Ubuntu 26.04 giữ Supported: 0 trong file đó cho đến khi bản point release đầu tiên được phát hành. 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 file bằng curl -s https://changelogs.ubuntu.com/meta-release-lts và đọ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; Ubuntu 26.04.1 được lên lịch phát hành vào 27 August 2026.

Có an toàn không nếu đặt Prompt=normal thay vì chờ point release?

Thao tác này nâng cấp hệ thống lên 26.04 đã phát hành, không phải development build, vì Prompt=normal đọc meta-release, trong đó 26.04 đã có 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 blocker do những người nâng cấp sớm phát hiện được khắc phục. Chỉ làm trên server có thể khôi phục từ snapshot và nơi bạn có thể truy cập provider console nếu reboot gặp lỗi. Đặt giá trị này lại thành lts sau đó.

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

Không. -d đọc meta-release-development; entry mới nhất trong đó vào ngày 13 August 2026 là Ubuntu 26.10, một bản phát hành vẫn đang được phát triển. 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 cho biết development release không được khuyến nghị 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, nên các package đã đượ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 cập nhật đầy đủ, do-release-upgrade có thể nâng cấp hệ thống lần lượt từng bản phát hành.

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. Tuy nhiên, tự làm trước sẽ tốt hơn vì bạn kiểm soát thứ tự và thấy được kết quả. Chạy apt policy trên các package bạn quan tâm để xác định package nào đến từ từng PPA, sau đó cài lại các package đó 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.