Re: [DNG] UEFI, software RAID1, LVM and encryption

[Gregory Nowak via Dng]

On Wed, Jul 27, 2022 at 07:54:24PM +0900, Olaf Meeuwissen wrote:
> 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:
> >
> > 
> >
> > The archwiki has even more scenarios:
> >
> > 
> 
> 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.

If filling the free space on the disk with random data is important to
you, then just filling the entire disk with random data before use is
probably the best way to go. You can then resize volumes in the future
without having to worry that the free space is being filled with non
random data. Do note that you don't want to enable discards in
lvm.conf (this is the default) if you want to be sure unencrypted data doesn't 
end up on the
disk. By not enabling discards, you are decreasing the life of your
flash, by how much, I'm not sure. I suspect that would depend on how
frequently the disk is written to. I keep my encrypted volumes on
RAID10 spinning disks, so this isn't a trade off I've had to deal with.

Greg


> --
> Olaf Meeuwissen
> 

-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Olaf Meeuwissen via Dng]

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:
>
> 
>
> The archwiki has even more scenarios:
>
> 

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

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Gregory Nowak via Dng]

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:



The archwiki has even more scenarios:



> 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.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[o1bigtenor via Dng]

On Mon, Jul 25, 2022 at 6:24 AM Olaf Meeuwissen
 wrote:
>
> Hi o1bigtenor,
>
> o1bigtenor writes:
>
> > On Sat, Jul 23, 2022 at 10:19 PM Olaf Meeuwissen via Dng
> >  wrote:
> >>
> >> Hi list,
> >>
> >> I lost the single SSD on my mini PC and am in the process of rethinking
> >> its storage.  So far, I've got myself two brand new and identical PCIe
> >> NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
> >> enable UEFI to get access to the BIOS from the GRUB menu.
> >>
> >> I want my /home directory on a partition of its own, at a minimum, and
> >> encrypt it.  I don't see a need to encrypt much else as I am not after
> >> plausible deniability.  It's mostly to be able to return a broken disk
> >> for a replacement and still sleep in relative peace of mind ;-)
> >>
> >> I haven't quite made up my mind as to a need for other partitions.  I
> >> use containers and VMs quite a bit.  Perhaps these are better stored
> >> some place other than the partitions for / or (an encrypted) /home.
> >>
> >> With 64GB of RAM, I don't see much need for swap.  If needed, I could
> >> always add a swapfile instead of a partition.
> >>
> >> Given the above,
> >>
> >>  - what are your expert(?) opinions on partitioning for this?
> >
> > Well - - - expert - - - lol - - maybe in my mind but not really even
> > there - - -grin
> > but I've just done something like this!
> >
> >>  - how do I make (and keep) both disks bootable?
> >
> > I used the partitions
> > 1. small (4M) empty in between each partition
> > 2. ESP on each disk (partiion #1)
> > 3. see #1
> > 4. partition on each disk
> > rolled each partition into a raid 1 array.
> > 5. see #1
> > 6. see #4
> > 7. repeat until complete
>
> I don't really understand why you used the "small" unused partitions in
> between.  Some kind of buffer to prevent "out-of-range" writes?

I first used gpt to partition a uefi setup some over 10 years ago.
At that time there was a recommendation of (IIRC) 2 MB spaces between
the partitions. Seemed to work and I moved to 4 MB as that is the (again
IIRC) block size on the items. So I have an empty block between every
partition. Given that I don't use anything smaller than 1 TB losing even
20 blocks of space imo is minimal. (Again) IIRC the idea was that if one
needed to rescue the partition have the empty space on either side was
to make things go better - - - dunno as to the legitimacy of such but
until its thoroughly debunked for me - - - I'll likely continue. (I
run a raid-10
array for my main storage (/home is more short term although I need to
do some serious cleanup) as I was serious security and like the speed
compared to raid-6 anyway. If I had need for a lot more space (would be
a lot more $$$) I think I would go to raid-60 for my main storage anyway.
>
> >>  - can I put the ESP on RAID1?
> >
> > I couldn't find a practical way to do this.
> > Read of some who built their system on disc 1 and then
> > copied everything to disc 2 then did some kind of interesting and, for me
> > anyway, confusing manipulations and then they had a raid-1 array where
> > one array had everything.
>
> I came across
>
>   https://wiki.archlinux.org/title/EFI_system_partition#ESP_on_software_RAID1
>   https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/
>
> which indicate it is possible but not without taking some extra care.
>
> >>- if not, how do I keep the copies in sync?
> >
> > Using the copy and then manipulate to make raid1 then supposedly does
> > that but I didn't do that so - - - dunno.
> >
> >>  - do I need a separate partition for /boot?
> >
> > I gave it one.
>
> In other follow up, Antony Stone and I concluded that it would not be
> needed for my needs.  In that case, I prefer to go without and keep it
> simple.
>
> >>- if so, can it be put on RAID1?
> >
> > My stuff has a raid1 array for every partition except ESP.
>
> I think that's what I'll end up using too.

IMO its not elegant to need to use a raid partition for each of my
partitions. I would think I could specify raid-1 for my partitions and
there would be one raid device instead of my bulging portemanteau
of them! But - - - I think I'm a fringe thinker for raid use. The linux
raid list denizens have at least indicated such. They see little need
for more than raid-5. Maybe I've been a business owner too long and
really really hated the last time I had to redo a years worth of data
for my business (recordkeeping) but once is enough!

>
> >>  - if not, how do I keep the copies in sync?
> >>  - should I use LVM?
> >
> > Me - - - maybe I'm just deficient but I didn't want to deal with one more
> > possible point of failure so I did NOT use LVM. (I tend to not only like
> > but practice the K.I.S.S. principle.) Maybe I should have but don't see the
> > value in adding complexity.
>
> Hmm, if I were to practice KISS (and I usually do), I'd leave out the
> unused partitions and keep /boot as part of the partition mounted on /
> :-P
>
> The 

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Olaf Meeuwissen via Dng]

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 

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Olaf Meeuwissen via Dng]

Hi Didier,

Didier Kryn writes:

> Le 24/07/2022 à 05:18, Olaf Meeuwissen via Dng a écrit:
>> Hi list,
>>
>> I lost the single SSD on my mini PC and am in the process of rethinking
>> its storage.  So far, I've got myself two brand new and identical PCIe
>> NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
>> enable UEFI to get access to the BIOS from the GRUB menu.
>>
>> I want my /home directory on a partition of its own, at a minimum, and
>> encrypt it.  I don't see a need to encrypt much else as I am not after
>> plausible deniability.  It's mostly to be able to return a broken disk
>> for a replacement and still sleep in relative peace of mind;-)
>>
>> I haven't quite made up my mind as to a need for other partitions.  I
>> use containers and VMs quite a bit.  Perhaps these are better stored
>> some place other than the partitions for / or (an encrypted) /home.
>>
>> With 64GB of RAM, I don't see much need for swap.  If needed, I could
>> always add a swapfile instead of a partition.
>
>   Apart from the containers, which I haven't any experience of, and
> given your pretty reasonable description of your needs, my take would be
> to reserve the whole of your RAID1 for /home and add a small ssd for all
> the OS, in one single partition. Of course, no swap.

Hmm, if I were to add a small ssd, I'd either have to use up the one
SATA SSD port I have or revert to using an SSD on one of the USB ports.

I think I'm better off carving out a 30GB or so partition for the OS on
the RAID1.  The 30GB value comes from a chimaera install using guided
partitioning for the entire disk with encrypted LVM and a separate
/home.  I've found a 30GB partition for the OS to be plenty roomy for my
needs but it will happily hold a mostly default Xfce4 GUI.  Even adding
fcitx-mocz and Japanese fonts, a must for me, leaves room to spare.

>   If you happen to loose the OS disk, which is very unlikely: not a
> big harm, install Devuan on a fresh one. Your home is safe, although the
> only protection against your own mistakes is, of course, backup. KISS!

Putting both OS and /home on RAID1 would keep both safe.  Backups don't
only protect against one's own mistakes, they also protect against very
bad disk failures ... as I recently found out the hard way :-(

# I didn't quite expect my SSD to go bad on me after six months and a
# bad.  Actually, I can still see some of the file system but as soon
# as I get an I/O error, the device disappears.
# Reading the initrd triggers one ... duh!

My new setup will definitely run rsync backups on (ana)cron to a NAS on
the home LAN.
--
Olaf Meeuwissen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Didier Kryn]

Le 24/07/2022 à 05:18, Olaf Meeuwissen via Dng a écrit :

Hi list,

I lost the single SSD on my mini PC and am in the process of rethinking
its storage.  So far, I've got myself two brand new and identical PCIe
NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
enable UEFI to get access to the BIOS from the GRUB menu.

I want my /home directory on a partition of its own, at a minimum, and
encrypt it.  I don't see a need to encrypt much else as I am not after
plausible deniability.  It's mostly to be able to return a broken disk
for a replacement and still sleep in relative peace of mind;-)

I haven't quite made up my mind as to a need for other partitions.  I
use containers and VMs quite a bit.  Perhaps these are better stored
some place other than the partitions for / or (an encrypted) /home.

With 64GB of RAM, I don't see much need for swap.  If needed, I could
always add a swapfile instead of a partition.


    Apart from the containers, which I haven't any experience of, and 
given your pretty reasonable description of your needs, my take would be 
to reserve the whole of your RAID1 for /home and add a small ssd for all 
the OS, in one single partition. Of course, no swap.


    If you happen to loose the OS disk, which is very unlikely: not a 
big harm, install Devuan on a fresh one. Your home is safe, although the 
only protection against your own mistakes is, of course, backup. KISS!


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Antony Stone]

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

> > 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.

> > 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).

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.

> > >  - 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.

> 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.

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.

> 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.  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.

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

> 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.


Antony.

-- 
When you find yourself arguing with an idiot,
you should first of all make sure
that the other person isn't doing the same thing.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Olaf Meeuwissen via Dng]

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.

Antony Stone writes:

> On Sunday 24 July 2022 at 05:18:47, Olaf Meeuwissen via Dng wrote:
>
>> Hi list,
>>
>> I lost the single SSD on my mini PC and am in the process of rethinking
>> its storage.  So far, I've got myself two brand new and identical PCIe
>> NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
>> enable UEFI to get access to the BIOS from the GRUB menu.
>>
>> I want my /home directory on a partition of its own, at a minimum, and
>> encrypt it.  I don't see a need to encrypt much else as I am not after
>> plausible deniability.  It's mostly to be able to return a broken disk
>> for a replacement and still sleep in relative peace of mind ;-)
>>
>> I haven't quite made up my mind as to a need for other partitions.  I
>> use containers and VMs quite a bit.  Perhaps these are better stored
>> some place other than the partitions for / or (an encrypted) /home.
>>
>> With 64GB of RAM, I don't see much need for swap.  If needed, I could
>> always add a swapfile instead of a partition.
>>
>> Given the above,
>>
>>  - what are your expert(?) opinions on partitioning for this?
>
> Use LVM on top of RAID - great flexibility, plus reliability.
>
>>  - how do I make (and keep) both disks bootable?
>
> grub-install /dev/thing1
> grub-install /dev/thing2
>
> You can keep /boot as a separate RAID1 (separate from LVM, that is) if you
> want to, or you can include it in LVM these days.
>
> That means you have the grub loader itself, the grub.conf, and the initramfs
> and kernel, all replicated on both disks.
>
> 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.

On top of that, I think I actually configured something like that in
/etc/default/grub on one of the machines at the office.

>>  - can I put the ESP on RAID1?
>
> 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/.

>>- if not, how do I keep the copies in sync?
>
>>  - 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.  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.

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

>>- if so, can it be put on RAID1?
>
> Yes.
>
>>  - if not, how do I keep the copies in sync?
>
> n/a

ACK.

>>  - should I use LVM?
>
> Yes, IMHO.
>
>>  - 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.

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 ...

Thanks again and looking forward to other opinions and follow-up!
--
Olaf Meeuwissen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Antony Stone]

On Sunday 24 July 2022 at 05:18:47, Olaf Meeuwissen via Dng wrote:

> Hi list,
> 
> I lost the single SSD on my mini PC and am in the process of rethinking
> its storage.  So far, I've got myself two brand new and identical PCIe
> NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
> enable UEFI to get access to the BIOS from the GRUB menu.
> 
> I want my /home directory on a partition of its own, at a minimum, and
> encrypt it.  I don't see a need to encrypt much else as I am not after
> plausible deniability.  It's mostly to be able to return a broken disk
> for a replacement and still sleep in relative peace of mind ;-)
> 
> I haven't quite made up my mind as to a need for other partitions.  I
> use containers and VMs quite a bit.  Perhaps these are better stored
> some place other than the partitions for / or (an encrypted) /home.
> 
> With 64GB of RAM, I don't see much need for swap.  If needed, I could
> always add a swapfile instead of a partition.
> 
> Given the above,
> 
>  - what are your expert(?) opinions on partitioning for this?

Use LVM on top of RAID - great flexibility, plus reliability.

>  - how do I make (and keep) both disks bootable?

grub-install /dev/thing1
grub-install /dev/thing2

You can keep /boot as a separate RAID1 (separate from LVM, that is) if you 
want to, or you can include it in LVM these days.

That means you have the grub loader itself, the grub.conf, and the initramfs 
and kernel, all replicated on both disks.

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.

>  - can I put the ESP on RAID1?

Er, what's ESP?

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

>  - do I need a separate partition for /boot?

You do not need one, but you can have one.

>- if so, can it be put on RAID1?

Yes.

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

n/a

>  - should I use LVM?

Yes, IMHO.

>  - 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?


Antony.

-- 
Too many people spend money they haven't earned
to buy things they don't want,
to impress people they don't like.

 - Will Rogers

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] UEFI, software RAID1, LVM and encryption

[Olaf Meeuwissen via Dng]

Hi list,

I lost the single SSD on my mini PC and am in the process of rethinking
its storage.  So far, I've got myself two brand new and identical PCIe
NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
enable UEFI to get access to the BIOS from the GRUB menu.

I want my /home directory on a partition of its own, at a minimum, and
encrypt it.  I don't see a need to encrypt much else as I am not after
plausible deniability.  It's mostly to be able to return a broken disk
for a replacement and still sleep in relative peace of mind ;-)

I haven't quite made up my mind as to a need for other partitions.  I
use containers and VMs quite a bit.  Perhaps these are better stored
some place other than the partitions for / or (an encrypted) /home.

With 64GB of RAM, I don't see much need for swap.  If needed, I could
always add a swapfile instead of a partition.

Given the above,

 - what are your expert(?) opinions on partitioning for this?
 - how do I make (and keep) both disks bootable?
 - can I put the ESP on RAID1?
   - if not, how do I keep the copies in sync?
 - do I need a separate partition for /boot?
   - if so, can it be put on RAID1?
 - if not, how do I keep the copies in sync?
 - should I use LVM?
 - does randomizing the partition for /home make sense if on LVM and may
   get resized sometime in the future?

Thanks in advance,

--
Olaf Meeuwissen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng