[gentoo-user] Benefits from full disk encryption on server?

[gentoo-user] Benefits from full disk encryption on server?

[whiteman808]

Hello,

I'm going to run on my server a few services for me and friends like
static HTML pages, gitea, jabber server, and mailing lists.

Are there any advantages from putting Linux on encrypted root at bare metal server if I often access remotely server from ssh, and sometimes need to reboot it? What about key supplied during unlocking server after reboot or manually power on? Giving remotely password doesn't seems safe to me.

I want to protect against burglary and I'm not sure whether doing full disk encryption is a right way to go. Maybe should I just instead of trying to focus on the software side try to take more care of physical security?

Thank you all gen2 folks,
whiteman

Re: [gentoo-user] Benefits from full disk encryption on server?

[Richard Freeman]

On 5/16/2025 12:59 PM, whiteman808 wrote:
> Hello,
>
> Are there any advantages from putting Linux on encrypted root at bare metal server if I often access remotely server from ssh, and sometimes need to reboot it? What about key supplied during unlocking server after reboot or manually power on? Giving remotely password doesn't seems safe to me.
>
> I want to protect against burglary and I'm not sure whether doing full disk encryption is a right way to go. Maybe should I just instead of trying to focus on the software side try to take more care of physical security?
>
Burglary is a difficult use case to protect against, because as you 
point out you need to provide the key somehow at boot.  There are 
TPM-based approaches that are not well-supported on Linux distros which 
try to ensure that the key is only readable if the disk is booted 
normally, but you're still vulnerable to any physical access OS 
vulnerability.

I run servers with full disk encryption on SOME of my storage, but not 
the OS drives. I store the key in a file on the OS drive. This obviously 
provides no security against burglary, but the benefit is that when a 
disk with sensitive data fails it is encrypted with a strong key (no 
memorable passphrase). You need both the OS disk and the encrypted disk 
to read anything sensitive, so I can just toss the failed disk in the 
trash. This also allows unattended boot.

Another approach you could consider is putting the key on another host 
available over the network. Your initramfs/etc could use a credential 
stored on it to access the remote host and retrieve the disk key. The 
remote host could be a Pi hidden someplace non-obvious. Then if the host 
is stolen and not kept powered on continuously (ie not a sophisticated 
attacker) the disk won't be readable, but it would boot just fine as 
long as it is attached to your LAN.

There might be some other variations on a theme like that using some 
sort of credential vault software. Approaches like that could also be 
used to remotely disable the device if you can't access it - the 
credential vault could be told to not provide the key any longer.

In any case there are definitely use-cases for full disk encryption that 
still add value even if it isn't as secure as having to remember a LUKS 
key on boot.

-- 

Rich

Re: [gentoo-user] Benefits from full disk encryption on server?

[Dale]

Richard Freeman wrote:
> On 5/16/2025 12:59 PM, whiteman808 wrote:
>> Hello,
>>
>> Are there any advantages from putting Linux on encrypted root at bare
>> metal server if I often access remotely server from ssh, and
>> sometimes need to reboot it? What about key supplied during unlocking
>> server after reboot or manually power on? Giving remotely password
>> doesn't seems safe to me.
>>
>> I want to protect against burglary and I'm not sure whether doing
>> full disk encryption is a right way to go. Maybe should I just
>> instead of trying to focus on the software side try to take more care
>> of physical security?
>>
> Burglary is a difficult use case to protect against, because as you
> point out you need to provide the key somehow at boot.  There are
> TPM-based approaches that are not well-supported on Linux distros
> which try to ensure that the key is only readable if the disk is
> booted normally, but you're still vulnerable to any physical access OS
> vulnerability.
>
> I run servers with full disk encryption on SOME of my storage, but not
> the OS drives. I store the key in a file on the OS drive. This
> obviously provides no security against burglary, but the benefit is
> that when a disk with sensitive data fails it is encrypted with a
> strong key (no memorable passphrase). You need both the OS disk and
> the encrypted disk to read anything sensitive, so I can just toss the
> failed disk in the trash. This also allows unattended boot.
>
> Another approach you could consider is putting the key on another host
> available over the network. Your initramfs/etc could use a credential
> stored on it to access the remote host and retrieve the disk key. The
> remote host could be a Pi hidden someplace non-obvious. Then if the
> host is stolen and not kept powered on continuously (ie not a
> sophisticated attacker) the disk won't be readable, but it would boot
> just fine as long as it is attached to your LAN.
>
> There might be some other variations on a theme like that using some
> sort of credential vault software. Approaches like that could also be
> used to remotely disable the device if you can't access it - the
> credential vault could be told to not provide the key any longer.
>
> In any case there are definitely use-cases for full disk encryption
> that still add value even if it isn't as secure as having to remember
> a LUKS key on boot.
>


