Nieudana aktualizacja Ubuntu: jak naprawić system

Nieudana aktualizacja Ubuntu w połowie procesu: najpierw rozpoznaj objawy

Nieudana aktualizacja wydania Ubuntu z 24.04 do 26.04 pozostawia serwer w jednym z czterech stanów. Każdy z nich wymaga innego rozwiązania. Program aktualizujący może nadal działać w sesji screen, z którą utracono połączenie. Proces dpkg mógł zostać przerwany, gdy pakiet był częściowo skonfigurowany. W takiej sytuacji apt odrzuca teraz każdą operację instalowania, usuwania lub aktualizowania pakietów, mimo że apt update oraz polecenia tylko do odczytu, takie jak apt show, nadal działają. Źródła apt mogą wskazywać na 26.04, podczas gdy zainstalowane pakiety nadal pochodzą z 24.04. Serwer może też w ogóle się nie uruchamiać. Przed wpisaniem jakiegokolwiek polecenia ustal, który z tych stanów wystąpił. Rozwiązanie właściwe dla jednego stanu może pogorszyć inny.

Jedna zasada dotyczy wszystkich czterech stanów. Nie uruchamiaj ponownie serwera, dopóki nie ustalisz stanu dpkg. Ponowne uruchomienie w trakcie wymiany pakietów może zmienić możliwe do naprawienia przerwanie pracy dpkg w przypadek, w którym system nie uruchamia się, opisany pod koniec tego poradnika. Nie uruchamiaj też drugiego procesu apt ani dpkg, gdy pierwszy może nadal działać. Dwa procesy zapisujące jednocześnie bazę danych pakietów mogą doprowadzić do jej uszkodzenia.

W tym poradniku przyjęto, że wykonano czynności opisane w poradniku aktualizacji z 24.04 do 26.04 oraz utworzono migawkę przed rozpoczęciem. Jeśli tego nie zrobiono, sekcję dotyczącą uruchamiania systemu należy czytać z uwzględnieniem tego faktu, ponieważ migawka jest rozwiązaniem w najgorszym przypadku.

Czy aktualizacja nadal trwa?

Wiele aktualizacji zgłoszonych jako nieudane nadal trwa. Sesja SSH została przerwana, terminal przestał wyświetlać dane, a program aktualizujący kontynuował pracę bez udziału użytkownika.

do-release-upgrade jest do tego przeznaczony. W trybie interfejsu tekstowego, używanym na serwerze, uruchamia się wewnątrz sesji GNU screen. Dzięki temu aktualizacja przetrwa utratę terminala, z którego ją uruchomiono. Ponadto po wykryciu uruchomienia z sesji SSH proponuje uruchomienie drugiego sshd na innym porcie (domyślnie 1022). Umożliwia to dalsze logowanie, jeśli główny daemon SSH przestanie działać podczas podmiany pakietów. Oba fakty mają teraz znaczenie.

Połącz się ponownie przez SSH i wyszukaj sesję screen. Aktualizacja działała w kontekście sudo, więc jej sesja screen należy do root. Zwykłe screen -ls wykonane jako własny użytkownik jej nie wyświetli.

sudo screen -ls

screen -ls oznacza każdą sesję jako podłączoną albo odłączoną. Jeśli widoczna jest jedna sesja, podłącz się do niej ponownie. Jeśli nadal ma status podłączonej, ponieważ przerwane połączenie SSH nie zwolniło sesji, -d najpierw odłączy nieaktualne podłączenie.

sudo screen -d -r

Jeśli widocznych jest kilka sesji, przekaż nazwę sesji z screen -ls jako argument do -r. Nie należy zakładać, że sudo do-release-upgrade podłączy ją ponownie automatycznie. Kod wyszukujący istniejącą sesję screen znajduje się w programie aktualizującym pobieranym przez ten mechanizm. Zanim jednak program pobierze jakiekolwiek dane, do-release-upgrade kończy działanie z komunikatem "Please install all available updates for your release before upgrading", gdy wykryje pakiet oczekujący na aktualizację (z wyjątkiem aktualizacji etapowanych). Jest to dokładnie stan systemu znajdującego się w połowie podmiany pakietów. Po ponownym podłączeniu użytkownik wraca do działającej aktualizacji, która zwykle oczekuje na odpowiedź dotyczącą zmienionego pliku konfiguracyjnego albo restartu usługi. Należy udzielić odpowiedzi i pozwolić aktualizacji zakończyć pracę.

