Skip to main content
In this lesson you’ll learn how to diagnose and fix common Linux boot failures by using GRUB editing, increasing kernel verbosity, and booting into emergency.target to repair configuration files (commonly /etc/fstab) or missing block devices. Key goals:
  • Reproduce the failure and observe where the boot stalls.
  • Boot with more verbose output to identify the offending device or mount.
  • Drop to an emergency shell to repair /etc/fstab and restore normal boot.

​
1. Reproduce the failure and collect boot messages

Reboot the server and, when the GRUB menu appears, edit the selected kernel entry (press e) to remove “quiet” and “rhgb” (or other quiet options). This exposes kernel and systemd messages so you can see where the boot process stops. Example GRUB edit (kernel lines shown):
Continue the boot (Ctrl+X) and watch the console output to identify where it stops. Example output showing a device activation timeout (indicating a missing device referenced by fstab):
The dev-mapper-...fake.device message and a halted boot typically point to a bad /etc/fstab entry referencing a non-existent UUID or block device.

​
2. Boot straight to an emergency shell

Reboot and edit the kernel command line again. Append systemd.unit=emergency.target to drop to a minimal single-user shell (emergency mode) where you can repair files. Example GRUB kernel line with emergency target:
Press Ctrl+X to boot with that parameter. The system will prompt for the root password:
Log in as root to get the emergency shell.
When you boot into emergency.target, the root filesystem is mounted read-only by default. To edit system files such as /etc/fstab, remount the root filesystem read-write.

​
3. Diagnose failing mounts and prepare to edit /etc/fstab

From the emergency shell:
  1. Try mount -a to see what fails. This will attempt to mount everything in /etc/fstab and show the error messages for missing devices or bad UUIDs.
  1. Remount the root filesystem read-write so you can edit files:
  1. Use blkid or lsblk -f to correlate device UUIDs with physical devices if you need to verify which entry is bad.

​
4. Edit /etc/fstab to remove or fix the bad entry

Open /etc/fstab with your preferred editor (e.g., vim or nano) and locate the entry referencing the nonexistent UUID or device. Remove or correct the line, ensuring the remaining entries have correct UUIDs and mount options. Example corrected /etc/fstab after removing the bad entry:
Save and exit the editor. Tip: After editing, systemctl daemon-reload will update any mount units generated by systemd from /etc/fstab.

​
5. Reboot and verify

Reboot the system:
Observe the boot process (remove kernel quiet options if needed) and confirm the system reaches its usual targets. If the boot completes normally, the issue is resolved.

​
Quick troubleshooting checklist

​
Additional notes and common pitfalls

  • If you’re uncertain which UUID maps to which device, use blkid and lsblk -f from a rescue environment or live ISO to verify before editing /etc/fstab.
  • After changing /etc/fstab, test mounts with mount -a to ensure there are no remaining errors (make sure the root partition is writable first).
  • If the boot still stalls after fixing /etc/fstab, inspect the journal for the failing boot:
    • Current emergency session: journalctl -xb
    • Previous boot: journalctl -b -1
  • Be cautious when removing swap or LVM-related entries; verify LVM volumes exist and are activated (e.g., lvm lvdisplay, vgchange -ay).
By following these steps you can quickly identify a bad /etc/fstab entry or a missing block device and recover a Linux system that stalls during boot.

Watch Video