Antony Stone writes:

> On Sunday 24 July 2022 at 11:58:01, Olaf Meeuwissen wrote:
>
>> Hi Antony,
>>
>> Thanks for the feedback. I've been researching a bit myself in the mean
>> time as well but still value additional input from the list.
>
> I completely agree - asking people with experience, and with whom you can have
> a bit of a dialogue, is always a bit more encouranging than finding informatin
> of random ageas from random people on the Internet :)

Exactly!

>> > The only part of this you need to remember to do manually is grub-install
>> > /dev/thing2 if there's ever a new version of grub itself.
>>
>> I vaguely recall reading that you could enter a list of space separated
>> devices to install GRUB to in the installer.
>
> True, you can do this in the installer, but if grub gets updated later on, my
> experience is that it only updates the boot loader on the primary disk.

I'll make a note of that.

>> > Er, what's ESP?
>>
>> It's not Extra-Sensory Perception in this context :-P
>> It's the EFI System Partition and is what gets mounted on /boot/efi/.
>
> Ah, right, I seriously doubt you can put that on Raid, because it's not being
> read by Linux - it's being read by the UEFI/Bios ystsem itself in the machine,
> in order to find the boot loader (as far as I understand this process).

Turns out you can but it needs some special tinkering. See

https://wiki.archlinux.org/title/EFI_system_partition#ESP_on_software_RAID1
https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/

Of course, you might get lucky and have a BIOS that understands RAID1 ...

> However, I also think it's something that you would simply install on both
> disksk and then leave it thre - either disk can then get the machien going.
>

>> > >    - if not, how do I keep the copies in sync?

>
> As far as *that* one goes, I don't think you need to - I don't think this ever
> gets updated.

Then what would be the point of mounting it on /boot/efi?
It looks like efibootmgr can be used to tweak a couple of things, so if
you do, you'd want that reflected to the copy as well.

>> > > - do I need a separate partition for /boot?
>> >
>> > You do not need one, but you can have one.
>>
>> Then I'd rather do without. I asked because on a few of my systems it
>> *is* a separate partition.
>
> Yes, it used to be necessary before Linux could find /boot in LVM on Raid, for
> example. You could put that separate /boot on Raid, but the LVM bit in the
> middle confused Grub before 2.00, as I recall.

So it won't be an issue on chimaera and beyond.

>> Thinking about that, I believe these were installed to use a "fully"
>> encrypted system, i.e. the partition mounted on / encrypted as well. In
>> that case it makes sense because most BIOSs probably do not handle that.
>
> It's not the Bios that's doing anything at this stage - it's Grub.
>
> Bios looks at the boot sector on the disk, discovers Grub, and hands control
> over to it. Grub then needs to know where / how to find /boot, because that
> contains /boot/grub/grub.cfg, which has all the details of everything want to
> be able to start up.

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.

> But, the Grub loader in the boot sector is small and simple, and also needs to
> be able to find an encryption key if it's going to be able to decipher /boot in
> an encrypted file system.

FTR, I enter the key via the keyboard.

>> If I only want/need an encrypted /home then I should be okay with /boot
>> on the partition that's mounted on /.
>
> Precisely.
>

>> > >  - does randomizing the partition for /home make sense if on LVM and may
>> > >    get resized sometime in the future?

>> >
>> > What do you mean by randomizing?
>>
>> Writing random data to the partition before using it. This is supposed
>> to make it harder to decrypt for prying eyes.
>
> Ah, right.
>
>> After I sent my mail, I thought I could randomize the whole disk (or
>> that part that's used as an LVM PV) but that might take a while ...
>
> Well, let's just think about that - if you write random data to a device and
> then use it as a PV for a VG, anyone who can get into the LVM system can see
> the VG and whatever LVs it contains, and therefore just ignores the random
> data.

True, but my concern was with the case where I'd resize the LV after
initial creation. Suppose the LV was randomized upon initial creation
and then I extend it by a couple of GB. Those extra GB would then not
be randomized, IIUC, and I'm not sure how one would go about randomizing
them after the fact. Hence, making sure everything that could possibly
end up being part of an encrypted LV is randomized beforehand would
solve that (at the expense of randomizing too much).

> Unless you can put LVM2 onto an encrypted block device (?), then I
> don't think this helps you. All you can do is create a VG (that's visible to
> anyone who can get this far into your machine) and then create an encrypted FS
> on it.

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 :-/

# FTR, I still have space for a SATA SSD in addition to the PCIe NVMe
# SSDs. I might just buy one and use that to stash my containers and
# VMs.

> However, as you may have worked out, this is beyond my eperience of setting
> things up - I do LVM on RAID all the time (both RAID 1 and RAID5), but I've
> never bothered to set up an encrypted file system.
>
> I'm sure others can offer expertise here :)

Eagerly awaiting that expertise ;-)

>> Thanks again and looking forward to other opinions and follow-up!
>
> Indeed - I hope other people chip in with different opinions and expertise of
> doing things outside my habits.

Same here.
--
Olaf Meeuwissen