4 ms·
In a systemd-boot setup there is no "boot partition", encrypted or otherwise. There is an EFI partition that contains the systemd-boot EFI binary and the UKI bi
by Arnavion 4y ago
In a systemd-boot setup there is no "boot partition", encrypted or otherwise. There is an EFI partition that contains the systemd-boot EFI binary and the UKI binary, and it is a regular unencrypted FAT32 partition.
The UKI will contain kernel + initramfs to be able to mount your encrypted root partition as `/`, using regular cryptsetup, not the special low-perf code used by grub.
And to be clear, this is how UEFI boot would work even if you didn't have systemd-boot and had your firmware directly boot the UKI.
- shmerl 4y agoHm, I don't want to put the kernel into EFI partition though. With GRUB the kernel sits in the encrypted /boot on the root. The catch is that GRUB can decrypt root on its own without the kernel, but it's super slow for some weird reason. So I need something similar, but without performance bottlenecks.
- Arnavion 4y ago>Hm, I don't want to put the kernel into EFI partition though. Because?
- shmerl 4y agoLet it be encrypted with everything else. That's the whole point of not using the boot partition.
- Arnavion 4y ago>Let it be encrypted with everything else. Why?
- shmerl 4y agoWrong question. Why not? I want everything to be encrypted. Something must be left out and it should be the least possible amount. Leaving out the kernel is clearly not the least possible.
- Arnavion 4y agoThen UEFI boot is not for you.
- shmerl 4y agoThat's the only one that's there unless you have custom firmware for the motherboard. So with UEFI, GRUB being left out is pretty small in comparison with leaving out the whole kernel.
- still_grokking 4y agoHave you ever looked at Grub more closely? It's actually a whole operating system by now! Only a very shitty one, and in comparison not well maintained…
- still_grokking 4y ago> I want everything to be encrypted. Why?
- michaelmrose 4y agoIt's advantageous for the process of trying a passphrase to be too slow to do a million times a second but fast enough that it isn't bothersome to the user. This is a tunable parameter --iter-time given in ms when adding or modifying a passphrase to a slot. If I understand correctly its cryptsetup luksChangeKey DEVICE --iter-time <time in ms> Consult your manual and backup before making any changes to encrypted devices lest tragedy ensue. 2 things of note. - Luks slots are tried in succession adding a second faster slot after a slow slot will be slower because it will try the slow one first fail then unlock with the fast slot. - You should back up your luks header because a small amount of corruption in the right place can make the entire encrypted volume unrecoverable
- shmerl 4y agoNot that slow. When kernel decrypts LUKS it's fast because it's using modern CPU commands that GRUB doesn't for some reason, if I understand correctly. Which just results in way worse decryption time.