Delay at boot with luks (not a bug, just FYI)

Thanks and congrats to the team the new release!

FYI, I just did a clean install using the latest iso and after rebooting, it asked for my luks password and stopped for 1 minute and 30 seconds (“a start job is running”), then displayed a couple of errors: “dependency fail for cryptography setup” and “for local encrypted volume”. Everything else was normal.

I looked inside /etc/cryptsetup and there were 2 crypto_keyfile.bin entries: one was for my ext4 uuid, the other one was causing the issue so I removed it. That uuid was for an external disk with a luks partition that I plugged in during installation to copy a file. It seems the installer automatically added it, just saying in case someone else is having this delay at boot.

4 Likes

I’ve noticed this too with udisks2 deciding to add transient usb-drives to my fstab. I don’t think it’s an Endeavour-OS issue per se, more something to do with the behaviour of udisks2 handling of devices. I may, however, be mistaken, but it’s a good catch! I wonder if it’s possible to just set noauto for any devices added, but this doesn’t take into account any new devices you add…

Thanks for posting! :slight_smile:

yes not a BUG more caused by a feature that makes calamares be hacked and used in many ways and custom setups :wink:

Longer luks grub decrypt times can be caused by the number of iterations used for the luks slot. The larger the iterations to longer to decrypt.

Use cryptsetup luksDump to view iterations (and other info) about your luks slots for a particular luks container.

1 Like