do-release-upgrade: no new release found - jak naprawić

Dlaczego do-release-upgrade informuje o braku nowej wersji

do-release-upgrade komunikat kończący się No new release found. niemal nigdy nie oznacza awarii narzędzia. Ścieżka, o którą pytasz, jest w danym momencie zamknięta, a narzędzie informuje o tym w najbardziej zwięzły sposób. Pięć czynników powoduje to zamknięcie: ustawienie Prompt w pliku /etc/update-manager/release-upgrades, mechanizm blokujący aktualizacje wydań punktowych w systemach LTS (long term support), zewnętrzne repozytoria, pakiety wstrzymane lub niepoprawnie skonfigurowane oraz wydanie, którego okres wsparcia już wygasł.

Przeanalizuj je w podanej kolejności. Każdy z tych punktów można zweryfikować za pomocą polecenia, które potwierdzi, czy dany problem dotyczy Twojego serwera, co eliminuje konieczność zgadywania przyczyny.

Co faktycznie raportuje flaga check-only

sudo do-release-upgrade -c
echo $?

-c to tryb sprawdzania. Narzędzie odczytuje metadane wydania Canonical przez HTTPS (hypertext transfer protocol secure) i wyświetla wynik. Nie pobiera żadnego narzędzia aktualizacyjnego ani nie modyfikuje plików źródłowych. Istotne są dwa komunikaty:

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.

Kod wyjścia przekazuje tę samą informację dla skryptów. Wynosi on 0, gdy dostępne jest nowe wydanie, oraz 1, gdy żadne nie istnieje. Jest to odwrotność standardowej konwencji powłoki, dlatego należy zachować ostrożność przy budowaniu automatyzacji w oparciu o ten wynik.

Jeśli baner logowania nadal wyświetla starą informację, oznacza to, że jest ona w pamięci podręcznej. Ten wiersz pochodzi z /etc/update-motd.d/91-release-upgrade, który wyświetla zapisany wynik zamiast odpytywać sieć. Odśwież go za pomocą sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd lub po prostu zaufaj -c. Baner jedynie powtarza wynik ostatniego wykonanego sprawdzenia.

Sprawdzenie wymaga również połączenia z changelogs.ubuntu.com. Na serwerze za restrykcyjnym firewallem wyjściowym lub proxy narzędzie nie może wysłać zapytania, więc nie znajdzie żadnych informacji.

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

Wiersz HTTP/2 200 oznacza, że serwer ma dostęp do metadanych. curl: (28) Connection timed out oznacza, że przyczyną są reguły ruchu wychodzącego i żadna edycja plików APT (advanced package tool) nie zmieni wyniku.

Jeśli polecenie w ogóle nie występuje, znajduje się w ubuntu-release-upgrader-core. Minimalne obrazy chmurowe czasami pomijają ten pakiet.

sudo apt install ubuntu-release-upgrader-core

Przed wprowadzeniem zmian należy przeczytać plik /etc/update-manager/release-upgrades

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Plik zawiera własną dokumentację w komentarzach. Dopuszczalne są trzy wartości:

• never: nigdy nie sprawdzaj dostępności nowych wydań i nie zezwalaj na aktualizację systemu.
• normal: oferuj wspierane wydanie, które bezpośrednio następuje po aktualnie uruchomionym.
• lts: oferuj pierwsze wydanie LTS, które następuje po aktualnie uruchomionym.

Wartość Prompt=never jest najłatwiejsza do zdiagnozowania, ponieważ narzędzie w swoim komunikacie wyjściowym wskazuje zarówno plik, jak i ustawienie:

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

Dostawcy usług hostingowych oraz narzędzia do zarządzania konfiguracją celowo ustawiają never, aby zapobiec rozbieżnościom wersji w zarządzanej flocie serwerów. Jeśli wartość ta występuje w pliku, została wybrana świadomie. Należy zmienić ją na lts w przypadku serwera, który ma korzystać ze ścieżki długoterminowego wsparcia (LTS), a następnie przywrócić poprzednią wartość, jeśli automatyzacja wymaga pierwotnego ustawienia.

