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

Przykładowy scenariusz: Casey utrzymuje hipotetyczną maszynę wirtualną Ubuntu Server, która przechodzi w tryb awaryjny po ponownym uruchomieniu, wkrótce po dodaniu opcjonalnego montowania woluminu danych /etc/fstab. Casey ma dostęp do konsoli, ale nie ma sesji SSH. Zmiana montowania jest tropem, a nie udowodnioną przyczyną: tryb awaryjny może wystąpić po kilku awariach rozruchu, dlatego Casey sprawdza logi bieżącej maszyny przed wprowadzeniem jakichkolwiek zmian. Poniższe panele terminala pokazują przykładowe układy i dane wyjściowe, a nie rzeczywistą naprawę ani test.

Co oznacza tryb awaryjny

W instalacji Ubuntu Server z użyciem systemd, emergency.targeturuchamiana jest minimalna powłoka na konsoli głównej. Jest ona bardziej ograniczona niż rescue.target, która uruchamia system bazowy i montuje tylko niezbędne usługi. W zależności od ścieżki do trybu awaryjnego, główny system plików może być już zamontowany w trybie tylko do odczytu lub do odczytu i zapisu. Sprawdź to, zamiast zakładać którykolwiek z tych stanów. Zapoznaj się z dokumentacją nadrzędną systemu systemd special-target .

Najpierw rozróżnij monit. Powłoka awaryjna systemd zazwyczaj wyświetla komunikat „Welcome to Emergency Mode!” i może prosić o podanie hasła roota w celu konserwacji. Monit BusyBox, taki jak „ (initramfs)oznacza”, że boot nie przełączył się jeszcze na zainstalowany system plików root; monit „oznacza” grub>lub grub rescue>„oznacza problem z bootloaderem”. Wymagają one różnych ścieżek odzyskiwania. Jeśli konto root jest zablokowane lub serwer jest zdalny, skorzystaj z konsoli szeregowej/VNC dostawcy hostingu lub środowiska ratunkowego; SSH zazwyczaj nie jest dostępne na tym etapie. Nie naciskaj Ctrl+D, aby kontynuować, dopóki nie zrozumiesz i nie naprawisz zgłoszonego błędu.

Ratowanie krok po kroku

1. Zachowaj dostęp do konsoli i zapisz dokładną awarię

Pozostań w konsoli awaryjnej. Zanotuj nazwę ostatniego nieudanego montowania lub usługi oraz wszelkie ścieżki do urządzeń lub identyfikatory UUID wydrukowane nad monitem. fstabWarto sprawdzić ostatnią edycję Caseya, ale nie komentuj każdego błędnego wiersza ani nie uruchamiaj polecenia naprawy na podstawie samego słowa „awaryjny”. Jeśli system jest maszyną wirtualną, pozostaw konsolę dostawcy otwartą do momentu naprawy i następnego ponownego uruchomienia.

2. Odczytaj aktualny dziennik rozruchu i uszkodzone jednostki

W powłoce awaryjnej uruchom:

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-bOgranicza zapytanie dziennika do tego rozruchu i -p errfiltruje błędy według priorytetów i wyższych. Szukaj pierwszego istotnego błędu, a nie tylko ostatniej kaskady komunikatów o niepowodzeniu zależności. Jeśli jednostka montowania uległa awarii, zanotuj jej nazwę w postaci esejów i ścieżkę docelową; jeśli usługa uległa awarii, określ, czy jest to przyczyna, czy jedynie konsekwencja brakującego montowania. journalctl(1)Podręcznik Ubuntu opisuje filtrowanie rozruchu i jednostek.

3. Sprawdź miejsce zamontowania roota i dostępną przestrzeń

Przed edycją plików lub próbą ich naprawy sprawdź, w jaki sposób zamontowany jest główny system plików i czy w systemie nie zabrakło bloków lub inodów:

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