That is what I do.  My OS is on plain file systems and can boot without
me doing anything.  Won't help if someone breaks into my house and
steals the puter tho.  My data is encrypted until I type in the
password.  I even have /home on a plain file system, so I can login to
the GUI. 

OP:  I've read, never did this tho, that some laptops require a password
to even start booting.  Some Linux users even have other things, like a
init thingy, that requires a password to boot, likely to access root
file system.  Basically, everything is password protected.  If someone
steals the laptop, well, unless they can reset everything and reinstall
a new OS, it's pretty worthless.  The data is secure tho.  You may want
to look at how people set up their laptops to prevent theft and see if
that would work in your case.  Really, that's kinda what you want to
accomplish even tho it is a desktop and not so easy to carry off. 

I've also read that some super secret gov't laptops have a lot of
security built in.  That may be something else you can look into if you
really want to lock down a puter and your BIOS supports that sort of
security level. 

Just a couple thoughts that may help. 

Dale

:-)  :-) 

Re: [gentoo-user] Benefits from full disk encryption on server?

[Grant Taylor]

On 5/16/25 11:59 AM, whiteman808 wrote:
> Hello,

Hi,

> Are there any advantages from putting Linux on encrypted root at bare 
> metal server ...

I think so.

But I've not yet done it myself.  I've only used LUKS for a data file 
system.

> ... if I often access remotely server from ssh, and sometimes need 
> to reboot it?

I don't think the method or frequency of access alters the advantages of 
FDE.

> What about key supplied during unlocking server after reboot or 
> manually power on? Giving remotely password doesn't seems safe to me.

I think this is where an OoB console access to provide the key, or 
initial RAM disk based SSH server can come into play.

I've actually had FDE provide /faster/ access to data than unencrypted 
for weird reasons related to caching.

There's also, destroy the key and the drive is cryptographically 
sanitized and available for re-use without concern.

I added a key to the FDE on my work notebook a couple of jobs ago and 
had that key stored in a 4 MB partition (smallest I could make) on a 
flash drive.  (Raw partition, not file.)  So when I booted my computer 
in the dock, the key could be found and automatically unlock the FDE. 
If I booted not connected to the dock, I had to enter my FDE password.

> I want to protect against burglary and I'm not sure whether doing full 
> disk encryption is a right way to go. Maybe should I just instead 
> of trying to focus on the software side try to take more care of 
> physical security?

Are you worried about disk theft or system theft?

The former is easier to protect against than the latter.

Take a look at a solution that Red Hat supports.  I'm sure Gentoo can be 
made to support it:

Clevis (client) and the Tang server

It's meant to be a way for servers to unlock FDE.  I don't remember the 
particulars at the moment.



-- 
Grant. . . .

Re: [gentoo-user] Benefits from full disk encryption on server?

[Wol]

On 17/05/2025 03:06, Grant Taylor wrote:
> Are you worried about disk theft or system theft?
> 
> The former is easier to protect against than the latter.

I believe modern hardware will automatically encrypt the disk and store 
the key in the TPM. At BIOS level. So that disk is only readable on that 
computer.