Jeden szczegół w komentarzach często sprawia trudności. Gdy ustawione jest Prompt=lts, a aktualnie uruchomione wydanie nie jest wydaniem LTS, narzędzie aktualizujące traktuje to ustawienie jak normal. Na maszynie z systemem 25.10 obie wartości działają identycznie. Na maszynie z systemem 24.04 działają inaczej i ta różnica stanowi treść całej następnej sekcji.

Dlaczego aktualizacja z LTS do LTS czeka na pierwsze wydanie punktowe

Prompt decyduje, który plik metadanych odczytuje narzędzie aktualizujące. Adresy znajdują się w /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 odczytuje meta-release-lts. Prompt=normal odczytuje meta-release. Oba pliki opisują każde wydanie w krótkim bloku kluczy, a narzędzie aktualizujące oferuje nowe wydanie tylko wtedy, gdy jego flaga Supported: ma wartość 1. Można sprawdzić je samodzielnie, pobierając dane z tego samego serwera:

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

Sprawdzone 13 sierpnia 2026 roku, oba pliki zawierają sprzeczne informacje na temat Ubuntu 26.04. Plik LTS podaje:

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

Zwykły plik podaje:

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

Wartość Supported: 0 w pliku LTS stanowi blokadę. Serwer 24.04 korzystający z domyślnego ustawienia Prompt=lts odczytuje ten plik, nie znajduje nowszego wydania LTS oznaczonego jako dostępne i wyświetla komunikat No new release found.. Z systemem jest wszystko w porządku. Canonical po prostu jeszcze nie otworzyło ścieżki aktualizacji.

Flaga zmienia się na 1 po wydaniu pierwszego point release. Ubuntu 26.04.1 ma zostać wydane 27 August 2026, ale harmonogramy wydań mogą się zmieniać, dlatego należy sprawdzić metadane, a nie opierać się na kalendarzu. Point release nie jest nową wersją Ubuntu. Jest to wyłącznie to samo wydanie zawierające wszystkie aktualizacje od momentu premiery, włączone do nowych nośników instalacyjnych, dlatego w przypadku działającego serwera znaczenie ma bramka, którą otwiera, a nie sam nośnik. Opóźnienie jest celowe: osoby wykonujące aktualizację wcześniej wykrywają blokery, które są następnie usuwane, zanim znacznie większa grupa serwerów LTS rozpocznie aktualizację. Jeśli ten termin już minął, gdy czytany jest ten tekst, informacje o zawartości wydania 26.04.1 i jego znaczeniu dla serwera 24.04 stanowią dalszy ciąg.

Pozostają dwie uczciwe możliwości. Należy poczekać na wydanie punktowe. Jest to właściwa decyzja w przypadku każdego serwera, którego nie trzeba stale monitorować. Można też ustawić Prompt=normal. Spowoduje to skierowanie tego samego narzędzia do meta-release, gdzie wersja 26.04 jest już oznaczona jako obsługiwana. Druga ścieżka aktualizuje system do wydanej wersji 26.04, a nie do kompilacji rozwojowej. Można ją uznać za uzasadnioną na maszynie, którą da się odtworzyć z migawki. Po zakończeniu należy przywrócić wartość lts. Szczegółowa procedura jest opisana krok po kroku w pełnej instrukcji aktualizacji serwera z 24.04 do 26.04. Serwer działający nadal pod kontrolą 22.04 wymaga dodatkowego etapu, ponieważ Prompt=lts zawsze oferuje tylko następną wersję LTS. Dlatego ścieżka z 22.04 do 26.04 prowadzi najpierw przez 24.04.

Repozytoria stron trzecich oraz PPA blokujące aktualizację

Narzędzie aktualizujące modyfikuje źródła APT, aby wskazywały na nowe wydanie. Może to zrobić tylko dla repozytorium, które publikuje pakiety dla nowej wersji, dlatego każde inne zostaje opatrzone komentarzem. Przyczyny są wypisywane w osobnych liniach dla każdego wpisu i są konkretne: was disabled (unknown mirror), was disabled (unknown dist) oraz was disabled (no Release file).

