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 usunęła 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 chcą się uruchomić", mogą wymagać zupełnie innych działań naprawczych.

Jak uzyskać dostęp do konsoli, gdy SSH nie odpowiada?

Otwórz panel sterowania dostawcy i wyszukaj konsolę. Najczęściej spotykane nazwy to VNC console, web console, noVNC oraz serial console. Jeśli dostępne są obie opcje, wybierz konsolę szeregową (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ę uruchamia. Szukanie jej w trakcie awarii utrudnia zachowanie spokoju niezbędnego do naprawy. Weryfikację tę należy wykonać w ramach pierwszych dziesięciu minut na nowym VPS, obok konfiguracji reguł zapory sieciowej 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 uruchamiane. Tryb ratunkowy to rozwiązanie awaryjne w przypadku uszkodzenia GRUB, a także sposób na skopiowanie danych z serwera, którego nie zamierzasz naprawiać.

Zazwyczaj konieczne będzie wykonanie twardego resetu z poziomu panelu, aby uzyskać dostęp do menu rozruchu, ponieważ nie można wykonać polecenia 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 podczas kolejnego uruchomienia należy spodziewać się sprawdzenia spójności systemu plików.

Jak wybrać starsze jądro 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 połączenie, więc zacznij naciskać wcześnie i kontynuuj tę czynność.

Gdy pojawi się menu, wybierz "Advanced options for Ubuntu". To podmenu wyświetla listę wszystkich zainstalowanych jąder, zaczynając od najnowszego, wraz z wpisem trybu odzyskiwania (recovery mode) dla każdego z nich. Wybierz drugi zwykły wpis, który odpowiada jądru poprzedzającemu najnowsze, i naciśnij Enter. Tryb odzyskiwania to inna funkcja: uruchamia minimalny system jednouserowy 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ź używaną wersję i zapisz numery.

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

Dane wyjściowe dpkg stanowią listę zainstalowanych jąder. Jeśli zawiera tylko jedną linię, brak jest jakiejkolwiek kopii zapasowej, co należy naprawić w pierwszej kolejności.

Menu GRUB nigdy się nie pojawia. Co teraz?

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

Istnieje również sytuacja odwrotna, w której menu jest widoczne na ekranie i oczekuje na interakcję, co wygląda jak zawieszenie systemu. GRUB rejestruje nieudany rozruch, a przy kolejnym starcie 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 wystąpił ten problem. Należy wybrać wpis i kontynuować.

Oba problemy należy naprawić, 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= robią to samo dla komunikatów startowych, które pojawiają się później. Dziesięć sekund opóźnienia przy każdym rozruchu to niska cena za menu, do którego można uzyskać dostęp o 2 w nocy.

Z jaką klasą awarii mam do czynienia?

Należy odczytać ostatnie dwadzieścia linii 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 albo pliku, który nie istnieje, a komunikaty jądra w ogóle się nie wyświetlają. Jądro nie zostało jeszcze uruchomione. Wynika to ze zmiany dysku lub partycji, albo 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ę, po czym następuje przejście do powłoki busybox, której znak zachęty to (initramfs), lub proces rozruchu kończy się paniką z powodu 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 odnajduje 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 identyfikator UUID. Należy skopiować ten UUID i porównać go później z wynikiem polecenia blkid.

Wolumin logiczny nie pojawia się. Jest to poprzednia klasa awarii z jedną konkretną przyczyną. W znaku zachęty (initramfs) należy uruchomić 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. Należy ręcznie aktywować grupy woluminów:

lvm vgchange -ay
ls /dev/mapper
exit

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

Brak jakichkolwiek komunikatów z 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 następuje przed uruchomieniem systemu Linux. Po przywróceniu dostępu należy sprawdzić, w jakim trybie faktycznie pracuje 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 obsługujące partycję systemową EFI zapisały dane w zwykłym, pustym katalogu. Oprogramowanie układowe uruchamia stary wpis rozruchowy tak długo, aż przestanie on być zgodny z zawartością dysku.

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

Czy uszkodzony jest pakiet jądra, czy initramfs?

Z poziomu konsoli oba przypadki wyglądają identycznie, lecz wymagają odmiennych działań naprawczych. Uruchom 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ć zbliżone, poprawne rozmiary. Brak pliku initrd lub jego znacznie mniejszy rozmiar w porównaniu do pozostałych wersji oznacza, że generowanie initramfs zakończyło się niepowodzeniem. Najczęstszą 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ąć, jakie zmiany zostały wprowadzone.

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 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 uszkodzony jest sam obraz jądra lub dpkg -l wskazuje stan pakietu inny 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 startuje

Jeśli każdy wpis w menu zawodzi, uruchom obraz ratunkowy dostawcy i napraw 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 dostępu przy kolejnym uruchomieniu

GRUB umożliwia jednorazowe uruchomienie wybranej pozycji, po czym automatycznie powraca do domyślnej konfiguracji. Należy ustawić domyślny wpis na jądro, które działa poprawnie, a następnie uruchomić nowe jądro tylko raz. W razie awarii, twardy reset z poziomu panelu sterowania przywróci system do stabilnego jądra, bez konieczności szybkiego reagowania w konsoli.

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

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

grub-editenv list powinno wyświetlić wybrany tytuł jako saved_entry. Ten wynik potwierdza działanie mechanizmu, ponieważ zapis wymaga zapisu do /boot/grub/grubenv, co w niektórych układach partycji może nie działać bez powiadomienia. Pozycja 0 to pierwszy element 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 wolno usuwać automatycznie. 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łapka tkwi w czasie wykonania operacji. Uruchomienie sudo apt autoremove --purge zaraz po restarcie do nowego jądra powoduje, że lista chronionych elementów zostaje zaktualizowana, więc starsze jądro, na którym polegałeś, przestaje być chronione. Na maszynie z podłączoną klawiaturą jest to niedogodność. Na serwerze bez monitora to różnica między wybraniem pozycji z menu a montowaniem dysku z obrazu ratunkowego.

Utrzymuj dwa jądra jako minimum, a trzy, gdy /boot ma wystarczająco dużo miejsca. Usuwaj stare wersje po nazwie, sprawdzając wcześniej uname -r, aby nigdy nie usunąć jądra, które jest aktualnie uruchomione:

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

Po zakończeniu 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 domyślnym był stary kernel, co pozwala ponowić aktualizację 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 wolumen, który kopiuje. Zrozumienie różnicy między migawkami VPS a rzeczywistymi kopiami zapasowymi decyduje o tym, co uratuje system w przypadku awarii wykraczającej poza problem z kernelem.

Ma to kluczowe znaczenie podczas aktualizacji wydania, w trakcie której kernel, narzędzia initramfs, bootloader oraz konfiguracja GRUB zmieniają się w jednym cyklu. Migawkę należy wykonać bezpośrednio przed rozpoczęciem aktualizacji systemu z Ubuntu 24.04 do 26.04, a nie poprzedniego dnia, aby punkt przywracania odpowiadał stanowi maszyny, która ma zostać zmodyfikowana.

Jak unattended-upgrades traktuje pakiety jądra

Narzędzie unattended-upgrades w systemie Ubuntu instaluje aktualizacje bezpieczeństwa bez pytania, a pakiety jądra trafiają do systemu przez repozytorium 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 uruchomi się ponownie, 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 wykonane tego dnia 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 zamienia tajemniczą awarię w dwuminutowy wybór w menu. Jeśli chcesz 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ż nie można zalogować się w celu poprawnego restartu. Podczas uruchamiania maszyny naciskaj wielokrotnie Esc lub przytrzymaj Shift w przypadku starszego BIOS, aby zatrzymać menu GRUB. Wybierz "Advanced options for Ubuntu" i wskaż wpis poniżej najnowszego jądra. Po uzyskaniu znaku zachęty do logowania, uruchom uname -r, aby potwierdzić aktualnie używane jądro, oraz dpkg -l 'linux-image-*', aby sprawdzić pozostałe zainstalowane wersje. 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 /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 /etc/default/grub, dodaj GRUB_TERMINAL="console serial", aby menu było dostępne również przez konsolę szeregową, a następnie uruchom 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?

Usuń najstarsze z nich, zachowując co najmniej dwa. Pełna partycja /boot stanowi samodzielny tryb awarii, ponieważ generowanie initramfs kończy się niepowodzeniem, co pozostawia system 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 polecenia sudo apt autoremove --purge na maszynie bez monitora, ponieważ lista chronionych jąder jest generowana ponownie przy każdej zmianie, a niefortunne wykonanie operacji może pozostawić system z jednym jądrem bez wpisu zapasowego w menu.

Czy unattended-upgrades może uszkodzić proces rozruchu?

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