How to Diagnose Boot Failures on Arch Linux

Boot failures can be frustrating, especially when they occur on a system like Arch Linux, which is designed to give the user full control over the operating system. While this control is powerful, it also means you’re responsible for troubleshooting problems when they arise. Fortunately, Arch Linux offers a variety of tools and methods to help you diagnose and resolve boot issues.

In this article, we’ll go through a structured approach to diagnosing boot failures on Arch Linux, including analyzing the boot process, using recovery tools, checking system logs, and addressing common misconfigurations.

1. Understanding the Boot Process

Before diagnosing a boot failure, it’s helpful to understand what normally happens during the boot process:

1. Firmware/UEFI or BIOS initializes the hardware.
2. The bootloader (like GRUB or systemd-boot) is loaded.
3. The kernel is loaded into memory.
4. The initramfs (initial RAM filesystem) is used to mount the root filesystem.
5. The init system (systemd in Arch Linux) takes over to start services and get the system running.

A failure at any of these stages can prevent your system from booting correctly.

2. Identifying the Boot Failure Stage

When you power on your machine and it fails to boot, the first step is to observe what happens:

• Do you see the bootloader menu?
• Does the bootloader load the kernel?
• Are there any error messages on the screen?
• Does it drop you to a rescue shell or emergency mode?

Answering these will help you pinpoint where the issue is occurring.

3. Recovering with a Live USB

If your system cannot boot into the root environment, you’ll need to use an Arch Live ISO or a bootable USB:

1. Boot from the Arch Linux installation media.

2. Connect to the internet if needed (iwctl for Wi-Fi or Ethernet should be detected automatically).

3. Mount your partitions to access your system:

   mount /dev/sdXn /mnt  # Replace sdXn with your root partition
   mount /dev/sdXY /mnt/boot  # If using a separate boot partition
   mount --bind /dev /mnt/dev
   mount --bind /proc /mnt/proc
   mount --bind /sys /mnt/sys
   chroot /mnt
   

Now you’re in a chroot environment with full access to your system as if you had booted into it.

4. Common Bootloader Problems

A. GRUB Not Showing

If your screen stays blank or shows a blinking cursor, the bootloader might be missing or misconfigured.

• Reinstall GRUB from the chroot environment:

  grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
  grub-mkconfig -o /boot/grub/grub.cfg
  

Make sure the EFI variables are mounted:

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

B. GRUB Configuration Errors

Sometimes GRUB loads but cannot find the kernel or initramfs:

• Check /boot/grub/grub.cfg for correctness.
• Confirm the presence of /boot/vmlinuz-linux and /boot/initramfs-linux.img.

5. Kernel and Initramfs Issues

After GRUB hands control to the kernel, the kernel loads and attempts to mount the root filesystem using the initramfs.

A. Kernel Panic

A kernel panic message like VFS: Unable to mount root fs usually means:

• The root partition is missing or mislabeled.
• The initramfs lacks drivers for your disk controller.

To regenerate initramfs:

mkinitcpio -P

Check /etc/mkinitcpio.conf for the correct HOOKS:

HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)

If using LVM, encryption (LUKS), or Btrfs subvolumes, you may need to add:

• lvm2
• encrypt
• btrfs

6. Filesystem Corruption

If the kernel loads but fails to mount the root partition, there may be filesystem corruption.

• Check filesystem integrity:

  fsck /dev/sdXn
  

  Warning: Running fsck on a mounted filesystem can cause damage. Ensure it’s unmounted or run from the live environment.

• For Btrfs:

  btrfs check /dev/sdXn
  

Use mount -o subvolid=... or subvol=... correctly if using Btrfs subvolumes.

7. Entering Emergency Mode

If systemd encounters an error it can’t handle, it drops you into emergency mode or rescue.target.

Check journal logs using:

journalctl -xb

Pay attention to:

• Missing /etc/fstab entries
• Incorrect UUIDs or labels
• Services that fail to start

A. Fixing fstab Errors

Misconfigured entries in /etc/fstab can cause systemd to fail mounting filesystems:

• Comment out problematic lines:

  nano /etc/fstab
  

• Use blkid or lsblk -f to get correct UUIDs and labels.

8. Diagnosing with journalctl

journalctl is a powerful tool for analyzing logs.

• After booting into a recovery shell or chroot:

  journalctl -xb
  

• To see previous boots:

  journalctl --list-boots
  journalctl -b -1  # Last boot
  

Look for messages marked with ERROR, FAILED, or DEPENDENCY FAILED.

9. Troubleshooting Display or Graphics Issues

Sometimes the system is actually booting but nothing is shown on screen due to display driver problems.

A. Black Screen After GRUB

• Try booting with the nomodeset kernel parameter:

  • At GRUB, press e to edit boot parameters.
  • Add nomodeset at the end of the linux line.
  • Press Ctrl + X to boot.

• This disables kernel mode setting and forces fallback graphics.

B. Reinstall Display Drivers

From chroot:

pacman -Syu nvidia  # Or intel/amd packages

10. Fixing Broken Packages or Updates

If your system broke after an update, some packages might be corrupted or incompatible.

• Check the latest pacman.log:

  less /var/log/pacman.log
  

• Downgrade problematic packages (if known):

  pacman -U /var/cache/pacman/pkg/package-version.pkg.tar.zst
  

• Try a full system update from chroot:

  pacman -Syu
  

11. Rebuilding the Init System

If systemd files are missing or corrupt:

pacman -S systemd

If you suspect a broken kernel package:

pacman -S linux linux-headers
mkinitcpio -P

12. Reinstalling the Bootloader Safely

If you’ve fixed the system but it still won’t boot:

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

For systemd-boot:

bootctl install

Conclusion

Diagnosing boot failures on Arch Linux can seem daunting at first, but with a methodical approach, you can identify and resolve most issues. By observing boot behavior, using a Live USB for recovery, and leveraging tools like journalctl, fsck, and mkinitcpio, you gain powerful insight into your system’s health.

Arch Linux’s DIY nature puts you in the driver’s seat. While that comes with some responsibility, it also means you’ll grow as a Linux user with every challenge you tackle. With a good recovery strategy and an understanding of how the system boots, you can confidently restore your system to working condition.