PPA (personal package archive) zbudowane dla noble nie posiada katalogu dla resolute na serwerze, więc narzędzie aktualizujące nie może pobrać pliku Release dla nowej serii i wyłącza dany wpis. Zazwyczaj jest to ostrzeżenie, które można zaakceptować. Staje się ono przeszkodą, gdy repozytorium strony trzeciej dostarcza pakiet, który znajduje się również w nowym wydaniu, ponieważ mechanizm obliczający aktualizację ma wtedy dwóch kandydatów i nie jest w stanie obsłużyć obu jednocześnie.

Należy podjąć decyzję samodzielnie przed rozpoczęciem procesu, zamiast pozwalać narzędziu na decydowanie w trakcie długiej, nieobsługiwanej sesji.

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

apt policy przy nazwie pakietu wyświetla, z którego repozytorium pochodzi każda zainstalowana wersja, dzięki czemu można dokładnie sprawdzić, które pakiety zależą od źródła, które ma zostać wyłączone. Usunięcie źródła nie powoduje automatycznego przywrócenia starszej wersji pakietu (downgrade), więc pakiet zainstalowany z PPA pozostaje w swojej wersji z PPA i może być nowszy niż ten dostępny w nowym wydaniu. Jeśli ma to znaczenie, należy również usunąć taki pakiet i zainstalować go ponownie z oficjalnego archiwum po zakończeniu aktualizacji. Repozytorium, które planuje się przywrócić, na przykład Tailscale, wymaga aktualizacji nazwy kodowej do nowego wydania, zanim pakiet będzie mógł zostać ponownie zainstalowany; stąd biorą się większość błędów instalacji Tailscale w Ubuntu.

Istnieje flaga dla przeciwnego wyboru. Strona podręcznika systemowego opisuje --allow-third-party jako "Spróbuj wykonać aktualizację z włączonymi lustrami i repozytoriami stron trzecich zamiast wyłączania ich przez komentarz". Należy jej używać tylko po potwierdzeniu, że repozytorium publikuje już pakiety dla docelowego wydania. Jeśli tego nie robi, wymusza się na APT rozwiązanie grafu zależności w odniesieniu do serii, dla której repozytorium nigdy nie zostało zbudowane.

W Ubuntu 24.04 i nowszych większość źródeł znajduje się w /etc/apt/sources.list.d/ubuntu.sources w formacie deb822. To samo repozytorium zapisane w starym i nowym formacie stanowi oddzielny błąd z własnym komunikatem, omówiony w błąd zduplikowanego wpisu źródłowego w formacie deb822.

Wstrzymane i częściowo skonfigurowane pakiety przerywają obliczenia

Aktualizacja wydania wymaga przeniesienia niemal każdego pakietu w systemie. Jeśli przeniesienie choć jednego pakietu jest niemożliwe, obliczenia kończą się niepowodzeniem, a instalator przerywa pracę, zamiast pozostawiać system w stanie niepełnej aktualizacji. Dwa polecenia pozwalają zidentyfikować przyczynę.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold wyświetla wstrzymane pakiety, po jednym w linii; w czystym systemie polecenie nie zwraca żadnych danych. Wstrzymanie (hold) to ręczna instrukcja blokująca zmiany w danym pakiecie. Ktoś mógł przypiąć wersję jądra lub bazy danych i o tym zapomnieć. Pakiety, które nie są już potrzebne w tym stanie, należy zwolnić za pomocą sudo apt-mark unhold, podając nazwę pakietu.

dpkg --audit wyświetla pakiety, które zostały rozpakowane, ale nie zostały skonfigurowane. Taki stan wynika z przerwania instalacji, najczęściej w wyniku zerwania sesji. Instalator podejmuje próbę naprawy i wyświetla dpkg interrupted, calling dpkg --configure -a, jednak samodzielne wykonanie naprawy pozwala na odczytanie błędu, zamiast obserwowania go w przewijanym dzienniku. Pakiet, którego narzędzie nie może naprawić, generuje komunikat Package in inconsistent state; wymaga on interwencji przed ponowieniem próby.

