How to Troubleshoot and Recover a Linux System That Won’t Boot

In Configuration Management, Linux Basics, Security & Hardening, System Administration, Web Servers
May 29, 2025
84 Views

When a Linux system refuses to boot, it can be daunting – but a methodical approach will often get you back up and running. This guide provides step-by-step troubleshooting for common boot issues on Ubuntu, CentOS, and RHEL, suitable for intermediate Linux users. We’ll cover preliminary checks (like hardware and BIOS/UEFI settings), using recovery modes or live CDs, fixing common problems (GRUB bootloader errors, missing initramfs, file system errors), and tools/techniques such as fsck, chroot, GRUB rescue mode, Boot-Repair, reinstalling GRUB, and restoring from backups.

Preliminary Checks: Hardware and Firmware Settings

Before diving into complex fixes, rule out simple issues:

Check Hardware Connections: Ensure your computer’s power is on and drives are properly connected (for desktops, SATA/Power cables; for laptops, the drive firmly seated). If the screen stays blank, verify the monitor is on and cables are secure. A completely unresponsive system might indicate hardware failure (RAM, motherboard, etc.), but if you see BIOS/UEFI screens or error messages, proceed to firmware checks.
Inspect BIOS/UEFI Settings: Enter your BIOS/UEFI setup (usually by pressing a key like F2, Del, or F12 during startup). Verify the boot order is correct – the drive with your Linux OS should have priority. Sometimes after adding a new disk or OS, the boot order changes. Also ensure the system firmware mode (Legacy BIOS vs UEFI) is consistent with your OS installation. For example, if your Linux was installed in BIOS/Legacy mode, make sure the system isn’t set to UEFI-only (or vice versa). If Secure Boot is enabled, consider disabling it (or ensure your Linux supports it), since it can sometimes block booting unsigned bootloaders.
Identify BIOS vs UEFI Boot: Knowing your boot mode will help in later steps. Clues: if your firmware interface is graphical and mentions UEFI, or your disk has an EFI System Partition (ESP) (FAT32, ~100–500 MB), then your system uses UEFI. Legacy BIOS systems boot from the MBR of a drive and typically lack an ESP. Understanding this will determine how we reinstall the bootloader later.
Listen for Error Beeps or Messages: Some BIOS/UEFI will display messages like “No bootable device found” or allow a one-time boot menu. Use these to ensure it’s trying to boot from the correct disk. A message like “Operating System not found” or “No boot device” suggests the BIOS/UEFI couldn’t find a valid bootloader – possibly a sign of GRUB corruption or a disconnected drive.
Consider Recent Changes: Reflect on what happened last. Did you update the kernel, change disk partitions, install another OS, or modify system files? For instance, installing Windows alongside Linux might overwrite GRUB, or altering partitions could mislead the bootloader about where to find files. These clues can point to specific fixes (e.g., restoring GRUB if Windows overwrote it).
Check for Physical Drive Issues: If the firmware doesn’t detect your hard drive at all, the drive might have failed. Conversely, if you suspect disk issues, many BIOS/UEFI have diagnostic tools. You can also use S.M.A.R.T. diagnostics from a live environment later. At this stage, ensure all cables and components are firmly connected and undamaged.

Once you’ve verified the basics – correct boot device, proper mode, and no obvious hardware faults – move on to software-level troubleshooting.

Accessing Recovery Mode or a Live Environment

If Linux still won’t boot normally, the next step is to boot into a rescue environment where you can run diagnostic tools and repairs:

Use Built-in Recovery/Rescue Mode (if available): Many distributions offer a rescue option on the boot menu. For Ubuntu/Debian, hold Shift (for BIOS) or Esc (for UEFI) during boot to access GRUB, then select an entry labeled “Advanced options” and choose a Recovery mode kernel. This boots the system in single-user mode with a minimal environment. It often presents a menu with options like “Drop to root shell” or “fsck”. For CentOS/RHEL, the installation media offers a Troubleshooting > Rescue a Linux system option. Selecting this will attempt to find your Linux installation and mount it (usually under /mnt/sysimage on RHEL/CentOS) for you.
Boot from Live CD/USB: If no convenient recovery mode exists or it fails, use a live Linux USB/DVD. Booting from live media gives you a full Linux environment (without using the installed OS on disk) to troubleshoot. Tip: Try to use a live media of the same distro and version as your installed system for compatibility. For example, if your Ubuntu 22.04 system won’t boot, use an Ubuntu 22.04 live USB. This ensures tools like GRUB on the live disk match your system.

