37

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.

4 Answers 4

36

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.

6
  • It was very helpful :)
    – ajukraine
    Oct 25, 2014 at 19:51
  • This seems hard to reproduce, I had the same problem and this fixed it but the same drive worked perfectly fine on another pc. The pc where the problem occurred was a rather old LGA775 pc and the solution above was not necessary when using a mbr partition table. So the problem only occurred when using a gpt partition table on an old system without UEFI . I don't know if Macs always use EFI but I wonder which partition table did you use ? Mar 2, 2017 at 13:22
  • It's been a while, and the MacBook is no more, but I'm fairly sure it used GPT.
    – hlt
    Mar 5, 2017 at 18:28
  • Although, I'm getting the same issues as OP and your answer seems to apply to me, it did not resolve my issue. Jan 10, 2019 at 4:16
  • You, my friend, you are the real MVP! This saved me after many hours of debug/crying
    – ClonedOne
    Mar 7, 2020 at 17:37
1

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

0

I had the same issue with my Dell XPS 15 (2021). I resolved it by changing the SATA/NVMe Operation setting in the bios from RAID On to AHCI/NVMe.

0

I tackled with the same error when I installed Arch to the flash drive.

I looked into /usr/lib/initcpio/init_functions script and found solution for that case:

  • Mount required partition when you are in initramfs: mount /dev/sdx8 /new_root/
  • Press Ctrl+D to boot into linux.
  • Edit /etc/default/grub, add rootdelay=90 to linux command line: GRUB_CMDLINE_LINUX="rootdelay=90".
  • Update grub: grub-mkconfig -o /boot/grub/grub.cfg.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .