"Unable to find root device" on a fresh ArchLinux install

I have installed the latest version of ArchLinux (2014.06.01) on a MacBook Pro 8,1 (15", if that matters regarding hardware) dual-booting with OSX following the instructions in the official install guide. However, when try and reboot into the newly installed system, it drops me into a recovery shell:

ERROR: device 'UUID=<snip>' not found. Skipping fsck.
ERROR: Unable to find root device 'UUID=<snip>'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty: job control turned off
[rootfs /]# 

(I removed the UUID because I didn't want to type it out, but it is the same as the one given to me by blkid (from the install disk) for the partition ArchLinux is installed on)

Other online sources suggest this is due to an outdated pacman, udev, filesystem or linux package. However, they describe this problem only after a kernel update from a working system, not a fresh install. I force-reinstalled these packages from the arch-chroot environment while booted to the install disk, but that did not change the situation.

Instead, a little bit of experimentation with my grub.cfg shows that whatever is complained about is the root parameter to the linux command selecting what vmlinuz file to use. Indeed, changing root=UUID=<snip> to root=LABEL=ArchLinux or root=/dev/sda8 (both describe where ArchLinux is installed and I have certainly used the second version successfully before with another distribution) gives Unable to find root device 'LABEL=ArchLinux' and Unable to find root device '/dev/sda8' respectively. Furthermore, GRUB seems to be able to find the partition by UUID, only the linux kernel complains about it not being found, as the initial ramdisk is properly loaded (ie. this is not a GRUB error as described here but rather a linux error).

As a side note: the recovery shell is severely limited, and standard output does not appear to work properly. Nevertheless, ls works, and listing files shows a basic (temporary) file system, but all disk devices appear to be missing from /dev. However, I don't know if this is part of the error or not.

This is similar, but not the same as Linux doesn't find root file system when booting, as the partition was ext4 from the beginning. Also not exactly the same, but maybe relevant is Unable to boot ArchLinux on Macbook Pro 7.1 - drops to recovery shell, however, there, it drops into a ramfs shell instead of a rootfs shell and the error messages differ.

Solution 1:

Instead of booting with the normal image, I used the fallback version and managed to boot into the system. As it turns out, Linux could not detect any drives due to the block mkinitcpio hook (responsible for block devices) missing from the default image. This was due to it being placed after autodetect in /etc/mkinitcpio.conf. To fix this, the HOOKS=... line in that file needs to be changed so that block comes before autodetect

Before the fix:

HOOKS="base udev autodetect block modconf filesystems keyboard fsck"

After the fix:

HOOKS="base udev block autodetect modconf filesystems keyboard fsck"

Running mkinitcpio -p linux to regenerate the initramfsthen fixed the problem permanently.

Solution 2:

I ran into a similar issue but with a different setup. I'm using ArchLinux in a virtual machine and my bootloader is syslinux. I used your trick on switching the kernel hooks order but I still ended up in a rootfs-shell.

What fixed the issue for me was changing the APPEND line in my syslinux.cfg from

APPEND root=UUID=<snip>

to

APPEND root=PARTUUID=<snip>

You can easily append the PARTUUID to the syslinux.cfg by using a command like blkid | grep sda1 | awk '{ print $7 }' >> /boot/syslinux/syslinux.cfg assuming your root partition is /dev/sda1

Afterwards you can use your favorite text-editor to move the line to the appropriate space.

EDIT: I just recognized that the column number in the small awk script may vary, so better have a look at the output before piping it into syslinux.cfg