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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
