LUKS slow early boot

General system Kernel, boot, graphics & hardware
1

Since the grub boot issue I have discovered my boot has become unbearable slow (again):

Startup finished in 5.493s (firmware) + 1min 22.731s (loader) + 2.511s (kernel) + 8.851s (userspace) = 1min 39.587s 
graphical.target reached after 8.586s in userspace.

I have a full disk encryption with LUKS and use brtfs.

I’m aware of the other topis about this topic and the fact that early boot will not have the hardware acceleration as when using the live system. Previously I had changed the iter count to something like 200 000 which proofed to be usable.

I’ve since changed the iter count to a very low value (10 000) as a test.

When currently booting and entering the passphrase it takes only a second to get the message “Slot 0 opened”. After this the system just waits/hangs for over a minute before showing grub and continuing a normal fast boot process.

For me this indicates that the decrypting goes fast. But I have no idea what takes so much time?!

Further info:

➜  ~ lsblk                                                                                           
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                       259:0    0 931.5G  0 disk  
├─nvme0n1p1                                   259:1    0   512M  0 part  /boot/efi
└─nvme0n1p2                                   259:2    0   931G  0 part  
  └─luks-edc44bc0-2f50-4c32-b33b-dbb1586cf37c 254:0    0   931G  0 crypt /var/lib/docker/btrfs
                                                                         /var/cache/pacman/pkg
                                                                         /var/cache
                                                                         /home
                                                                         /

➜  ~ sudo cryptsetup luksDump /dev/nvme0n1p2 
LUKS header information for /dev/nvme0n1p2

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
MK digest:      3c 6b c2 72 ab a0 77 ef ff dd fd 8f 06 c8 d0 8e 62 17 29 04 
MK salt:        85 96 2b 33 3a 44 bd 51 36 0e b1 32 38 fb a0 bb 
                fc 66 54 0d ce 28 fa ef e4 1b ec e6 77 b4 6b 1a 
MK iterations:  316599
UUID:           edc44bc0-2f50-4c32-b33b-dbb1586cf37c

Key Slot 0: DISABLED
Key Slot 1: ENABLED
        Iterations:             10000
        Salt:                   ae c3 cc 5a 1b 87 0c e6 eb 7f 97 07 76 6a 95 ab 
                                84 6b 2f 43 09 31 70 1a ab 19 ae 2a 53 fe 98 10 
        Key material offset:    512
        AF stripes:             4000
Key Slot 2: ENABLED
        Iterations:             10000
        Salt:                   4f 95 3c 21 a8 96 b8 b6 2d 63 b3 a3 28 de fc c0 
                                10 0b 93 51 1c f5 26 42 af e8 39 1e 44 17 36 73 
        Key material offset:    1016
        AF stripes:             4000
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

I hope someone will understand why there is such a huge wait between opening slot0 at boot and grub :).

2

The grub package currently in testing, 2:2.06.r322.gd9b4638c5-4 is supposed to help with grub slow boot issues.

3

Would you happen to have a link to the why for this?

I’m not sure how to just test this grub version from testing, without committing to the full testing repo’s (is that even possible?). Or I should just accept this until this version comes into the normal repo’s and hope it will fix itself :slight_smile: .

Thanks for the reply!

4

Of course, it is an increase in the default heap size.

You can install it directly with pacman -U https://arch.unixpeople.org/testing/os/x86_64/grub-2%3A2.06.r322.gd9b4638c5-4-x86_64.pkg.tar.zst

5

No wonder, Linux Kernel is encrypted in /boot/ that is why grub decrypts the Kernel much slower than unecrypted Kernel in /boot.

6

I’ve tried this + a grub-install but sadly it did not make any difference. Looks like it should though, so maybe still user error somewhere (it’s definitely not my main area of expertise!) :).

Thanks for the links tot the issues! It seems that I’m experiencing a very similar regression so that’s hopeful.

Edit: it does look that the issue is describing issues after reaching the grub menu? For me the slowdown is between opening slot0 and reaching grub menu. Hmm.

7

I’m aware my /boot is also encrypted. In the past it was never such a big issue when booting. Only opening the ‘slot’ took a bit longer, but afterwards I got to grub menu very quickly. Now it takes ages after opening the slot before reaching the grub menu. Especially with the low iterations it seems something is off.

8

Having same issue on 3 separate (one older pc, one newer pc, and a newer laptop) machines since grub stuff happened a couple weeks ago. Machines have had EndevourOS for at least a year (one for 2+years)

I had posted something here: ( Since grub issue extremely slow boots on encrypted btrfs systems ) and @dalto referred me to this post.

Does this sound like a waiting game? What’s boggling me is that on 2 of my machines I have a hard drive light, and from the moment it says “slot 0 opened” until I get to a logon prompt (as long as minutes in some cases) the hard drive appears to be going full blast

9

I have the same issue on a fully encrypted btrfs root - the 5 second delay I had before is now 15-20 seconds.

10

If you want encryption and booting into btrfs snapshot in grub, an idea would be two separated partitions:

  • A unencrypted partition / lets Grub quickly load Linux Kernel and boot into any system snasphot.
  • A encrypted partition /home, your private data are encrypted in it and can be restored by home snapshot.

If you do not need booting into btrfs snapshot, just use systemd-boot instead grub.

11

It is very hard to ensure that all your private data stays in /home. For example, how do you keep it out of /var/cache and/or /tmp.

12

This is fine and good, but the issue is that everything was fine and booting great (for years) with it all configured as is and using grub, then the grub thing happened and booting is so slow. So I’m just trying to understand what changed, and why?

13

/tmp uses the RAM based filesystem tmpfs by default, temporary data is not stored in any hard disk, but it is in RAM that will erase data when PC is turned off without power.

/var/cache is mostly used for apps because of better performance in general, but it is rarely a small part of your private cache data. But a large part of the private cache data is stored in $HOME/.cache/

Yes, for example /var/lib/docker and any databases etc…, they would be moved manually to home partition or other encryption partition and mounted with their same places in the root partition.

14

It is pretty common for a laptop to be stolen while it does have power…

Each individual needs to decide for themselves which risk scenarios they do and don’t care about.

My more general point was that encrypting /home ins’t a solution for someone who wants full disk encryption. It is an alternative solution for someone who doesn’t require FDE.