Create a bootable USB (if you don’t have one ready) with your distribution’s ISO. Boot your computer from this media (you might need to press F12/F10 or configure BIOS to boot USB).
For Ubuntu: select “Try Ubuntu without installing.” For RHEL/CentOS: boot from the DVD/USB and choose “Rescue a Linux system” as mentioned.
Once booted into the live session, open a terminal.

Ensure Correct Boot Mode: It’s important to boot the live media in the same mode (UEFI or BIOS) that your system was installed. For instance, if your installed OS is UEFI (has an EFI partition), make sure the live USB boots in UEFI mode (your firmware boot menu might show two options for the USB: one UEFI, one BIOS/Legacy). Using the matching mode avoids confusion when reinstalling bootloaders.
Mount Your Partitions: If using a generic live environment (like Ubuntu “Try” mode), you’ll need to manually mount your Linux filesystem to access and repair it. Identify the root partition with fdisk -l or lsblk. Suppose your Linux root is /dev/sda2 (for example). Then:

  sudo mkdir /mnt/sysroot 
  sudo mount /dev/sda2 /mnt/sysroot

If you have a separate /boot partition (common on RHEL/CentOS or if you set one up), mount it too (e.g., /dev/sda1 to /mnt/sysroot/boot). For UEFI systems, also mount the EFI System Partition (e.g., /dev/sda1) to /mnt/sysroot/boot/efi. The idea is to assemble all parts of your Linux installation under the /mnt/sysroot mount point (you can use /mnt or any directory). This will allow using chroot or direct file operations on your system disk.

Use Chroot (if needed): In many repair cases, you’ll want to run commands as if you are on the installed system. To do this, perform a chroot (change root):

  sudo mount --bind /dev /mnt/sysroot/dev && sudo mount --bind /proc /mnt/sysroot/proc 
  sudo mount --bind /sys /mnt/sysroot/sys && sudo mount --bind /dev/pts /mnt/sysroot/dev/pts
  sudo chroot /mnt/sysroot

After this, you are “inside” your installed system (with its directories like /etc, /boot, etc. now the root). Commands you run will affect the installed OS. This is useful for running package managers, grub-install, update-initramfs, etc., using the installed system’s tools. Note: If the live environment is the same OS release, you could alternatively use simpler non-chroot methods (like grub-install --boot-directory=/mnt/sysroot/boot /dev/sda), but chroot is a reliable approach for comprehensive fixes.

Now that you have a recovery shell (either via a chroot or a root shell in recovery mode), you can start diagnosing specific issues.

Common Boot Issues and Their Solutions

Let’s address frequent boot failure scenarios one by one. In each case, choose the method (command-line or automated tool) that you find simplest and most reliable.

1. GRUB Bootloader Problems

Symptoms: When GRUB (the bootloader) is broken or missing, you might see a GRUB rescue prompt (grub rescue>) or a GRUB minimal console (grub>) on boot, or an error like “no such partition” or “unknown filesystem” followed by the rescue prompt. In other cases, the machine might just skip to the next boot device (e.g., boot Windows or show “Operating System not found”). Basically, GRUB isn’t loading the Linux kernel as it should. This often happens after installing another OS (which overwrote the MBR/boot sector) or if GRUB’s files were corrupted or a partition moved.

Approach: The goal is to restore a working GRUB so it can boot your Linux. There are two main approaches: using an automated tool (Boot-Repair) or doing it manually (reinstalling GRUB). We’ll cover both, plus how to use the GRUB rescue console to boot in a pinch.

Using Boot-Repair (Ubuntu/Debian systems): If you’re dealing with an Ubuntu (or derivative) system, the Boot-Repair utility can fix most GRUB issues automatically. This is a user-friendly approach:

Launch Boot-Repair: If you booted an Ubuntu live USB, you can install Boot-Repair there. Ensure internet is available (Boot-Repair might need to download packages). In a terminal, add the Boot-Repair PPA and install it:
```
 sudo add-apt-repository ppa:yannubuntu/boot-repair  
 sudo apt-get update  
 sudo apt-get install -y boot-repair  
 boot-repair
```
The Boot-Repair GUI will open. Simply click the “Recommended repair” button. Boot-Repair will analyze your system and apply fixes automatically – typically reinstalling GRUB and restoring boot menu entries. It may also create a report (and ask to upload it) which is useful if further help is needed, but for most cases the default repair is enough.
Once it completes, reboot your system (remove the live USB) and see if your Linux now boots. Boot-Repair can handle scenarios like GRUB replaced by a Windows bootloader or a messed up GRUB config, etc., with a single click.

Boot-Repair’s interface offering a “Recommended repair” option. This tool reinstalls GRUB and fixes common boot issues automatically.

Note: Boot-Repair is primarily for Debian/Ubuntu-family distros. It might work on others, but on CentOS/RHEL you’ll likely use manual methods. Also, Boot-Repair can sometimes fix other issues (like a broken file system if you check advanced options), but here we focus on GRUB repair.

Manually Reinstalling GRUB: If you prefer command-line or Boot-Repair isn’t available, you can reinstall the GRUB bootloader yourself. The process differs slightly for BIOS vs UEFI systems:
For BIOS (Legacy) systems:

Boot into your live/recovery environment and mount your root partition (and /boot if separate) as described earlier (e.g., under /mnt/sysroot).
If using chroot: enter the chroot (chroot /mnt/sysroot as shown above). If not using chroot, adjust commands to point to the mounted path.
Run the grub-install command to write the bootloader to the disk’s MBR. Identify the disk (e.g., /dev/sda is the first HDD). Be careful to specify the disk (like /dev/sda) without a partition number. For example:
```
 grub-install --boot-directory=/boot /dev/sda
```
If in chroot, you can often simply do grub-install /dev/sda. The above with --boot-directory explicitly tells where the grub files are (on the mounted disk). This should return no errors (“Installation finished. No error reported.”). It writes a new bootloader to the MBR and places core GRUB files in /boot/grub.
After that, update the GRUB configuration so it detects your OS and generates a new menu:
```
 update-grub
```
On Ubuntu/Debian, update-grub will generate /boot/grub/grub.cfg. On CentOS/RHEL, use:
```
 grub2-mkconfig -o /boot/grub2/grub.cfg
```
This scans for kernels and other OSes. (If the system is in chroot, these commands update the system’s own /boot).
Exit the chroot (exit) if used, unmount the filesystems (umount /mnt/sysroot/...), and reboot. With GRUB reinstalled on the MBR, the system should now display the GRUB menu or boot directly into Linux.
For UEFI systems: UEFI systems don’t use the MBR for booting; instead, they rely on files in the EFI System Partition (ESP). To reinstall GRUB:
Ensure the ESP is mounted at /boot/efi under your system’s root (for example, in chroot or by mount /dev/sda1 /mnt/sysroot/boot/efi). The ESP is usually a small FAT32 partition.
Install the GRUB EFI binary and support files: In Ubuntu/Debian chroot, you might do:
```
 grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
```
The --bootloader-id is a name identifier for the UEFI firmware (you can use any name, like “ubuntu” or “centos”). This command copies grub files to the ESP (under /EFI/ubuntu for example) and registers it in UEFI. On RHEL/CentOS, if using a rescue environment, you might instead reinstall the grub2 EFI packages:
```
 yum reinstall grub2-efi grub2-efi-modules shim:contentReference[oaicite:18]{index=18}
```
This replaces any missing bootloader files on the ESP.
Next, (on RHEL) if the GRUB config in the ESP was wiped, regenerate it:
```
 grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg:contentReference[oaicite:19]{index=19}
```
(On Ubuntu, the grub.cfg in the ESP just points to the one in /boot, so running update-grub as above suffices to update both.)
Reboot after a successful install. Enter UEFI settings if needed to ensure the new bootloader entry is selected. You should get your GRUB menu back if all went well.
In summary, BIOS systems need GRUB in the MBR (via grub-install /dev/sda), while UEFI systems need the GRUB EFI files in the EFI partition. After reinstalling, always update the grub.cfg. This manual method is essentially what Boot-Repair does behind the scenes.

