VPS nie uruchamia się po aktualizacji jądra: jak naprawić

Co zrobić w pierwszej kolejności, gdy VPS nie uruchamia się po aktualizacji jądra

VPS, który nie uruchamia się po aktualizacji jądra, jest zazwyczaj możliwy do odzyskania w kilka minut, ponieważ aktualizacja nie usuwa jądra, które działało poprzedniego dnia. Ubuntu instaluje nowe jądro obok starego i zmienia jedynie wpis, który GRUB uruchamia domyślnie. Dlatego pierwszym krokiem nie jest naprawa. Należy wybrać poprzednie jądro w menu startowym, odzyskać dostęp do wiersza logowania, a następnie przeprowadzić diagnostykę z poziomu działającego systemu.

Naprawa tego problemu na serwerze różni się od naprawy laptopa, ponieważ nie jest podłączona klawiatura, a monitor nie wyświetla komunikatu o błędzie (kernel panic). SSH również nie odpowie, ponieważ maszyna nie osiągnęła etapu, w którym uruchamia się sshd. Wszystkie poniższe czynności wykonuje się za pośrednictwem konsoli dostarczonej przez dostawcę usług.

Przed wprowadzeniem jakichkolwiek zmian należy przeczytać zawartość konsoli. Tekst wyświetlony na ekranie określa klasę awarii, a dwa serwery, z których oba "nie uruchamiają się", mogą wymagać zupełnie innych działań naprawczych.

Jak uzyskać dostęp do konsoli, gdy SSH nie działa?

Otwórz panel sterowania dostawcy i wyszukaj konsolę. Typowe nazwy to VNC console, web console, noVNC oraz serial console. Jeśli dostępne są obie, wybierz serial console, ponieważ zapewnia ona tekst, który można przewijać i kopiować, podczas gdy widok VNC to jedynie obraz ekranu. Znajdź tę funkcję teraz, gdy maszyna działa poprawnie, i sprawdź, czy się otwiera. Szukanie jej podczas awarii utrudnia zachowanie spokoju niezbędnego do naprawy. Ta weryfikacja powinna znaleźć się w pierwszych dziesięciu minutach pracy z nowym VPS, obok reguł firewalla i kluczy SSH.

Większość paneli oferuje również tryb ratunkowy (rescue mode) lub obraz odzyskiwania. Uruchamia on niewielki system z sieci dostawcy i montuje dysk jako dodatkowe urządzenie, dzięki czemu żadne oprogramowanie z dysku nie jest wykonywane. Tryb ratunkowy to rozwiązanie awaryjne w przypadku uszkodzenia GRUB, a także sposób na skopiowanie danych z serwera, którego nie zamierzasz przywracać do działania.

Zazwyczaj konieczne będzie wykonanie twardego resetu z poziomu panelu, aby uzyskać dostęp do menu rozruchowego, ponieważ nie można uruchomić sudo reboot na maszynie, do której nie ma dostępu. Twardy reset jest równoznaczny z odcięciem zasilania. Systemy plików zostaną zamknięte w sposób nieprawidłowy, więc należy spodziewać się sprawdzenia spójności systemu plików przy następnym uruchomieniu.

Jak wybrać starszą wersję jądra w menu GRUB?

Obserwuj konsolę od momentu naciśnięcia przycisku reset. Naciskaj wielokrotnie Esc w ciągu pierwszych sekund lub przytrzymaj Shift na maszynie uruchamianej w trybie legacy BIOS. Okno czasowe jest krótkie, a podgląd konsoli często potrzebuje chwili na nawiązanie połączenia, dlatego zacznij naciskać wcześnie i kontynuuj tę czynność.

Gdy pojawi się menu, wybierz "Advanced options for Ubuntu". To podmenu wyświetla każde zainstalowane jądro, zaczynając od najnowszego, wraz z wpisem trybu odzyskiwania (recovery mode) dla każdego z nich. Wybierz drugi standardowy wpis, który odpowiada jądru poprzedzającemu najnowsze, i naciśnij Enter. Tryb odzyskiwania to inne narzędzie: uruchamia minimalny system jednousytkownikowy i służy do prac naprawczych, a nie do przywracania działania usług.

