Fixing Linux Boot Errors: A Complete Recovery Guide

Introduction / Why This Is Needed

Boot problems are one of the most frequent and critical errors in Linux. The causes can vary widely: from accidental deletion of bootloader files and filesystem corruption to driver conflicts after a kernel update. This guide provides a universal diagnostic and recovery algorithm that works for most popular distributions using GRUB 2 and systemd. As a result, you will be able to restore your system to a working state without reinstalling.

Requirements / Preparation

Before you begin, ensure you have:

1. Another working computer to create a bootable USB drive.
2. An empty USB drive (at least 4 GB).
3. The ability to boot from USB (configure the boot priority in UEFI/BIOS).
4. Basic Linux terminal skills: navigation, file editing (nano, vim), executing commands with sudo.
5. Knowledge of the root password (or the ability to use sudo) for the target system.

Important: If you cannot pinpoint the exact problem, start with Step 1 (Diagnostics).

Step-by-Step Instructions

Step 1: Diagnose the Boot Stage

First, determine exactly where the boot process stops. This is the crucial step.

• Is the POST/BIOS/UEFI screen blank or stuck on the manufacturer's logo? → Problem with hardware (RAM, SSD/HDD) or UEFI/BIOS settings (Secure Boot, Fast Boot). Try resetting BIOS/UEFI settings to factory defaults.
• Does the GRUB menu appear, but the system freezes or reboots when selecting a kernel? → Problem with the kernel, drivers (most commonly video drivers like nvidia, amdgpu), or the filesystem.
• Do you see an error like grub rescue> or error: no such partition? → GRUB cannot find its modules or configuration. The partition or bootloader is corrupted.
• Do you see a lot of text ending with Kernel panic - not syncing: VFS: Unable to mount root fs or Failed to mount /? → The kernel cannot mount the root filesystem. Causes: incorrect kernel parameters (e.g., root=), filesystem corruption, or missing driver for the disk controller.
• Does booting stop at Loading basic kernel... or Loading initial ramdisk...? → Problem with initramfs (the initial ramdisk image).
• Does the system start booting (you see systemd logs) but freeze on a specific unit (e.g., NetworkManager-wait-online.service)? → Problem with systemd configuration or a specific service.

Conclusion: Note the last message on the screen. It is your primary clue.

Step 2: Create and Boot from a Live USB

1. On another computer, download the ISO image of any modern distribution (Ubuntu, Fedora, Manjaro).
2. Use dd (Linux/macOS) or Rufus (Windows) to write the image to the USB drive.

   # Example for Linux (replace /dev/sdX with your device!)
   sudo dd if=ubuntu-22.04.iso of=/dev/sdX bs=4M status=progress oflag=sync
   

3. Insert the USB into the problematic computer, power it on, and press the key to select the boot device (F12, F10, Esc — depends on the manufacturer). Choose your USB drive.
4. Boot into the Live session (Try Ubuntu / Start Fedora Live).

Step 3: Identify Partitions and Mount Them

In the terminal window of the Live system, run:

# Show all disks and partitions
lsblk -f

You will see a list of devices (/dev/sda, /dev/nvme0n1) and their partitions. You need to find:

• The root partition (usually with filesystem ext4, btrfs, or xfs).
• The EFI System Partition (ESP, usually vfat, size 100-500 MB, type EFI System). It exists only when booting in UEFI mode.
• A separate /boot partition, if one is used (also often ext4).

Example output for a UEFI system:

NAME        FSTYPE  LABEL     UUID                                 MOUNTPOINT
nvme0n1
├─nvme0n1p1 vfat    ESP        ABCD-1234                            # This is the ESP
├─nvme0n1p2 ext4    root       1234abcd-5678-ef90-1234-567890abcdef # This is root
└─nvme0n1p3 swap    swap       5678abcd-1234-ef90-5678-90abcdef1234

Mount the partitions:

# Create a mount point
sudo mkdir -p /mnt/root

# Mount the root partition (replace /dev/nvme0n1p2 with yours)
sudo mount /dev/nvme0n1p2 /mnt/root

# If you have a separate /boot (not inside ESP), mount it
# sudo mount /dev/nvme0n1p3 /mnt/root/boot