GRUB Rescue Mode (Optional Advanced): If you are at a grub rescue> prompt and need to boot immediately (before fixing GRUB permanently), you can attempt a manual boot: This is a bit advanced, but in brief, you’d identify the partition with your /boot files, load the normal module, and boot:

At grub rescue>, type ls to list devices (like (hd0,gpt2) (hd0,gpt3) ... or (hd0,msdos1) ...). Identify which partition might contain your /boot (look for one of the right size or use trial).
Once you pick (say (hd0,gpt2)), set it as the prefix and root:
```
 grub rescue> set prefix=(hd0,gpt2)/boot/grub  
 grub rescue> set root=(hd0,gpt2)  
 grub rescue> insmod normal  
 grub rescue> normal  
```
If the paths were correct, this loads the normal GRUB menu. You can then boot your Linux. (If insmod normal fails with unknown filesystem, try a different partition from ls.)
This is a temporary boot to get into your system. Once booted, immediately reinstall GRUB properly as described above so you don’t have to do this again.
If the above is too cumbersome, simply booting from a live CD and reinstalling GRUB as described is often easier (and more reliable). But for completeness, grub rescue allows recovery if no external media is available.

Recap: GRUB issues are resolved either by automated tools or by reinstalling the bootloader. Boot-Repair is a quick fix for Ubuntu users. Manual reinstallation involves mounting and using grub-install. Don’t forget to verify BIOS/UEFI boot device settings again – sometimes after repair, you might need to reselect the boot entry for your OS in firmware.

2. File System Errors and Disk Corruption

Symptoms: The boot process halts with errors about the file system – for example: “filesystem check failed,” “/dev/sdaX: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY,” or “cannot mount root filesystem,” dropping you into an initramfs busybox or emergency mode prompt. In some cases, you see a message “Give root password for maintenance or press Ctrl+D to continue” – which indicates the system detected a serious disk issue and won’t proceed without repair. These issues can arise from an improper shutdown, power loss causing disk corruption, or a failing drive.

Approach: Use the file system check tool fsck to repair errors on disk. This can be done from a recovery shell or live environment (since you typically can’t fix a mounted root filesystem while it’s active).

Run fsck on the Affected Partition: If you’re in an initramfs or emergency shell, you may need to run fsck manually. Usually, it’s safer to do this from a live CD/rescue environment so the partition isn’t in use. Identify the device (say /dev/sda2 for root). Then run:

  sudo fsck -f -y /dev/sda2

The -f forces a check and -y auto-answers “yes” to repair prompts (you can omit -y to review each change, but there can be many). This will attempt to fix filesystem inconsistencies. It’s a good idea to backup data first if possible (e.g., mount the disk read-only and copy important files, if the situation allows), because while fsck usually repairs issues safely, there is some risk of data loss especially if the drive is failing.

Use Recovery Mode’s fsck Option: On Ubuntu, if you got into the GRUB recovery menu, there’s an option “fsck” – selecting it will run fsck on your root filesystem and prompt to fix errors. This is just an automated way of running the above command (it will then remount the root filesystem and allow you to resume booting if fixes succeeded).
External Live USB Method: If you prefer, boot a live USB and use the Disk Utility or GParted GUI to check the disk. For ext4 or similar, though, running fsck in terminal is straightforward. For example, GParted might show a warning and you can right-click a partition and choose “Check”. This essentially runs fsck in the background.
Check All File Systems: If one partition was corrupted (like root), others might be as well (e.g., /home, or the boot partition). Use fsck on each Linux partition (except swap – for swap use mkswap -f if it’s corrupted, but that’s rare). If you’re not sure of the device names, sudo blkid or sudo fdisk -l can list them. You can also run fsck -A to check all filesystems listed in /etc/fstab (use with caution and ensure the fstab in the mounted system is accurate).
After a Successful fsck: Reboot and see if the system now boots normally. Often, a corrected filesystem will boot fine. If the root filesystem was fixed, the “filesystem requires manual fsck” error should be gone.
If fsck Finds Serious Errors or Fails: If errors can’t be fixed, or they recur frequently, you may have a failing drive. Consider using smartctl (S.M.A.R.T. tool) to check drive health. In a terminal:

  sudo smartctl -a /dev/sda

