Troubleshooting Boot Failures

A Quick Review of the Linux Boot Process

Before we can diagnose a failed boot, we need a clear mental map of a successful one. At a high level, the boot process unfolds in a series of distinct stages.

As the article outlines, the sequence is:

1. BIOS/UEFI Initialization: The computer's firmware wakes up, performs a hardware check (POST), and finds the bootloader.
2. Bootloader (GRUB): The GRUB bootloader loads the Linux kernel and the initial RAM disk (initramfs) into memory.
3. Kernel Initialization: The kernel takes control, initializes hardware drivers, and mounts the root filesystem.
4. Init/systemd: The first user-space process (systemd on modern systems) starts, bringing up services and reaching the desired system state (like a graphical login screen).

This visual diagram breaks down the process even further and is a great reference to keep in mind as we explore what can go wrong.

Now, let's explore the symptoms that arise when one of these stages fails.

Identifying Failures at Each Stage

We will now walk through the boot process again, but this time focusing on the common error messages and system states you'll encounter when something goes wrong.

1. Stage: Firmware & Bootloader (GRUB)

This is the earliest stage of failure. The hardware is on, but it can't find or execute the operating system's bootloader.

Common Symptoms:

• "No bootable device found" or similar BIOS/UEFI error: The firmware scanned all available disks and couldn't find a bootloader. This could mean the disk has failed, is disconnected, the boot order is incorrect in the BIOS/UEFI settings, or the bootloader itself is corrupted or missing from the disk's master boot record (MBR) or EFI partition.
• The grub rescue> prompt: This is a specific GRUB error mode. It means the first part of GRUB loaded successfully, but it cannot find the rest of its files (like grub.cfg) or the kernel image. This often happens after resizing partitions or moving a Linux installation incorrectly.
• System hangs at the GRUB menu: If the system stops at the normal GRUB selection menu and won't proceed, it often points to a corrupted or misconfigured grub.cfg file.

The article "Boot Process In Linux" provides a good summary of these issues.

2. Stage: Kernel Initialization

If GRUB successfully loads the kernel but the boot process halts immediately after, the problem lies with the kernel itself or its very early dependencies.

Common Symptom:

• Kernel Panic: You'll see a screen full of text, ending with a message that includes "Kernel panic - not syncing:". This is an unrecoverable error detected by the kernel.
  • Causes: Common culprits include a recent kernel update that's incompatible with a hardware driver, a corrupted initramfs (the initial RAM filesystem), or a critical hardware failure (like faulty RAM).

The good news is that Linux distributions typically keep older, working kernels available in the GRUB menu. Let's watch how to use this feature for recovery.

3. Stage: Filesystem Mounting & initramfs

At this stage, the kernel is running but is trying to mount the root filesystem (/) to continue the boot process. Failures here are very common.

Common Symptoms:

• The system drops into an initramfs or (boot) prompt: You will see messages indicating failure to mount the root filesystem, often followed by a minimal shell.
• The system drops into emergency mode: This is a systemd recovery mode. It indicates that systemd started but failed to mount critical filesystems (like / or /home). The prompt will often say You are in emergency mode.
• Errors like fsck failed or dependency failed for /home: These messages scroll by during boot and point directly to filesystem corruption or an error in the /etc/fstab file, which defines how filesystems should be mounted.

Here is an example of what a severe filesystem mounting failure looks like:

A common cause for entering emergency mode is a simple typo in /etc/fstab. Let's see a practical demonstration.

4. Stage: Graphical Interface (X Server)

Sometimes, the core system boots successfully, but the graphical user interface (GUI) fails to start.

Common Symptoms:

• The system boots to a text-based login prompt instead of a graphical one.
• The screen goes black or flickers after the boot messages disappear.
• The graphical login screen appears briefly, but trying to log in returns you to the same screen.

These symptoms almost always point to a problem with the display manager or, more commonly, the graphics drivers (e.g., NVIDIA or AMD drivers) which may have been broken by a recent system update. The underlying system is running fine; only the graphical component is affected.

A key diagnostic step is to switch to a text-only virtual console, or TTY.

Conclusion

By understanding the distinct stages of the Linux boot process, you can interpret failure symptoms to quickly narrow down the source of a problem.

Key Takeaways:

• Boot failures can be mapped to specific stages: Firmware/GRUB, Kernel, Filesystem Mounting, and Services/GUI.
• grub rescue> prompt: GRUB can't find its configuration files or the kernel.
• Kernel Panic: A fatal kernel error, often related to hardware or a bad kernel update. Booting an older kernel is a common first step.
• Emergency Mode / initramfs prompt: The kernel is running but failed to mount critical filesystems, often due to an /etc/fstab error or filesystem corruption.
• Black Screen / No GUI: The core system is likely running, but the graphics drivers or X server are failing. Switching to a TTY (Ctrl+Alt+F[1-6]) is the primary way to gain access.

Preview of the Next Lesson:
We've just learned how to identify the symptoms of a boot failure. In our next lesson, we will focus on the solution. We will explore how to use single-user and emergency modes to perform basic system repairs, putting the diagnostic skills you've acquired today into practical action.