# If you have UEFI, mount the ESP at /mnt/root/boot/efi
sudo mount /dev/nvme0n1p1 /mnt/root/boot/efi

Verify the mounts:

lsblk
# Ensure your partitions have a mountpoint of /mnt/root (and /mnt/root/boot/efi)

Step 4: Chroot into the Target System

Now we "place" the root of your system at /mnt/root and switch into it to run commands on its behalf.

# Mount the virtual filesystems needed for chroot to work
sudo mount --bind /dev /mnt/root/dev
sudo mount --bind /proc /mnt/root/proc
sudo mount --bind /sys /mnt/root/sys
sudo mount --bind /run /mnt/root/run  # Important for systemd

# If you have UEFI, ensure /dev/sdX1 (ESP) is mounted at /mnt/root/boot/efi

# Switch into chroot
sudo chroot /mnt/root

You are now in the terminal of your system being recovered. The command prompt may change (e.g., from $ to #). All subsequent commands are executed inside the chroot.

Step 5: Reinstall and Configure GRUB

The commands depend on your boot mode (BIOS/Legacy or UEFI).

1. For BIOS/Legacy boot systems:

# Install GRUB to the disk (not a partition!), usually /dev/sda
grub-install /dev/sda

# Update GRUB configuration (generate a new grub.cfg)
update-grub

Expected output: Installing for i386-pc platform... Installation finished. No error reported.

2. For UEFI boot systems:

# Ensure ESP is mounted at /boot/efi (check with the mount command)
mount | grep efi

# Install GRUB for UEFI
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

# Force a configuration update
update-grub

Expected output: Installing for x86_64-efi platform... Installation finished. No error reported.

3. Additional: Restore GRUB configuration (if files exist but config is broken)

# Recreates config based on installed kernels
grub-mkconfig -o /boot/grub/grub.cfg

Step 6: Check and Repair Filesystems

If the issue was with the filesystem (e.g., after a sudden power loss), perform a check.

WARNING: fsck can only be run on unmounted partitions! In our case, the partition is mounted at /mnt/root. You must unmount it from within chroot, but this is impossible as it is the root. Therefore:

1. Exit the chroot:

   exit
   

2. Unmount the root partition (and others if needed):

   sudo umount /mnt/root/boot/efi  # if it was mounted
   sudo umount /mnt/root
   

3. Run fsck on the unmounted partition:

   # For ext4/ext3/ext2
   sudo fsck -y /dev/nvme0n1p2
   
   # For Btrfs (caution, --repair can damage data!)
   # sudo btrfs check --readonly /dev/nvme0n1p2  # Read-only first
   # If errors are found and you accept the risk:
   # sudo btrfs check --repair /dev/nvme0n1p2
   
   # For XFS (read-only check; for repair, use xfs_repair after mounting with -o recovery)
   sudo xfs_repair /dev/nvme0n1p2
   

4. After a successful check, mount the partitions again and re-enter chroot (Steps 3 and 4) to continue if necessary.

Step 7: Update initramfs and Kernel

Often the problem lies in an outdated or corrupted initramfs (initial ramdisk) image. Inside chroot, run the command appropriate for your distribution.

• Debian, Ubuntu, and derivatives:

  update-initramfs -u -k all
  

• RHEL, CentOS, Fedora:

  dracut --force
  

• Arch Linux, Manjaro:

  mkinitcpio -P
  

• openSUSE:

  mkinitrd
  

What does this do? It creates a new initramfs image for all installed kernels. This image contains drivers necessary to mount the root filesystem (e.g., NVMe, LVM, DM-RAID drivers).

Step 8: (Optional) Check Kernel Configuration

If the problem occurs after a kernel update, try booting with a previous kernel version from the GRUB menu (Advanced options). If that works, you need to, from within chroot:

1. Make the current (broken) kernel old by default or remove it entirely.

   # For Debian/Ubuntu: list installed kernels
   dpkg -l | grep linux-image
   
   # Remove the problematic kernel (e.g., linux-image-5.15.0-50-generic)
   apt remove linux-image-5.15.0-50-generic
   

2. Update GRUB so it doesn't show the removed kernel:

   update-grub
   

Step 9: Exit and Reboot

1. Exit the chroot (if you haven't already): exit.
2. Unmount all mounted filesystems (in the correct order):

   sudo umount /mnt/root/boot/efi  # if it was mounted
   sudo umount /mnt/root
   

3. Reboot the computer, after first removing the USB drive.

   sudo reboot
   

Verify the Result

1. The system should boot to the graphical login manager (GDM, SDDM, LightDM) or a text login.
2. If boot was successful, immediately back up important data.
3. Check systemd logs for errors after boot:

   journalctl -p 3 -xb  # Show only critical errors from the current boot
   

4. Ensure all partitions mount automatically (check /etc/fstab).

Potential Problems

• GRUB continues to show grub rescue> after reinstallation.
  • Cause: The wrong disk was specified in grub-install or the ESP was identified incorrectly.
  • Solution: In chroot, ensure the ESP is mounted at /boot/efi (for UEFI). For BIOS, verify you specified the whole disk (/dev/sda), not a partition (/dev/sda1).
• After recovery, GRUB doesn't see my kernels (no such device in the menu).
  • Cause: GRUB cannot read modules from the disk because a driver for your controller (e.g., nvme) is missing.
  • Solution: In chroot, reinstall grub and shim (for UEFI Secure Boot), as well as linux-image and grub-common packages. Ensure /boot/grub contains i386-pc or x86_64-efi directories with modules.
• System boots but immediately crashes with Kernel Panic after an update.
  • Cause: A broken or incompatible kernel/driver (often proprietary NVIDIA drivers).
  • Solution: Boot with a previous kernel from the GRUB menu (Advanced options). Log in and remove/rollback the problematic kernel or driver. For NVIDIA, you can temporarily boot with the kernel parameter nomodeset.
• Error Failed to mount / or VFS: Unable to mount root fs.
  • Cause: Incorrect root= parameter in GRUB config, filesystem superblock corruption, or missing disk controller driver in initramfs.
  • Solution: In chroot, check /etc/default/grub (the GRUB_CMDLINE_LINUX line). After editing, run update-grub. Rebuild the initramfs (Step 7). If the issue is the filesystem — check it with fsck (Step 6).
• Freezing at Loading basic kernel... or Loading initial ramdisk....
  • Cause: Corrupted initramfs image or a slow/failing medium (if booting from USB).
  • Solution: Rebuild the initramfs (Step 7). Try booting from a different USB port (USB 2.0 is often more reliable). If the initramfs itself is the problem, check its integrity in /boot/.
• Cannot mount ESP at /boot/efi. Error wrong fs type, bad option, bad superblock.
  • Cause: The ESP is not formatted as vfat (FAT32) or is corrupted.
  • Solution: Check the partition type with fdisk -l. If it's not FAT32, you will need to recreate it (this will delete bootloaders for Windows and other OSes!). Create a new vfat partition, format it (mkfs.vfat), and mount it again. Then reinstall GRUB.
• After all actions, update-grub finds no kernels.
  • Cause: The /boot partition (or root) is not mounted inside chroot, or the /boot/grub directory is missing.
  • Solution: Inside chroot, run ls /boot. If the folder is empty or lacks vmlinuz-* files, you mounted the wrong partition. Unmount everything, find the correct partition containing the kernels (usually root or a separate /boot), and mount it again.

Preventing Boot Problems

To minimize risks in the future:

1. Never power off the machine during a system update or disk write operation.
2. Regularly back up important data and take system snapshots (if using Btrfs or ZFS).
3. When updating the kernel (especially proprietary NVIDIA drivers), do not remove the old kernel immediately. Keep at least one previous working kernel so you can boot via the GRUB menu.
4. Enable Secure Boot only if you are sure about driver compatibility. It can block the loading of unsigned modules.
5. Create a bootable Live USB in advance and store it in a safe place. This is your primary recovery tool.

Conclusion

Recovering Linux boot is primarily about systematic diagnosis. Identify the stage where the failure occurs, boot from a Live USB, mount your partitions, and reinstall GRUB. In most cases, this is sufficient. If the problem lies with the filesystem or initramfs, use fsck and rebuild the image. The key is to act methodically and not panic. Most boot problems are solvable without data loss.