Uruchamianie systemu Ubuntu Server w trybie awaryjnym: przewodnik ratunkowy krok po kroku

Serwer Ubuntu restartuje się po aktualizacji lub przerwie w zasilaniu, a następnie zatrzymuje się na monicie „Włączanie trybu awaryjnego”. SSH jest niedostępny, usługi nie działają, a konsola prosi o konserwację. Zazwyczaj oznacza to, że systemd nie mógł wykonać wymaganego kroku rozruchu, często z powodu niepowodzenia sprawdzania systemu plików lub braku możliwości znalezienia wymaganego punktu montowania. Potraktuj ten komunikat jako wskazówkę: zidentyfikuj uszkodzoną jednostkę przed edycją plików lub uruchomieniem polecenia naprawy.

Niniejszy podręcznik dotyczy konwencjonalnych instalacji Ubuntu Server z wykorzystaniem systemd. Polecenia i menu startowe mogą się różnić w Ubuntu Core, systemach szyfrowanych, obrazach w chmurze i serwerach zarządzanych przez dostawcę. Aktualne strony podręcznika Ubuntu opisują emergency.target jako minimalną powłokę, która nie uruchamia standardowych usług ani nie montuje standardowych systemów plików; w zależności od sposobu dotarcia do głównego systemu plików, może on być tylko do odczytu lub do odczytu i zapisu. Dlatego pierwszym krokiem jest inspekcja i utworzenie kopii zapasowej.

1. Przeczytaj opis błędu przed zmianą czegokolwiek

Zaloguj się do konsoli lokalnej lub konsoli dostawcy, jeśli zostaniesz o to poproszony. Na komputerze fizycznym podłącz klawiaturę i monitor; na serwerze wirtualnym użyj konsoli szeregowej dostawcy lub konsoli odzyskiwania. Zrób zdjęcie lub skopiuj cały błąd, zwłaszcza nazwę jednostki, taką jak systemd-fsck@dev-disk-by-uuid-....servicelub jednostkę montowania kończącą się na .mount. Brakujący identyfikator UUID, nieudane sprawdzenie systemu plików i uszkodzona usługa wymagają różnych rozwiązań.

Z poziomu powłoki awaryjnej sprawdź uszkodzone jednostki i aktualny dziennik rozruchu:

systemctl --failed
journalctl -xb

Szukaj pierwszego znaczącego błędu, a nie tylko ostatniego wiersza „dependency failed” (niepowodzenie zależności). Jeśli log identyfikuje montowanie, zanotuj jego punkt montowania i identyfikator UUID urządzenia. Jeśli identyfikuje usługę niezwiązaną z magazynem, nie zmieniaj jej /etc/fstablosowo; sprawdź tę konkretną jednostkę systemctl status unit-namei jej ostatnie komunikaty w logu.

2. Sprawdź, czy system plików główny pozwala na edycję

Przed edycją pliku konfiguracyjnego sprawdź, w jaki sposób montowany jest system plików główny:

findmnt /

Jeśli opcje wskazują ro, główny system plików jest tylko do odczytu. Jeśli system plików jest poza tym sprawny i musisz dokonać drobnej naprawy konfiguracji, zamontuj go ponownie w trybie do odczytu i zapisu:

mount -o remount,rw /

Uruchom findmnt /ponownie, aby potwierdzić zmianę. Jeśli ponowne montowanie się nie powiedzie, zatrzymaj i zapisz błąd. Tryb tylko do odczytu (root) może być odpowiedzią ochronną na problemy z systemem plików; wymuszanie zapisu lub wielokrotne ponawianie prób montowania może utrudnić odzyskiwanie. Użyj środowiska ratunkowego lub pomocy technicznej dostawcy, jeśli wolumin główny wydaje się uszkodzony.

3. Sprawdź dyski i porównaj je z /etc/fstab

Częstą przyczyną jest nieaktualny /etc/fstabwpis: dysk został usunięty, identyfikator UUID został zmieniony lub ścieżka montowania została błędnie wpisana. Najpierw wyświetl listę wykrytych systemów plików i ich identyfikatorów:

lsblk -f
blkid

Następnie należy odczytać konfigurację tabeli montowania:

cat /etc/fstab

Dopasuj każdy skonfigurowany UUID do wyniku polecenia lsblk -flub blkidi sprawdź, czy punkt montowania i typ systemu plików są poprawne. Nie zastępuj nazwy urządzenia, np. /dev/sdb1tylko bieżącą literą; kolejność urządzeń może się zmienić. Identyfikatory UUID są często bardziej stabilne, ale nadal muszą być zgodne z rzeczywistym systemem plików.

Plik jest tłumaczony na jednostki montowania systemd podczas rozruchu. Jego pola i opcje mają określone znaczenie, więc jeśli któryś wpis jest dla Ciebie niezrozumiały, /etc/fstabzapoznaj się z oficjalnym podręcznikiem Ubuntu fstab .

4. Tymczasowo pomiń brakujący opcjonalny uchwyt

Jeśli błędny wpis wskazuje na nieistotny dysk z danymi, którego celowo brakuje, wykonaj kopię zapasową /etc/fstab, a następnie zakomentuj tylko ten jeden wiersz, umieszczając go #na jego początku. Pozwoli to sprawdzić, czy brakujący element montowania jest blokerem rozruchu. Nie komentuj wpisu dotyczącego głównego systemu plików, /bootani wpisu dotyczącego zaszyfrowanego woluminu, jeśli nie rozumiesz układu pamięci masowej systemu.

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

Alternatywnie, jeśli dysk ma być opcjonalny w normalnym działaniu, rozważ nofailopcję montowania po sprawdzeniu zamierzonego zachowania. Używaj jej tylko w przypadku prawdziwie opcjonalnego montowania: dodanie jej do wymaganego woluminu systemowego może ukryć rzeczywistą awarię pamięci masowej. Sieciowe systemy plików mogą wymagać dodatkowych opcji specyficznych dla Systemd i zależności sieciowych; nie kopiuj opcji z niepowiązanej konfiguracji.

Po zakończeniu edycji poproś systemd o ponowne załadowanie wygenerowanych jednostek i przetestowanie pliku:

systemctl daemon-reload
mount -a

Odczytaj wszystkie dane wyjściowe. Czysty wynik nie dowodzi, że każda aplikacja może korzystać z zamontowanych danych, ale zgłoszony UUID, błąd składni lub błąd montowania wskazują, co należy jeszcze naprawić. Podręcznik systemd-fstab-generator wyjaśnia, jak systemd konwertuje wpisy fstab na jednostki montowania.

5. Napraw błędny UUID, ścieżkę lub opcję montowania

Jeśli dysk jest obecny, ale jego UUID jest inny, przed aktualizacją odpowiedniego pola sprawdź, czy zidentyfikowano właściwy system plików UUID=.... Sprawdź, czy katalog punktu montowania istnieje, typ systemu plików jest poprawny i czy opcje są prawidłowe dla tego systemu plików. Popraw po jednym wpisie na raz, a następnie uruchom ponownie systemctl daemon-reloadi mount -a.

W przypadku opcjonalnego wymiennego lub dodatkowego dysku danych, ustawienie odpowiedniej polityki opcjonalnego montowania może zapobiec blokowaniu rozruchu przez nieobecne urządzenie. W przypadku woluminu krytycznego, zamiast maskować awarię, napraw urządzenie, kabel, mapowanie szyfrowania lub identyfikator. Jeśli uszkodzona jednostka nazywa się urządzeniem LUKS lub LVM, sprawdź powiązane mapowanie i stan woluminu; nie zastępuj jej identyfikatora UUID partycją o podobnej nazwie.

6. Uruchom sprawdzanie systemu plików tylko wtedy, gdy cel jest odmontowany

Jeśli konsola zgłasza błędy systemu plików, przed naprawą zidentyfikuj typ systemu plików i urządzenie. Nie uruchamiaj narzędzia naprawczego dla zamontowanego systemu plików, zwłaszcza dla aktywnego systemu plików głównego. W podręczniku Ubuntu fsck opisano polecenie wrapper; poprawne opcje sprawdzania i naprawy zależą od systemu plików.