(There are ways to back up the key, but to a first approximation, take 
the disk out of the computer and it's cryptographically wiped.)

Cheers,
Wol

Re: [gentoo-user] Benefits from full disk encryption on server?

[Grant Taylor]

On 5/17/25 3:04 AM, Wol wrote:
> I believe modern hardware will automatically encrypt the disk and store 
> the key in the TPM. At BIOS level. So that disk is only readable on that 
> computer.

Some systems have that capability.  But all of the systems that I've 
looked at don't enable it automatically.

Sadly, it doesn't offer any protection if the entire system is taken, 
Hence the question of what to protect.

This also offers no protection against physical based / connected attacks.

> (There are ways to back up the key, but to a first approximation, take 
> the disk out of the computer and it's cryptographically wiped.)

I get what you're saying, but if you put it back in the same system the 
data is available again.  Thus the data wasn't wiped.  Conversely 
destroy the key and now you can't get the data back without massive 
brute force.



-- 
Grant. . . .

Re: [gentoo-user] Benefits from full disk encryption on server?

[byte.size226]

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


> Are there any advantages from putting Linux on encrypted root at bare metal server

There are always advantages of having FDE, including when a theft 
occurs. While ofc FDE will not protect against theft, at least the data 
on the drive(s) will be secure.

If you're "hosting" other people's data, I think this there's even more 
good reason to use encryption, whether that data is sensitive or not.

Personally, I use FDE for everything. It's only one step further than an 
encrypted data partition, so I don't see why not. Here's an sample 
single-disk (no RAID) layout:

/dev/sda
├─ /dev/sda1 : EFI System Partition
├─ /dev/sda2 : /boot partition, not encrypted
└─ /dev/sda3 : LUKS crypt container
    └─ hello_lvm - LVM Physical Volume and "hello_lvm" Volume Group
       ├─ hello_lvm/root : LVM volume, OS / partition
       └─ hello_lvm/home : LVM volume, /home partition

LVM-over-LUKS gives you the flexibility to still "partition" your drive 
as you wish while having everything encrypted and you can have a single 
key open everything. Though, of course, you might want to put the OS 
root on its own separate partition and encrypt that with a separate LUKS 
container with its own protection, meaning you will need to unlock both 
at boot.

I hear GRUB these days supports LUKS so maybe an encrypted /boot is 
possible too, but I've never tried it myself. I might be wrong.

> if I often access remotely server from ssh, and sometimes need to reboot it?

These advantages would not be negated from the need to access or reboot 
the machine.

> I want to protect against burglary and I'm not sure whether doing full disk encryption is a right way to go. Maybe should I just instead of trying to focus on the software side try to take more care of physical security?

It's a tough one, but I think these are complementary measures. Unless 
you can guarantee 100% impenetrable physical security, then there's 
always the potential of burglary, regardless how small, and you might 
want to ensure the data is not accessible.

>  What about key supplied during unlocking server after reboot or manually power on? Giving remotely password doesn't seems safe to me.

There are ways around this. Like Grant had suggested earlier, an OOB 
console is one way, and so is a lightweight ramdisk SSH server.

The latter ramdisk approach can be very user friendly as it's a simple 
"ssh + provide unlock password" experience. It's relatively easy to set 
up, and can be set up in a secure manner.

You can set up the ramdisk SSH server to only allow a specific set of 
authorised SSH keys for login, through the usual "authorized_keys" and 
prevent password access. This is good practice for regular SSH too.

I have only done this on Debian and Fedora, but I don't see why it can't 
be done on Gentoo. For Debian I've used "dropbear-initramfs" and on 
Fedora I've used "dracut-sshd" [1] which is just a Dracut module and 
should work on most Dracut-generated ramdisks. The GitHub page shows 
that a contributor has tested it on Gentoo and it works. 
gentoo-kernel-bin uses Dracut, so that could be something to try.

You can also strengthen your remote access measures by not exposing any 
ports that do not need to be, and this includes SSH. If your router 
supports it, configuring OpenVPN or Wireguard is a very neat approach to 
securely access your home network. If not, a cheap SBC such as a 
Raspberry Pi (even an older model should suffice) could be used to run 
OpenVPN or Wireguard and provide access. Wireguard is very easy to set 
up compared to OpenVPN, I would highly recommend it for something like this.

So to recap, not-exposing SSH ports, using self-hosted VPN to access 
your home network, and only using authorised SSH keys for access should 
be pretty good.

Hope this helps. I'm sure there's other ways too.

[1] https://github.com/gsauthof/dracut-sshd

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 928 bytes --]

Re: [gentoo-user] Benefits from full disk encryption on server?

[Dale]

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

byte.size226@simplelogin.com wrote:
> There are always advantages of having FDE, including when a theft
> occurs. While ofc FDE will not protect against theft, at least the
> data on the drive(s) will be secure.
>
> If you're "hosting" other people's data, I think this there's even
> more good reason to use encryption, whether that data is sensitive or
> not.
>
> Personally, I use FDE for everything. It's only one step further than
> an encrypted data partition, so I don't see why not. Here's an sample
> single-disk (no RAID) layout:
>
> /dev/sda
> ├─ /dev/sda1 : EFI System Partition
> ├─ /dev/sda2 : /boot partition, not encrypted
> └─ /dev/sda3 : LUKS crypt container
>    └─ hello_lvm - LVM Physical Volume and "hello_lvm" Volume Group
>       ├─ hello_lvm/root : LVM volume, OS / partition
>       └─ hello_lvm/home : LVM volume, /home partition
>
> LVM-over-LUKS gives you the flexibility to still "partition" your
> drive as you wish while having everything encrypted and you can have a
> single key open everything. Though, of course, you might want to put
> the OS root on its own separate partition and encrypt that with a
> separate LUKS container with its own protection, meaning you will need
> to unlock both at boot.
>
> I hear GRUB these days supports LUKS so maybe an encrypted /boot is
> possible too, but I've never tried it myself. I might be wrong.
> <<< SNIP >>>
>
> Hope this helps. I'm sure there's other ways too.
>
> [1] https://github.com/gsauthof/dracut-sshd


Do you have a link, or several links, on how to set that up?  I'd like
to read it and may even play with it on one of my old rigs, then maybe
on my main rig at some point. 

OP sure is getting a lot of options.  :-D 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 2979 bytes --]