Jeśli aktualizacja została uruchomiona wewnątrz tmux, zgodnie z zaleceniami instrukcji aktualizacji, należy najpierw ponownie podłączyć tmux za pomocą tmux attach. Sesja screen działa wewnątrz tego panelu tmux, więc aktualizacja będzie widoczna bezpośrednio. Jeśli panel zawiera tylko znak zachęty powłoki, program aktualizujący już tam nie działa i kolejnym sprawdzeniem powinno być sudo screen -ls.

Jeśli główny port SSH odrzuca połączenie, należy użyć portu awaryjnego: ssh -p 1022 user@host. Ten daemon działa tylko przez czas trwania aktualizacji. Jeśli nie można zalogować się przez żaden z tych portów, należy użyć konsoli dostawcy. Z konsoli sudo ss -ltnp wyświetla porty, na których nasłuchuje proces sshd, a sudo ufw status informuje, czy firewall przepuszcza ruch na port awaryjny.

Jeśli nie istnieje sesja screen i konsola nie oczekuje na żadną odpowiedź, aktualizacja rzeczywiście została zatrzymana. Przed przystąpieniem do naprawy należy potwierdzić, że nic nadal nie pracuje na bazie danych pakietów:

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

Pusty wynik oznacza, że dpkg jest bezczynny i można przejść do naprawy. Proces dpkg lub apt działający przez długi czas, bez sesji screen, do której można się ponownie podłączyć, jest zawieszony. Należy odczekać kilka minut, sprawdzić na konsoli, czy debconf nie oczekuje na odpowiedź, i dopiero wtedy zakończyć ten proces. Nie wolno usuwać plików blokad w /var/lib/dpkg/ ani /var/lib/apt/lists/, gdy proces nadal je posiada. Blokada jest jedynym mechanizmem, który chroni bazę danych pakietów przed uszkodzeniem przez dwóch jednocześnie zapisujących użytkowników.

dpkg został przerwany, a apt odmawia działania

Gdy dpkg zostanie zakończony między rozpakowaniem pakietu a uruchomieniem jego skryptu konfiguracyjnego, pozostawia ten pakiet oznaczony jako częściowo ukończony oraz niedokończone wpisy w swoim dzienniku pod /var/lib/dpkg/updates/. Każde polecenie apt, które blokuje dpkg, czyli każde polecenie instalujące, usuwające lub aktualizujące pakiety, najpierw sprawdza ten dziennik i kończy działanie z komunikatem dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.. Polecenia, które nigdy nie blokują dpkg, takie jak apt update, apt list, apt show i apt-cache, nadal działają, więc można sprawdzić stan systemu. Niezależnie od pozostałych komunikatów apt pierwszy krok jest taki sam.

sudo dpkg --configure -a

Polecenie to kończy konfigurację każdego pakietu, który został rozpakowany, ale nie został skonfigurowany. Uruchamia skrypty opiekuna pakietu w kolejności wynikającej z zależności. Na częściowo zaktualizowanym systemie może to potrwać długo, dlatego należy pozostawić je do zakończenia. Jeśli zatrzyma się na pakiecie, wyświetli nazwę pakietu oraz skrypt, który zakończył się błędem. Należy zapisać tę nazwę. Jest to pakiet, który zatrzymał aktualizację. W następnej sekcji opisano sposób odczytania jego błędu.

Następnie należy zlecić apt naprawę zależności, które pozostały niespełnione po przerwaniu, ponieważ niektóre pakiety zostały zaktualizowane, a pakiety, od których zależą, nie zostały zaktualizowane.

sudo apt --fix-broken install

Następnie należy dokończyć aktualizację rozpoczętą przez narzędzie aktualizujące:

sudo apt update
sudo apt full-upgrade

