mjhjmtu

Update. This issue has been resolved by a kernel update in December 2017. I could not figure out what the problem had been – but in hindsight, coming from another problem I had in the meantime, it might have stemmed from compatibility issues in writing a disk UIID with or without hyphens: Linux wants hyphens, but GRUB doesn’t.

I run Parabola Linux with linux-libre kernel 4.11.9-gnu-1 and Libreboot on my computer.

Problem: I recently updated my system (pacman -Syu), and ever since my boot process fails.
Specifically, the kernel seems to fail to find the logical volume on which my actual system resides. The error I get is ERROR: device '/dev/aether/core/' not found. Skipping fsck.

Any help fixing or diagnosing this problem is greatly appreciated. My understanding is too little to fix this myself and I am quite desperate.

I will next describe the problem in more detail and, after that, I will describe what I have done so far.

This is my setup: I have a solid disk with a single, fully encrypted partition, on top of which I have a logical volume named core within a volume group named aether. My system / root directory lives on the logical volume core. (The disk is encrypted with cryptsetup, the logical volumes are managed with lvm.)

And here is what happens when I boot (as I interpret it).

Boot loader phase.

1. Libreboot successfully loads GRUB.



2. 
   

   GRUB asks me for a passphrase to decrypt the encrypted partition.

   
   
   

   a. I type in a passphrase.

   
   
   

   b. GRUB sucessfully decrypts the encrypted partition.

   
   



3. GRUB succesfully loads the kernel image and the initramfs.

Kernel phase. The following happens:

 …
 :: running early hook [udev]
 …
 :: running early hook [lvm2]
 …
 :: running hook [encrypt]
 Waiting 10 seconds for device /dev/aether/core ...
 [ 4.250559] sd 4:0:0:0: [sdb] No Caching mode page found.
 [ 4.250612] sd 4:0:0:0: [sdb] Assuming drive cache: write through
 ERROR: device '/dev/aether/core/' not found. Skipping fsck.
 :: mounting '/dev/aether/core' on real root
 mount: you must specify the filesystem type
 You are now being dropped into an emergency shell.
 sh: can't access tty; job control turned off
 [rootfs ]#

I have left out some messages, indicated by …. The full log is here, but I don’t think the rest is helpful.

GRUB is configured on the firmware of Libreboot. Here is the relevant part of my grub.cfg:

 cryptomount -a
 set root=lvm/aether-core
 linux /boot/vmlinuz-linux-libre root=/dev/aether/core cryptdevice=/dev/disk/by-uuid/〈uuid of the encrypted partition〉:core cryptkey=rootfs:/etc/〈keyfile〉
 initrd /boot/initramfs-linux-libre.img

I don’t think the problem lies with GRUB itself, though.

Things I have done. I have successfully chrooted into my system. From within, /dev/aether/core does exist. Both the passphrase and the keyfile successfully unlock the encrypted partition. I have also tried downgrading the kernel to 4.10.*- (some version where I know I could boot), but to no avail either: The problem remains.

This question concerns a similar problem. Mine is different in that, for one, the correct device name is quoted in my error message, and is not found anyhow; and, I can type in the emergency shell.

What is the problem here? How can I fix this?

A guess is that you are relying on some udev naming that doesn't exist in the initramfs. I.e. the encrypted partition gets decrypted, but not linked to /dev/aether/core.

I'd recommend trying to specify the root partition by UUID, or name, or use the device name that you used to chroot to.

All of that, assuming that you are not using LVM on top of the encryption.

As said in the update:

This issue has been resolved by a kernel update in December 2017. I could not figure out what the problem had been – but in hindsight, coming from another problem I had in the meantime, it might have stemmed from compatibility issues in writing a disk UIID with or without hyphens: Linux wants hyphens, but GRUB doesn’t.

But more likely, this has been simply a kernel bug.

However, I have had a similar problem in the meantime. (Or maybe even the exact same, I can’t remember.) The solution was to use different UUIDs in the GRUB configuration – one for GRUB and one for Linux. Specifically, in the line

linux /boot/vmlinuz-linux-libre root=/dev/aether/core cryptdevice=/dev/disk/by-uuid/〈uuid of the encrypted partition〉:core cryptkey=rootfs:/etc/〈keyfile〉

the ⟨uuid of the encrypted partition⟩ should read with hyphens, whereas the ⟨uuid of the encrypted partition⟩ in

cryptomount -u ⟨uuid of the encrypted partition⟩

should read without hyphens. (This line would replace the cryptomount -a line in the original question.)