Look for attributes indicating failure. Also watch dmesg logs for disk I/O errors. If the disk is dying, backup immediately and plan drive replacement. No software fix can overcome hardware failure.

Mount Issues (e.g., fstab errors): Sometimes a boot drops to emergency mode not due to disk corruption but a bad fstab entry (like a UUID that doesn’t exist). If you suspect this (for instance, you edited /etc/fstab recently), boot into recovery, open /etc/fstab and correct or comment out the offending line. A common hint is an error like “cannot mount /mnt/data (UUID=xxxxx) – not found” leading to emergency mode. Fix the UUID or mount options, then retry boot.

In summary, file system errors are addressed by fsck which checks and repairs disk consistency. Always ensure critical data is backed up before repairing if possible. Once fixed, the system should boot unless other issues persist.

3. Missing initramfs or Kernel Issues

Symptoms: The boot process might fail with a kernel panic, possibly with messages like “unable to mount root fs” or “can’t find initramfs” or dropping to an initramfs> prompt (BusyBox shell). You might also see errors about “missing initrd” or “initramfs image not found” from GRUB. Essentially, the kernel either cannot load the necessary initramfs or drivers to start the system. This often happens if an update did not properly generate an initramfs, or if the initramfs file was deleted or is mismatched. It can also occur if a new kernel was installed but the old initrd was not created, or if the boot partition (if separate) ran out of space during an upgrade, leaving you without a correct initramfs.

Approach: Regenerate or reinstall the initramfs (and possibly the kernel) so that the kernel can boot with the correct initial environment.

Try Booting an Older Kernel: If you have the GRUB menu accessible, attempt to select an older kernel (from the “Advanced options” submenu in GRUB). Often, when a new kernel’s initramfs is bad, an older kernel entry (with its initramfs intact) might still boot. If that works, you can then regenerate the initramfs for the latest kernel from within the system. This is the quickest way out if available.
Chroot and Recreate Initramfs: If no kernel boots, use the live CD and chroot method discussed. Once in the chroot of your system, run the command to rebuild the initramfs for the current kernel. The command differs by distro:
Ubuntu/Debian: Use update-initramfs. For example, list kernels in /boot. If you see vmlinuz-5.15.0-50-generic and its corresponding initrd.img-5.15.0-50-generic is missing or suspect, run:
```
update-initramfs -c -k 5.15.0-50-generic
```
The -c creates a new initrd (-u updates an existing one). If you’re not sure of kernel version, you can do update-initramfs -c -k all to (re)create for all installed kernels.
RHEL/CentOS (dracut): RHEL uses dracut to build initramfs. In the chroot, run:
```
dracut --force /boot/initramfs-$(uname -r).img $(uname -r)
```
This force-recreates the initramfs for the current kernel (uname -r will show the version if you chroot into the system after booting with a live kernel; alternatively specify the version manually). If you suspect the initramfs is missing entirely, you may need to ensure the kernel package is installed. Running yum reinstall kernel-core (for RHEL8) or similar might reinstall any missing boot files.
Ensure /boot has Space: One reason initramfs creation fails is lack of space on /boot (common if /boot is a small separate partition). While in recovery, check df -h /boot. If it’s 100% full, you might need to delete old kernels or files before regenerating. For instance, on Ubuntu you can remove old kernels via apt (apt-get remove linux-image-<version>). On CentOS, remove old kernel packages. Free up space, then run the above commands.
Reinstalling a Kernel (if needed): If the kernel itself is corrupted or missing, use your package manager to reinstall it. In Ubuntu, for example:

  apt-get install --reinstall linux-image-generic