W danych findmntwyjściowych „ rooznacza tylko do odczytu”, a „ rwodczyt i zapis”. Ustawienie katalogu głównego tylko do odczytu może być celowe na etapie ścieżki odzyskiwania lub może świadczyć o problemach z systemem plików. Nie należy od razu wymuszać ponownego montowania w trybie odczytu i zapisu, jeśli logi jądra zgłaszają błędy wejścia/wyjścia lub systemu plików. Pełny system plików lub wyczerpana tablica inodów może również spowodować niepowodzenie niezwiązanych z nim usług i montowań. Podręcznik Ubuntu findmnt(8)opisuje , jak sprawdzać zamontowane systemy plików.

4. Sprawdź /etc/fstabi zweryfikuj identyfikatory urządzeń

Ponieważ Casey niedawno zmienił /etc/fstab, sprawdź zarówno jego składnię, jak i to, czy odwoływane urządzenia istnieją:

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verboseSprawdza wpisy fstab pod kątem problemów z analizą i użytecznością. Porównaj każdy wpis UUID=w podejrzanym wierszu z identyfikatorem UUID pokazanym przez lsblk -flub blkid. Sprawdź również punkt montowania, typ systemu plików i opcje. Skopiowany identyfikator UUID z innego dysku, urządzenie, które nie jest podłączone, lub nieprawidłowa opcja mogą uniemożliwić ukończenie wymaganego montowania. Nie zgaduj partycji, takiej jak /dev/sda1; nazwy urządzeń mogą się zmieniać między rozruchami.

5. Napraw tylko potwierdzony problem z mocowaniem

Jeżeli system plików główny jest zapisywalny, a sprawdzenie fstab wykryje nieprawidłowy wiersz, przed edycją należy wykonać kopię zapasową:

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

Popraw UUID lub inne pole dopiero po potwierdzeniu, że dane urządzenie jest przeznaczone do instalacji. Jeśli montowanie jest rzeczywiście opcjonalne i serwer powinien się uruchomić pomimo braku tego woluminu, można użyć wiersza fstab obsługującego systemd nofaili poczekać na urządzenie, na przykład:

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Zastąp symbol zastępczy prawdziwym identyfikatorem UUID i użyj rzeczywistego typu systemu plików. Nie dodawaj nofaildo roota, boot ani innych systemów plików wymaganych do prawidłowego działania komputera lub jego aplikacji. Z nofailopcją boot, boot jest kontynuowany nawet w przypadku niepowodzenia montowania, więc usługi zależne mogą nadal wymagać uwagi. Te opcje fstab są opisane w podręczniku Ubuntu systemd mount-unit .

Po edycji należy ponownie sprawdzić poprawność przed próbą zamontowania:

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

Użyj rzeczywistego punktu montowania w ostatnim poleceniu. Jeśli nadal występuje błąd, odczytaj nowy błąd i sprawdź, czy dysk jest podłączony i sprawny. Jeśli główny system plików jest tylko do odczytu, nie wymuszaj zmian bez powodu; użyj środowiska odzyskiwania dostawcy lub rozruchowego nośnika Ubuntu, aby bezpiecznie sprawdzić i edytować zainstalowany system.

6. Zbadaj niedziałającą usługę tylko wtedy, gdy dziennik wskazuje na jedną

Tryb awaryjny nie oznacza, że ​​każda awaria usługi spowodowała zatrzymanie rozruchu. Jeśli błąd dotyczy konkretnej usługi, sprawdź tę jednostkę i jej logi zamiast ją maskować lub wyłączać:

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

Zastąp example.servicedokładną nazwą jednostki. Sprawdź, czy nie brakuje pliku konfiguracyjnego, pliku wykonywalnego, danych uwierzytelniających lub wymaganego punktu montowania. Jeśli awaria występuje poniżej brakującego woluminu danych Casey, najpierw napraw ten punkt montowania, a następnie ponownie przetestuj usługę. Wyłączenie kluczowej usługi może ukryć objaw, a jednocześnie uniemożliwić korzystanie z serwera.

