Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: How to decrypt and mount second (non-boot) backup nvme at boot?  (Read 2563 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How to decrypt and mount second (non-boot) backup nvme at boot?

Hi All,

My system has 2 LUKS encrypted 4TB nvme drives:

lsblk -f

                                         nvme1n1
                                        │├─nvme1n1p1    259:2    0    1G  0 part  /boot/efi
                                        │└─nvme1n1p2    259:3    0  3.6T  0 part
                                        │  └─btw        253:0    0  3.6T  0 crypt
                                        │    ├─btw-swap 253:1    0  68G  0 lvm  [SWAP]
                                        │    └─btw-root 253:2    0  3.6T  0 lvm  /.snapshots
                                        │                                        /var
                                        │                                        /home
                                        │                                        /
                                        │nvme0n1        259:1    0  3.6T  0 disk


My goal is to autodecrypt LUKS encrypted nvme0n1 (which contains 1 btrfs and 1 ext4 partition as LVM inside the Luks container) using lukskey file after entering Luks password for nvme1n1 (which works fine). In addition the nvme0n1 Luks container should be closed automatically when shutting down the system as well, as I assume is the case with nvme1n1.


Since the 2 partitions in nvme0n1 are logical volumes they are not recognised because vgchange -ay is not automatically executed during boot. ChatGPT tells me I need to create a Runit service to achieve this. Is this correct? Or is there already a runit package that does this?

Manual login to nvme0n1 and mounting the 2 partitions after boot works fine. I would just like to automate this process but cannot find reliable information on this.


I had to restore my system multiple times already when trying to achieve this. Hoping someone here has more insight into this. Thank you!


Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #1 –
1. you should use "sudo lsblock -f"

2. when the keyfile is on the encrypted boot device and you are using runit (like me), I would unlock and mount the other drive in /etc/rc.local

Locking on reboot/shutdown ist done anyway.

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #2 –
To automatically open luks on boot, /etc/crypttab is usually used (the key file is also specified there). And /etc/fstab specifies what is mounted where.

If you did nothing during manual login except cryptsetup open... and mount /dev/mapper..., then this should work.

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #3 –
This is in my /etc/fstab

Code: [Select]
/dev/mapper/work /mnt/work ext4 defaults,nofail 0 0
/dev/mapper/Data /mnt/Data ext4 defaults,nofail 0 0

and /etc/crypt

Code: [Select]
work UUID=14611d7c-4004-4bf3-a759-cc0c9613126f /etc/keys/wkeys luks,discard,key-slot=1
Data UUID=e519c4bd-5686-433a-ab69-c68d68be14b3 /etc/keys/dkeys luks,discard,key-slot=1

When I created the vols, I used a password then added keyfiles. Slot 0 being the password, Slot 1 being the keyfile
Supercalifragilisticexpialidocious

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #4 –
@cds yes this works on my other laptop where the nvme has a single partition in the Luks container. I see you have separate Luks containers for each partition.

However  my second nvme has a 2 partitions inside of the same Luks container. Specifically I've created the partitions inside the Luks container using the following commands (example) to create LVM volume group (VG) on LUKS, in this case I've also used btc as VG's name.


# vgcreate btc /dev/mapper/btc
# lvcreate -L 500G -n ext btc
# lvcreate -l +100%FREE -n btrfs btc



Because of that the partitions do not become visible after opening the Luks container.
sudo lsblk -f

nvme0n1         crypto_LUKS             be3ed216-4d9f-42b0-a914-350fda8d59c2                                                        │libparted 3.6
└─nvme0n1_crypt LVM2_member             KvOwaC-uKgi-Cnjf-fVMU-xDSb-Ph9d-d9kFBu



To show the partitions the following command needs to be run after opening the Luks container:

sudo vgchange -ay


Which finally shows the correct partitions inside the LVM2_member:
sudo lsblk -f

nvme0n1         crypto_LUKS             be3ed216-4d9f-42b0-a914-350fda8d59c2                                                        │
└─nvme0n1_crypt LVM2_member             KvOwaC-uKgi-Cnjf-fVMU-xDSb-Ph9d-d9kFBu                                                      │
  ├─btc-ext     ext4                    469a23cf-6cfb-4128-9cd7-d88c06644a5a                                                        │
  └─btc-btrfs   btrfs                   e06668bc-c5b1-49a2-af8b-f8a2e713a805




The regular crypttab entry does not seem to work as I've tried that already. It looks like the command vgchange -ay is not automatically executed during boot, hence I've had to use the rescue live usb multiple times already after changing fstab and crypttab.

Also my mkinitcpio.conf hooks seem to be correct:

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt lvm2 filesystems fsck)