Re: [Possible phishing attempt] Re: [gentoo-user] Benefits from full disk encryption on server?

[byte.size226]

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

Dale wrote:
> Do you have a link, or several links, on how to set that up?  I'd like 
> to read it and may even play with it on one of my old rigs, then maybe 
> on my main rig at some point.

I don't think I have any step-by-step resources at hand but I can 
outline a general "recipe" if that helps.

For LVM, if unfamiliar, I can highly recommend the Gentoo [1] and Arch 
Wiki [2] pages. The former has useful information on boot parameters, 
which I'll get to near the end, and kernel configuration.

But other than getting the initramfs to unlock the LUKS-encrypted volume 
there isn't anything unusual to the set up - it's simply combining the 
two building blocks together.

Let's start with the sample layout I gave earlier:

> /dev/sda
> ├─ /dev/sda1 : EFI System Partition
> ├─ /dev/sda2 : /boot partition, not encrypted
> └─ /dev/sda3 : LUKS crypt container
>    └─ hello_lvm - LVM Physical Volume and "hello_lvm" Volume Group
>       ├─ hello_lvm/root : LVM volume, OS / partition
>       └─ hello_lvm/home : LVM volume, /home partition 

The above assumes a GPT formatted drive, but GPT is not a prerequisite. 
If using MBR, there's no need for the /dev/sda1 ESP. Everything below, 
of course, also assumes that it is not done on a "live" system and 
something like the gentoo live install ISO or another live distro is used.

1) /dev/sda2 - format as usual with filesystem of choice, e.g. ext4 
(must be supported by GRUB).

2) Now for /dev/sda3. Format as LUKS as usual:

     # cryptsetup luksFormat /dev/sda3

and supply the unlock password. Any LUKS configuration specifics that 
one might have can also be specified here - e.g. hashing algorithm, key 
size, etc, see cryptsetup-luksFormat(8)

You can now open the LUKS container and call it, e.g. "crypt_gentoo":

     # cryptsetup open /dev/sda3 crypt_gentoo

which will show up as "/dev/mapper/crypt_gentoo". This is the now 
unlocked device where LVM will be set up.

3) "Format" the unlocked device as an LVM Physical Volume:

     # pvcreate /dev/mapper/crypt_gentoo

You can confirm LVM can detect it as such by inspecting the output of

     # pvdisplay

Which should show information about "/dev/mapper/crypt_gentoo", its 
overall size, etc.

4) Next, create the "hello_lvm" LVM Volume Group (or a name of your 
choice) by passing in the LVM Physical Device where it will be placed:

     # vgcreate hello_lvm /dev/mapper/crypt_gentoo

and can verify if LVM can detect it with

     # vgdisplay

5) Create the "root" logical volume, say 30GB, into the target VG:

     # lvcreate --size 30G --name root hello_lvm

