Resolving 'Unable to mount root fs' and Boot Failures in Arch Linux

The Problem: The Boot-Time Wall

When an Arch Linux system fails to find its root filesystem, it typically manifests in one of two ways: a Kernel panic - not syncing: VFS: Unable to mount root fs error or a drop into an emergency shell (the initramfs environment). This means the kernel has loaded, but it cannot find or access the disk partition containing your operating system.

Diagnostic Matrix: Identifying the Cause

Symptom	Likely Cause	Primary Diagnostic Tool
Immediate Kernel Panic	Missing or corrupted initramfs image	Bootloader config check
Drop to initramfs shell	Incorrect root UUID or missing driver	lsblk / blkid
'Failed to mount /boot' error	Incorrect /etc/fstab or partition change	mount command

Step 1: Initial Triage in the Emergency Shell

If you are dropped into an (initramfs) prompt, you can diagnose the hardware visibility before rebooting into a live environment.

1. Verify Partition Visibility: Run lsblk to see if the kernel recognizes your drives. If the list is empty, you may have a storage controller driver issue.
2. Check UUIDs: Run blkid. Note the UUID of your root partition (e.g., UUID="a1b2c3d4...").
3. Inspect Boot Parameters: Type cat /proc/cmdline. Compare the root=UUID=... value here with the output from blkid. If they do not match, the bootloader is pointing to the wrong disk.

Step 2: Recovery via Live Environment

Since you cannot fix a corrupted initramfs from within the failed boot, you must use the Arch Linux installation medium.

Entering the Chroot

Boot from your USB and mount your partitions. Replace /dev/sdXn with your actual root partition (e.g., /dev/nvme0n1p2).

# Mount root filesystem
mount /dev/sdXn /mnt

# Mount boot partition (Crucial: omit this and mkinitcpio will fail to update the image)
mount /dev/sdXm /mnt/boot

# Enter the system
arch-chroot /mnt

Fixing the Initramfs (The most common fix)

If a kernel update was interrupted, the initramfs (Initial RAM Filesystem)—the small archive that loads essential drivers to mount the real root—may be missing or empty.

Run the following command to regenerate images for all installed kernels:

# Regenerate all presets
mkinitcpio -P

Risk: Ensure /boot is mounted before running this. If you run it without mounting /boot, the images will be written to a folder on your root partition instead of the EFI/Boot partition, and the system will still fail to boot.

Correcting Bootloader Parameters

If the /proc/cmdline check in Step 1 revealed a UUID mismatch, update your bootloader configuration. For GRUB users:

1. Edit /etc/default/grub.
2. Ensure the GRUB_CMDLINE_LINUX_DEFAULT line contains the correct root=UUID=... or that the configuration is set to detect the drive automatically.
3. Regenerate the config: grub-mkconfig -o /boot/grub/grub.cfg.

Comparison: Hooks vs. UUIDs

Depending on the failure, the fix differs fundamentally:

Scenario	Root Cause	Required Action
Driver Missing	Missing hook in /etc/mkinitcpio.conf (e.g., missing btrfs hook)	Add hook to HOOKS=() array and run mkinitcpio -P
Wrong Address	Disk UUID changed after reformatting or cloning	Update /etc/fstab and bootloader config

Verification and Rollback

To verify the fix, exit the chroot, unmount the partitions, and reboot:

exit
umount -R /mnt
reboot

If the system still panics, check the /etc/mkinitcpio.conf file to ensure the MODULES=() array contains any specific RAID or NVMe drivers required for your hardware.

Rollback Procedure

If the mkinitcpio -P command produced errors or the system becomes less stable, you can revert to a previous kernel image if you have one installed (e.g., switching from linux to linux-lts) by selecting the alternative kernel in the bootloader menu at startup.