Należy użyć full-upgrade zamiast upgrade, ponieważ aktualizacja wydania usuwa pakiety, a zwykłe upgrade odmawia usuwania czegokolwiek. Przed potwierdzeniem należy przeczytać podsumowanie wyświetlone przez apt. Krótka lista usuwanych pakietów jest normalna. Lista obejmująca ubuntu-server, systemd, openssh-server lub pakiet jądra nie jest normalna. W takim przypadku należy odpowiedzieć „no” i ustalić, dlaczego apt chce je usunąć, zanim aktualizacja będzie kontynuowana.

Przed wykonaniem jakiejkolwiek innej czynności należy sprawdzić wynik:

sudo dpkg --audit
sudo apt-get check

dpkg --audit wyświetla każdy pakiet, który nadal jest w stanie uszkodzonym, a apt-get check zgłasza niespełnione zależności. Oba polecenia powinny nie wyświetlić niczego. Jeśli tak jest, należy uruchomić sudo apt autoremove, aby usunąć automatycznie zainstalowane zależności, których nic już nie potrzebuje. Pakiety oznaczone jako zainstalowane ręcznie pozostają, nawet gdy nic z nich nie korzysta. Następnie należy potwierdzić wydanie za pomocą cat /etc/os-release, uruchomić sudo update-initramfs -u -k all i sudo update-grub, a dopiero potem ponownie uruchomić system.

Jak odczytać /var/log/dist-upgrade, aby znaleźć pakiet, który zatrzymał aktualizację

Narzędzie aktualizujące zapisuje wszystko w /var/log/dist-upgrade/. Jeśli zostało uruchomione więcej niż raz, przenosi dzienniki wcześniejszej próby do podkatalogu o nazwie zawierającej znacznik czasu. Najpierw należy sprawdzić ls -la /var/log/dist-upgrade/ i odczytać katalog odpowiadający nieudanej próbie.

main.log jest własnym dziennikiem narzędzia aktualizującego. Zapisuje fazę, w której znajdowała się aktualizacja, oraz decyzje dotyczące źródeł pakietów. Jeśli samo narzędzie aktualizujące uległo awarii, znajduje się tu również ślad stosu Pythona. Należy czytać od końca: ostatnie wiersze wskazują fazę, w której narzędzie się zatrzymało. Ślad stosu oznacza w tym miejscu, że zawiodło narzędzie, a nie pakiet.

apt.log zawiera uzasadnienie decyzji rozstrzygania zależności. Jest szczegółowy i ma znaczenie, gdy apt w ogóle odmówił obliczenia aktualizacji. Oznacza to błąd, który wystąpił przed przetworzeniem jakiegokolwiek pakietu. Jeśli aktualizacja doszła do etapu instalowania pakietów, zwykle można go pominąć.

apt-term.log jest plikiem potrzebnym w przypadku awarii pakietu. Przechwytuje wyjście terminala dpkg podczas aktualizacji, czyli ten sam tekst, który byłby wyświetlany na ekranie. Ostatni pakiet wymieniony przed końcem pliku jest pakietem przetwarzanym w chwili zatrzymania aktualizacji. Jeśli skrypt opiekuna pakietu zakończył się błędem, komunikat dpkg znajduje się tam wraz z właściwym błędem skryptu bezpośrednio powyżej.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

Należy porównać wynik z /var/log/dpkg.log, który rejestruje zmiany stanów oraz działania wykonywane przez dpkg, każde wraz ze znacznikiem czasu. tail -n 30 /var/log/dpkg.log pokazuje ostatni pakiet przetwarzany przez dpkg oraz wykonywaną na nim czynność. Jest to ta sama odpowiedź z drugiego źródła tylko wtedy, gdy od wystąpienia błędu nic nie uruchomiło dpkg. Po uruchomieniu dpkg --configure -a lub apt --fix-broken install ich wpisy znajdują się na końcu, dlatego należy przewinąć do wierszy ze znacznikami czasu odpowiadającymi chwili zatrzymania aktualizacji.

