Btrfs + LUKS via tutorial = Slowwwww boot time

General system
1

Hello all,
I recently converted from Manjaro KDE to Endeavor OS with KDE. I followed the Btrfs + LUKS installation guide. All works fine, however unlocking the partition(s) takes FOREVER. systemd-analyze reports the following…

Startup finished in 19.187s (firmware) + 42.058s (loader) + 8.186s (kernel) + 2.426s (userspace) = 1min 11.858s
graphical.target reached after 2.092s in userspace

I am running on an AMD Ryzen 3950X with a 1TB Sabrent Rocket 4.0, so there isn’t a problem with a slow SSD or a slow CPU. When I used to run Kubuntu on my laptop (Core i7-8750H 6 core/12 thread) with LUKS on an ext4 root partition it unlocked almost instantly and resumed booting. However, I understand that the setup used in the tutorial encrypts the /boot partition as well and is not quite apples to apples as the decryption occurs before GRUB loads rather than after.

If there is any way to remedy this situation I would be greatly appreciative.

3

So, after doing a bit of reading, it seems that my issue is down to the number of iterations placed on the individual key slots. Currently, this is my output from “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: 32 d7 81 f1 14 b2 c4 36 60 10 8f c5 f6 11 7e 14 bb 8c a3 be
MK salt: 75 d2 93 bc 7a 6a c2 1c 81 43 86 87 69 17 44 40
06 ca e3 5e a8 0b 1f 70 12 3a d4 48 2e 4a 30 4f
MK iterations: 308042
UUID: 50cd8d58-0225-45a0-b0d2-f262020d404a

Key Slot 0: ENABLED
Iterations: 5059474
Salt: ef 0c dd 03 42 14 83 82 2d 30 b7 0a fc fa 3d 5b
16 88 70 e3 e4 7b 36 3d 41 f6 89 f0 4e 08 00 29
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 4905618
Salt: 7e b3 fd b0 72 32 5c 47 ec d8 61 64 d6 c1 ea 0a
9e 96 ef 18 4b b2 a0 da 9f d4 45 e2 da 0a 23 db
Key material offset: 512
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

~5 million iterations seems very high from what I’ve read? Is this normal behavior for the setup via the tutorial? I tried to lower it via “cryptsetup luksAddKey /dev/[luks_drive] -S 0 --pbkdf-force-iterations [iteration count]” that I read in a thread on the arch forums, but it complains that the keyslot is already occupied.

Now, I have read the LUKS wiki and while I understand that using a higher iteration value increases the security of a passphrase, but taking 40+ seconds to unlock seems insane to me. I mean I wouldn’t mind waiting half or a third of that…

4

Welcome @klandrith
I run both an encrypted install dual boot with Windows 10 on one Intel system and a triple boot of EndeavourOS on Ryzen 3800X using both encrypted and unencrypted install via the wiki tutorial. Hopefully @2000 will see this post and respond as he is the one behind the wiki tutorial for BtrfsonLUKS with timeshift and snapshots. My install is good on both machines. Doesn’t take too long for decryption.

5

Thanks for the info on your system. Hopefully he will respond, that would help very much I am sure.

1 Like
6

Ok, so after reading another forum post, I checked the unlock time using “sudo cryptsetup -v luksOpen --test-passphrase /dev/nvme0n1p2” and it took maybe ~2 seconds. So it doesn’t seem to be an issue related to my actual LUKS decryption scheme, but rather something else. Given that, I’m not sure where to be looking now.

7

Hi @klandrith,

sorry seeing you unhappy with your current setup but given your specs it’s totally understandable; on your system you shouldn’t see those startup times.

Your firmware and loader times seem excessive!? :astonished:

Afaik, there are some things you could try but if the below doesn’t work there’s not much you can do about the firmware time as it really has nothing to do with the operating system.

  1. You may want to check to see if there is some kind of option for “fast boot” in your BIOS. If not, you could try to see if you can disable as much as possible in the UEFI firmware menu (bios). When the machine POSTs, it polls for anything and everything that may be attached to the machine. For things like USB, that can be pretty slow. So if you can disable them, it should speed things up. Once the kernel is loaded, it will re-poll for devices anyway and get everything going.
  2. You could combine the above with changing the default/fallback boot path. Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. The solution is reinstalling or moving the GRUB EFI executable.

But all of this really is highly dependent on the particular firmware that the board ships with. You’ll just have to try different combinations and see if that helps.

I have the exact encryption setup running on an old laptop with similar startup times. This laptop only has an Intel Celeron N2830 which doesn’t support AES-NI, so the de-/encryption bottleneck is the cpu and not the storage.

Your processor should have this feature enabled by default, but to check try the following:

  • To get an idea of what de-/encrypting speeds your system is theoretically capable off, run
    cryptsetup benchmark

  • To check which cipher is currently in use (probably aes-xts, 512b), run
    sudo cryptsetup luksDump <yourLuksDevice> | grep "Cipher\|bits"

Without the AES-instructions enabled on my cpu I can only de-/encrypt about 70 to 75 MiB/s; much less than my ssd could handle. On my other systems with a standard ssd and enabled aes-ni it’s the opposite, here the ssd-speed is the bottleneck.

  • To check if aes-ni is used/activated, run
    grep -m1 -o aes /proc/cpuinfo
    Output should contain “aes” if your cpu uses it; nothing if aes isn’t active.

Instead of lowering the iterations of an existing key you could simply try to add a NEW key with the desired iterations by omitting the specific slot:
sudo cryptsetup luksAddKey /dev/[luks_drive] --pbkdf-force-iterations [iteration count]

Or, if you really want to change the existing key in slot 0, try the following:
sudo cryptsetup luksChangeKey /dev/[luks_drive] --pbkdf-force-iterations [iteration count]
You’ll be prompted to enter in the existing passphrase first, then to enter in your new passphrase and confirm the new passphrase.

But, as you already stated …

… I don’t think this would actually help with your boot times.

That’s all I can think of at the moment, sorry :worried:. Changing your bios settings and the default boot path seems to be the best option for now :pray: . If something else comes to mind I’ll post it here.

8

Welcome aboard! :smile:

One thing that comes to mind (if nothing else helps!) is updating the firmware/BIOS, if that is not up to date on your system.
But if you even consider doing that, please make absolutely sure you’ll use the exactly correct firmware/BIOS for your system. Otherwise you will seriously brick your system.

1 Like
9

Well, with the BIOS/firmware it is somewhat known that the x570 motherboards have a slow boot/POST time, for one reason or another. That’s always been an issue with this board (Gigabyte Aorus Master x570), but I will do some research and see if there is anything to remedy it. It’s not the latest up to date BIOS, I believe its the one from about a year ago.

As far as the LUKS setup, it is aex-xts 512bit. As well, aes-ni is enabled. Benchmarking shows…

aes-xts 512b 1861.0 MiB/s 1828.5 MiB/s

Which is almost a third the speed of what my SSD is capable of without encryption/decryption.

systemd-analyze critical-chain reports the following…(bottlenecks noted)

graphical.target @1.499s
└─sddm.service @1.499s
└─systemd-logind.service @1.453s +45ms [Red - Bottleneck]
└─basic.target @1.445s
└─sockets.target @1.445s
└─dbus.socket @1.445s
└─sysinit.target @1.444s
└─systemd-update-done.service @1.439s +3ms [Red - Bottleneck]
└─ldconfig.service @1.285s +153ms [Red - Bottleneck]
└─local-fs.target @1.285s
└─boot-efi.mount @1.129s +155ms [Red - Bottleneck]
└─systemd-fsck@dev-disk-by\x2duuid-EDA6\x2dE768.service @1.111s +17ms [Red - Bottleneck]
└─local-fs-pre.target @1.110s
└─lvm2-monitor.service @602ms +508ms [Red - Bottleneck]
└─lvm2-lvmetad.service @921ms
└─systemd-udevd.service @881ms +39ms [Red - Bottleneck]
└─systemd-tmpfiles-setup-dev.service @876ms +4ms [Red - Bottleneck]
└─systemd-sysusers.service @855ms +19ms [Red - Bottleneck]
└─systemd-remount-fs.service @605ms +248ms [Red - Bottleneck]
└─systemd-journald.socket @599ms
└─system.slice @583ms
└─-.slice @583ms