Would be grateful for any additional ideas.

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #5 –
It's crazy - I posted the question to AI - Is it possible to auto open a nested luks partition

Quoting -
Yes, it's possible to automatically unlock nested LUKS partitions on Linux systems, though the process involves several steps to configure key files and system startup settings
.
Here's a general approach:

    Outer LUKS partition:
        Unlock it at boot, often using a key file stored in an unencrypted /boot partition. This typically involves updating crypttab and the initramfs to use this key file during the boot process.
        The key file acts as a passphrase substitute, enabling the system to unlock the outer LUKS container automatically, according to Dradis Pro.
    Inner (Nested) LUKS partitions:
        The outer LUKS container's decrypted volume can then contain further LUKS partitions, for example, within Logical Volume Management (LVM) volumes residing within the outer container.
        These nested LUKS partitions can be set up to use key files for automatic unlocking as well.
        The key files for the inner partitions could be stored within the now-accessible (decrypted) outer LUKS volume.
        Configuration in /etc/crypttab for each nested LUKS partition can specify the key file to be used, enabling automatic unlocking after the outer LUKS container is opened.

Important considerations

    Security: Automating LUKS unlocks using key files, especially when stored on the same system, carries security implications. If an attacker gains access to the key file, they could unlock the associated LUKS partition.
    Initramfs update: After making changes to key files or /etc/crypttab entries for partitions involved in the boot process (including the root filesystem if encrypted), it's crucial to regenerate the initramfs to incorporate the changes for the bootloader.
    Systemd units: For more granular control and reliable mounting, using systemd units for both decryption and mounting of nested LUKS volumes is recommended, says withblue.ink.

In essence, the strategy involves a chain of trust: the system first unlocks the outer LUKS container with a key file (perhaps stored on the unencrypted boot partition), and then the system uses key files within the unlocked outer container to automatically unlock any nested LUKS partitions. \

Granted, it really does not say the best way (or a way) to do that, but honestly, I never thought about a nested luks partition.
You probably saw the same.
Supercalifragilisticexpialidocious

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #6 –
Exactly that, GPT-5 is being very general and not giving concrete steps. Tells me to modify initframe in a weird way or alternatively to create a systemd/runit service to mount the partitions after boot...

At least we are safe from the terminator for now...

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #7 –
Quote from: simon – on
The regular crypttab entry does not seem to work as I've tried that already. It looks like the command vgchange -ay is not automatically executed during boot, hence I've had to use the rescue live usb multiple times already after changing fstab and crypttab.
As said: Use /etc/rc.local

There you can do unlock, vgchange and mount one after the other and has all in one place.

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #8 –
Appologies @Caramon2 , I've never heard of  /etc/rc.local before hence my brain didn't process... I will try this out next, thank you very much for that suggestion.

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #9 –
Thanks again @Caramon2 that works flawlesly! For those struggling here is the sample content of my current /etc/rc.local :

Quote
/usr/bin/cryptsetup luksOpen /dev/disk/by-uuid/14611d7c-4004-4bf3-a759-cc0c9612326f luksdata --key-file /etc/lukskeys/mykey

/usr/bin/vgchange -ay

/usr/bin/mount /dev/mapper/luksdata-ext /home/user1/Public/mount1/

/usr/bin/mount /dev/mapper/luksdata-btrfs /home/user1/Public/mount2/

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #10 –
Quote from: simon – on
/etc/rc.local
Btw: I'm using it for zRAM (no swap):

https://forum.artixlinux.org/index.php/topic,8274.msg49481.html#msg49481

"exit 0" was recommended someday:

https://unix.stackexchange.com/questions/247378/do-i-need-exit-0-at-the-end-of-rc-local

At least it doesn't hurt. ;)

Re: How to decrypt and mount second (non-boot) backup nvme at boot?

Reply #11 –
Added "exit 0"  and now learning about zRAM as well. I've also found /etc/rc.shutdown file and planning to add close and unmount commands to it for that second nvme at shutdown. Probably not needed based on your previous post, but I'm open to any ideas for what it could be used for.