Przed przystąpieniem do aktualizacji wydania należy w pełni zaktualizować bieżącą wersję systemu.

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

Opcja aktualizacji etapowych (phased updates) ma większe znaczenie, niż mogłoby się wydawać. Ubuntu udostępnia niektóre aktualizacje tylko dla określonego procenta maszyn, więc zwykłe apt upgrade może pozostawić część pakietów bez zmian, przez co serwer jest mniej aktualny, niż zakłada administrator. Ta opcja wymusza pobranie wszystkich dostępnych aktualizacji. Po instalacji należy wykonać restart, jeśli w zestawie znajdowało się jądro, aby aktualizacja odbyła się z poziomu aktualnie uruchomionego kernela. Serwer, który samodzielnie dba o poprawki poprzez automatyczne aktualizacje bezpieczeństwa, ma w tym zakresie mniej pracy, choć mechanizm ten z założenia nigdy nie przekracza granic wydania systemu.

Gdy wydanie utraciło wsparcie standardowe

Wydanie tymczasowe Ubuntu jest wspierane przez dziewięć miesięcy. Po zakończeniu tego okresu flaga Supported: zmienia się na 0, a standardowa ścieżka aktualizacji przestaje oferować możliwość przejścia na nowszą wersję. Stan na 13 sierpnia 2026 roku, meta-release podaje następujące informacje o wersji 25.10:

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

W tym samym czasie przenoszone jest archiwum. Pakiety dla wydania, którego cykl życia dobiegł końca, są usuwane z archive.ubuntu.com i przenoszone do old-releases.ubuntu.com. W rezultacie apt update zaczyna zwracać 404 Not Found, systemu nie można już zaktualizować, a ponieważ narzędzie aktualizujące wymaga systemu w bieżącej wersji, proces zostaje przerwany. Należy najpierw naprawić źródła.

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

Skieruj zarówno archive.ubuntu.com, jak i security.ubuntu.com na old-releases.ubuntu.com, pozostawiając nazwę kodową bez zmian. Zmienia się wyłącznie nazwa hosta.

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

Wykonaj to samo polecenie względem /etc/apt/sources.list, jeśli serwer nadal przechowuje źródła w tym jednym pliku. Opcja -i.bak tworzy kopię zapasową obok oryginału, co pozwala na przywrócenie stanu pierwotnego w razie błędnej edycji pliku. Poprawne wykonanie apt update oznacza, że archiwum jest ponownie dostępne, a do-release-upgrade nawiąże połączenie.

Należy realistycznie ocenić skuteczność tego rozwiązania. Ubuntu wspiera przejście tylko o jeden krok wydania naraz, więc serwer, który pominął dwa lub trzy wydania, wymaga przeprowadzenia każdej aktualizacji po kolei. Każdy etap może zakończyć się niepowodzeniem z powodu zewnętrznego repozytorium lub wstrzymanego pakietu. W przypadku VPS często szybszym rozwiązaniem jest postawienie nowego serwera na bieżącym wydaniu LTS, przeniesienie usług i zachowanie starej instancji do czasu potwierdzenia poprawności działania. Zapewnia to również możliwość wycofania zmian, czego nie oferuje aktualizacja w miejscu. Jeśli rozważasz, na której ścieżce pozostać w przyszłości, warto zapoznać się z różnicami między wydaniami LTS a wydaniami tymczasowymi na serwerze przed podjęciem decyzji.

Co w rzeczywistości robi flaga wydania rozwojowego

-d, lub --devel-release, sprawia, że program aktualizujący odczytuje meta-release-development zamiast pliku wybranego przez Prompt. Strona podręcznika systemowego opisuje to następująco: „Jeśli używasz najnowszego wspieranego wydania, zaktualizuj do wydania rozwojowego”.

Sprawdzono 13 sierpnia 2026 r., najnowszy wpis w tym pliku to nie 26.04:

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

