Can /boot be on an own partition to avoid 2 times password with disk encryption?

English Install/Boot/Login
1

Hi, so far, I enjoy my new Leap installation a lot, but there is one thing I dislike.

The disk encryption password for Grub.
It is slow, and when written wrong, there is no retry, but you land in an ugly grub shell.

I know I can do a setup so I have to provide the password only once. But that will be the grub password, with its disadvantages.

I don’t care about the security impact of having a non-ecrypted boot. I am OK if only the data on the disk is encrypted.

Would moving /boot on its partition solve that, and would there be any disadvantages for functionality when doing so?

2

Yes, it is slow. Grub is using BIOS services (or UEFI firmware services), and those tend to be slower.

I rarely get the passphrase wrong. When I do, I use CTRL-ALT-DEL to retry.

On my primary desktop, I do use a separate “/boot” and that avoids the problem. However, I am using “ext4” as the file system. With “btrfs” you might have a problem with restoring an older snapshot, because the kernel for the snapshot might not match what grub expects.

3

With “btrfs” you might have a problem with restoring an older snapshot, because the kernel for the snapshot might not match what grub expects.

Maybe I am wrong, but I think the boot partition is not part of snapshots since subvolumes are excluded.

4

With a separate “/boot”, it won’t be part of the snapshot.

If “/boot” is part of the root partition, then it is not a subvolume, as I recall. However, “/boot/grub2/x86_64-efi” is a subvolume, so that grub itself is not part of the snapshot (and a similar directory if using BIOS booting instead of UEFI booting). So a rollback will roll back the kernel properly in that case.

5

Ok, thanks, that makes sense.
I fear I will have to live with the slow Grub decryption.
But that also makes dracut-crypt-ssh useless, in case remote booting an encrypted disk could be important
I think I will have to weigh the pros and cons per use case