Proxmox w Hetznerze nie wstał po aktualizacji. Winne były Secure Boot i nazwy macierzy RAID

Aktualizacja, po której serwer przestał odpowiadać

Serwer pracował na Proxmoxie z dwoma dyskami NVMe połączonymi w programową macierz RAID1 i z rozruchem UEFI. Pierwotnie był to zwykły Debian, na którym później doinstalowano Proxmoxa. Przez lata działał stabilnie, dlatego aktualizacja do nowszej wersji Proxmoxa i Debiana, wykonywana w ramach bieżących prac, nie zapowiadała problemów.

Po restarcie serwer jednak nie wrócił: nie odpowiadał na ping, nie dało się połączyć przez SSH, co w efekcie sprawiło, że maszyny wirtualne klienta były niedostępne.

Diagnoza bez podglądu ekranu

W takiej sytuacji pierwszym narzędziem jest zwykle konsola KVM, czyli zdalny podgląd ekranu serwera. Tu pojawił się pierwszy problem: Hetzner wysyła dane dostępowe do KVM na adres właściciela konta, a wiadomości te trafiały u klienta na adres, na którym łatwo je było przeoczyć. Na początku miałem więc do dyspozycji tylko tryb Rescue, czyli system ratunkowy uruchamiany z sieci, z którego można zamontować dyski serwera i pracować na nich bez uruchamiania samego systemu.

Z poziomu Rescue sprawdziłem po kolei to, co najczęściej psuje rozruch po aktualizacji: system plików, zainstalowane jądro, obraz initramfs i konfigurację GRUB-a. Wszystko było na miejscu i wyglądało poprawnie. To oznaczało, że problem nie polega na brakujących lub uszkodzonych plikach, tylko na tym, jak te elementy współpracują ze sobą podczas startu.

Pierwsze znalezisko: macierze RAID pod niewłaściwą nazwą

Każda macierz mdadm ma zapisaną w swoich metadanych nazwę, zwykle powiązaną z nazwą serwera, i na jej podstawie system rozpoznaje przy starcie, które macierze są „jego”. Na tym serwerze macierze nosiły nazwę systemu ratunkowego Hetznera zamiast nazwy hosta – co samo w sobie było dość nietypowe.

mdadm --detail /dev/md3 | grep Name
              Name : rescue:3  (local to host rescue)

Zostały nadpisane podczas pracy w trybie Rescue, a ta sama błędna nazwa trafiła do konfiguracji mdadm. W takim stanie system startowy mógł nie złożyć macierzy, na których znajdują się partycja rozruchowa i główny system plików.

Przywróciłem właściwe nazwy w metadanych wszystkich macierzy, poprawiłem konfigurację mdadm i przebudowałem initramfs. Zmiana nazwy w metadanych wymaga zatrzymania macierzy i ponownego jej złożenia z nową nazwą. Wykonałem to z trybu Rescue dla każdej z czterech macierzy:

mdadm --stop /dev/md3
mdadm --assemble /dev/md3 --update=name --name=serwer:3 /dev/nvme0n1p4 /dev/nvme1n1p4
mdadm --detail /dev/md3 | grep Name
              Name : serwer:3

sed -i 's/name=rescue:/name=serwer:/' /etc/mdadm/mdadm.conf
update-initramfs -u -k all

Przy okazji wyszły jeszcze dwie rzeczy, które mogły zatrzymać start systemu: w pamięci firmware brakowało wpisów rozruchowych dla dysków, a w konfiguracji montowania znajdował się udział sieciowy z kopiami zapasowymi (Storage Box), który przy niedostępności sieci blokowałby uruchamianie. Udział sieciowy z kopiami zapasowymi warto montować z opcją nofail, dzięki której jego niedostępność nie blokuje startu systemu:

Odtworzyłem wpisy rozruchowe dla obu dysków, a montowanie kopii zapasowych zablokowałem do czasu poprawienia konfiguracji. Dodatkowo doinstalowałem serwer SSH do obrazu initramfs, żeby w razie kolejnego zatrzymania na wczesnym etapie startu móc zalogować się do serwera bez konsoli.

//uXXXXXX.your-storagebox.de/backup /mnt/backup cifs credentials=/root/.storagebox,nofail,_netdev 0 0

Serwer nadal zatrzymywał się na „Welcome to GRUB!”

Po tych poprawkach serwer wciąż nie startował. Gdy w końcu udało się uruchomić konsolę KVM z działającą klawiaturą, objaw stał się jasny: GRUB wyświetlał powitanie i zawieszał się, zanim zdążył odczytać swoją konfigurację. Nie reagował na klawiaturę, nie pokazywał menu ani wiersza poleceń.