Zatem -d nie dostarcza serwerowi z wersją 24.04 wydania 26.04. Celuje w 26.10, czyli wydanie, które jest wciąż w fazie przygotowań. Starsze porady, aby „po prostu dodać -d”, zostały napisane w okresie przed wydaniem wersji LTS, a powtarzanie ich obecnie kieruje serwer w miejsce, do którego nie zamierzałeś go wysyłać. Przy wciąż aktywnym Prompt=lts, flaga zatrzymuje się z własnym komunikatem:

There is no development version of an LTS available.

Dokumentacja serwerowa Ubuntu jasno określa tę flagę: „używanie wydania rozwojowego (lub flagi -d) nie jest zalecane w środowiskach produkcyjnych”. Wydanie rozwojowe zmienia się codziennie i nie posiada gwarancji wsparcia bezpieczeństwa, więc pakiet działający rano może uszkodzić usługę po południu. Używaj go na maszynie wirtualnej typu scratch, stworzonej do testowania własnej konfiguracji. Nie używaj go na serwerze, od którego ktokolwiek jest zależny. Gdy chcesz uzyskać wydane 26.04 przed otwarciem bramki LTS, właściwą drogą jest Prompt=normal.

Uruchamianie aktualizacji w sposób odporny na zerwanie sesji SSH

Aktualizacja wydania zastępuje większość systemu, w tym openssh-server i systemd. Jeśli sesja SSH (secure shell) zostanie przerwana podczas pracy dpkg, proces zostanie zakończony, a pakiety pozostaną rozpakowane i nieskonfigurowane. Taki stan uniemożliwi kolejną próbę. Jeśli już do tego doszło, odzyskanie aktualizacji przerwanej w połowie jest osobnym zadaniem i należy je wykonać przed ponowną próbą. Za każdym razem należy rozpoczynać aktualizację wewnątrz multipleksera terminala.

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

W przypadku zerwania połączenia zaloguj się ponownie i wykonaj tmux attach -t upgrade. Aktualizacja działała w tle, ponieważ jest procesem potomnym serwera tmux, a nie sesji SSH. screen -S upgrade oraz screen -r upgrade pełnią tę samą funkcję, jeśli preferujesz narzędzie screen.

Narzędzie aktualizacyjne posiada własny mechanizm zabezpieczający dla użytkowników niekorzystających z multipleksera. Gdy wykryje, że działa w sesji SSH, zaproponuje uruchomienie drugiego procesu sshd na porcie 1022. Dzięki temu w razie awarii głównej sesji pozostaje alternatywna droga dostępu. Decyzja podejmowana jest poprzez analizę drzewa procesów nadrzędnych w poszukiwaniu procesu o nazwie sshd. Wewnątrz tmux lub screen analiza ta wskazuje na serwer multipleksera, więc propozycja się nie pojawia, a plik pid /var/run/release-upgrader-sshd.pid jest zapisywany tylko wtedy, gdy dodatkowy demon faktycznie zostanie uruchomiony. Brak tego komunikatu nie oznacza błędu; korzystasz już z lepszego zabezpieczenia.

Jeśli zaakceptujesz ofertę, port nie zostanie otwarty automatycznie. Narzędzie informuje o tym wprost, ponieważ otwarcie portu jest decyzją dotyczącą bezpieczeństwa, której program nie powinien podejmować za użytkownika. Otwórz port na czas trwania aktualizacji, a następnie zamknij go ponownie.

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

Większość dostawców VPS stosuje drugą zaporę sieciową w panelu sterowania, poza systemem operacyjnym. Port 1022 musi być otwarty również tam; w przeciwnym razie zapasowy proces nasłuchujący będzie działał, lecz pozostanie nieosiągalny, co jest najgorszym z możliwych scenariuszy.

Przed wpisaniem komendy upewnij się, że spełnione są cztery warunki:

• Wykonaj migawkę (snapshot) lub pełną kopię zapasową. Aktualizacja wydania w miejscu nie posiada funkcji cofania zmian, a to jest jedyna szansa na zabezpieczenie danych.
• Potwierdź, że masz dostęp do konsoli dostawcy, zanim będzie ona potrzebna. Jeśli serwer nie uruchomi się po restarcie, dostęp przez SSH będzie niemożliwy. Jądro systemu, które nie startuje, to odrębny problem wymagający własnych kroków naprawczych, opisanych w VPS, który nie uruchamia się po aktualizacji jądra.
• Sprawdź wolne miejsce za pomocą df -h / /boot. Aktualizacja pobiera pełny zestaw pakietów, a partycja /boot zawierająca kilka starych jąder jest częstym miejscem, w którym proces zostaje wstrzymany.
• Przeczytaj informacje o wydaniu dla używanych usług. Duży skok wersji w PostgreSQL lub PHP nastąpi wraz z aktualizacją systemu, niezależnie od tego, czy został zaplanowany.

FAQ

Dlaczego do-release-upgrade twierdzi, że nie znaleziono nowej wersji na Ubuntu 24.04?

Domyślny Prompt=lts w /etc/update-manager/release-upgrades sprawia, że narzędzie odczytuje https://changelogs.ubuntu.com/meta-release-lts, a Ubuntu 26.04 zawiera Supported: 0 w tym pliku aż do pierwszego wydania punktowego. Program aktualizujący nie znajduje nowszego wydania LTS oznaczonego jako dostępne, więc przerywa działanie. Sprawdź plik samodzielnie za pomocą curl -s https://changelogs.ubuntu.com/meta-release-lts i przeczytaj ostatni blok. Stan na 13 sierpnia 2026 roku wskazywał, że flaga to nadal 0, a wydanie Ubuntu 26.04.1 zaplanowano na 27 sierpnia 2026 roku.

Czy ustawienie Prompt=normal jest bezpieczne zamiast czekania na wydanie punktowe?

Aktualizuje system do wydanego 26.04, a nie do wersji rozwojowej, ponieważ Prompt=normal odczytuje meta-release, gdzie 26.04 ma już ustawione Supported: 1. Ryzykiem jest czas. Przeprowadzasz proces, zanim błędy wykryte przez pierwszych użytkowników zostaną naprawione. Wykonaj to na serwerze, z którego możesz przywrócić snapshot i do którego masz dostęp przez konsolę dostawcy w razie nieudanego restartu. Po zakończeniu przywróć wartość lts.

Czy flaga -d aktualizuje system do 26.04?

Nie. -d odczytuje meta-release-development, którego najnowszy wpis w dniu 13 sierpnia 2026 roku dotyczył Ubuntu 26.10, czyli wersji będącej w fazie rozwoju. Na maszynie LTS z Prompt=lts flaga wyświetla There is no development version of an LTS available. i kończy działanie. Dokumentacja serwerowa Ubuntu odradza stosowanie wersji rozwojowych w środowiskach produkcyjnych, dlatego użyj Prompt=normal, jeśli chcesz wcześnie uzyskać wydane 26.04.

apt update zwraca błędy 404 dla starej wersji. Jak ją zaktualizować?

Wsparcie dla tej wersji wygasło, więc pakiety zostały przeniesione z archive.ubuntu.com do old-releases.ubuntu.com. Zmień tylko nazwy hostów w /etc/apt/sources.list.d/ubuntu.sources lub w /etc/apt/sources.list w starszych układach, zachowując nazwę kodową systemu. Następnie uruchom sudo apt update oraz sudo apt full-upgrade. Gdy system będzie aktualny, do-release-upgrade pozwoli na przejście do kolejnej wersji.

Czy muszę usuwać PPA przed uruchomieniem do-release-upgrade?

Nie jest to konieczne, ponieważ program aktualizujący komentuje każde źródło, które nie publikuje pakietów dla nowej wersji i wyświetla komunikat typu was disabled (no Release file) dla każdego z nich. Lepiej jednak zrobić to samodzielnie, ponieważ masz kontrolę nad kolejnością i widzisz wynik. Uruchom apt policy dla interesujących Cię pakietów, aby sprawdzić, które pochodzą z danego PPA, a następnie zainstaluj je ponownie z głównego repozytorium, jeśli wersja z PPA jest nowsza niż ta dostępna w nowym wydaniu.