Większość awarii na tym etapie na serwerze wynika z kilku przyczyn. Usługa ponownie uruchamiana przez pakiet w jego postinst nie startuje z powodu zmodyfikowanego pliku konfiguracyjnego. Polecenia systemctl status oraz journalctl -xeu wykonane dla tej usługi wskażą wiersz, którego usługa nie akceptuje. Dysk został zapełniony, najczęściej /boot przez stare jądra albo /var przez pamięć podręczną pakietów apt, a df -h / /boot /var pokaże ten stan. sudo apt clean opróżnia pamięć podręczną nawet wtedy, gdy apt jest zablokowany z innego powodu. Dysk zgłaszający brak wolnego miejsca, gdy du tego nie potwierdza ma własne wyjaśnienie. Pakiet z repozytorium zewnętrznego, które narzędzie aktualizujące wyłączyło, zależy od biblioteki, której wydanie 26.04 już nie udostępnia. Wstrzymany pakiet (apt-mark showhold) zablokował aktualizację zależności. Należy usunąć przyczynę, a następnie ponownie uruchomić sudo dpkg --configure -a. Polecenie wznowi działanie od miejsca zatrzymania.

Jeśli jeden pakiet odmawia konfiguracji niezależnie od podejmowanych działań, a nic istotnego od niego nie zależy, należy usunąć go i ponownie zainstalować po zakończeniu aktualizacji:

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

Należy stosować to wobec pakietu, którego nazwę i przyczynę usunięcia można jasno wskazać. Nie wolno stosować tego wobec biblioteki ani czegokolwiek w łańcuchu zależności ubuntu-server, ponieważ wymuszone usunięcie pomija kontrole, które wskazałyby, co jeszcze przestanie działać.

Źródła zostały przełączone, ale pakiety nie

Program aktualizujący przepisuje źródła apt na wczesnym etapie, zanim pobierze jakiekolwiek pakiety. Jeśli proces zostanie przerwany po tym etapie, źródła wskazują 26.04, a zainstalowane pakiety stanowią mieszankę wersji. Taki stan dezorientuje narzędzia i dlatego do-release-upgrade może teraz twierdzić, że nie ma nowego wydania.

Porównaj dwa miejsca, które określają używane wydanie. /etc/apt/sources.list.d/ubuntu.sources to plik źródeł deb822 wprowadzony w 24.04, a jego wiersze Suites: zawierają nazwę kodową wydania. /etc/os-release jest zapisywany przez pakiet base-files i wskazuje, które wydanie jest faktycznie zainstalowane.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

Istotne są trzy kombinacje. Źródła nadal wskazują 24.04 (nazwa kodowa noble), a os-release nadal informuje o 24.04: aktualizacja nie przeszła kontroli wstępnych i można ponownie uruchomić sudo do-release-upgrade po zapoznaniu się z main.log, aby ustalić przyczynę zatrzymania. Program odmówi uruchomienia, jeśli oczekuje dowolna aktualizacja 24.04 albo jeśli /var/run/reboot-required.pkgs wskazuje libc6, linux-base lub pakiet linux-image, dlatego uruchom sudo apt full-upgrade i uruchom ponownie system, jeśli ten plik wymaga tego w pierwszej kolejności. Źródła wskazują nazwę kodową 26.04, a os-release nadal informuje o 24.04: rozpoczęła się zamiana pakietów, ale została przerwana, a naprawa dpkg opisana w poprzedniej sekcji, kończąca się poleceniem apt full-upgrade, służy do jej dokończenia. Nie uruchamiaj ponownie programu aktualizującego w tym stanie. Przy oczekujących pakietach 26.04 program zatrzyma się i poprosi najpierw o zainstalowanie wszystkich dostępnych aktualizacji. Źródła wskazują 26.04, a os-release informuje o 26.04: base-files był jednym z pakietów, które zostały zainstalowane, więc system określa się teraz jako 26.04, nawet jeśli większość pakietów nadal pochodzi ze starszego wydania.

Ostatnia kombinacja jest problematyczna. do-release-upgrade określa używane wydanie na podstawie tych samych informacji, które zawiera os-release. Jeśli os-release wskazuje już 26.04, narzędzie szuka wydania nowszego niż 26.04, nie znajduje go i zgłasza brak dostępnego nowego wydania. Narzędzie odpowiada na pytanie dotyczące os-release, a os-release zawiera nieprawidłową informację. Nie uruchamiaj ponownie programu aktualizującego. Dokończ aktualizację za pomocą apt: sudo apt update, a następnie sudo apt full-upgrade. Drugie polecenie zaktualizuje pakiety, które nadal mają wersję z 24.04, z wyjątkiem pakietów wstrzymanych (ich listę wyświetla apt-mark showhold). Może też zamiast tego usunąć niektóre pakiety, dlatego należy zapoznać się z podsumowaniem, a następnie uruchomić sudo apt autoremove. Pozostałe przyczyny zgłaszania przez do-release-upgrade braku nowego wydania, takie jak monit LTS oczekujący na pierwsze wydanie punktowe, należy wykluczyć, jeśli os-release nadal wskazuje 24.04.

Program aktualizujący wyłącza również źródła innych firm w /etc/apt/sources.list.d/ i zachowuje kopię zapasową każdego zmienionego pliku, dodając przyrostek do jego pierwotnej nazwy. Uruchom ls -la /etc/apt/sources.list.d/ i diff dla każdej oryginalnej pary plików, aby dokładnie sprawdzić wprowadzone zmiany. Pozostaw wpisy innych firm wyłączone do czasu uzyskania spójnego stanu pakietów Ubuntu. Następnie włączaj je pojedynczo, dopiero po potwierdzeniu, że dostawca publikuje pakiety dla 26.04. Jeśli apt update zgłasza, że źródło jest skonfigurowane więcej niż raz, stary wpis sources.list i nowy wpis ubuntu.sources opisują ten sam zestaw pakietów, a błąd zduplikowanego źródła deb822 wskazuje, który wpis należy usunąć.

Serwer nie uruchamia się po aktualizacji

Ponowne uruchomienie ujawnia skutki nieukończonej aktualizacji. W przypadku VPS najczęstszymi przyczynami są kernel zainstalowany bez initramfs, konfiguracja GRUB, której nie wygenerowano ponownie, pakiet pozostawiony w stanie niepełnej konfiguracji, od którego zależy jednostka uruchamiana podczas startu, albo zapełniony dysk, gdy dpkg zapisywał zmiany.

Przed wykonaniem jakiejkolwiek innej czynności otwórz konsolę udostępnioną przez dostawcę. Pokazuje ona miejsce zatrzymania startu: menu GRUB, kernel panic, sprawdzanie systemu plików oczekujące na odpowiedź albo awaryjną powłokę systemd żądającą hasła root. Ta obserwacja określa następny krok.

Jeśli pojawi się GRUB, uruchom poprzedni kernel 24.04 z podmenu opcji zaawansowanych. Poprzedni kernel zwykle pozostaje zainstalowany do czasu uruchomienia autoremove. Po uruchomieniu systemu ze starym kernelem wykonaj sudo dpkg --configure -a i pozostałe czynności naprawcze z poprzedniej sekcji, a następnie sudo update-initramfs -u -k all i sudo update-grub, zanim ponownie spróbujesz uruchomić nowy kernel. Odzyskiwanie VPS, który nie uruchamia się po aktualizacji kernela szczegółowo opisuje kwestie GRUB i initramfs.

Jeśli zostanie uruchomiona awaryjna powłoka, główny system plików jest zwykle zamontowany tylko do odczytu. Zamontuj go ponownie i wykonaj tę samą naprawę:

mount -o remount,rw /
dpkg --configure -a

Jeśli system w ogóle nie dociera do powłoki, uruchom obraz ratunkowy dostawcy, zamontuj dysk VPS i wykonaj naprawę z użyciem chroot. Znajdź partycję główną za pomocą lsblk zamiast zgadywać jej nazwę.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