Jeśli starsze jądro uruchomi się, serwer ponownie działa. Potwierdź aktualną wersję i zapisz numery.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Dane wyjściowe dpkg stanowią listę zainstalowanych jąder. Jeśli zawierają tylko jedną linię, brak jest jakiegokolwiek mechanizmu awaryjnego i jest to pierwsza rzecz, którą należy naprawić.

Menu GRUB nie pojawia się. Co teraz?

Obrazy chmurowe zawierają konfigurację ukrywającą menu. Obrazy Ubuntu zazwyczaj ustawiają limit czasu na 0 w pliku w /etc/default/grub.d/, przez co najnowsze jądro uruchamia się natychmiast i nie ma możliwości wyboru.

Występuje również sytuacja odwrotna, w której menu pozostaje na ekranie i oczekuje, co wygląda jak zawieszenie systemu. GRUB rejestruje nieudany rozruch, a przy kolejnym uruchomieniu może utrzymywać menu otwarte do momentu naciśnięcia klawisza. Na maszynie bez podłączonej klawiatury to oczekiwanie nigdy się nie kończy. Jeśli konsola wyświetla menu i nic się nie dzieje, oznacza to, że właśnie to się stało. Należy wybrać wpis i kontynuować.

Oba problemy należy rozwiązać, gdy maszyna jest sprawna. Edytuj /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Następnie zastosuj zmiany i sprawdź, czy edycja została zachowana, ponieważ pliki w /etc/default/grub.d/ są odczytywane po /etc/default/grub i mogą nadpisać ustawienia.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" wysyła menu do konsoli graficznej oraz portu szeregowego, dzięki czemu pojawia się ono w każdym podglądzie udostępnianym przez panel. Argumenty jądra console= wykonują to samo dla komunikatów startowych, które następują później. Dziesięć sekund opóźnienia przy każdym rozruchu to niewielka cena za menu, do którego można uzyskać dostęp o 2 w nocy.

Z jaką klasą awarii mam do czynienia?

Przeanalizuj ostatnie dwadzieścia linii dziennika przed zatrzymaniem się konsoli. Cztery wzorce obejmują większość zdarzeń występujących po aktualizacji jądra.

GRUB nie może odnaleźć własnych plików. Pojawia się znak zachęty grub rescue> lub błąd dotyczący partycji lub pliku, który nie istnieje, a komunikaty jądra w ogóle się nie wyświetlają. Jądro nie zostało jeszcze uruchomione. Sytuacja ta wynika ze zmian na dysku lub partycjach, albo z zapisania bootloadera na niewłaściwym urządzeniu, a nie z samego pakietu jądra.

Jądro startuje, ale nie może zamontować systemu plików root. Komunikaty jądra przewijają się, a następnie system przechodzi do powłoki busybox z znakiem zachęty (initramfs) lub kończy działanie błędem typu panic z informacją o niemożności zamontowania głównego systemu plików. Jądro zostało załadowane. Initramfs, czyli mały tymczasowy system plików root, który lokalizuje i montuje właściwy system plików, nie odnalazł dysku. W systemie Ubuntu tej powłoce zazwyczaj towarzyszy komunikat o przerwaniu oczekiwania na urządzenie root, zawierający poszukiwany UUID. Skopiuj ten UUID i porównaj go później z wyjściem polecenia blkid.

Wolumin logiczny nie pojawia się. Jest to poprzednia klasa awarii z jedną konkretną przyczyną. W znaku zachęty (initramfs) uruchom ls /dev/mapper. Jeśli jedynym wpisem jest control, oznacza to, że żaden wolumin LVM (logical volume manager) nie został aktywowany, więc urządzenie root jeszcze nie istnieje. Uruchom grupy woluminów ręcznie:

lvm vgchange -ay
ls /dev/mapper
exit

exit przekazuje kontrolę z powrotem do skryptu initramfs, który ponawia próbę montowania. Jeśli system uruchomi się poprawnie, oznacza to, że w nowym obrazie initramfs brakuje komponentów LVM. Naprawa polega na przebudowaniu tego obrazu, a nie na ingerencji w jądro.

