Chyba każdy Linuksowiec korzystający z dystrybucji z systemd ujrzał kiedyś taki napis w trakcie rozruchu:
Welcome to emergency mode! After login in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot in default mode.
Okazuje się, że rozwiązanie problemu może być bardzo proste.
Po pierwsze – warto użyć sugerowanego journalctl -xb i kliknąć End (journalctl ładuje logi do less’a) aby przejść na sam koniec. Jeśli błąd nam nic nie mówi, albo nie ma nic do rzeczy z rozruchem, jak chociażby:
systemd[456]: Failed at step EXEC spawning /bin/plymouth: No such file or directory Subject: Process /bin/plymouth coud not be executed and failed Defined by: systemd
to nawet jeśli faktycznie przykładowy /bin/plymouth nie istnieje należy się zastanowić, czy nie ma problemu z montowaniami jakiejkolwiek partycji. Jeśli mamy w /etc/fstab na sztywno wpisanego jakiegoś NTFSa (np. wspólną dla Win i Linuks partycję na dane) to w ciemno obstawiam „nie-czyste” (Volume not cleanly unmounted) odmontowanie partycji (czyt. wymuszone ubicie Windowsa) lub hibernację (flaga hibernacji sprawia kłopoty; co ciekawsze – niektóre Windowsy wykazują chęć usuwania wszystkich modyfikacji systemu plików, które powstały w trakcie hibernacji – czyli hibernacja Win, zmiana plików pod Linuksem, wybudzenie Win nic nie da). Może to też być zachcianka (szczególnie Win8) do zmiany identyfikatorów partycji lub czegoś podobnego. Nawet, żebyśmy używali jako identyfikatorów partycji do montowania ścieżek z /dev/ zamiast UUID= to systemd i tak może uznać to za błąd. A ze swojej głupoty odmówi ich montowania i co gorsza przerwie rozruch sypiąc losowym błędem (albo niekrytycznym błędem który akurat wystąpił).
Rozwiązanie: na początek w /etc/fstab komentujemy wszystko poza rootfs’em, zapisujemy i reboot – sugerowany systemctl default nie przeładuje systemd od odpowiedniego momentu. Jeśli po restarcie wszystko działa trzeba ręcznie sprawdzić każdy wpis w fstab’ie i zaktualizować plik odpowiednimi zmianami.