(Replace with specific version if needed). On RHEL:

  yum reinstall kernel-core

This will ensure both the vmlinuz and initramfs are in place. After reinstall, run update-grub/grub2-mkconfig to ensure GRUB picks it up.

Update GRUB Configuration: After fixing or adding kernel/initrd files, always update the GRUB config (especially if you installed a new kernel). Run update-grub (Debian/Ubuntu) or grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL) so that the boot menu has the correct entries pointing to the restored kernel and initramfs.

Now exit the chroot and reboot. If the initramfs was the issue, the kernel should now boot without panicking. You should no longer see the “initramfs” or “kernel panic” errors related to missing files.

4. Other Tips and Last Resorts

Double-Check BIOS/UEFI After Repairs: If you’ve been booting from live media, sometimes the BIOS boot order might change (some UEFI firmwares add “ubuntu” entries etc.). Make sure your hard drive/OS is again the first boot option. This is a small detail but can be confusing if after all fixes the system still seems to skip booting your Linux.
Test Booting after Each Major Fix: It’s wise to change one thing at a time and then try booting. For example, first fix GRUB and test boot – if you then hit a filesystem error, go back and fix that, etc. This way you know which actions resolved which problems.
Use GRUB’s Advanced Options: If you can get to the GRUB menu, remember there are often recovery modes and memory test options. Booting in recovery (single-user) mode is handy for editing files or checking logs if the normal boot fails at some later stage (like a driver issue).
Check Logs: When troubleshooting, logs are your friend. From a recovery shell or chroot, check journalctl -xb (logs from the last boot attempt) or see specific logs under /var/log/ (like dmesg or boot.log). They might contain error messages that pinpoint the issue (for instance, a specific driver failing, or a mount failure). This can guide your fixes (e.g., if a specific service is causing hang-ups, you could disable it in recovery to see if boot progresses).
When All Else Fails – Restoring from Backup: If you have backups or snapshots of your system, now is the time to use them. For example, if you used a tool like Timeshift (common on Ubuntu/Linux Mint) to take system snapshots, you can boot a live CD, install Timeshift there, and restore a previous snapshot (which would restore system files to a working state). If you have a full disk image backup, you could re-image the disk. On enterprise systems, you might restore from a backup server or use LVM snapshots if configured. Restoring a backup will put your system back to a known-good state (you’ll likely still need to reinstall GRUB if the backup didn’t include the bootloader, or run update-grub if the UUIDs changed, etc., but those are minor in comparison). Always make sure to backup your personal data from the non-booting system (you can mount and copy files from the live USB) before doing any risky operations. If no recent backup is available or the system is too far gone, as a last resort you might perform a fresh OS install on the machine and then restore data from your home directory backup. Sometimes a fresh installation can be quicker if you’ve spent a long time with no success – but try the above fixes first, as Linux is usually recoverable without a full reinstall.
Preventive Tip: After you recover, consider setting up a regular backup routine or system snapshot tool, and keep a live USB handy. Also, avoid force-shutting down your system to minimize filesystem corruption, and keep an eye on disk health (bad sectors can cause recurrent boot problems).

Conclusion

Troubleshooting a non-booting Linux system involves a mix of systematic checking and targeted repairs. We started with the simplest checks – hardware connections and BIOS/UEFI settings – because a misconfigured boot order or loose cable can be the culprit. If the issue runs deeper, booting into a rescue environment allows us to address the big three: bootloader issues, filesystem issues, and missing critical files. We learned how to repair GRUB (automatically with Boot-Repair, or manually for both BIOS and UEFI systems), how to fix corrupted filesystems with fsck, and how to recreate initramfs or reinstall kernels so the system can start properly. Throughout the process, choosing the right method (GUI tool vs. command-line, chroot vs. direct commands) depends on what you’re most comfortable with – the goal is to use the simplest effective method for each problem.

By following these steps and tips, you can resolve most boot problems on Ubuntu, CentOS, or RHEL and get your Linux system back on its feet. Remember that careful changes, one at a time, coupled with keeping backups, will make the recovery both successful and safe.