Partition table instead of LVM inside a LUKS container

Partition table instead of LVM inside a LUKS container

[Mistave]

Hello,

Just a request for some opinions and suggestions.

In most online tutorials about encrypted linux setups it's recommended 
to use LVM (and by that I mean tools like pvcreate, vgcreate and 
lvcreate) on-top of a LUKS container to further partition the encrypted 
block device. However, my question is that, provided you are using a 
full device encryption (e.g. "cryptsetup luksFormat /dev/sdb" and then 
"cryptsetup open /dev/sdb container"), are there any negative effects of 
simply skipping LVM and creating a partition table with partitions 
directly on the new dm-crypt device?

I tried creating a test setup on an empty drive, and the system (Ubuntu 
22.04 LTS) was able to recognize the partitions after creating a new GPT 
partition table with two ext4 primary partitions on 
/dev/mapper/container device. The partitions appeared as 
/dev/mapper/container1 and /dev/mapper/container2, and were also visible 
in /dev/disk/by-id/ folder. No /dev/loop devices or LVM ("lvs" command 
returned nothing) appear to have been used while setting up the environment.

The setup was like (as root):
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb container
gparted /dev/mapper/container => New GPT table + 2x 10G ext4 partitions
mount /dev/mapper/container1 /mnt/disk => Mounted OK.


- Are there any benefits or drawbacks by using this approach over using 
LVM inside the LUKS container?

- Is this recommended or generally well supported?

- Can such setup be used to host the linux rootfs and other mount points 
in an encrypted Linux setup (including /boot)? Grub?

- Can I expect problems unmounting and closing the dm-crypt device i.e. 
by system shutdown scripts? For example, if I (after unmounting 
/mnt/disk) tried to close the device by doing "cryptsetup close 
container" in my test setup, it complained that the device is still in 
use. I had to first close the "container2" device, then "continer1" and 
finally the "container" device in /dev/mapper to remove the dm-crypt 
mapping.


Thanks in advance.

Re: Partition table instead of LVM inside a LUKS container

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

On Sun, 2024-02-25 at 16:14 +0100, Mistave wrote:
> Hello,

Hi.

> Just a request for some opinions and suggestions.

Since you asked about opinions… :-)

Note that I am not really going to answer your question directly but
rather wonder about motivations.

> In most online tutorials about encrypted linux setups it's
> recommended 
> to use LVM (and by that I mean tools like pvcreate, vgcreate and 
> lvcreate) on-top of a LUKS container to further partition the
> encrypted 
> block device.

I personally put LVM on every machine I build.  I only use partitions
as the vehicle to getting a bootable LVM-ized system.  That is
typically two partitions at most, one for the boot filesystem and one
for the LVM PV which is the rest of the disk.  I'd even dispense with
partitions entirely and use LVM on the whole disk (i.e. /dev/sda) if
GRUB could boot from LVM, which I have done in the past but it seems
frowned upon.

> However, my question is that, provided you are using a 
> full device encryption (e.g. "cryptsetup luksFormat /dev/sdb" and
> then 
> "cryptsetup open /dev/sdb container"), are there any negative effects
> of 
> simply skipping LVM and creating a partition table with partitions 
> directly on the new dm-crypt device?

The "negative effects" in my mind is the huge backwards step in time
and manageability of a system using partitions.  They are an antiquated
hack of yesteryear.  LVM makes the management of block devices so much
more wonderful.  Resizing, creating and destroying unlimited numbers of
block devices which you can build/destroy any time you want while the
system is running (assuming you do not do the other silly thing which
is creating one single large block device and putting absolutely
everything in it), etc.


So while I cannot comment on any experience with using partitions
inside of a LUKS container, I just couldn't imagine not using LVM.

What is your hesitance to using LVM?

Cheers,
b.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Partition table instead of LVM inside a LUKS container

[Mistave]

On 2/25/24 16:36, Brian J. Murrell wrote:
> So while I cannot comment on any experience with using partitions
> inside of a LUKS container, I just couldn't imagine not using LVM.
> 
> What is your hesitance to using LVM?
> 

I'm only asking for opinions in my quest to learn new things about the 
secluded parts of Linux. My "hesitance" was initially that I wanted to 
remove another layer of complexity and use something simpler than LVM... 
that is assuming the partition layout is performed at system setup and 
will remain static for the lifetime of the device.

Also, I'm not sure, if GPT partitions are as antiqued as you're making 
them sound like.

Best regards.

Re: Partition table instead of LVM inside a LUKS container

[Arno Wagner]

On Sun, Feb 25, 2024 at 18:04:58 CET, Mistave wrote:
> On 2/25/24 16:36, Brian J. Murrell wrote:
> > So while I cannot comment on any experience with using partitions
> > inside of a LUKS container, I just couldn't imagine not using LVM.
> > 
> > What is your hesitance to using LVM?
> > 
> 
> I'm only asking for opinions in my quest to learn new things about the
> secluded parts of Linux. My "hesitance" was initially that I wanted to
> remove another layer of complexity and use something simpler than LVM...
> that is assuming the partition layout is performed at system setup and will
> remain static for the lifetime of the device.
> 
> Also, I'm not sure, if GPT partitions are as antiqued as you're making them
> sound like.
> 
> Best regards.

Here is my take: I never use LVM, since I consider it
much more of a problem than a solution. Except for some
automation that tries to do everything the same way, I
do not see any use for LVM at all. 

What I do is partition the basic devive (and no, GPT is 
in no way outdated), and then put LUKS containers
into one or more partitions and filesystems directly
on top of that. Quite enought flexibility for a manual
set-up and if something goes wrong, you actually have a 
resonable chance of fixing things.

Alsaus remember KISS is the very basis of all reliable, 
secure and save design. Do not use a mechanism unless
you really need it. Avoid complexity at all cost. 

Regards,
Arno

 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier