Share your lsblk output. It’s likely that your system still leaves the bootloader unencrypted on the disk, even if the kernels and bootloader config are being encrypted (they aren’t encrypted by default on most installs).
It is theoretically possible to have only one partition that is luks encrypted, but this requires you to store the bootloader in the UEFI, and not all motherboards support this, so distros usually just install it to an unencrypted partition. The UEFI needs to be able to read an unencrypted bootloader from somewhere. That’s why it’s somewhat absurd to claim that the ESP can be encrypted, because it simply can’t.
From your link:
One difference is that the kernel and the initrd will be placed in the unencrypted ESP,
Yeah, I’m using a large font in reader mode and I think I had the word encrypted showing without un onscreen.
You are correct, it makes a custom binary in the fat partition that is verified by TPM for unlocking/proceeding, that binary then contains the other parts to move forward.
Share your lsblk output. It’s likely that your system still leaves the bootloader unencrypted on the disk, even if the kernels and bootloader config are being encrypted (they aren’t encrypted by default on most installs).
It is theoretically possible to have only one partition that is luks encrypted, but this requires you to store the bootloader in the UEFI, and not all motherboards support this, so distros usually just install it to an unencrypted partition. The UEFI needs to be able to read an unencrypted bootloader from somewhere. That’s why it’s somewhat absurd to claim that the ESP can be encrypted, because it simply can’t.
From your link:
Yeah, I’m using a large font in reader mode and I think I had the word encrypted showing without un onscreen.
You are correct, it makes a custom binary in the fat partition that is verified by TPM for unlocking/proceeding, that binary then contains the other parts to move forward.