How to Recover a Failing Linux Boot: Single‑User Mode, GRUB Fixes & Rescue Techniques

Background

Linux systems may fail to boot due to a variety of issues, including corrupted file systems, incorrect GRUB settings, or missing configuration files. When normal multi‑user boot is impossible, administrators can resort to single‑user mode, GRUB command‑line editing, or the Linux rescue environment to restore functionality.

1. Using Single‑User Mode

Single‑user mode (runlevel 1) boots the kernel into a minimal environment with only a root shell, no networking, and a few essential processes. It is useful for repairing file‑system damage, restoring configuration files, or moving user data.

Case 1: Forgotten root password

At the boot splash screen, press any key to reach the GRUB menu.

Highlight the desired kernel entry and press e to edit.

Move to the kernel line, append single at the end, then press Enter and b to boot.

When the root shell appears, reset the password with passwd root, then exit to reboot.

Additional single‑user tasks include disabling problematic services (e.g., chkconfig smb off) and changing the default runlevel by editing /etc/inittab (e.g., set id:3:initdefault: for runlevel 3).

Case 2: Disk sector corruption

If a hard‑disk sector error prevents boot, the system may display “Press root password or ctrl+D”. After entering the root password to reach single‑user mode, run a file‑system check: fsck -y /dev/hda6 Replace /dev/hda6 with the appropriate partition. After repair, reboot with reboot.

Case 3: GRUB configuration typo

An “Error 15” often means the kernel filename in grub.conf is misspelled (e.g., vmlinux instead of vmlinuz). Press any key to return to the GRUB edit screen, correct the typo, press Enter, then b to boot. Remember to fix the typo in the persistent /boot/grub/grub.conf file.

2. GRUB Boot Fault Diagnosis

When the system drops to a grub> prompt, the most common causes are:

Incorrect options in grub.conf.

Missing or corrupted grub.conf (or other boot files).

First, locate the partition containing /boot/grub/grub.conf: grub> find /boot/grub/grub.conf (hd0,0) Inspect the file: grub> cat (hd0,0)/boot/grub/grub.conf If the file is corrupted, you can boot manually by specifying the root, kernel, and initrd lines:

root (hd0,0)
kernel /boot/vmlinuz-2.6.18-1.2798.fc6 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.18-1.2798.fc6.img
boot

Key parts of a GRUB entry:

title : identifies the OS.

root : points to the /boot partition.

kernel : path to the kernel and its parameters.

initrd : path to the initial RAM disk.

3. Linux Rescue Mode

If neither single‑user mode nor GRUB commands can restore the system, boot from a Linux installation medium and select “linux rescue”. The rescue environment mounts the damaged system under /mnt/sysimage and provides a chroot shell.

Case 1: Dual‑boot bootloader restoration

Enter rescue mode and run chroot /mnt/sysimage.

Reinstall GRUB to the MBR: grub-install /dev/hda (adjust device name as needed).

Exit the chroot twice ( exit) and reboot.

Case 2: Missing /etc/inittab

If /etc/inittab is lost, restore it from a backup or reinstall the package that provides it.

With a backup: cp /etc/inittab.bak /etc/inittab.

Without a backup, identify the owning RPM: rpm -qf /etc/inittab (e.g., initscripts-8.45.3-1).

Mount the installation CD (usually at /mnt/source) and reinstall the package:

rpm -ivh --replacepkgs --root /mnt/sysimage /mnt/source/Fedora/RPMS/initscripts-8.45.3-1.i386.rpm

Alternatively, extract only /etc/inittab from the RPM:

rpm2cpio /mnt/source/Fedora/RPMS/initscripts-8.45.3-1.i386.rpm | cpio -idv ./etc/inittab
cp etc/inittab /mnt/sysimage/etc

After restoring the file, exit the chroot ( exit ) and reboot.

Conclusion

Understanding Linux’s boot process—single‑user mode, GRUB configuration, and the rescue environment—enables administrators to diagnose and fix a wide range of startup failures, from password loss to disk corruption and bootloader errors.