Brak jakichkolwiek komunikatów systemu Linux. Konsola wyświetla tekst oprogramowania układowego, powłokę UEFI (unified extensible firmware interface), pusty ekran bez komunikatów jądra lub pętlę restartów. Awaria występuje przed uruchomieniem systemu Linux. Po odzyskaniu dostępu sprawdź, w jakim trybie faktycznie działa serwer, ponieważ wiele instancji VPS uruchamia się w trybie legacy BIOS i w ogóle nie korzysta ze ścieżki EFI:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Niezamontowany /boot/efi podczas aktualizacji jest częstą przyczyną na maszynach UEFI, ponieważ pakiety zarządzające partycją systemową EFI zapisały dane w zwykłym, pustym katalogu. Oprogramowanie układowe kontynuuje uruchamianie starego wpisu rozruchowego, dopóki wpis ten przestaje być zgodny z zawartością dysku.

Jeden dodatkowy wzorzec w ogóle nie jest awarią rozruchu. Jeśli uzyskasz dostęp do powłoki root z informacją, że system jest w trybie awaryjnym (emergency mode), oznacza to, że jądro wystartowało, ale przestrzeń użytkownika (userspace) została zatrzymana. Zazwyczaj oznacza to błędną linię w /etc/fstab lub system plików, który nie przeszedł weryfikacji. Uruchom journalctl -xb w tej powłoce i odczytaj nazwę jednostki, która uległa awarii.

Czy uszkodzony jest pakiet jądra, czy initramfs?

Z poziomu konsoli oba problemy wyglądają identycznie, lecz wymagają odmiennych metod naprawy. Uruchom system ze starszą wersją jądra, a następnie porównaj pliki.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Dla każdej zainstalowanej wersji wymagany jest jeden plik vmlinuz- oraz odpowiadający mu initrd.img-, przy czym oba powinny mieć wiarygodne rozmiary. Brak pliku initrd lub rozmiar znacznie mniejszy niż w przypadku sąsiednich wersji oznacza, że generowanie initramfs zakończyło się niepowodzeniem. Typową przyczyną jest zapełnienie partycji /boot, a dowody znajdują się w dziennikach pakietów:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

Plik history.log zawiera również dokładną listę pakietów zainstalowanych podczas ostatnich operacji wraz z datami, co pozwala rozstrzygnąć wątpliwości dotyczące wprowadzonych zmian.

Jeśli partycja /boot jest pełna, najpierw zwolnij miejsce, a następnie przebuduj obraz dla wymaganej wersji i odśwież menu. Użyj ciągu znaków wersji uzyskanego z własnego polecenia ls, ponieważ poniższy symbol zastępczy nie odnosi się do rzeczywistego wydania:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

Ostatnie polecenie ls służy do weryfikacji. Plik o standardowym rozmiarze oznacza, że obraz został poprawnie utworzony. Jeśli natomiast uszkodzony jest sam obraz jądra lub dpkg -l wskazuje, że pakiet znajduje się w stanie innym niż ii, należy przeinstalować pakiet:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Naprawa z trybu ratunkowego, gdy żaden kernel nie uruchamia się

Jeśli każdy wpis w menu kończy się niepowodzeniem, należy uruchomić obraz ratunkowy dostawcy i naprawić dysk z zewnątrz. Dysk jest widoczny jako niezamontowane urządzenie, więc żadne procesy na nim nie działają i nie blokują operacji.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Testowanie nowego jądra bez ryzyka utraty możliwości kolejnego rozruchu

Program GRUB umożliwia jednorazowe uruchomienie wybranej pozycji, po czym następuje powrót do domyślnej konfiguracji. Należy ustawić domyślny rozruch na znane i stabilne jądro, a następnie uruchomić nowe jądro tylko dla jednej sesji. W przypadku awarii, twardy reset z poziomu panelu przywróci system do stabilnego jądra, bez konieczności precyzyjnego wyczucia momentu na wybór w menu konsoli.

Ustaw GRUB_DEFAULT=saved w pliku /etc/default/grub, wykonaj sudo update-grub, a następnie wyświetl listę tytułów pozycji, aby móc wskazać właściwą:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

Polecenie grub-editenv list powinno wyświetlić wybrany tytuł jako saved_entry. Ten wynik jest potwierdzeniem poprawnego działania mechanizmu, ponieważ zapis wymaga zapisu w pliku /boot/grub/grubenv, co w niektórych układach partycji może nie działać bez zgłaszania błędów. Pozycja 0 to pierwsza opcja w menu, czyli najnowsze jądro. Używanie tytułów jest bezpieczniejsze niż numerów, ponieważ numery zmieniają się przy każdej instalacji lub usunięciu jądra.

