> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Demo Troubleshooting Boot Issues > Diagnosing and repairing Linux boot failures by editing GRUB, increasing kernel verbosity, booting to emergency.target, and fixing bad fstab entries or missing block devices. 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): ```bash theme={null} load_video set gfxpayload=keep insmod gzio linux ($root)/vmlinuz-6.12.0-124.8.1.el10_1.x86_64 root=/dev/mapper/rhel-root ro crashkernel=2G-64G:256M,64G-:512M resume=UUID=f7ba6641-f5c1-4503-a64f-c804eda85768 rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap initrd ($root)/initramfs-6.12.0-124.8.1.el10_1.x86_64.img $tuned_initrd ``` 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`): ```bash theme={null} [ OK ] Finished systemd-udev-trigger.service - Coldplug All udev Devices. Mounting lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. Starting systemd-journal-flush.service - Flush Journal to Persistent Storage... [ OK ] Finished systemd-sysctl.service - Apply Kernel Variables. [ OK ] Started systemd-userdbd.service - User Database Manager. [ OK ] Reached target local-fs-pre.target - Preparation for Local File Systems. [ OK ] Started lvm-activate-rhel.service - /usr/sbin/lvm vgchange -aay --autoactivation event rhel. Mounting boot.mount - /boot... XFS (sda2): Mounting V5 Filesystem 691cc3c4-617b-46de-88a8-72845adc7636 [ OK ] Mounted boot.mount - /boot. [ OK ] Finished systemd-udevd.service - Rule-based Manager for Device Events and Files. [ OK ] Finished modprobe@dm_mod.service - Load Kernel Module dm_mod. [ OK ] Finished modprobe@dm_multipath.service - Load Kernel Module dm_multipath. [ OK ] Finished modprobe@efi_pstore.service - Load Kernel Module efi_pstore. [ OK ] Finished modprobe@loop.service - Load Kernel Module loop. [ OK ] dev-mapper-vg\x2duuid\x2dfake.device/start running (7s / 1min 30s) ``` 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: ```bash theme={null} load_video set gfxpayload=keep insmod gzio linux ($root)/vmlinuz-6.12.0-124.8.1.el10_1.x86_64 root=/dev/mapper/rhel-root ro crashkernel=2G-64G:256M,64G-:512M resume=UUID=f7ba6641-f5c1-4503-a64f-c804eda85768 rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap systemd.unit=emergency.target initrd ($root)/initramfs-6.12.0-124.8.1.el10_1.x86_64.img $tuned_initrd ``` Press Ctrl+X to boot with that parameter. The system will prompt for the root password: ```bash theme={null} You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, or "exit" to continue bootup. Give root password for maintenance (or press Control-D to continue): ``` Log in as root to get the emergency shell. When you boot into [emergency.target](https://www.freedesktop.org/software/systemd/man/emergency.target.html), 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. ```bash theme={null} # Show failing mounts mount -a # Example error: # mount: /fakemount: can't find UUID=fake ``` 2. Remount the root filesystem read-write so you can edit files: ```bash theme={null} # Remount root as read-write mount -o remount,rw / ``` 3. Use `blkid` or `lsblk -f` to correlate device UUIDs with physical devices if you need to verify which entry is bad. ```bash theme={null} # List device UUIDs blkid # or lsblk -f ``` *** ## 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: ```text theme={null} # # /etc/fstab # Created by anaconda on Tue Mar 31 10:50:07 2026 # # Accessible filesystems, by reference, are maintained under '/dev/disk'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # UUID=d3b9cb8c-5cf7-45cb-8bef-9dec51747be4 / xfs defaults 0 0 UUID=691cc3c4-617b-46de-88a8-72845adc7636 /boot xfs defaults 0 0 UUID=f7ba6641-f5c1-4503-a64f-c804eda85768 none swap defaults 0 0 ``` 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: ```bash theme={null} # Reboot the system systemctl reboot ``` 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 | Step | Command / Action | Purpose | | - | - | - | | Show failing mounts | `mount -a` | Reveals which fstab entries fail to mount | | Verify device UUIDs | `blkid` or `lsblk -f` | Map UUIDs to block devices | | Remount root writable | `mount -o remount,rw /` | Allow editing of `/etc/fstab` | | Inspect journal | `journalctl -xb` or `journalctl -b -1` | Detailed logs for current/previous boot | | Boot emergency shell | Add `systemd.unit=emergency.target` to kernel line | Minimal environment for repair | *** ## 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`). *** ## Links and references * systemd emergency.target — [https://www.freedesktop.org/software/systemd/man/emergency.target.html](https://www.freedesktop.org/software/systemd/man/emergency.target.html) * blkid manual — [https://man7.org/linux/man-pages/man8/blkid.8.html](https://man7.org/linux/man-pages/man8/blkid.8.html) * lsblk manual — [https://man7.org/linux/man-pages/man8/lsblk.8.html](https://man7.org/linux/man-pages/man8/lsblk.8.html) * journalctl manual — [https://man7.org/linux/man-pages/man1/journalctl.1.html](https://man7.org/linux/man-pages/man1/journalctl.1.html) * GRUB manual — [https://www.gnu.org/software/grub/manual/](https://www.gnu.org/software/grub/manual/) 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.