Long delay after entering LUKS passphrase for grub

I installed Tumbleweed recently and selected to use encryption but not LVM. For now it means I need to enter two passphrases on boot but that’s all right.

Now when my PC boots I get the prompt to unlock the root, which I enter.

Enter passphrase for hd0,gpt2 ( ... ): ****************************
Attempting to decrypt master key...

The screen now hangs here for about 50 seconds. Slot 0 opened flashes up briefly and then I get to the GRUB menu. I am prompted to decrypt the swap partition later in the boot process.

Does anyone know where this long delay comes from, or what I might do to fix it? It’s not a big deal but it’s interesting.

As I understand it, LUKS decryption currently isn’t able to take any advantage of any hardware acceleration, which is why it’s relatively slow. My laptop isn’t quite as slow as you’re reporting, but it’s definitely not what I’d call snappy, and it’s less than a year old.

Grub uses the BIOS for reading the disk. And the BIOS is often slow.

For me, it is perhaps 20-30 seconds. Be happy that you are using “ext4”, because it would probably be slower with “btrfs”.

It’s 20 seconds for me using btrfs.
I may be wrong, but I believe the reason you have to enter the passphrase twice is due to having a second, swap, partition.
I got around this by reinstalling and creating a swap file instead.

You can also avoid the passphrase request for a swap partition, by configuring it as randomly encrypted swap. Hibernation won’t work, but it is otherwise fine. And the OP’s swap partition is probably too small for hibernation.

I mentioned the swap partition just in case there was any interaction but I don’t think it has an effect here. It’s not bothering me any case. It’s just the slowness in the first unlock that I’m curious about. When the Debian installer sets up full disk encryption, for example, GRUB gets to run immediately, which I’m guessing may be due to leaving a larger /boot partition unencrypted. The prompt to unlock comes after selecting the kernel and always proceeds quickly. Perhaps I would have to create a similar arrangement but it’s just guesswork at this point. :slight_smile:

Yes, that’s correct.

I use a separate unencrypted “/boot” partition, and the grub menu comes up quickly. The encryption request is later, but still goes fairly quickly. But that’s because the kernel has already been loaded and handling disks more efficiently than the BIOS. Your early encryption request is slow because of slow BIOS speed for accessing disks.

1 Like

To be sure it is due to slow BIOS access, you could boot from a USB stick and then mount the disk using luksOpen, how long does that take?

On my desktop I have my home directory encrypted and that is opened later in the boot process. On my Laptop I have full disk encryption but that is only asking for a password after the Grub menu, that works by having /boot not encrypted.

I selected disc encryption during install and don’t seem to have an encrypted /boot/efi however I still get the 20sec delay.

Only 2% of my 512mb boot partition is being used.

From my system:

% df | grep  boot
/dev/sdc3                     477538    139878    312060  31% /boot
/dev/sdc1                     510984     18420    492564   4% /boot/efi

It is “/boot” rather than “/boot/efi” that matters. “/boot/efi” should be your EFI partition, and is never encrypted.

Here, “/boot” is an “ext2” partition that is not encrypted. The kernel, the “initrd” and the boot menu (“/boot/grub2/grub.cfg”) are all in that unencrypted partition. So grub can access them without a password.

If “/boot” is encrypted, then “grub” will need a password to access those files.

I assume you mean “/boot/efi”. Here it is 4%, but that’s because I have Tumbleweed, Leap 15.4 and Leap 15.5 installed. I don’t worry about the space usage in that partition.

As you can see, “/boot” is 31% used. The space is mostly for two kernels and their related “initrd” files. It’s good to have some spare space there if I need to install a special purpose kernel.

1 Like