Dlaczego autoremove jest ryzykowne na serwerze bez monitora

APT przechowuje listę pakietów jądra, których nie może samodzielnie usunąć. Sprawdź swoją listę:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Plik ten jest generowany ponownie przy każdej zmianie pakietów jądra i chroni aktualnie uruchomione jądro oraz najnowsze wersje. Pułapką jest czas wykonania operacji. Uruchomienie sudo apt autoremove --purge zaraz po restarcie do nowego jądra powoduje aktualizację listy chronionej, przez co starsze jądro, na którym polegałeś, przestaje być chronione. Na maszynie z podłączoną klawiaturą jest to niedogodność. Na serwerze bez monitora oznacza to różnicę między wybraniem wpisu w menu a koniecznością montowania dysku z obrazu ratunkowego.

Utrzymuj dwa jądra jako minimum, a trzy, gdy /boot ma wystarczająco dużo miejsca. Usuwaj stare jądra po nazwie, po uprzednim sprawdzeniu uname -r, aby nigdy nie usunąć wersji, na której aktualnie pracuje system:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

Po wykonaniu tej operacji uruchom ponownie ostatnie polecenie. Zmniejszenie liczby z trzech do dwóch oznacza poprawne oczyszczenie. Zmniejszenie do jednego oznacza awarię oczekującą na kolejny restart.

Wykonanie migawki przed aktualizacją

Migawka wykonana przed apt upgrade stanowi jedyną ścieżkę odzyskiwania, która nie wymaga uruchamiania żadnych dodatkowych narzędzi. Jej przywrócenie powoduje powrót dysku do stanu, w którym starsze jądro było domyślne, co pozwala na ponowienie aktualizacji przy otwartej konsoli. Migawki działającej maszyny są spójne w przypadku awarii (crash consistent), co oznacza, że rejestrują stan dysku tak, jakby nastąpiło nagłe odcięcie zasilania. Dlatego, jeśli dostawca wspiera migawki offline, należy najpierw wyłączyć serwer. Migawka nie jest kopią zapasową, ponieważ zazwyczaj znajduje się na tej samej infrastrukturze co kopiowany wolumen. Zrozumienie różnicy między migawkami VPS a rzeczywistymi kopiami zapasowymi decyduje o tym, co uratuje system w przypadku awarii wykraczającej poza samo jądro.

Ma to kluczowe znaczenie podczas aktualizacji wydania, w trakcie której jądro, narzędzia initramfs, bootloader oraz konfiguracja GRUB zmieniają się w jednym cyklu. Migawkę należy wykonać bezpośrednio przed rozpoczęciem aktualizacji z Ubuntu 24.04 do 26.04, a nie poprzedniego dnia, aby punkt przywracania odpowiadał stanowi maszyny, która ma zostać zmodyfikowana. Jeśli aktualizacja nie została jeszcze zaoferowana na serwerze, przyczyną jest harmonogram, a nie błędna konfiguracja, ponieważ przejście między wydaniami LTS otwiera się dopiero w momencie pierwszego wydania punktowego, 26.04.1.

Jak unattended-upgrades obsługuje pakiety jądra

Narzędzie unattended-upgrades w systemie Ubuntu instaluje aktualizacje bezpieczeństwa bez pytania, a pakiety jądra trafiają do systemu przez kanał security, tak jak wszystkie inne. Wynikają z tego dwie konsekwencje.

Po pierwsze, nowe jądro jest instalowane, ale nie jest uruchomione. Jądro zaczyna działać dopiero po restarcie. Pojawia się plik /var/run/reboot-required, a /var/run/reboot-required.pkgs wskazuje, co wywołało żądanie restartu, jednak nic nie zostanie zrestartowane, dopóki nie włączysz Unattended-Upgrade::Automatic-Reboot w pliku /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

