Hi!
I installed openSUSE on a new disk and made a backup of /home but I forgot about my LUKS encrypted BTRFS RAID1 disks.
How can I add them back to my new installed system? I can unlock them with the passphrase and btrfs can see them but how can I have them to automount and decrypt at start-up like they used to?
Thanks.
Add them to /etc/crypttab and /etc/fstab.
More information would be very helpful.
I did as per your suggestion. It leads to booting into emergency mode.
if I comment out the fstab entry, system loads. But of course, my btrfs volumes are inaccesible.
Could you provide the outputs of:
# run as root
lsblk -f
cat /etc/crypttab
cat /etc/fstab
Don’t request command output as root when no elevated rights are needed.
Linux security basics: Don’t use root when not necessary!
crypttab is not user-readable.
But generally a good concept to keep in mind, though I wouldn’t worry about it when working with filesystems, most of them are not user programs.
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda crypto 1 0ae86c72-564c-41d1-9333-eedfe64c84ea
└─sda
btrfs 3a5fa0a8-1e39-4c4c-ab16-064f211e5c03
sdb crypto 1 031c7ad8-0776-4601-b774-bc396c6298e1
└─luks-031c7ad8-0776-4601-b774-bc396c6298e1
btrfs 3a5fa0a8-1e39-4c4c-ab16-064f211e5c03
sdc
├─sdc1
│ vfat FAT32 D914-F0A6
└─sdc2
crypto 1 e3b3d9a3-c744-40fe-a550-6b201dc6544c
sr0
nvme0n1
├─nvme0n1p1
│ vfat FAT32 B719-5173 505M 1% /boot/efi
└─nvme0n1p2
crypto 1 4834839d-7933-4294-acff-3fa6f5e22909
└─cr_nvme-eui.00000000000000016479a7716f0000f7-part2
LVM2_m LVM2 kXpguq-2gfd-fc7f-QiEw-ES0t-PBEv-f3MNlY
├─system-swap
│ swap 1 e4ee98e6-2e04-4f04-87ff-3c4368513e43 [SWAP]
├─system-root
│ btrfs 4114a69e-5b10-4537-ab86-60773064a389 152G 4% /var
│ /usr/local
│ /srv
│ /root
│ /opt
│ /boot/grub2/x86_64-efi
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
└─system-home
xfs e1403994-22f8-4099-a912-49f4e92a048f 283.6G 2% /home
cr_nvme-eui.00000000000000016479a7716f0000f7-part2 UUID=4834839d-7933-4294-acff-3fa6f5e22909 none x-initrd.attach
sda /dev/disk/by-uuid/0ae86c72-564c-41d1-9333-eedfe64c84ea none luks
/dev/system/root / btrfs defaults 0 0
/dev/system/root /var btrfs subvol=/@/var 0 0
/dev/system/root /usr/local btrfs subvol=/@/usr/local 0 0
/dev/system/root /srv btrfs subvol=/@/srv 0 0
/dev/system/root /root btrfs subvol=/@/root 0 0
/dev/system/root /opt btrfs subvol=/@/opt 0 0
/dev/system/home /home xfs defaults 0 0
/dev/system/root /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
/dev/system/root /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
/dev/system/swap swap swap defaults 0 0
/dev/system/root /.snapshots btrfs subvol=/@/.snapshots 0 0
UUID=B719-5173 /boot/efi vfat utf8 0 2
#UUID=3a5fa0a8-1e39-4c4c-ab16-064f211e5c03 /mnt/raid btrfs defaults 0 0
In /etc/crypttab, both the Btrfs RAID disks (sda and sdb) must be unlocked:
cr_nvme-eui.00000000000000016479a7716f0000f7-part2 UUID=4834839d-7933-4294-acff-3fa6f5e22909 none x-initrd.attach
sda UUID=0ae86c72-564c-41d1-9333-eedfe64c84ea none x-initrd.attach
sdb UUID=031c7ad8-0776-4601-b774-bc396c6298e1 none x-initrd.attach
I’ve found adding x-initrd.attach useful even for encrypted USB drives as otherwise systemd attempts to close them prior to unmounting the fs during shutdown. Add nofail option in crypttab and fstab entries if these are external drives or you do not want the boot to fail due to them.
To test:
# reload to let systemd pick up on updated crypttab entries
sudo systemctl daemon-reload
# use systemd to open the encrypted volumes
sudo systemctl start systemd-cryptsetup@sda.service
sudo systemctl start systemd-cryptsetup@sdb.service
# mount btrfs raid volume after uncommenting the line in fstab
sudo mount -av
Thanks @pavinjoseph it worked, except for this error when running cryptsetup:
Job for systemd-cryptsetup@sdb.service failed because the control process exited with error code.
See "systemctl status systemd-cryptsetup@sdb.service" and "journalctl -xeu systemd-cryptsetup@sdb.service" for details.
systemd-cryptsetup@sdb.service - Cryptography Setup for sdb
Loaded: loaded (/etc/crypttab; generated)
Active: failed (Result: exit-code) since Tue 2024-03-26 10:24:34 CST; 5min>
Docs: man:crypttab(5)
man:systemd-cryptsetup-generator(8)
man:systemd-cryptsetup@.service(8)
Process: 23511 ExecStart=/usr/bin/systemd-cryptsetup attach sdb /dev/disk/b>
Main PID: 23511 (code=exited, status=1/FAILURE)
CPU: 2.387s
It’s better to name the encrypted device as something other than sda or sdb as those names are given to the disks by the system and could change after the next reboot, leading to some confusion. It would be already quite confusing as the disk /dev/sda and /dev/mapper/sda both existing!
Try this in /etc/crypttab:
raid_disk1 UUID=0ae86c72-564c-41d1-9333-eedfe64c84ea none x-initrd.attach
raid_disk2 UUID=031c7ad8-0776-4601-b774-bc396c6298e1 none x-initrd.attach
sudo systemctl daemon-reload
sudo systemctl start systemd-cryptsetup@raid_disk1.service
sudo systemctl start systemd-cryptsetup@raid_disk2.service
Did systemd ask you for the encrypted volume’s password when starting it? Perhaps it only supports key files.
If there are errors, please show the output of:
sudo journalctl --no-pager -eu systemd-cryptsetup@raid_disk1.service
The disks are back and working, just had to restart. Thanks for the suggestion of changing the names to something more consistent.
The disks work with a passphrase, but I had a key setup to avoid the double password issue. Problem is the key is in my old root partition on my secondary disk. I think I have to generate the key again with the passphrase. I really didn’t think through this “migration”.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.