The Arch Linux Survival Guide: Fixing the 'Root Device Not Found' Error

There is a special silence when Arch doesn't boot: the emergency shell, one error line — ERROR: device 'UUID=...' not found. Skipping fsck. — and your whole week rearranges itself. Take a breath. Your data is almost certainly fine; what broke is the boot chain, usually after a kernel update or a partition change. Here is the repair, in order.

Boot the rescue USB

Use a current Arch ISO — old ones can fail to chroot into newer systems. Boot it (disable Secure Boot if you haven't enrolled your own keys), get online, and sync the clock, because broken time breaks TLS and keyring updates later:

iwctl
timedatectl set-ntp true

Mount and chroot

Find your partitions, then mount root and EFI:

lsblk
mount /dev/nvme0n1p2 /mnt        # add -o subvol=@ if you're on btrfs
mount /dev/nvme0n1p1 /mnt/boot
arch-chroot /mnt

arch-chroot mounts /dev, /proc and /sys for you and drops you into the broken system as if it had booted. This one command is half of Arch system administration.

The three usual culprits

The initramfs. Most common by far. A kernel update with a stale or failed initramfs means the kernel literally cannot see your root filesystem. Check the hooks line in /etc/mkinitcpio.conf:

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

Then regenerate everything:

mkinitcpio -P

fstab UUID drift. Rarer — happens after partition resizing or a restore from backup. Compare blkid output with what /etc/fstab expects, or regenerate from the live environment before chrooting:

genfstab -U /mnt > /mnt/etc/fstab

The bootloader. GRUB just needs reminding where to look:

grub-mkconfig -o /boot/grub/grub.cfg

On systemd-boot, run bootctl update and check that the entries in /boot/loader/entries/ point at real kernel and initramfs files.

Two modern traps

• NVMe enumeration. Some boards present the drive too slowly for the kernel's first mount attempt. Add nvme to MODULES= in mkinitcpio.conf, rerun mkinitcpio -P, and consider rootwait as a kernel parameter.
• LUKS. If root is encrypted, a missing encrypt (or sd-encrypt) hook produces this same error, because the container was never opened. The hook belongs after block and before filesystems, with cryptdevice=UUID=...:cryptroot root=/dev/mapper/cryptroot in your kernel parameters.

Leave it better than you found it

exit
umount -R /mnt
reboot

For next time: install linux-lts as a fallback kernel you can pick from the boot menu, keep the rescue USB fresh every few months, and if you're on btrfs, snapshots through snapper let you roll back a bad update before it ever bites. Read pacman's output after kernel updates — it tells you when initramfs regeneration failed, and most of us scroll right past it.

Every rescue like this is why I like the free-software idea: you are allowed to open the machine and fix it yourself. That freedom is worth remembering when you think of the developers in Gaza, pushing patches through blackouts on whatever solar charge remains — code keeps moving because people refuse to let it stop.

When the terminal finally behaves, earn the other kind of boot. We keep a soft spot at HTG Travels for people who fix their own systems — our Naltar and Hunza treks, out of Sialkot, where the only kernel worth worrying about is the one inside the walnuts.