The device for this volume will appear under "/dev/hello_lvm/root" and 
"/dev/mapper/hello_lvm-root"

6) Create the "home" volume, and let it occupy all the remaining 
available space:

     # lvcreate --extents 100%FREE --name home hello_lvm

The device for this volume will appear under "/dev/hello_lvm/home" and 
"/dev/mapper/hello_lvm-home"

You can check that both the volumes are correctly configured with:

     # lvdisplay hello_lvm

7) Format the volumes as usual with a filesystem of choice, e.g. ext4

     # mkfs.ext4 /dev/hello_lvm/root
     # mkfs.ext4 /dev/hello_lvm/home

These can now be mounted as usual to a target location, e.g.:

     # mount /dev/hello_lvm/root /mnt/gentoo

8) Skipping forward and assuming that Gentoo is now present on the root 
volume, configuring fstab is nothing special. the UUID entries for "/" 
and "/home" are those of the LVM volumes:

     # blkid /dev/hello_lvm/root
     # blkid /dev/hello_lvm/home

e.g.

     UUID=<lvm fs uuid> / ext4 defaults 1 1

9) Ensure the relevant LUKS and LVM tools are available on the Gentoo 
installation, if not already, i.e. "sys-fs/cryptsetup" and 
"sys-fs/lvm2". Add lvm2 to the boot runlevel (chroot will be needed):

     # rc-update add lvm2 boot

10) Setting up the boot parameters. This is really the "critical" part 
as you need to tell the initramfs that a LUKS volume needs to be 
unlocked. Support for LUKS and LVM must be added to the initramfs.

10.1) If using genkernel, Enable LUKS and LVM in "/etc/genkernel.conf":

     LVM="yes"
     LUKS="yes"

Alternatively, one must remember to add "--lvm" and "--luks" when 
generating an initramfs.

For GRUB you also need to add the relevant parameters. In 
"/etc/default/grub" add the following to "GRUB_CMDLINE_LINUX":

     crypt_root=UUID=<UUID of /dev/sda3> dolvm

Note that the UUID is that of /dev/sda3, i.e. the LUKS formatted 
partition, *not* the unlocked one:

     # blkid /dev/sda3

Regenerate the initramfs and GRUB config as usual (chroot will be needed).

10.2) If using Dracut things are a bit simpler. LUKS and LVM support is 
added in by default. So you only need to add the relevant boot 
parameters to "/etc/default/grub"

     rd.luks.uuid=luks-<UUID of /dev/sda3> rd.lvm.vg=hello_lvm 
rd.lvm.lv=hello_lvm/root

Regenerate the initramfs and GRUB config as usual (chroot will be needed).

And that's it! Encrypted /boot is not covered, as I've not dabbled into 
it so far. Whether that is merited and poses a risk is subjective. If 
compiling your own kernel, I'd suggest looking at the relevant kernel 
configuration sections in [1,3]. Otherwise, "gentoo-kernel-bin" with 
Dracut should work out of the box.

If the system doesn't boot, it will be most likely due to boot 
parameters or the initramfs not having support for LUKS and LVM. Any 
error messages should hint to the cause.

As always, please, please backup any data beforehand, sanity check 
commands at every step, and I would always recommend using a disposable 
VM to try on first. None of it is complicated, but can be error-prone 
and risks data loss.

Hope this helps and that I've not missed anything. I usually refrain 
from sharing "guides" on disk setup with working CLI examples to avoid 
people blindly following without sanity checking and messing up their 
data. But this a Gentoo community, an exception can be made :)


Refs:
[1] https://wiki.gentoo.org/wiki/LVM
[2] https://wiki.archlinux.org/title/LVM
[3] https://wiki.gentoo.org/wiki/Dm-crypt

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 928 bytes --]

Re: [Possible phishing attempt] Re: [gentoo-user] Benefits from full disk encryption on server?

[Dale]

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

byte.size226@simplelogin.com wrote:
> Dale wrote:
>> Do you have a link, or several links, on how to set that up?  I'd
>> like to read it and may even play with it on one of my old rigs, then
>> maybe on my main rig at some point.
>
> I don't think I have any step-by-step resources at hand but I can
> outline a general "recipe" if that helps.
>
> For LVM, if unfamiliar, I can highly recommend the Gentoo [1] and Arch
> Wiki [2] pages. The former has useful information on boot parameters,
> which I'll get to near the end, and kernel configuration.
>
> But other than getting the initramfs to unlock the LUKS-encrypted
> volume there isn't anything unusual to the set up - it's simply
> combining the two building blocks together.
>
> Let's start with the sample layout I gave earlier:
>
>> /dev/sda
>> ├─ /dev/sda1 : EFI System Partition
>> ├─ /dev/sda2 : /boot partition, not encrypted
>> └─ /dev/sda3 : LUKS crypt container
>>    └─ hello_lvm - LVM Physical Volume and "hello_lvm" Volume Group
>>       ├─ hello_lvm/root : LVM volume, OS / partition
>>       └─ hello_lvm/home : LVM volume, /home partition 
>
> The above assumes a GPT formatted drive, but GPT is not a
> prerequisite. If using MBR, there's no need for the /dev/sda1 ESP.
> Everything below, of course, also assumes that it is not done on a
> "live" system and something like the gentoo live install ISO or
> another live distro is used.
>
> 1) /dev/sda2 - format as usual with filesystem of choice, e.g. ext4
> (must be supported by GRUB).
>
> 2) Now for /dev/sda3. Format as LUKS as usual:
>
>     # cryptsetup luksFormat /dev/sda3
>
> and supply the unlock password. Any LUKS configuration specifics that
> one might have can also be specified here - e.g. hashing algorithm,
> key size, etc, see cryptsetup-luksFormat(8)
>
> You can now open the LUKS container and call it, e.g. "crypt_gentoo":
>
>     # cryptsetup open /dev/sda3 crypt_gentoo
>
> which will show up as "/dev/mapper/crypt_gentoo". This is the now
> unlocked device where LVM will be set up.
>
> 3) "Format" the unlocked device as an LVM Physical Volume:
>
>     # pvcreate /dev/mapper/crypt_gentoo
>
> You can confirm LVM can detect it as such by inspecting the output of
>
>     # pvdisplay
>
> Which should show information about "/dev/mapper/crypt_gentoo", its
> overall size, etc.
>
> 4) Next, create the "hello_lvm" LVM Volume Group (or a name of your
> choice) by passing in the LVM Physical Device where it will be placed:
>
>     # vgcreate hello_lvm /dev/mapper/crypt_gentoo
>
> and can verify if LVM can detect it with
>
>     # vgdisplay
>
> 5) Create the "root" logical volume, say 30GB, into the target VG:
>
>     # lvcreate --size 30G --name root hello_lvm
>
> The device for this volume will appear under "/dev/hello_lvm/root" and
> "/dev/mapper/hello_lvm-root"
>
> 6) Create the "home" volume, and let it occupy all the remaining
> available space:
>
>     # lvcreate --extents 100%FREE --name home hello_lvm
>
> The device for this volume will appear under "/dev/hello_lvm/home" and
> "/dev/mapper/hello_lvm-home"
>
> You can check that both the volumes are correctly configured with:
>
>     # lvdisplay hello_lvm
>
> 7) Format the volumes as usual with a filesystem of choice, e.g. ext4
>
>     # mkfs.ext4 /dev/hello_lvm/root
>     # mkfs.ext4 /dev/hello_lvm/home
>
> These can now be mounted as usual to a target location, e.g.:
>
>     # mount /dev/hello_lvm/root /mnt/gentoo
>
> 8) Skipping forward and assuming that Gentoo is now present on the
> root volume, configuring fstab is nothing special. the UUID entries
> for "/" and "/home" are those of the LVM volumes:
>
>     # blkid /dev/hello_lvm/root
>     # blkid /dev/hello_lvm/home
>
> e.g.
>
>     UUID=<lvm fs uuid> / ext4 defaults 1 1
>
> 9) Ensure the relevant LUKS and LVM tools are available on the Gentoo
> installation, if not already, i.e. "sys-fs/cryptsetup" and
> "sys-fs/lvm2". Add lvm2 to the boot runlevel (chroot will be needed):
>
>     # rc-update add lvm2 boot
>
> 10) Setting up the boot parameters. This is really the "critical" part
> as you need to tell the initramfs that a LUKS volume needs to be
> unlocked. Support for LUKS and LVM must be added to the initramfs.
>
> 10.1) If using genkernel, Enable LUKS and LVM in "/etc/genkernel.conf":
>
>     LVM="yes"
>     LUKS="yes"
>
> Alternatively, one must remember to add "--lvm" and "--luks" when
> generating an initramfs.
>
> For GRUB you also need to add the relevant parameters. In
> "/etc/default/grub" add the following to "GRUB_CMDLINE_LINUX":
>
>     crypt_root=UUID=<UUID of /dev/sda3> dolvm
>
> Note that the UUID is that of /dev/sda3, i.e. the LUKS formatted
> partition, *not* the unlocked one:
>
>     # blkid /dev/sda3
>
> Regenerate the initramfs and GRUB config as usual (chroot will be
> needed).
>
> 10.2) If using Dracut things are a bit simpler. LUKS and LVM support
> is added in by default. So you only need to add the relevant boot
> parameters to "/etc/default/grub"
>
>     rd.luks.uuid=luks-<UUID of /dev/sda3> rd.lvm.vg=hello_lvm
> rd.lvm.lv=hello_lvm/root
>
> Regenerate the initramfs and GRUB config as usual (chroot will be
> needed).
>
> And that's it! Encrypted /boot is not covered, as I've not dabbled
> into it so far. Whether that is merited and poses a risk is
> subjective. If compiling your own kernel, I'd suggest looking at the
> relevant kernel configuration sections in [1,3]. Otherwise,
> "gentoo-kernel-bin" with Dracut should work out of the box.
>
> If the system doesn't boot, it will be most likely due to boot
> parameters or the initramfs not having support for LUKS and LVM. Any
> error messages should hint to the cause.
>
> As always, please, please backup any data beforehand, sanity check
> commands at every step, and I would always recommend using a
> disposable VM to try on first. None of it is complicated, but can be
> error-prone and risks data loss.
>
> Hope this helps and that I've not missed anything. I usually refrain
> from sharing "guides" on disk setup with working CLI examples to avoid
> people blindly following without sanity checking and messing up their
> data. But this a Gentoo community, an exception can be made :)
>
>
> Refs:
> [1] https://wiki.gentoo.org/wiki/LVM
> [2] https://wiki.archlinux.org/title/LVM
> [3] https://wiki.gentoo.org/wiki/Dm-crypt


