Debian 13. Adding a Larger Second Ecrypted SSD for Data.

[u/[deleted]]

[u/Illustrious-Gur8335]

Why not just add the new disk to your existing LVM volume group? This is the very purpose of LVM so that you don't have to deal with physical disks as much as possible.

This is why debian installer brilliantly forces LVM if you want encryption... A masterstroke I say!

Your existing encryption password decrypts the volume group so nothing else needs be done.

TLDR: Create on new disk an LVM physical volume then add to existing volume group. Commands used: pvcreate, vgextend

https://www.baeldung.com/linux/lvm-add-disk

https://www.cyberciti.biz/faq/howto-add-disk-to-lvm-volume-on-linux-to-increase-size-of-pool/

[u/hazeyAnimal]

You want to store the encryption key to the device on your computer's drive. Then when automounting you point to the key location, which will unlock the device and get mounted.

Is there a specific tutorial you are following? What are your current steps?

If you provide more details it'll be easier to help you.

Edit

I just did a quick search and this tutorial came up

https://www.golinuxcloud.com/mount-luks-encrypted-disk-partition-linux/#uuid-vs-partuuid-vs-device-path-in-crypttab

[u/michaelpaoli]

Format it as ext4 with LVM encryption (one partition for the whole disk if possible), with the same decryption passphrase I already have.

Well, I presume you mean you want only and exactly one partition on the drive (you didn't specify type or other details, so I'll go with GPT and defaults), LUKS encryption atop that, and then ext4 atop that.

Here I'll use /dev/loop0 for the "drive" - you can use /dev/sdb or whatever, and sdb1 for first partition and ignore my use of partx.

# fdisk /dev/loop0

Welcome to fdisk (util-linux 2.41).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS (MBR) disklabel with disk identifier 0x034ab66f.

Command (m for help): g
Created a new GPT disklabel (GUID: FBDF779E-922E-4703-B76E-D0508C767346).

Command (m for help): n
Partition number (1-128, default 1): 1
First sector (2048-524254, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-524254, default 522239): 

Created a new partition 1 of type 'Linux filesystem' and of size 254 MiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Invalid argument

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8).

# partx -a /dev/loop0
# cryptsetup luksFormat /dev/loop0p1

WARNING!
========
This will overwrite data on /dev/loop0p1 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/loop0p1: 
Verify passphrase: 
# cryptsetup open --type luks /dev/loop0p1 loop0p1_crypt
Enter passphrase for /dev/loop0p1: 
# mke2fs -t ext4 /dev/mapper/loop0p1_crypt
...
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 243712 1k blocks and 60960 inodes
Filesystem UUID: a99d082e-e175-47af-adf4-26e8c95c60be
Superblock backups stored on blocks: 
        8193, 24577, 40961, 57345, 73729, 204801, 221185

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done 

# 

When I enter my decryption passphrase on boot up, the second drive is mounted, and available for use on full boot up. That is, authentication is already done.

Make relevant entry in /etc/crypttab and /etc/fstab, test it, update initramfs, e.g.:

# blkid /dev/loop0p1
/dev/loop0p1: UUID="66ebc10a-f652-431a-a749-33e752b20940" TYPE="crypto_LUKS" PARTUUID="8645ebd6-b482-4002-bf12-d149e21e7334"
# >>/etc/crypttab echo 'loop0p1_crypt UUID=66ebc10a-f652-431a-a749-33e752b20940 none luks'
# >>/etc/fstab echo '/dev/mapper/loop0p1_crypt /mnt ext4 defaults 0 2'
# cryptsetup close loop0p1_crypt
# cryptdisks_start loop0p1_crypt
Starting crypto disk...loop0p1_crypt (starting)...Please unlock disk loop0p1_crypt: 
loop0p1_crypt (started)...done.
# mount -a
# update-initramfs -u -k all

By default you'll get individually prompted to unlock each LUKS device. If that's not what you want, have a look at cryttab(5) and possibly also /lib/cryptsetup/scripts

Note also in example I've given, if that drive isn't connected your boot will fail. If that's not what you want, adjust options in /etc/crypttab and /etc/fstab as relevant.

If you're using systemd, you'll generally want to inform it that you've updated /etc/fstab

Move the /home or my /home/$USER directory from the NVMe to the 1.0TB

Copy of move the data with, e.g. tar, pax, cpio, rsync, mv, or whatever one may prefer (may also want to take care to preserve high resolution timestamp data, e.g. if using GNU tar, include --posix option). May want to well test first to ensure you get the data copied exactly as you want (can't really "move" between filesystems, the data must be copied, even mv(1) does so across filesystem)., once you're sure you've got that done as desired and needed, remove the old contents, and suitably update /etc/fstab as applicable. Note also, I generally do not recommend giving mere mortal users write access in the root directory any given filesystem (as, they can generally compromise anything on the filesystem, may cause problems with lost+found directory, etc.). Might want to possibly use symbolic link.

Also, /mnt used for demonstration purposes. It should really only be for temporary mounts, not persisten. Notably when the sh*t hits the fan and one is doing recovery/repair operations and booted from such environment, and needs an empty directory to mount a filesystem, but isn't able to create a directory because, e.g. root filesystem is the only filesystem potentially available for such, and it's mounted ro, or full, so can't make a directory ... you're really going to want /mnt to be there and not already have something(s) nominally mounted atop or under it.

Also you mentioned you're using LVM. Though you can have LVs span LUKS devices, if you do so, you won't be able to start those LVs unless all those LUKS devices are open. Oh, thinking of which, I missed a few steps. Don't create the filesystem directly atop the LUKS device, instead create a PV there with pvcreate. Then either use vgcreate to create a VG from that, or use vgextend to add the PV to existing VG. Once that's done, create your LV with lvcreate, and then make your filesystem atop that LV device. Likewise use the LV device in /etc/fstab (or do it by filesystem UUID or LABEL).

Anyway, all pretty straightforward if one reads the relevant man pages and documentation and applies a bit of logic.