How to add another disk to luks encryption

Support
1

Hi!
I would like to begin by saying thanks reading this.
Even if you cannot help me i appreciate you using your time browsing the forums intending to help out.

I finally got tierd of windows for good and decided to go back to linux. Read good things about Manjaro so decided this would be my home. Used to use Linux years back but i was never really very good at it.

Anyways gonna stop wasting your time.
Few days ago i installed Manjaro KDE latest stable and decided to go with LUKS encryption. I used the guided setup so at the moment i got a NVME with one partition + swap file encrypted.

I ordered a new ssd disk which arrived today to add to my setup.
How would i go about to add this disk to the current LUKS setup so that its encrypted with the same password and gets mounted at boot?

Thank you for your time.

2

Solved this by reading the dm_crypt docu on archlinux website.
While doing this i learned that the password for both the diskencryption and system encryption is stored on a keyfile in /.

Sure, no one can read this file when the system is not unencrypted but feels a bit unsafe that its just staying there, hanging after the system is decrypted. Guessing the reason this file has to exists is so that /boot/ can be encrypted.

But honestly i think i’d rather have an unencrypted /boot/ partition and not having to store keyfiles with 0 hash on the harddrive.

3

Hi and welcome to the forum :+1:

First of all, you need to understand that luks encryption does not support chaining different drives/partitions like RAID or LVM.
So you can’t “Add another disk” to that encryption like your title suggests…
You can however add another disk/partition to the entire system which can be encrypted also. :wink:

So going by the intention that you want to add another disk to your system while using encryption on that also:
For comparision this is my current setup:

  • My ESP is on a different disk as my OS.
  • I use full disk LUKS2 on my OS’s HD.
  • I keep my LUKS2 password(s) inside the initrd, which is stored under /boot
  • I mount my ESP at /efi and do a bind-mount of a subdir of the ESP as /boot
    I plan on moving this ESP to an USB Stick :wink:

You could make use of /etc/crypttab.initramfs which will become /etc/crypttab on the initramfs only.
In there you could use the same password or an entirely different one for the extra SSD disk.
Just make sure to include the file(s) with the password(s) inside the initrd when you reference it inside that /etc/crypttab.initramfs.
(If you don’t you will be prompted for the password at boot)

I have the file(s) with the password(s) used in the crypttab, mentioned above, placed under /etc/cryptfs-keys.d/
And use this inside the /etc/mkinitcpio.conf to copy them into the initrd

FILES=(
    /etc/cryptfs-keys.d/root
#    /etc/cryptfs-keys.d/swap
)

(Yes i disabled swap on disk for my setup and use a zram because of my extra RAM)

I also make use of these in same file to apply personal preferences to my bootup:

HOOKS=(
    base
    systemd
    autodetect
    modconf
    block
    keyboard
    keymap
#    sd-vconsole
    sd-encrypt
    sd-lvm2
#    lvm2
    filesystems
    bootsplash-manjaro
#    bootsplash-vendor
#    bootsplash-xfce
    fsck
#    consolefont
)

At first thought you would maybe say: "But the passwords are still on the hard-disk, and on top of that you also place them inside the initrd, and you are right but you don’t need to be afraid of them.

  • Your Operating System is stored inside a LUKS2 container in encrypted form, so it is relatively safe from outsiders.
  • The only place they are still in plain-text form is the initrd, but as i mentioned i plan to move the whole ESP where it is stored onto an USB-Stick which i will be able to unplug and carry around with me :wink:
4

Hi, in addition to @TriMoon 's setup, i.e. utilizing a removable USB disc holding the keys, another trick you can consider is:

  1. place respective key to unlock your new Ssd on the /boot partition (given it’s a separate partition, as you write).
  2. Don’t let the system automount /boot.
    During kernel runtime /boot is generally not needed anymore (even not for suspend to ram; obviously it is needed for system updates, but you can always mount it).

The proper way to setup dm-crypt with more than one physical disc would be to employ a tool that can manage multiple discs, disc changes for the encryption, e.g. LVM or a filesystem like btrfs. But that is a much more involved process to setup, let alone migrate to with an existing single-disc setup.

5

/etc/crypttab is exactly for that purpose…

6

Yes and no. I was unclear. I meant a dm-crypt block device spanning more than one physical disc, i.e. the new SSD to integrate into the setup, extending an existing block device not creating a new one (=new mount/encryption key line in crypttab is what @Paffpaffu has done).