W przypadku partycji danych ext2, ext3 lub ext4 należy najpierw upewnić się, że nie jest zamontowana za pomocą findmnt. Jeśli jest zamontowana, należy ją odmontować przed sprawdzeniem. Typowe sprawdzenie ext4 w odpowiednim środowisku ratunkowym wygląda następująco:

sudo e2fsck -f /dev/DEVICE

Wymień /dev/DEVICEtylko po dopasowaniu prawidłowej partycji z lsblk -f. Przeczytaj pytania i status modułu sprawdzającego; nie dodawaj automatycznej odpowiedzi „tak na wszystko” bez zrozumienia ryzyka utraty danych. W przypadku systemu plików głównego, którego nie można odmontować z działającej powłoki awaryjnej, uruchom środowisko odzyskiwania na żywo lub dostawcy i sprawdź je w trybie offline. Btrfs, XFS i inne systemy plików używają różnych narzędzi i procedur naprawczych. W szczególności nie traktuj ogólnego fsckpolecenia jako dowodu na to, że każdy typ systemu plików został naprawiony.

7. Używaj GRUB-a lub odzyskiwania zewnętrznego tylko wtedy, gdy powłoka jest niedostępna

Jeśli serwer nigdy nie osiągnie powłoki awaryjnej, otwórz menu GRUB i wypróbuj wpis recovery dystrybucji, o ile jest dostępny. W standardowej instalacji Ubuntu do menu często można dotrzeć, przytrzymując klawisz Shift w starszych systemach BIOS lub naciskając klawisz Esc w systemach UEFI, ale hostowane maszyny wirtualne mogą korzystać z innego przepływu konsoli. W przypadku jednorazowego awaryjnego rozruchu systemd, administrator może edytować wybrany wpis GRUB i dodać go systemd.unit=emergency.targetdo wiersza poleceń jądra Linux. Zmiana dotyczy tylko tego rozruchu; usuń ją przed następnym normalnym rozruchem. Zobacz oficjalny opis menu GNU GRUB .

Jeśli nie można zamontować woluminu rozruchowego, należy go sprawdzić za pomocą środowiska Ubuntu Live lub systemu ratunkowego dostawcy chmury. Odblokuj zaszyfrowany dysk i aktywuj LVM tylko wtedy, gdy jest to zgodne z instalacją. Montowanie głównego systemu plików serwera z poziomu recovery wiąże się z dodatkowym ryzykiem; unikaj zapisywania danych, dopóki dysk i system plików nie zostaną zidentyfikowane. Ubuntu Core korzysta z własnego procesu odzyskiwania i nie można go naprawić, postępując ślepo zgodnie z instrukcjami desktopowego lub konwencjonalnego programu Server GRUB.

8. Uruchom ponownie i sprawdź naprawę

Gdy zgłoszona przyczyna zostanie usunięta, a testy montażowe zakończą się pomyślnie, należy ponownie uruchomić komputer:

reboot

Po uruchomieniu sprawdź, czy host osiągnął swój zwykły cel wielodostępności, czy zamontowano oczekiwane systemy plików i czy ważne usługi są aktywne:

systemctl is-system-running
systemctl --failed
findmnt --target /

Sprawdź oczekiwane punkty montowania danych za pomocą findmnt /path/to/mount, i potwierdź krytyczne usługi za pomocą systemctl status service-name. Jeśli tryb awaryjny powróci, ponownie sprawdź pierwszą awarię nowego rozruchu, zamiast powtarzać tę samą naprawę. Pomyślne uruchomienie oznacza, że ​​serwer zakończy normalny rozruch, a wymagana pamięć masowa i usługi będą dostępne; samo wyświetlenie monitu logowania nie wystarczy.

Aktualne zachowanie systemd można znaleźć w podręczniku jednostek specjalnych Ubuntu . Wersje pakietów i menu odzyskiwania mogą się różnić w zależności od wersji Ubuntu i platformy hostingowej, dlatego w przypadku różnic w poleceniu lub jednostce należy skorzystać z dokumentacji zainstalowanej wersji.