This is not a new problem and has been discussed earlier here: archived.forum.manjaro . org/t/grub-luks-slow-boot/117673
Ok, my problem is, that I have full disk encryption via LUKS. Upon booting, I have to decrypt, which works fine, but takes a long time (around 10-20 seconds).
When decrypting the drive in some running environment, it doesn’t need a second for it.
As far as I understand, not the full CPU capacity is being used under GRUB, so it’s rather slow. A workaround is to decrease the iteration of the used key.
Mine for example has a rather high setting:
Key Slot 0: ENABLED
Iterations: 2221558
As this is on a production environment, I fear that I might break something. In the mentioned post, users are trying to add a new key with fewer iterations. That might work.
I also came across this answer, where you could reencrypt a key with fewer iterations: archived.forum.manjaro . org/t/grub-luks-slow-boot/117673/21
These are the mentioned commands:
cryptsetup-reencrypt --keep-key --hash sha256 /dev/"yourencryptedpartitionhere"
or
cryptsetup-reencrypt --keep-key --iter-time=5000 /dev/"yourencryptedpartitionhere"
Two questions:
Is this a safe method, like in, not making a dumpster fire out of my installation?
Can I do this in the running environment or is booting from a live ISO necessary? (so no mounted disk)
I’m also interested in other answers, if there are some
Use systemd-boot instead of GRUB. I complained about the same problem several times, provided lots of debugging info to prove that (unlike some “experts” want you to believe) this issue has nothing to do with your encryption settings (so changing number of iterations or re-creating keys in LUKS won’t help).
You can find my tests on archived Manjaro forum, and you can repeat them yourself if you are interested. One of them: create a new encrypted partition using the same settings and decrypt it manually using command line - you will see decryption takes a second, which proves it’s not related to iterations, keys, or other settings. It’s solely GRUB’s fault.
Thankfully, some forum members suggested me to switch to systemd-boot and promised it will fix the problem. So I switched to systemd-boot on all my Manjaro machines and decryption now takes a second (like it should).
The only downside - you will need to re-install everything and use Manjaro Architect (can’t do that with “normal” ISO). But as long as you can follow basic instructions, it will be fine.
really?
I thought it is rather simple to switch from booting via grub to booting via systemd-boot.
Although there where some catches and prerequisites not every system meets and the updating the boot entries when a new kernel is installed was not as smooth and required some manual intervention. But that might have changed now.
When re-installing, I’d leave /boot unencrypted - then the decryption is not done by grub but with system tools and at full speed instead of with just one core of the cpu.
But that scenario is not easily possible to achieve because the Manjaro installer doesn’t support that option.
Yes, that’s why I said he will need to re-install using Architect. Unless there’s an easy way to decrypt currently encrypted partitions, switch to another boot manager and re-update encryption settings accordingly. It was way easier for me to re-install from sratch using Architect.
… without looking it up in the arch wiki:
systemd-boot needs an unencrypted /boot partition?
If not, then swapping boot loaders would be easy.
Which I thought it was.
edit:
I had a quick look - found not the arch wiki but two guides
both use a fully encrypted disk and systemd-boot
GRUB is indeed super slow. It uses completely outdated crypto libraries which pretty much don’t utilize any hardware acceleration.
The thing with the keyslots is that they are tested one by one. If you create a new keyslot with way less hash iterations than the initial one, you need to make sure it is in a slot that comes before the one that was generated initially. (Basically just delete the previous / initial one. Of course only if you are sure the new one is accepted and working ok ).
I use this command to get the iterations down enough so grub decrypts in 2-3 seconds. Substitute nvme0n1p6 for your luks partition. You will need to supply your current slot0 password. sudo cryptsetup -v luksAddKey --iter-time 300 /dev/nvme0n1p6 -S 0
This will change the itterations in slot0 and then you can check it by: sudo cryptsetup luksDump /dev/nvme0n1p6
Then your old slot0 that was moved to slot2 (use luksDump to confirm) can be removed: sudo cryptsetup -v luksKillSlot /dev/nvme0n1p6 2
This got my slot0 iterations down to 231600 and a 2.5 second decrypt.
sudo cryptsetup -v luksAddKey --iter-time 300 /dev/nvme0n1p2 -S 0
Enter any existing passphrase:
Key slot 0 unlocked.
Enter new passphrase for key slot:
Verify passphrase:
Key slot 0 is full, please select another one.
Command failed with code -1 (wrong or missing parameters).
Hello, thank you for posting this, I was experiencing exactly the same issue on my surface go with Debian (no matter Manjaro/Debian, the problem seems to be at GRUB decryption, I currently experience ~20s just for decryption which I personally feel too long for a “tablet”).
I just would like you to confirm your above code since the section sudo cryptsetup luksDump /dev/nvme0n1p2 is repeated twice.
Luks manpage is not easy to understand therefore I would like you to confirm my understanding :
luksDump allows to see the slots, right ?
then luksChangeKey allows you to decrease the iteration time (by the way, is 300 reasonable against hacking ?)
finally you did luksDump again to check that iteration change was successful, is it correct ? if yes, which criteria shall I check to confirm this ?
Last questions :
did you perform all those codes from your session or did you use a live USB stick for changing the iteration time ?
And of course, does it format your data ?
Sorry for all those questions but this is my first attempt to manage luks code so I want to be sure I don’t mistake.