Zanim spędzisz godzinę w tym środowisku chroot, porównaj tę opcję z użyciem snapshotu. Snapshot został utworzony przed rozpoczęciem prac, a jego przywrócenie u większości dostawców trwa kilka minut. Następnie ponownie wykonasz aktualizację, co na VPS zajmuje znacznie mniej niż godzinę, a tym razem z wyprzedzeniem wiadomo, który pakiet należy naprawić. Przywrócenie jest szybszą ścieżką, gdy zachodzi dowolny z tych warunków: nie można uzyskać dostępu do konsoli ani obrazu ratunkowego, nie można wskazać pakietu, który zatrzymał aktualizację, zablokowanych jest więcej niż jeden pakiet albo na serwerze działa usługa, na którą czekają użytkownicy. Ręczna naprawa jest szybsza tylko wtedy, gdy wiadomo, co dokładnie uległo awarii, a rozwiązaniem jest pojedyncze polecenie.

Przed przywróceniem skopiuj /var/log/dist-upgrade/ poza serwer, korzystając z obrazu ratunkowego, jeśli jest to jedyny sposób uzyskania dostępu. Przywrócenie usuwa te dzienniki, a druga próba zakończy się dokładnie tak samo, jeśli nie zostanie ustalona przyczyna pierwszej awarii. Warto przeczytać Co snapshot może przywrócić, a czego nie może przed poleganiem na tym rozwiązaniu. Snapshot przywraca cały dysk do wcześniejszego stanu, w tym usuwa wszystkie dane zapisane od momentu jego utworzenia. Jest to właściwe w trakcie aktualizacji, ale nie tydzień później.

Trzy oznaki, że zamiast tego należy przebudować system

Nie każdą aktualizację warto ratować. Przywrócenie migawki i ponowne uruchomienie procesu jest tanie, ale jeśli przyczyną awarii był stan samego systemu, drugie uruchomienie również zakończy się niepowodzeniem. W takiej sytuacji właściwym rozwiązaniem jest świeży obraz 26.04 i odtworzenie danych z kopii zapasowej. Trzy oznaki wskazują, że nadszedł ten moment.

Po pierwsze, uszkodzona jest własna baza danych dpkg. Jeśli dpkg --audit lub apt-get check nie może w ogóle odczytać /var/lib/dpkg/status, zamiast zgłaszać uszkodzone pakiety w tej bazie, oznacza to utratę informacji o zainstalowanym oprogramowaniu. Ubuntu przechowuje codzienne kopie w /var/backups/ (ls -la /var/backups/dpkg.status*), a zastąpienie bieżącej bazy najnowszą poprawną kopią czasami działa. Jeśli jednak ta kopia nie odpowiada rzeczywistemu stanowi dysku, pozostaje zgadywanie, a każde kolejne uruchomienie apt opiera się na tym założeniu.

Po drugie, uszkodzone są narzędzia potrzebne do naprawy systemu. Jeśli apt lub dpkg nie uruchamia się, ponieważ usunięto bibliotekę współdzieloną albo zastąpiono ją tylko częściowo, lub systemd nie może uruchamiać jednostek, ponieważ jego własny pakiet jest skonfigurowany tylko częściowo, nie ma już działającego menedżera pakietów, który mógłby naprawić menedżera pakietów. ldd /usr/bin/apt informuje, czy wszystkie biblioteki apt są obecne. Czasami można wyjść z tej sytuacji, uruchamiając system chroot z obrazu ratunkowego, ale zwykle trwa to dłużej niż przebudowanie systemu.

Po trzecie, lista uszkodzonych pakietów nie skraca się. Jeśli przez ponad godzinę wielokrotnie uruchamiano dpkg --configure -a i apt --fix-broken install, a każde kolejne przejście ujawnia nowy pakiet zamiast usunąć poprzedni problem, oznacza to, że system przeniósł do aktualizacji problemy, których sama aktualizacja nie spowodowała: ręcznie edytowane pliki w /usr, przypięte lub wstrzymane pakiety, repozytorium zewnętrzne, które zastąpiło biblioteki systemowe, albo wcześniejszą aktualizację, której nigdy nie ukończono. Świeży obraz nie zawiera tych problemów, a odtworzenie na nim danych zajmuje mniej czasu niż ich wykrywanie.

Przebudowa jest tania tylko wtedy, gdy dane znajdują się poza tym systemem. Na tym polega różnica między migawką a kopią zapasową i dlatego instrukcja aktualizacji wymaga obu.

FAQ

Czy można po prostu ponownie uruchomić do-release-upgrade po przerwaniu aktualizacji?

