Hi Gregory,

Gregory Nowak via Dng writes:

> On Mon, Jul 25, 2022 at 08:54:00PM +0900, Olaf Meeuwissen via Dng wrote:
>> OK but if / and /boot are encrypted, something has to be able to decrypt
>> that before GRUB can read /boot/grub/grub.cfg. It might be that GRUB is
>> able to do that itself these days (haven't checked) but on my LibreBoot
>> laptop it's the LibreBoot BIOS that does the decrypting, AFAIK.
>> Hence, my comment.
>
> I can confirm that grub2 in at least Beowulf and now Chimaera can deal
> with decrypting the boot partition if you use LUKS for the encryption:
>
> <https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html>
>
> The archwiki has even more scenarios:
>
> <https://wiki.archlinux.org/title/dm-crypt/Encrypting_an_entire_system>

Thanks for the pointers.

>> I was thinking/hoping I could make an encrypted LV, without encrypting
>> all PVs in the VG. I use a fair number containers and VMs and don't see
>> a need to encrypt those. Actually, I don't see much need for putting
>> these on RAID1 either :-/
>
> You can in fact do what you describe. Make your LV, but instead of
> creating a file system on it, format it as LUKS, unlock it, and create
> your file system on /dev/mapper/unlocked_volume.

I know that but my concern was with increasing LV size.

For encrypted "partitions", the recommendation is to randomize their
content before use to make cracking the decryption harder. If I were to
randomize the content after initial creation of a LUKS formatted LV, any
space added afterwards would *not* be randomized. Hence my idea of
"just" randomizing content of the *whole* disk (all 256GB of it!) before
use.
--
Olaf Meeuwissen