7. Traktuj błędy systemu plików jako zadanie naprawy offline

Jeśli dziennik jądra zgłasza uszkodzenie systemu plików lub błędy wejścia/wyjścia pamięci masowej, należy przerwać zapisy, o ile to możliwe, i zachować kopię zapasową lub migawkę dostawcy przed naprawą. Potwierdź dokładne urządzenie i system plików za pomocą lsblk -f. W przypadku systemu plików głównego, uruchom system ratunkowy dostawcy lub nośnik odzyskiwania/live Ubuntu, upewnij się, że partycja docelowa jest odmontowana i użyj narzędzia sprawdzającego odpowiedniego dla tego systemu plików. W przypadku ext2/3/4 tym narzędziem jest e2fsck; XFS, Btrfs i inne formaty mają różne procedury.

Nigdy nie uruchamiaj fsckani e2fsckna zamontowanym systemie plików, w tym na zamontowanym katalogu głównym tylko do odczytu. e2fsck(8)Podręcznik Ubuntu ostrzega, że ​​sprawdzanie zamontowanego systemu plików jest generalnie niebezpieczne, a wyniki nie są prawidłowe. Jeśli dysk zgłasza powtarzające się błędy wejścia/wyjścia, priorytetem powinno być odzyskanie danych lub skontaktowanie się z dostawcą pamięci masowej, a nie wielokrotne próby naprawy.

8. Wróć do normalnego rozruchu i sprawdź wynik

Po usunięciu potwierdzonej przyczyny należy ponownie uruchomić konsolę:

systemctl reboot

Po uruchomieniu Ubuntu sprawdź skonfigurowany domyślny cel, aktualny stan systemu, uszkodzone jednostki i nowy rozruch:

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

Jeśli celowo kontynuujesz bieżący rozruch, systemctl defaultprosi systemd o uruchomienie skonfigurowanego domyślnego systemu docelowego. Użyj tego polecenia dopiero po usunięciu błędu blokującego; nie naprawia nieprawidłowego zamontowania ani uszkodzonego systemu plików. systemctl get-defaultPokazuje skonfigurowany domyślny system docelowy; systemctl is-system-runninginformuje, czy systemd uważa bieżący stan za działający, zdegradowany, czy inny. Czyste odzyskiwanie oznacza, że ​​oczekiwane systemy plików są zamontowane, wymagane usługi są aktywne, a ta sama sytuacja awaryjna nie pojawia się ponownie po ponownym uruchomieniu.

(initramfs)Jeśli zamiast tego pojawi się monit

Nie wykonuj kroków systemd emergency-shell w initramfs BusyBox bezmyślnie. Etap initramfs próbuje zlokalizować i zamontować rzeczywisty system plików root przed przekazaniem kontroli zainstalowanemu systemowi. Zapisz dokładny błąd, sprawdź, czy oczekiwane urządzenie pojawia się w /devi /dev/disk/by-uuid, i porównaj wartość wiersza poleceń rozruchu root=z rzeczywistym UUID roota. Jeśli brakuje dysku lub zaszyfrowanego/LVM woluminu, użyj narzędzi do przechowywania i odzyskiwania dostawcy, aby to sprawdzić. Odbudowa initramfs lub zmiana parametrów GRUB bez zidentyfikowania brakującego urządzenia może utrudnić odzyskiwanie rozruchu.

W przypadku hipotetycznej maszyny wirtualnej Caseya, użytecznym rezultatem jest zweryfikowana przyczyna i korekta o wąskim zakresie: przywrócenie oczekiwanego woluminu opcjonalnego, skorygowanie jego potwierdzonego identyfikatora lub skonfigurowanie go jako opcjonalnego tylko wtedy, gdy obciążenie rzeczywiście na to pozwala. Następnie należy zweryfikować kolejne uruchomienie z konsoli przed zamknięciem sesji odzyskiwania.