Jak naprawić błąd rozruchu /etc/fstab za pomocą journalctl
Poziom: Początkujący / Średnio zaawansowany
Szacowany czas: ~15 minut
Cel: Przeanalizować logi systemowe za pomocą journalctl, aby zidentyfikować i naprawić błąd w /etc/fstab, który uniemożliwia uruchomienie systemu.
Wprowadzenie
Prosty błąd składni w /etc/fstab może uniemożliwić uruchomienie serwera i przenieść Cię do awaryjnej powłoki konserwacyjnej. Odzyskanie systemu wymaga analizy logów systemowych, aby wskazać dokładne miejsce awarii. W tym poradniku użyjemy journalctl do przeszukiwania dziennika systemd i wyświetlenia logów systemowych generowanych przez Linuksa podczas uruchamiania. Zrozumienie logów systemd to kluczowa umiejętność w zarządzaniu logami w Linuksie, zapewniająca szybkie odzyskiwanie i wysoką dostępność usług. Podstawowa znajomość poleceń journalctl jest potrzebna, aby zlokalizować punkt montowania, który spowodował awarię.
Zarządzanie logami w Linuksie i stos logowania
Zanim przejdziesz do odzyskiwania systemu, warto zrozumieć zaangażowane komponenty. Systemd (system init i menedżer usług w Linuksie) korzysta z Systemd-journald (usługi systemowej, która zbiera i przechowuje dane logów). Usługa ta gromadzi każdy log (zapis zdarzeń zachodzących w systemie) w dzienniku (Journal) (binarnych danych logów przechowywanych przez Systemd-journald). Obejmują one logi systemowe (zapisy zdarzeń i zmian stanu w skali całego systemu), logi rozruchu (zapisy procesu uruchamiania systemu) oraz logi jądra (komunikaty generowane przez jądro systemu operacyjnego).
W zależności od konfiguracji mogą to być logi nietrwałe (logi przechowywane w pamięci, tracone po ponownym uruchomieniu) lub logi trwałe (logi, które przetrwają restarty systemu, zwykle zapisywane na dysku). Dziennik stale rośnie, dlatego rotacja logów (proces archiwizowania i zarządzania starymi plikami logów w celu oszczędzania miejsca na dysku) jest obsługiwana automatycznie przez systemd.
Wymagania wstępne
Przed rozpoczęciem upewnij się, że spełnione są następujące warunki:
- System operacyjny: Przetestowano na Ubuntu 22.04/24.04 LTS, Debian 12/13, AlmaLinux/Rocky 9/10
- Dostęp: Bezpośredni dostęp do konsoli (IPMI, VNC lub konsola fizyczna), aby dostać się do powłoki awaryjnej
- Wymagana wiedza: Swobodna obsługa wiersza poleceń Linuksa i podstawowa edycja tekstu
W domyślnych instalacjach Ubuntu i Debiana konto root jest zablokowane. Ustaw hasło roota z wyprzedzeniem poleceniem sudo passwd root, w przeciwnym razie nie zalogujesz się do trybu awaryjnego.
Instancje VPS są często dostarczane z domyślnie włączonym użytkownikiem root.
Krok 1: Rozpoznanie awarii rozruchu
Błąd składni, literówka lub brakujące urządzenie w /etc/fstab uruchomią tryb awaryjny, wstrzymają proces rozruchu i wyświetlą komunikat podobny do poniższego:
Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode. Give root password for maintenance (or press Control-D to continue):
Wpisz hasło roota, aby przejść do wiersza poleceń. Na tym etapie niektóre systemy plików mogą nie być zamontowane lub mogą być zamontowane tylko do odczytu.
Krok 2: Użycie journalctl do wyświetlenia i analizy logów systemowych generowanych przez Linuksa
Aby zidentyfikować przyczynę awarii, musimy sprawdzić logi z bieżącego rozruchu.
Wykonaj poniższe polecenie:
sudo journalctl -xb
Używamy tu Journalctl (narzędzia wiersza poleceń do przeszukiwania dziennika systemd). To jedno z najważniejszych poleceń journalctl. Nakazuje narzędziu wyświetlić logi bieżącego rozruchu (-b) oraz dołączyć dodatkowy tekst objaśniający (-x).
Wynik może być ogromny. Musimy przeprowadzić filtrowanie logów (zawężanie wyniku do wpisów spełniających określone kryteria), aby znaleźć błąd.
Aby przeszukiwać zawartość pagera (który korzysta z less), wpisz /fstab lub /mount i naciśnij Enter.
Fragment oczekiwanego wyniku:
-- Subject: A start job for unit mnt-data.mount has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- A start job for unit mnt-data.mount has finished with a failure. -- -- The job identifier is 123 and the job result is failed.
Oznacza to, że nie powiodło się działanie jednostki (unit) (pliku konfiguracyjnego opisującego, jak zarządzać zasobem w systemd) odpowiedzialnej za zamontowanie /mnt/data. Konkretnie nie udało się uruchomić jednostki montowania (mount unit) (pliku konfiguracyjnego jednostki, który zawiera informacje o procesie zarządzanym przez systemd).
Spacją przewijasz o stronę w dół, a klawiszem q zamykasz przeglądarkę logów.
Krok 3: Filtrowanie logów systemd w celu znalezienia konkretnych błędów
Jeśli przewijanie całego logu rozruchu jest zbyt wolne, możemy analizować logi za pomocą journalctl, stosując konkretne filtry.
Wykonaj poniższe polecenie, aby zobaczyć tylko błędy o wysokim priorytecie:
sudo journalctl -p err -b
Oczekiwany wynik:
May 23 10:00:01 server systemd[1]: Failed to mount mnt-data.mount - /mnt/data. May 23 10:00:01 server systemd[1]: Dependency failed for Local File Systems.
Komunikat Dependency failed for Local File Systems pojawia się tylko podczas rozruchu, a nie przy ręcznym uruchomieniu systemctl start.
Dzięki filtrowaniu logów w journalctl według priorytetu (-p err) eliminujemy komunikaty informacyjne.
Możemy też bezpośrednio sprawdzić logi usługi, jeśli znamy dokładną jednostkę, która zawiodła. Wykonaj:
sudo journalctl -u mnt-data.mount
Gdy analizujesz logi za pomocą journalctl na poziomie jednostki, izolujesz dokładny problem konfiguracyjny. Inną metodą filtrowania w journalctl jest określenie przedziału czasu, ale w przypadku problemów z rozruchem filtrowanie według jednostki jest najskuteczniejsze.
Krok 4: Naprawa błędu w /etc/fstab
Skoro dziennik systemd potwierdził, że problemem jest punkt montowania /mnt/data, musimy poprawić plik konfiguracyjny.
Najpierw spróbuj edytować plik. Jeśli podczas zapisu pojawi się błąd Read-only file system, musisz ponownie zamontować główny system plików w trybie do odczytu i zapisu, ponieważ tryb awaryjny często montuje go tylko do odczytu:
sudo mount -o remount,rw /
Następnie wykonaj kopię zapasową pliku konfiguracyjnego przed wprowadzeniem zmian:
sudo cp /etc/fstab /etc/fstab.bak
Potem otwórz plik (w systemach opartych na RPM, takich jak AlmaLinux, Rocky czy RHEL, nano może nie być domyślnie zainstalowany, więc najpierw zainstaluj go poleceniem sudo dnf install -y nano):
sudo nano /etc/fstab
Znajdź wiersz odwołujący się do /mnt/data (poprawny UUID znajdziesz poleceniem blkid):
UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defualts 0 2
Zwróć uwagę na literówkę: defualts zamiast defaults. Popraw literówkę:
UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defaults 0 2
Zapisz plik i zamknij edytor. Następnie przeładuj konfigurację menedżera systemd, aby systemd uwzględnił zmiany wprowadzone w /etc/fstab:
sudo systemctl daemon-reload
Zawsze weryfikuj UUID-y i składnię w /etc/fstab. Nieprawidłowy wpis spowoduje, że przy następnym uruchomieniu system ponownie przejdzie do powłoki awaryjnej.
Weryfikacja
Przed ponownym uruchomieniem zweryfikuj składnię /etc/fstab za pomocą findmnt:
findmnt --verify
Jeśli nie zgłoszono błędów, sprawdź, czy punkt montowania działa:
Wykonaj:
sudo mount -a
Jeśli polecenie nie zwraca żadnego wyniku, składnia jest poprawna, a montowanie się powiodło. Jeśli nadal występuje błąd, polecenie wyświetli komunikat o błędzie. W Debianie 13 i AlmaLinux 10 komunikat może wskazywać dokładną przyczynę (np. Unknown parameter 'defualts'), ale w Ubuntu 24.04 wynik jest często ogólny (wrong fs type, bad option). W Ubuntu wykonaj sudo dmesg | tail, aby uzyskać szczegóły.
Po weryfikacji wyjdź z powłoki awaryjnej, aby kontynuować rozruch, lub uruchom system ponownie:
sudo systemctl reboot
Po restarcie możesz ponownie sprawdzić logi usługi poleceniami journalctl, aby upewnić się, że montowanie powiodło się bez błędów podczas zwykłego rozruchu:
sudo journalctl -u mnt-data.mount -b
Rozwiązywanie problemów
- Powłoka awaryjna jest niedostępna: Jeśli konto root jest zablokowane i nie możesz uzyskać dostępu do powłoki awaryjnej, musisz uruchomić serwer z nośnika Live USB lub środowiska odzyskiwania, zamontować partycję główną i edytować
/etc/fstabbezpośrednio stamtąd. - UUID uległ zmianie: Jeśli sformatowano partycję lub wymieniono dysk, UUID się zmieni. Użyj
sudo blkid, aby znaleźć nowy UUID, i odpowiednio zaktualizuj/etc/fstab. - Zapobieganie awariom rozruchu przez dyski nieistotne: W przypadku woluminów niebędących głównymi ani systemowymi (takich jak dyski kopii zapasowych lub danych) dodaj do wpisu w
/etc/fstabopcję montowanianofail(np.ext4 defaults,nofail 0 2). Dzięki temu systemd kontynuuje rozruch, nawet jeśli urządzenia nie uda się zamontować.
Wycofanie zmian
Jeśli serwer uruchomił się poprawnie, ale zmodyfikowany wiersz /mnt/data powoduje nieoczekiwane zachowanie aplikacji, możesz cofnąć montowanie, komentując ten wiersz w /etc/fstab:
sudo sed -i 's|^UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|#UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|' /etc/fstab
Następnie odmontuj wolumin, aby przywrócić poprzedni stan:
sudo umount /mnt/data
Podsumowanie
Skuteczne zarządzanie logami w Linuksie w dużej mierze zależy od umiejętności poruszania się po logach systemd. Dzięki journalctl możesz wyświetlać logi systemowe generowane przez Linuksa, aby sprawnie je analizować i odzyskiwać system po krytycznych awariach rozruchu, takich jak błędna konfiguracja /etc/fstab. Opanowanie tych narzędzi pozwala utrzymać dostępność i diagnozować złożone problemy w całej infrastrukturze.
Wersja dokumentu: 1.0
Ostatnia aktualizacja: maj 2026
Właściciel: Zespół dokumentacji technicznej
