No /boot/efi/EFI/EndeavourOS/grubx64.efi?
Afaik, it should have been created in that path in the default efi install process.
Either …
/boot/efi/.../grub64.efi to/boot/efi/EFI/BOOT/BOOTX64.EFI, regardless of where it’s located right now-OR-
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --removableLeave your /etc/default/grub as is.
OK, I misspoke earlier. There was/is a bootx64.efi present under /boot/efi/EFI/EndeavourOS…I thought it was supposed to be under /boot/efi/EFI since that is the path you mentioned in your post before. Before I realized that I re-installed GRUB per your latest post…So I’m a little unsure how to proceed now…I have the following files present under the following paths…
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/EndeavourOS/EndeavourOS/grubx64.efi
/boot/efi/EFI/EndeavourOS/bootx64.efi
How shall I proceed?
Again, thank you so much for all the help!!! Times like these remind me why I love the FOSS community so much (even with the troubles lol).
You could try to check and set the boot order with
efibootmgr
followed by
sudo efibootmgr -o [boot order] e. g. sudo efibootmgr -o 0001,0000,0003,0002
and then reboot.
If running efibootmgr returns something like “No BootOrder is set; firmware will attempt recovery” you can try to reboot and choose and set up the the correct .efi from within your BIOS.
OK, I erased two SSD’s that had Windows on them (they will be going into a diff machine shortly anyways…), rebooted and my BIOS only listed “UEFI OS” as a viable boot option other than the actual drives themselves. However, efibootmgr still reports a bunch of entries (including a manjaro entry that I don’t know how is still there?). I selected UEFI OS in the BIOS and it booted to the GRUB password prompt like before, and the time to system load and unlock as reported via systemd-analyze was roughly the same as before…
Try to delete unwanted entries with the -B switch, e. g.
sudo efibootmgr -Bb 0003
You should be able to safely remove everything under /boot/efi/EFI/... except the last install as /boot/efi/EFI/BOOT/BOOTX64.EFI
Done. I will reboot later this evening and see how it goes and post an update.
I have these on my dual boot Windows 10 and EndeavourOS with BtrfsonLUKS with timeshift & snapshots.
These are on EndeavourOS. Windows will also have an efi partition with it’s files also.
/boot/efi/EFI/boot/bootx64.efi
/boot/efi/EFI/EndeavourOS/grubx64.efi
This is how mine is set on my dualboot with Windows 10 and EndeavourOS is on a separate SSD drive.
I cleared my Windows drives. Since I am going to be doing some hardware reconfiguration shortly, I may just grab a Samsung 980 Pro 512GB since they support hardware encryption via Opal and as such there isn’t a performance hit like with LUKS, and the 512GB models aren’t too expensive. I have an NAS setup with a 10TB raid 1 array, so I have plenty of space for random crap on the NAS, and I can always use encrypted containers on that if need be…I just installed EndeavourOS the other day, and as such hardly have anything installed/setup yet, so that is a feasible option.
Not really jumping in here - but I thought I saw something that might be troubling. Next time into your BIOS, ensure that Fast Boot is disabled. This is a Windows item - and skipping boot processes in Linux is not what you want 
If there is a CSM entry (Compatability mode) that should be off as well, and secure boot disabled on top of that. Secure boot CAN be handled, but is not needed or a particularly good idea (need boot shims and other tricks to make it work). I am not saying these are this problem (possible, but I don’t know) - but they WILL cause problems if left enabled…
could you please edit your post - to make it readable - to remove the markdown formatting - surround the terminal output / config file content with
``` # content comment content ```
Depending on your systems capabilities running decryption round trips you can lower the amount of round trips when initializing the encrypted partition. The --iter-time argument is defining how many round trips to make during encryption and therefore decryption as well.
# cryptsetup --verbose --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sdyX
See, that’s what I thought, so that’s why I always had it disabled before…Thanks for the tips.
Just to get everybody back on topic; 
the OP has a problem with really slow boot times he shouldn’t have regarding his system …
Just to clarify, I was referring to the BIOS’s fast boot feature, which is distinct from the Windows Fast Startup feature.
The Windows “fast boot” should always be disabled (from within Windows) in dual boot situations.
Regarding the bios’s fast boot feature I’ll just quote good old Rod: [bold by me 
]
This feature can speed up the boot process by taking shortcuts in hardware initialization. Sometimes this is fine, but sometimes it can leave USB hardware uninitialized, which can make it impossible to boot from a USB flash drive or similar device. Thus, disabling fast boot may be helpful, or even required; but you can safely leave it ACTIVE and deactivate it only if you have trouble getting the Linux installer to boot. Note that this feature sometimes goes by another name. In some cases, you must enable USB support rather than disable a fast boot feature.
In almost all cases I’d agree with @freebird54’s recommendation, but seeing as @klandrith could successfully boot and shave off 18 seconds simply by activating fast boot I’d recommend leaving fast boot enabled for now. Just remember that If you notice some strange behavior with some usb devices in the future it could be related to this bios feature. (Sorry @freebird54 )
Thanks for the command @Root, may come in handy some time.
But, …
… I think we’ve already established that @klandrith’s slow boot time shouldn’t have anything to do with his chosen encryption cipher and iteration count.
I still think our best bet is cleaning up these boot entries and “repairing” grub.
Something along the line of …
For good measure, maybe also
Thanks for the clarification on the fast boot front. I have only seen warnings about it - not the possibility of an advantage! Perhaps I should see if the difference can be made use of on my system - as Windows has never come near it (one of the reasons I build my own).
Let’s get him fixed UP!
OK, so I followed all of the suggestions you made, and the time is roughly the same.
Startup finished in 12.788s (firmware) + 44.674s (loader) + 7.973s (kernel) + 3.603s (userspace) = 1min 9.039s
graphical.target reached after 3.254s in userspace
I noticed something though, after entering my pass phrase at the grub menu, it takes about 30 seconds to open slot 0, then it takes about another 10 seconds to get to the grub menu. The reason that I mention this, is because I have two keyslots. I’m assuming that one is for /boot and the second is for the root partition. So grub would unlock slot 0, then the kernel would unlock slot 1. When I was reading before, it was mentioned that grub may use an inefficient crypto library that can result in slow unlocking time of LUKS encrypted /boot partitions.
I’m wondering if maybe I should just scrap this install and try again tomorrow. Maybe there was something I missed or did out of order, I don’t know.
Although grub2 unlocking of a fully encrypted system is slow, 30 seconds is way to slow! ~3-10s is expected, depending on the system specs.
Having a minimum of two keys is normal. Without the second key you’d have to enter your passphrase at least a second time.
I didn’t want to recommend this yet, but it may be the fastest way out .
If you’re dedicating the whole drive/device to this install I’d recommend following the “quick, copy & paste” wiki version.
But try to get rid of all the information residue on the device before installing! For instance in gparted, first delete all partitions and then create a new GPT partition table. We don’t want that Manjaro boot entry and etc. resurfacing.
@klandrith
I agree with @2000. The fast boot is a feature of UEFI and fast startup is a Windows 10 feature that uses hiberfile which i always recommend being turned off. CSM or UEFI only won’t make any difference but i recommend it be on UEFI only. CSM just gives legacy support to boot from non UEFI. On my setup for both BtrfsononLUKS with Timshift and Snap Shots and also the non encrypted installs i used the quick copy and paste version. Mostly because i don’t totally understand all of it. It’s just easier for me than the verbose method. My encrypted install only has one slot that it opens. I have messed the password up once and tried to change it and did but i messed it up. I have installed this a few times so i’m getting used to doing it. I also suspect there may be an issue with grub and i posted what my grub shows. Mine has two entries but i think that is because i am using rEFInd on triple boot and i add the icons to boot from. I have one set up encrypted with xfce dualboot with Windows 10 and the triple boot on rEFInd has Cinnamon Encrypted with Xfce and KDE non Encrypted. Both work well and the decryption on mine does take a little time but it’s not too bad. Slower than i would like but after it decrypts there is no issue with boot time.
@2000: Once again thank you for your great support on encrypted systems!
I do have a similar problem with a newly installed laptop with a dual boot with EOS and W10Pro.
My startup time is really bad for a Ryzen 5 3500U with a 256GB SSD.
system-analyze:
Startup finished in 3.453s (firmware) + 26.041s (loader) + 7.238s (kernel) + 1.983s (userspace) = 38.716s
graphical.target reached after 1.536s in userspace
I also see that time of approximately 20 sec. after entering the passphrase until the grub menu appears. During the last weeks I tried to follow all your hints in this thread, but none of them did help or change the situation.
Do you have any idea where to start an analysis to find the root cause?
If you need any further information, please tell me what you need and I will provide them.
Thanks in advance!
GRUB is early boot. There is no OS (no Linux) available yet. Unfortunately Grub’s implementation is really sh*** and slow on most machines, since (unlike the kernel) it can only do pure software decryption or AES-NI, not SSE-accelerated decryption.
There are some other things you could try instead, though.
cryptomount lacks an option to specify the key slot index to open. All active key slots are tried sequentially until a match is found. Running the PBKDF algorithm is a slow operation, so to speed up things you’ll want the key slot to unlock at GRUB stage to be the first active one.sudo cryptsetup luksOpen --test-passphrase --verbose <encrypted-device>Key slot 0 unlocked.You could try if a different hash and/or iter-time makes any difference. Current cryptsetup defaults are sha256 as the hash algorithm and a iter-time of 2000. (Disclaimer: I haven’t tried this myself; this is purely theoretical).
Release 1.7.0 changed defaults from
sha1tosha256“not for security reasons [but] mainly to prevent compatibility problems on hardened systems where SHA1 is already [being] phased out”[1]. The former default ofsha1can still be used for compatibility with older versions of cryptsetup since it is considered secure
Number of milliseconds to spend with PBKDF2 passphrase processing. Release 1.7.0 changed defaults from
1000to2000to “try to keep PBKDF2 iteration count still high enough and also still acceptable for users.”[2].
You should be able to get the current and change the iterations (not iter-time!) with the following commands …
sudo cryptsetup luksDump <encrypted-device> | grep -B1 "Iterations:"
sudo cryptsetup luksChangeKey --pbkdf-force-iterations <iterations> <encrypted-device>
Changing it affects the unlocking time linearly: for instance halving the iteration count would speed up unlocking by a factor of two; and of course, making low entropy passphrases twice as easy to brute-force. There is a trade-off to be made here.
To change hash and/or iter-time for the whole device you’ll have to run cryptsetup offline with something like this …
sudo cryptsetup-reencrypt --keep-key --hash sha1 --iter-time 1000 <encrypted-device>
My personal opionion :
I rechecked and I too see similar unlock times on all (except one) of my systems with an encrypted boot. I’ve actually never questioned this because I mostly run quite old and seasoned hardware.
I think I’ll just have to accept that the tradeoff for added security is additional boot time (~20 seconds). Of course I could revert to an unencrypted boot scheme; I used to do it that way for about 15 years - but I won’t at this point.
Thanks for all your work and your ideas. I will check them all.
All my laptops and PCs in my family do have a non encrypted /boot-partition and they are all faster than the mentioned laptop even if the rest of the system is encrypted. I am aware of the security problem but it is not a problem for me.
So if all your ideas in this post do not help, I will redo the BtrfsOnLUKS installation with a additional /boot-partition as I do have on all other encrypted systems (installed as LVMonLUKS). And because all user data is stored on a “server” it will be not a big problem.
I checked that. Passphrase is the key for slot 0.
I skipped that.
Key Slot 0: ENABLED
Iterations: 3460646
Key Slot 1: ENABLED
Iterations: 3566584
I did not change any of the iterations or passphrases, because I do not expect great changes compared to changing the installation to a non encrypted /boot-partition.