Btrfs + LUKS via tutorial = Slowwwww boot time

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.