Thanks for welcoming me. I know you have commented on that topic here in the past. So I know this topic is disputed. I know my approach here is not for everyone. I’m willing to trade convenience for security, which does also include backing up my LUKS headers and restoring them. Even if you don’t encrypt your boot partition and go for the default root partition encryption that Anaconda offers you would have to backup your LUKS header anyway.
I don’t want to rely on a key file (or TPM), I’d rather commit a passphrase to my memory or use a password manager. I also don’t trust UEFI secure boot to keep the boot process secured and neither do IT security analysts. Exploits like BootHole and BlackLotus have shown in the past that secure boot has fundamental flaws, and recent PKfail has shown this once more. So what’s left if one can’t choose something like Coreboot and wants to make it harder for attackers with hardware access?
I have read that OpenSUSE does offer encrypted boot with their default installer (haven’t verified it, though) but apparently Fedora’s Anaconda still doesn’t. This issue has already been brought up here a couple of time, e.g. here but still lacks a proper solution (see my comment on your advanced installer suggestion below). That’s why I started this thread.
Do I understand correctly, that you created “/boot,” “/” and “/home” all under one LVM and encrypted that with LUKS2? If yes as GRUB does not support argon2id yet, there would be no other option than to use (weaker) pbkdf2 for the whole. And that’s exactly what I want to prevent. I don’t want to fall back to a weaker kdf for “/” and "/home’.