You are not logged in.

#1 2015-04-16 16:51:41

tcdavis
Member
Registered: 2011-06-02
Posts: 5

Grub, UEFI, and encrypted partitions

I followed the tutorials on the Wiki regarding setting up luks encryption over LVM which worked fine. Part of this process involved getting grub to decrypt the root partition, which also worked. However, I later went and followed instructions for getting UEFI boot to work; I created a separate /boot partition, used grub-install, etc. I'm now in a weird state, though: grub is still using (and unlocking) the root partition and using whatever is in its /boot directory when it really should be using the /boot partition. I've managed to confuse myself enough through all this that I'm not sure what config files and commands I need to mess with to get grub to load the initramfs from the actual boot partition while not also screwing up the root partition that should be unlocked/mounted by systemd.

My common sense tells me that the latter has nothing to do with the former but it took me long enough to figure out the hack of copying everything in the boot partition to root's /boot just to get the thing booting again after a kernel update that I'd rather just ask here wink

Offline

#2 2015-04-16 17:26:27

Head_on_a_Stick
Member
From: The Wirral
Registered: 2014-02-20
Posts: 8,778
Website

Re: Grub, UEFI, and encrypted partitions

tcdavis wrote:

I created a separate /boot partition, used grub-install, etc.

How did you create this partition?

What filesystem did you use?

Did you change /etc/fstab and copy over the contents of your original /boot?

Did you reconfigure GRUB after you installed it?


Jin, Jîyan, Azadî

Offline

#3 2015-04-16 22:34:54

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,489

Re: Grub, UEFI, and encrypted partitions

If you, in your first attempt, installed grub to the MBR and your bios is set to dual legacy/uefi, the grub bios may take precedence now. You should boot the machine/install ISO in pure efi mode before executing the grub install for uefi and best wipe the grub bios which probably installed itself to sectors before the first partition.
edit: actually wiping might not be necessary, if it is set to uefi boot.

Last edited by Strike0 (2015-04-17 07:16:10)

Offline

#4 2015-04-17 12:22:19

EscapedNull
Member
Registered: 2013-12-04
Posts: 129

Re: Grub, UEFI, and encrypted partitions

tcdavis wrote:

I'm now in a weird state, though: grub is still using (and unlocking) the root partition and using whatever is in its /boot directory when it really should be using the /boot partition.

UEFI and a dedicated /boot partition are separate things, and they are not dependent on one another. The problem is most likely coincidental.

Make sure your "root=" and "cryptdevice=" kernel parameters are correct. Edit /etc/default/grub, and use the UUID of the LUKS container on the new /boot partition, replacing the old UUID of the root filesystem. This should be the UUID of the LUKS container itself, not the filesystem contained within it. Use `cryptsetup luksUUID /dev/sda2` substituting sda2 with your /boot partition. This only applies to the kernel and is not directly related to GRUB, so it's just a precautionary measure.

Make sure /boot is mounted, and regenerate grub.cfg:

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

Delete the contents of /boot on the root partition to prevent confusion:

umount /boot
rm -r /boot
mkdir /boot
mount /boot

Also make sure your /boot partition is being mounted (via crypttab and a keyfile) automatically at boot, or you will run into problems later on.

Strike0 wrote:

If you, in your first attempt, installed grub to the MBR and your bios is set to dual legacy/uefi, the grub bios may take precedence now. You should boot the machine/install ISO in pure efi mode before executing the grub install for uefi and best wipe the grub bios which probably installed itself to sectors before the first partition.

I don't know enough about the GRUB internals to say whether or not the UUID of the /boot partition is embedded in GRUB's UEFI stub, but in theory the following commands should overwrite both the BIOS boot loader and UEFI.

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

This way GRUB should use the correct /boot no matter if it is booting in BIOS or UEFI mode.

If these instructions don't solve your problem, please specify what stage of the boot process is failing, and what you saw prior to the boot failure (e.g. did you get a GRUB rescue shell? Did you see the GRUB menu? Did GRUB indicate an incorrect UUID?)

Offline

#5 2015-04-20 14:45:56

tcdavis
Member
Registered: 2011-06-02
Posts: 5

Re: Grub, UEFI, and encrypted partitions

Thank you for the replies! One clarification: BIOS is set to UEFI boot only and this latest format was done with UEFI only in mind; Grub was never installed to the MBR.

EscapedNull wrote:

Make sure your "root=" and "cryptdevice=" kernel parameters are correct...

This is part of my confusion, actually. Let's say my setup is:

sda1 - /boot - no encryption
sdb1 - /root - encrypted

That is, the partition Grub should be using to get the initramfs and stuff is just a straight vfat partition I ran grub-install against. The root partition is encrypted, so maybe those settings need to stay the same anyway. Currently I have:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/lvm/lvroot:root root=/dev/mapper/root resume=/dev/mapper/swap"

You're saying root should be /boot (or UUID) instead?

Last edited by tcdavis (2015-04-20 14:46:10)

Offline

#6 2015-04-21 12:08:35

EscapedNull
Member
Registered: 2013-12-04
Posts: 129

Re: Grub, UEFI, and encrypted partitions

You're not alone in your confusion. This post explains the difference between kernel parameters and GRUB commands, and which UUIDs to use where. That post pertains to grub.cfg instead of /etc/default/grub, but you'll notice that the kernel command line is copied from the latter to the former.

From what I can see, your kernel parameters look correct for LUKS on LVM. The problem must lie in grub.cfg, which is parsed before the kernel is loaded. Follow the instructions in the above linked post to make sure your "search --set=root" commands in grub.cfg contain the UUID for your /boot. Actually, you might find it helpful to read over that whole thread, since it is similar to the problem you're having (sans an encrypted /boot).

If the instructions in my previous post don't work, then please post the output of these commands so we can go through the problem step by step.

lsblk
mount
echo "p" | gdisk /dev/sda
cat /boot/grub/grub.cfg

Offline

Board footer

Powered by FluxBB