I'm somewhat familiar with LVM.  I got over a dozen drives using it. 
I'm not saying I know all of LVM tho.  Just the parts I use a lot,
mostly referring back to notes. 

If I did this, I'd likely do it on a spare drive at first.  I may even
buy another m.2 or use a m.2 I already have laying around here.  That
way I can easily go back if needed. 

I moved a copy of this to my folder where I put other howtos and
guides.  Makes it easier to find later. 

Thanks much for the info and links.  May help some other poor soul
wanting to do this too.  Search engines are amazing at finding good
info, sometimes.  ;-)  

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 10808 bytes --]

Re: [gentoo-user] Benefits from full disk encryption on server?

[Rahul Sandhu]

Hi,

You may want to look into TPM2-based disk encryption; during normal
operation it's basically transparent. My servers all have an encrypted
root partition, and I do not need to enter a password to boot it as the
decryption keys are stored in the TPM. Take a look at this page[1] for
information on how to do it with Clevis, however I would recommend the
usage of systemd-cryptenroll(1) instead for systemd systems[2].

[1] https://wiki.gentoo.org/wiki/Trusted_Platform_Module/LUKS
[2] https://wiki.gentoo.org/wiki/User:Ajak/Measured_Boot

Thanks,
Rahul

Re: [gentoo-user] Benefits from full disk encryption on server?

[Richard Freeman]

On 5/17/2025 8:43 AM, Rahul Sandhu wrote:
> Hi,
>
> You may want to look into TPM2-based disk encryption; during normal
> operation it's basically transparent. My servers all have an encrypted
> root partition, and I do not need to enter a password to boot it as the
> decryption keys are stored in the TPM. Take a look at this page[1] for
> information on how to do it with Clevis, however I would recommend the
> usage of systemd-cryptenroll(1) instead for systemd systems[2].
>
I didn't realize that this had progressed so far. With LUKS you could 
presumably also set a passphrase in case the PCRs get messed up.

This is basically how most corporate laptops are configured.

-- 
Rich