To był ważny sygnał. Skoro GRUB zawieszał się, zanim sięgnął po konfigurację, jądro czy initramfs, wszystkie dotychczasowe poprawki, choć potrzebne, nie mogły tego naprawić. Kolejny raz przebudowałem i ponownie zainstalowałem GRUB-a na obu dyskach. Wynik był identyczny. Przyczyna musiała leżeć niżej – w tym, jak firmware serwera uruchamia sam program rozruchowy.

Secure Boot, którego nie dało się wyłączyć

Ustawienia firmware pokazały, że Secure Boot działa w trybie Custom, a BIOS serwera nie oferuje ani opcji jego wyłączenia, ani zarządzania kluczami. W tej konfiguracji standardowy, podpisany łańcuch rozruchu GRUB-a, który dociąga swoje moduły z dysku w trakcie startu, zawieszał się na samym początku. Najprostsze rozwiązanie, czyli wyłączenie Secure Boot, nie wchodziło w grę.

Samodzielny obraz GRUB-a przywrócił rozruch

Zamiast walczyć z ustawieniami firmware, przygotowałem nowy obraz GRUB EFI, w którym wszystkie potrzebne moduły i podstawowa konfiguracja są wbudowane w jeden plik. Taki obraz nie musi niczego doczytywać na wczesnym etapie startu: sam odnajduje partycję rozruchową po jej identyfikatorze i wczytuje z niej właściwą konfigurację.

insmod part_gpt
insmod mdraid1x
insmod ext2
search --no-floppy --fs-uuid --set=root <UUID-partycji-boot>
set prefix=($root)/grub
configfile ($root)/grub/grub.cfg

grub-mkstandalone -O x86_64-efi -o /boot/efi/EFI/BOOT/BOOTX64.EFI "boot/grub/grub.cfg=/tmp/embed.cfg"

Umieściłem go w domyślnej ścieżce rozruchu awaryjnego na partycji EFI, która dzięki macierzy RAID jest zapisana na obu dyskach.

Gotowy plik ma prawie 10 MB, zamiast około 150 KB standardowego programu rozruchowego, bo zawiera wszystkie moduły GRUB-a. Po restarcie serwer przeszedł przez etap GRUB-a, macierze złożyły się poprawnie, a Proxmox uruchomił się razem z maszynami wirtualnymi klienta. Na koniec ustawiłem domyślne jądro i zrobiłem kopię całej konfiguracji rozruchu, żeby w razie problemów można było szybko wrócić do działającego stanu.

Serwer działa, ale aktualizacje wymagają teraz ostrożności

Nowy obraz GRUB-a rozwiązał problem, ale ma istotną cechę: standardowe aktualizacje pakietów GRUB-a go nie odświeżają, a automatyczna reinstalacja GRUB-a mogłaby nadpisać działający rozruch i ponownie zablokować serwer. Dlatego zablokowałem aktualizacje tych pakietów.

To świadoma i udokumentowana decyzja: przy każdej większej aktualizacji, takiej jak planowane przejście na nową wersję Proxmox VE, blokadę trzeba zdjąć ręcznie, zaktualizować rozruch i przetestować restart, najlepiej z wcześniej uzgodnionym dostępem do konsoli KVM.

apt-mark hold grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin grub2-common
apt-mark showhold

Czego ten przypadek uczy właścicieli serwerów w Hetznerze

Większość problemów, które zatrzymały ten serwer, nie dawała żadnych objawów, dopóki serwer cały czas pracował i nie był w ogóle restartowany. Ujawnił je dopiero restart po aktualizacji. Gdyby doszło do niego nie podczas zaplanowanych prac, lecz po awarii zasilania albo jakiejś nieprzewidzianej awarii, serwer pozostałby niedostępny do czasu interwencji, a odzyskanie go bez sprawnego dostępu do konsoli trwałoby znacznie dłużej.

Przed restartem serwera w Hetznerze, a zwłaszcza po większej aktualizacji, warto sprawdzić:

• czy nazwy macierzy RAID są zgodne z nazwą hosta, zwłaszcza jeśli serwer był kiedyś naprawiany z trybu Rescue,
• czy w firmware są wpisy rozruchowe dla obu dysków,
• czy zasoby sieciowe w konfiguracji montowania nie zablokują startu, gdy będą niedostępne,
• w jakim trybie działa Secure Boot i czy rozruch go uwzględnia,
• kto otrzymuje dane dostępowe do konsoli KVM i czy te wiadomości do niego docierają.

Jeśli masz serwer w Hetznerze i nie masz pewności, czy uruchomi się po kolejnej aktualizacji, zajrzyj na stronę administracja serwerami Hetzner. Sprawdzę konfigurację i usunę problemy, zanim same się ujawnią i unieruchomią Twój serwer na znacznie dłużej.