Just to give an idea of how the actual boot process proceeds…I am greeted with the GRUB prompt for a password for decryption. After entering it, it takes approximately 30+ seconds to reach the actual GRUB boot menu from there. After selecting Endeavor OS, it takes about another 10 seconds for the kernel to load and for SDDM to load as well. So, it seems that the problem lay somewhere between the GRUB password prompt phase, and getting to the actual GRUB boot menu. Which has me perplexed, given that the opening test only took 2 seconds max to unlock…

10

Did you try the recomendations I posted as “1.” and especially “2.” above?

11

I enabled fastboot. That cut down the firmware time by 7s, and the loader time down by 11s.

[kyle@kyle-x570aorusmaster ~]$ systemd-analyze
Startup finished in 12.907s (firmware) + 31.492s (loader) + 8.220s (kernel) + 1.207s (userspace) = 53.827s
graphical.target reached after 901ms in userspace

I wasn’t able to follow through with #2 just yet. I’m not quite sure what I am doing on that one. Reading the Arch wiki, I have the instructions on what to do, I’m just a little shakey on what exactly I’m doing, lol. Keep in mind, when I had Manjaro installed it booted up just fine without delay (there still was the POST delay as I didn’t have fastboot enabled).

In my BIOS, under the boot order selection, I have “EndeavorOS” as #1, followed by the actual drive it resides on, followed by “UEFI OS.” Before I go changing the GRUB location, that is the correct order, is it not?

Also, I just wanted to say thank you all for the help thus far!

12

You can move your already installed GRUB EFI executable to the default/fallback path:

sudo mv /boot/efi/EFI/EndeavourOS /boot/efi/EFI/BOOT 
sudo mv /boot/efi/EFI/BOOT/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

You could then change/check the boot order with efibootmgr or set it up in your bios.

If need be you can always change back by booting into the live-iso and chroot’ing, :wink:

13

I have an MSI X570 gaming plus and it seems to be fine for booting time.

14

x570 is slower than one would expect - especially compared to b450! My ASUS TUF x570 got much faster than it was with the last BIOS update - but still rather slow. From the sound of it, though, that is not where the problem lies - I would expect perhaps 7 seconds from leaving BIOS screen to greeter on my system under these circumstances.

15

Mine isn’t slow… what you talking about Willis?

16

I guess it depends on your definition of slow! Anything over a 2 count is pretty slow in my book - the B450 ASUS comes to BIOS under that…

17

I thought you meant how long it took to decrypt?

18

Nope! Yours should be too fast for you to pick up your coffee mug. OP is talking about having time to go out to the kitchen and pour a new one!

19

Well it’s not fast but i wouldn’t say it’s slow either. Could be faster yes, but it’s acceptable. Decrypting is a bit slow. I’m booting to rEFInd and then to grub menu on this triple boot EnOS.

20

Thank you for the explanation. It was the changing the boot order part I was missing. I know what you mean now. I will give it a go in a bit and see if it helps.

21

Since I enabled fastboot it only flashes the BIOS logo and key options for a couple seconds at most now before going to the GRUB unlocking prompt. Still gotta move the EFI executables and see if that helps. I’m running the AEGIS BIOS from last December, btw. Anyone know if there is any appreciable reason to update it?