Po drugie, ten odstęp czasowy maskuje przyczynę problemów. Serwer może zainstalować jądro w marcu, a zrestartować się w czerwcu z zupełnie innego powodu, po czym nie wstać. Zmiana, która uniemożliwiła rozruch, ma trzy miesiące, więc żadne działanie z dnia awarii jej nie wyjaśnia. W /var/log/apt/history.log znajdziesz informacje o przebiegu instalacji jądra, na którym obecnie występuje błąd.

Restartuj system celowo, w wybranym przez siebie dniu, mając otwarte okno konsoli. Ten jeden nawyk zmienia tajemniczą awarię w dwuminutowy wybór w menu. Jeśli chcesz korzystać z automatyzacji bez niespodzianek, pozostaw włączone automatyczne instalacje, ale wyłącz automatyczne restarty. Zobacz jak skonfigurować unattended-upgrades w Ubuntu, aby poznać dokładne ustawienia. Wstrzymanie pakietów jądra za pomocą sudo apt-mark hold linux-image-generic całkowicie je blokuje, co jednocześnie zatrzymuje poprawki bezpieczeństwa jądra, więc traktuj to jako świadomy kompromis, a nie jako środek bezpieczeństwa.

FAQ

Jak uruchomić starsze jądro na VPS bez dostępu do klawiatury?

Otwórz konsolę dostawcy (VNC lub szeregową) i wymuś twardy reset z poziomu panelu sterowania, ponieważ poprawne zalogowanie się w celu restartu jest niemożliwe. Podczas ponownego uruchamiania maszyny naciskaj wielokrotnie Esc lub przytrzymaj Shift w przypadku starszego BIOS-u, aby zatrzymać menu GRUB. Wybierz "Advanced options for Ubuntu" i wskaż wpis znajdujący się poniżej najnowszego jądra. Po uzyskaniu znaku zachęty do logowania wykonaj uname -r, aby potwierdzić aktualnie używane jądro, oraz dpkg -l 'linux-image-*', aby sprawdzić, jakie inne wersje są zainstalowane. Diagnostykę przeprowadź dopiero po ponownym uruchomieniu systemu.

Dlaczego na moim VPS w ogóle nie widać menu GRUB?

Obrazy chmurowe zazwyczaj ustawiają limit czasu GRUB na 0 w pliku w lokalizacji /etc/default/grub.d/, przez co najnowsze jądro uruchamia się bez możliwości przerwania procesu. Ustaw GRUB_TIMEOUT=10 oraz GRUB_TIMEOUT_STYLE=menu w pliku /etc/default/grub, dodaj GRUB_TERMINAL="console serial", aby menu było dostępne również przez konsolę szeregową, a następnie wykonaj sudo update-grub. Zweryfikuj ustawienia za pomocą grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, ponieważ pliki w tym katalogu są odczytywane po pliku głównym i mogą nadpisać wprowadzone zmiany.

Czy należy usuwać stare jądra, aby zwolnić miejsce w /boot?

Usuwaj tylko najstarsze wersje, zachowując co najmniej dwie. Pełna partycja /boot stanowi przyczynę awarii, ponieważ generowanie initramfs kończy się niepowodzeniem, a system pozostaje z jądrem bez działającego obrazu. Usuwaj pakiety przez podanie dokładnej nazwy po sprawdzeniu uname -r, aby bieżące jądro nigdy nie zostało wybrane do usunięcia. Unikaj masowego polecenia sudo apt autoremove --purge na maszynie bez monitora, ponieważ lista chronionych jąder jest generowana ponownie przy każdej zmianie, a niefortunne wykonanie polecenia może pozostawić system z jednym jądrem bez wpisu zapasowego w menu.

Czy unattended-upgrades może uniemożliwić uruchomienie systemu?

Usługa ta może zainstalować jądro, które później nie uruchomi się poprawnie, jednak nie restartuje maszyny, chyba że opcja Unattended-Upgrade::Automatic-Reboot jest ustawiona na true w /etc/apt/apt.conf.d/50unattended-upgrades. Typowy scenariusz to opóźniona awaria: jądro instaluje się podczas automatycznej aktualizacji, pojawia się /var/run/reboot-required, a problem ujawnia się dopiero przy kolejnym restarcie po kilku tygodniach. Restartuj system świadomie, mając otwartą konsolę, i odczytaj /var/log/apt/history.log, aby sprawdzić, która sesja zainstalowała jądro, z którego korzystasz.