Nie jako pierwszy krok. Jeśli program aktualizujący nadal działa w sesji screen, należy ponownie się do niej podłączyć za pomocą sudo screen -d -r. Drugie do-release-upgrade zatrzyma się, zanim dojdzie do własnego kodu ponownego podłączania, ponieważ odmawia uruchomienia, gdy oczekuje aktualizacja dowolnego pakietu. Jeśli program aktualizujący zakończył działanie, najpierw należy uruchomić sudo dpkg --configure -a i sudo apt --fix-broken install. Gdy źródła zawierają już wersję 26.04, należy dokończyć aktualizację za pomocą sudo apt full-upgrade, a nie programu aktualizującego. Gdy nadal zawierają wersję 24.04, należy uruchomić sudo apt full-upgrade, wykonać ponowne uruchomienie, jeśli /var/run/reboot-required.pkgs wyświetla libc6, linux-base lub jądro, a następnie ponownie uruchomić program aktualizujący. Odmawia on również działania, gdy Prompt=never jest ustawione w /etc/update-manager/release-upgrades albo gdy serwer Ubuntu zgłasza komunikat „Release upgrade not possible right now”.

Dlaczego do-release-upgrade informuje, że nie ma nowej wersji, gdy aktualizacja zakończyła się niepowodzeniem?

Ponieważ base-files, pakiet zapisujący /etc/os-release, został zaktualizowany przed przerwaniem. Narzędzie odczytuje teraz ten plik, uznaje, że system działa pod kontrolą wersji 26.04, i nie znajduje nowszej wersji do zaoferowania. Należy porównać grep VERSION_ID /etc/os-release z grep Suites /etc/apt/sources.list.d/ubuntu.sources, a następnie dokończyć aktualizację za pomocą sudo apt update && sudo apt full-upgrade.

Czy ponowne uruchomienie częściowo zaktualizowanego serwera Ubuntu jest bezpieczne?

Nie, dopóki sudo dpkg --audit nie zwróci żadnych wyników. Ponowne uruchomienie z rozpakowanym, ale nieskonfigurowanym jądrem albo bez ponownego wygenerowania GRUB jest najczęstszą przyczyną sytuacji, w której aktualizacja możliwa do naprawienia w ciągu dziesięciu minut wymaga użycia obrazu ratunkowego. Należy dokończyć naprawę dpkg i apt full-upgrade, uruchomić update-initramfs -u -k all oraz update-grub, a dopiero potem wykonać ponowne uruchomienie.

Jak ustalić, który pakiet zatrzymał aktualizację?

Należy odczytać koniec /var/log/dist-upgrade/apt-term.log, w którym znajdują się końcowe komunikaty dpkg. Ostatni pakiet wymieniony przed końcem dziennika to pakiet aktualnie przetwarzany. Jeśli skrypt opiekuna pakietu zakończył się niepowodzeniem, jego błąd znajduje się bezpośrednio nad komunikatem dpkg. /var/log/dpkg.log jest drugim źródłem informacji. Wiersze z oznaczeniem czasu odpowiadającym zatrzymaniu aktualizacji wskazują ten sam pakiet. Wszystkie operacje wykonane później za pomocą dpkg są jednak zapisywane po tych wierszach, dlatego ostatnie wpisy mogą dotyczyć już innych działań. Jeśli natomiast main.log kończy się śladem stosu języka Python, awarii uległ sam program aktualizujący i żaden pakiet nie jest przyczyną problemu.

Czy należy przywrócić migawkę, czy kontynuować naprawę?

Migawkę należy przywrócić, gdy nie można wskazać pakietu, który zakończył działanie niepowodzeniem, gdy zablokowany jest więcej niż jeden pakiet, gdy nie ma dostępu do konsoli albo gdy serwer musi szybko wznowić działanie. Naprawę należy kontynuować tylko wtedy, gdy znana jest jedna przyczyna problemu, a jej usunięcie wymaga pojedynczego polecenia. Przed przywróceniem należy skopiować /var/log/dist-upgrade/ poza serwer. W przeciwnym razie druga próba zakończy się w taki sam sposób.