Arch Linux

linduxed

Member

Registered: 2008-10-12

Posts: 64

Website

[SOLVED] btrfs on encrypted volume: GRUB can't find UUID

I've got the following setup:

• System files installed, don't think there are any problems with that.

• /dev/sda and all its partitions has Windows.

• /dev/sdb1 is an EFI partition and /dev/sdb2 is a dm-crypt+LUKS encrypted volume.

• Inside the encrypted volume there's a btrfs filesystem with two subvolumes called ROOT and home. The encrypted volume is opened to /dev/mapper/cryptroot. As for the btrfs subvolumes, I didn't prepend stuff like "__active", just the names right away (if that's bad for some reason, please enlighten me).

• The EFI partition is mounted on /boot/efi inside the ROOT subvolume.

• GRUB was chosen as bootloader. I needed to add the "GRUB_ENABLE_CRYPTODISK=y" flag at the end of the /etc/default/grub file due to the root filesystem being on an encrypted volume (grub-mkconfig required this to continue).

When I boot up, it finds the UEFI system and gets into GRUB. I'm immediately required to enter the password to my encrypted volume (which I found a bit odd, considering I've always entered it during system boot, not before GRUB). If I enter it correctly, I'm greeted with the usual GRUB list of systems to boot.

Regardless of which system I pick (regular or rescue) I get the following error:

error: no such device: xxxxxxxx-xxxx-.....
Loading LInux core repo kernel ...
error: no such partition.
LOading initial ramdisk ...
alloc magic is broken at 0x12312312: 123123123

Those x's are a UUID. I checked what the UUID refers to when I boot up Arch on a USB stick and it refers to one of the btrfs subvolumes when they're open and mounted; specifically, it's /dev/dm-0. /dev/dm-1 is also present and I suspect that's the "home" subvolume, although I'm not sure.

Here's the command I used to install GRUB:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub_uefi --recheck

Here's the command I used to generate the GRUB configuration:

grub-mkconfig -o /boot/efi/EFI/grub_uefi/grub.cfg

Here's the /etc/default/grub I use:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sdb2:cryptroot:allow-discards"

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable Hidden Menu, and optionally hide the timeout count
#GRUB_HIDDEN_TIMEOUT=5
#GRUB_HIDDEN_TIMEOUT_QUIET=true

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=auto

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter 
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx" 
GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper 
# modes only.  Entries specified as foreground/background.
#GRUB_COLOR_NORMAL="light-blue/black"
#GRUB_COLOR_HIGHLIGHT="light-cyan/blue"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/path/to/wallpaper"
#GRUB_THEME="/path/to/gfxtheme"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

#GRUB_SAVEDEFAULT="true"

GRUB_ENABLE_CRYPTODISK=y

The resulting /boot/efi/EFI/grub_uefi/grub.cfg can be found here: http://sprunge.us/LgIa
For some reason I've also got a /boot/grub/grub.cfg which can be seen here: http://sprunge.us/LLFi

More interestingly, it's actually the second file that is being loaded in the GRUB menu that I see, not the first one. I know this, since Windows is present as a menu option in the first .cfg-file, but that option is not present in the menu I see.

As a side-note, I don't like the fact that GRUB decrypts my partition; I'd prefer if decrypting was handled during boot by the "encrypt" hook in mkinitcpio.conf. GRUB taking over the decryption might have something to do with the actual problem.

Last edited by linduxed (2015-03-18 16:02:46)

linduxed

Member

Registered: 2008-10-12

Posts: 64

Website

Re: [SOLVED] btrfs on encrypted volume: GRUB can't find UUID

I found this thread on the topic of the wrong .cfg-file being used:

https://bbs.archlinux.org/viewtopic.php?id=146754

It could be as simple as copying the .cfg-file from the EFI partition to /boot/grub/.
However, that doesn't change the fact that it's annoying to have to enter the password before booting.

I'll see this evening if this works.

MSC

Member

Registered: 2014-07-13

Posts: 33

Re: [SOLVED] btrfs on encrypted volume: GRUB can't find UUID

/boot/grub/grub.cfg is the correct file. I'm confused what you mean by "it's annoying to have to enter the password before booting" though...what would be the point of encrypting the disk if it didn't require a password? Note that you can use a key-file (e.g. a key stored on a USB stick) if you'd prefer to require a physical device as opposed to a password.

Another note: it's usually best to use a UUID as your cryptdevice instead of a /dev/sd* path, as sd* can sometimes change on boot.

linduxed

Member

Registered: 2008-10-12

Posts: 64

Website

Re: [SOLVED] btrfs on encrypted volume: GRUB can't find UUID

I figured it out!

As mentioned in the OP, I had mounted the EFI partition on /boot/efi/. This meant that the rest of the necessary files for starting GRUB (at least that's how I understand it) were located outside of the EFI partition, on an encrypted btrfs subvolume. This necessitated the pre-GRUB decryption step.

Why it then inisted on using /boot/grub/grub.cfg instead of /boot/efi/EFI/grub_uefi/grub.cfg, I don't understand.

My solution to the problem was to reinstall the system, mounting the EFI partition on /boot instead, so that everything boot-related was placed in the unencrypted partition. This also means that GRUB once more tried loading /boot/grub/grub.cfg, which this time was the correct file to use.

Booting worked great. I'll mark the thread as solved.