I have a 2 TB Western Digital MyBook I encrypted with LUKS over a year ago. A few months ago, I decided to be reckless and accidentally formatted the disk in Windows when trying to create a boot-able USB disk with different software. The drive was totally reformatted. But then, I put a GPT partition header (GUID partition table) on it with no data. I use Linux Mint 22.1 as my default OS. Long story short - the drive and partition are gone with a new GPT partition installed. This means the 'disks' app still shows the drive as /dev/sdc (which it is) but that it is "Unallocated Space". To say that the data on this drive is important is an understatement. I’ve looked through the following articles to try and address this issue, but to no avail: - https://unix.stackexchange.com/questions/706070/restore-a-luks-partition-that-was-overwritten-by-pvcreate/706071#706071 - https://unix.stackexchange.com/questions/741404/overwritten-luks-with-a-partition-table/741850#741850 When performing hexdump -C /dev/sdc | grep LUKS, for over an hour, I see the following:

4774f600  eb 02 92 95 54 d3 f2 e3  ca d1 4c 55 4b 53 e0 16  |....T.....LUKS..|
98ea5380  d7 01 bf 4c 55 4b 53 8c  f2 24 43 72 9f 4a 63 94  |...LUKS..$Cr.Jc.|
c7b54730  7c f3 4c 4c 55 4b 53 71  4c 47 40 69 96 53 57 12  ||.LLUKSqLG@i.SW.|
2963da820  04 75 9e 51 4c 55 4b 53  fe 1c 76 f6 30 ad c5 c1  |.u.QLUKS..v.0...|
495e522c0  aa e1 e4 ac 21 6c 29 4c  55 4b 53 b0 e9 98 63 b5  |....!l)LUKS...c.|
508fbcd90  ec 2e 2b 4e 59 1f 4c 55  4b 53 b7 27 18 1b 60 62  |..+NY.LUKS.'..`b|
59dde6680  d2 4c 55 4b 53 57 5f d3  f8 40 ce 4f d6 3e b0 83  |.LUKSW_..@.O.>..|
7d4a7f640  70 9d 24 a6 05 d5 bd 4c  55 4b 53 67 c6 74 56 62  |p.$....LUKSg.tVb|
7f38a7520  ee 9d e8 1e 13 19 b2 28  55 e9 d8 4c 55 4b 53 1b  |.......(U..LUKS.|
81bac7400  fc 10 90 53 a2 9e 78 d9  37 8c db b4 4c 55 4b 53  |...S..x.7...LUKS|
8ff10e9f0  4c 55 4b 53 9d a5 a7 67  a6 3d 5a e4 62 8b 20 39  |LUKS...g.=Z.b. 9|
a51b31010  f0 4c 55 4b 53 d9 d7 e7  df 6e 03 53 9c 54 8a ef  |.LUKS....n.S.T..|
ca9ecb700  1e 53 df f2 4c 55 4b 53  b7 bf 24 86 89 00 49 06  |.S..LUKS..$...I.|
ceb247eb0  47 4c 55 4b 53 c6 1c 95  d8 41 86 19 d0 e9 74 c9  |GLUKS....A....t.|
e6521bb10  45 ff ec cd 68 a5 58 bf  b1 4c 55 4b 53 5b 14 51  |E...h.X..LUKS[.Q|
ead66c2e0  d0 6b 8d a0 c3 cf 4c 55  4b 53 1b 14 86 01 a2 c2  |.k....LUKS......|

I created an image of the disk (image.dd). When following frostschutz' procedure for "cryptsetup repair, Part Two — Full Header Recovery" (https://unix.stackexchange.com/questions/741404/overwritten-luks-with-a-partition-table/741850#741850) Step 1: Result of metadata recovery: stdbuf -oL strings -n 64 -t d image.dd | grep '"keyslots":' 20480 {"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offset":"32768","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2id","time":12,"memory":1048576,"cpus":4,"salt":"5JN08SD5Z1cryqRFiQvn+JensssvRMuayF2jHXKjGDY="}}},"tokens":{},"segments":{"0":{"type":"crypt","offset":"16777216","size":"dynamic","iv_tweak":"0","encryption":"aes-xts-plain64","sector_size":512}},"digests":{"0":{"type":"pbkdf2","keyslots":["0"],"segments":["0"],"hash":"sha256","iterations":313944,"salt":"cHPpJJpF2ivqLjkyTTJmKmqVcVSaRqN0L0V+yx0La+E=","digest":"COHktekQxX/2Jfq4ro8hqDweVOmom5bGAPa23nzkEV0="}},"config":{"json_size":"12288","keyslots_size":"16744448"}} Valid JSON string found at offset 20480.... After following the entire procedure to its end (working on the image.dd) it keeps saying "Device luks.recovery is not a valid LUKS device." Is this pointless? If I can see LUKS keyslots, the offsets, etc, then am I just doing this wrong? Thanks!

I'm trying to decrypt the Debian root with a key file stored in the boot partition (decrypted partition). This will break the security, but it doesn't matter now. I have to conclude this successfully or die trying. I have created the hooks to the initramfs and the key file is on the /boot directory inside the initrd.img-* file. The path to the key file (/boot/keyfile) is on the /etc/crypttab file. I updated the initramfs with sudo update-initramfs -u but I received this message: cryptsetup: WARNING: target sdaX_crypt uses a key file, skipped. Ignoring the message and rebooting results in a unbootable disk. The message Gave up waiting for root device. is displayed and drops to initramfs shell. In the initramfs environment the cryptsetup don't exists. *(It should exists?)* Seens that the update-initramfs -u "thinks" the sdaX_crypt device will be mounted in another way and don't configure to decrypt with the keyfile. *How can I do that?*

HardenedArray has a helpful archlinux-installation guide at [Efficient Encrypted UEFI-Booting Arch Installation](https://gist.github.com/HardenedArray/31915e3d73a4ae45adc0efa9ba458b07) . However, I encountered difficulty early in the installation process -- specifically, at the point of opening my LUKS partition. The command cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 completes without error, but after I enter the command cryptsetup luksOpen /dev/sda3 tsundoku, _/dev/mapper/tsundoku_ does not become available. ls /dev/mapper lists _/dev/mapper/control_ alone, and not also _/dev/mapper/tsundoku_ as I would expect. The following error message appears upon cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug: "Trying to read ... LUKS2 header at offset .... LUKS header read failed (-22). Command failed with code -1 (wrong or missing parameters)." Could anyone offer any hints at to the cause of this error? My attempts at online research to this point haven't been fruitful. Thanks much --- EDIT --- I've asked this question for help to achieve any of three goals: (1) to install arch-linux (in any manner) on a 6ish-year-old x86-64 Intel Core i5 2.50GHz ASUS; (2) more specifically, to install arch-linux securely with an encrypted partition; (3) to learn why, despite my expectations, cryptsetup luksOpen /dev/sda3 tsundoku does not create a _tsundoku_ mapping entry in the path _/dev/mapper_. I'm a newcomer to arch-linux, so although I'd prefer installing the OS with encryption, I'd settle for installing it in any way. I haven't had much luck following the installation instructions in the official arch wiki in the past, so upon seeing HardenedArray's clearly delineated installation guide, I thought I'd give it a go -- worst case scenario being that I might encounter a problem like the one described above, whereby I might learn something new. As for the issue, here are some more details: As per HardenedArray's guide: I gdisk /dev/sda and create the following partitions: * /dev/sda1, default, 100M, EF00 * /dev/sda2, default, 250M, 8300 * /dev/sda3, default, default, 8300 Then I do the following: mkfs.vfat -F 32 /dev/sda1 mkfs.ext2 /dev/sda2 At this point, I attempt to initialize a LUKS partition and set up a mapping. > cryptsetup --verbose -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 Command successful > cryptsetup -v isLuks /dev/sda3 Command successful > ls /dev/mapper control > cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug cryptsetup 2.0.0. processing "cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug" Running command open. Locking memory. ... Trying to load any crypt type from device /dev/sda3. Crypto backend ... initialized ... Detected kernel Linux 4.14.9-1-ARCH x86_64. ... Reading LUKS header of size 1024 from device /dev/sda3. ... Activating volume tsundoku using token -1. STDIN descriptor passphrase entry requested. Activating volume tsundoku [keyslot -1] using passphrase. ... Detected dm-ioctl version 4.37.0. Device-mapper backend running with UDEV support enabled. dm status tsundoku [ opencount flush ] [...] (...) Trying to open key slot 0 [ACTIVE_LAST]. Reading key slot 0 area. Using userspace crypto wrapper to access keyslot area. Trying to open key slot 1 [INACTIVE]. # key slots 2-7 are also [INACTIVE] Releasing crypt device /dev/sda3 context. Releasing device-mapper backend. Unlocking memory. Command failed with code -2 (no permission or bad passphrase). > ls /dev/mapper control > cryptsetup luksDump /dev/sda3 LUKS header information for /dev/sda3 Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha512 ... UUID: 56d8... Key Slot 0: ENABLED ... Key Slot 1: DISABLED # Key Slots 2-7 are also DISABLED ----- Are the steps I've listed above inaccurate in any way? Perhaps there were alternatives I should have taken instead or intervening actions that I missed? If not, is the command cryptsetup luksOpen /dev/sd{a} {volume} supposed to create a volume mapping in the path _/dev/mapper_? If so, do the details I've added above allow anyone to ascertain why the path _/dev/sda3/tsundoku_ does not appear on my machine? And if not, is there any additional information that I could add to make the problem clearer? Thanks much.

I had two volumes mounted: /dev/sda1 and /dev/mapper/b ~ $ sudo mount -v -t ext4 -o noatime /dev/sda1 /mnt/a mount: /dev/sda1 mounted on /mnt/a. ~ $ sudo cryptsetup -v open --type luks /dev/sda2 b No usable token is available. Enter passphrase for /dev/sda2: Key slot 0 unlocked. Command successful. ~ $ sudo mount -v -t ext4 -o noatime /dev/mapper/b /mnt/b mount: /dev/mapper/b mounted on /mnt/b. ~ $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 223.6G 0 disk ├─sda1 8:1 0 128G 0 part /mnt/a └─sda2 8:2 0 95.6G 0 part └─b 253:0 0 95.6G 0 crypt /mnt/b zram0 254:0 0 4G 0 disk [SWAP] nvme0n1 259:0 0 119.2G 0 disk ├─nvme0n1p1 259:1 0 512M 0 part /boot └─nvme0n1p2 259:2 0 118.7G 0 part / I accidentally mounted them again when they were already mounted, using the same three commands: ~ $ sudo mount -v -t ext4 -o noatime /dev/sda1 /mnt/a mount: /dev/sda1 mounted on /mnt/a. ~ $ sudo cryptsetup -v open --type luks /dev/sda2 b No usable token is available. Enter passphrase for /dev/sda2: Key slot 0 unlocked. Command successful. ~ $ sudo mount -v -t ext4 -o noatime /dev/mapper/b /mnt/b mount: /dev/mapper/b mounted on /mnt/b. Then I unmounted them: ~ $ sudo umount -v /mnt/b umount: /mnt/b unmounted ~ $ sudo cryptsetup -v close b Device b is still in use. Command failed with code -5 (device already exists or device is busy). sudo umount -v /mnt/a umount: /mnt/a unmounted But I discovered that they were still mounted: ~ $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 223.6G 0 disk ├─sda1 8:1 0 128G 0 part /mnt/a └─sda2 8:2 0 95.6G 0 part └─b 253:0 0 95.6G 0 crypt /mnt/b zram0 254:0 0 4G 0 disk [SWAP] nvme0n1 259:0 0 119.2G 0 disk ├─nvme0n1p1 259:1 0 512M 0 part /boot └─nvme0n1p2 259:2 0 118.7G 0 part / Then I unmounted them again: ~ $ sudo umount -v /mnt/b umount: /mnt/b unmounted ~ $ sudo cryptsetup -v close b Command successful. ~ $ sudo umount -v /mnt/a umount: /mnt/a unmounted This time they were unmounted: ~ $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 223.6G 0 disk ├─sda1 8:1 0 128G 0 part └─sda2 8:2 0 95.6G 0 part zram0 254:0 0 4G 0 disk [SWAP] nvme0n1 259:0 0 119.2G 0 disk ├─nvme0n1p1 259:1 0 512M 0 part /boot └─nvme0n1p2 259:2 0 118.7G 0 part / Were the volumes mounted twice to the same mount points? If not, what happened?

Hi my crypttab looks as follows: crypt_device /dev/sda luks,header=/boot/header.img update-initramfs -u -k all works with success, but for some reason cryptsetup will not find the header.img which resides on the usb stick (that also contains the boot partition) during boot. It is stored on /boot/header.img (using luks encryption with detached header, and seperate boot partition on usb, os: lubuntu 18)

I wanted to disable cryptswap on my PopOS (an Ubuntu derivative). - Used mkswap to re-initialize the swap partition - Edited /etc/fstab to directly reference it (as opposed to a crypto device) - Removed the now non-existent crypto partition from /etc/crypttab - Ran sudo cryptsetup remove cryptswap And yet, every time I boot, the system waits for a few seconds for the now non-existent encrypted swap partition to become available. Seems like there is some remaining configuration which I have not removed. What is it and how do I remove it completely?

ver since I set up my LUKS-encrypted BTRFS RAID1 between my two NVMe drives on Debian 12, the shutdown process has taken way too long, about a minute and a half. I had to get a video of the shutdown screen before it powers off, which led me to the culprit of the dm/crypt not being un-mounted. I realize that / being on the unlocked BTRFS file systems must complicate the umounting process during shutdown, but waiting this long cannot be the only way. I wouldn't care too much, as other posts about this issue suggest, except that waiting this long for a shutdown is annoying, and waiting this long for a reboot is frustrating. It's also a laptop, so waiting this amount of time before putting it away in my bag is a problem. I am guessing that this is supposed to happen, I wouldn't think people with LUKS and BTRFS are trulying waiting this long for reboot/shutdown?? 1. In my particular disk setup, is there any risk in these devices not being umounted properly? 2. Is there any way to remove the huge delay in shutdown? I attempted to change systemd's watchdog timer to 3 seconds, but it did not affect the shutdown time. 3. Why doesn't systemd handle this already? On a normal system, "/" would be on an EXT4 filesystem that would also need to be umounted at shutdown? lsblk

NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1         259:0    0 931.5G  0 disk
├─nvme0n1p1     259:2    0   949M  0 part  /boot/efi
└─nvme0n1p2     259:3    0 930.6G  0 part
  └─crypt_nvme0 254:0    0 930.6G  0 crypt /
nvme1n1         259:1    0 931.5G  0 disk
├─nvme1n1p1     259:4    0   949M  0 part
└─nvme1n1p2     259:5    0 930.6G  0 part
  └─crypt_nvme1 254:1    0 930.6G  0 crypt

cat /etc/fstab

# MAIN
# Primary efi partition - secondary below
UUID=A490-28B5                            /boot/efi             vfat    umask=0077,noexec,nodev,nosuid  0       1

# BTRFS RAID 1 (UUID applies to both disks)
UUID=15767954-1ec3-44aa-b1e3-b890ca937277 /             btrfs   defaults,subvol=@,ssd,noatime,space_cache=v2,commit=120,compress=zstd 0 0

cat /etc/crypttab

crypt_nvme0 UUID=63780057-f91e-426d-9be3-84383fd9b534 none luks
crypt_nvme1 UUID=c434a425-6552-4036-ae34-4f8c1c728d9a none luks

journald logs before next boot:

Nov 17 15:35:36 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:36 debian systemd-cryptsetup: Device crypt_nvme0 is still in use.
Nov 17 15:35:36 debian systemd-cryptsetup: Failed to deactivate: Device or resource busy
Nov 17 15:35:36 debian systemd: systemd-cryptsetup@crypt_nvme0.service: Failed with result 'exit-code'.
Nov 17 15:35:36 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:37 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:37 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:37 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:37 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:37 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:38 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:38 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:38 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:38 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:38 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:39 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:39 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:39 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:39 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:39 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:40 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:40 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:40 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:40 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:40 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:41 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:41 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:41 debian systemd-cryptsetup: device-mapper: remove ioctl on crypt_nvme1  failed: Device or resource busy
Nov 17 15:35:41 debian systemd-cryptsetup: Device crypt_nvme1 is still in use.
Nov 17 15:35:41 debian systemd-cryptsetup: Failed to deactivate: Device or resource busy
Nov 17 15:35:41 debian systemd: systemd-cryptsetup@crypt_nvme1.service: Failed with result 'exit-code'.
Nov 17 15:35:41 debian kernel: watchdog: watchdog0: watchdog did not stop!

Last messages before power off:

systemd-shutdown: Could not detach DM /dev/dm-1: Device or resource busy
systemd-shutdown: Could not detach DM /dev/dm-0: Device or resource busy
watchdog: watchdog0: watchdog did not stop!
sstemd-shutdown: Failed to finalize DM devices, ignoring.

ls -l /dev/mapper/

total 0
crw------- 1 root root 10, 236 Nov 17 15:36 control
lrwxrwxrwx 1 root root       7 Nov 17 15:36 crypt_nvme0 -> ../dm-0
lrwxrwxrwx 1 root root       7 Nov 17 15:36 crypt_nvme1 -> ../dm-1

After reboot systemd crypt services:

● blockdev@dev-mapper-crypt_nvme0.target - Block Device Preparation for /dev/mapper/crypt_nvme0
     Loaded: loaded (/lib/systemd/system/blockdev@.target; static)
     Active: active since Sun 2024-11-17 15:36:35 PST; 5min ago
       Docs: man:systemd.special(7)

● systemd-cryptsetup@crypt_nvme1.service - Cryptography Setup for crypt_nvme1
     Loaded: loaded (/etc/crypttab; generated)
     Active: active (exited) since Sun 2024-11-17 15:36:35 PST; 5min ago
       Docs: man:crypttab(5)
             man:systemd-cryptsetup-generator(8)
             man:systemd-cryptsetup@.service(8)
    Process: 896 ExecStart=/lib/systemd/systemd-cryptsetup attach crypt_nvme1 /dev/disk/by-uuid/c434a425-6552-4036-ae34-4f8c1c728d9a none luks (code=exited, status=0/SUCCESS)
   Main PID: 896 (code=exited, status=0/SUCCESS)
        CPU: 5ms

Nov 17 15:36:35 debian systemd-cryptsetup: Volume crypt_nvme1 already active.

● system-systemd\x2dcryptsetup.slice - Cryptsetup Units Slice
     Loaded: loaded (/lib/systemd/system/system-systemd\x2dcryptsetup.slice; static)
     Active: active since Sun 2024-11-17 15:36:34 PST; 5min ago
       Docs: man:systemd-cryptsetup@.service(8)
      Tasks: 0
     Memory: 828.0K
        CPU: 10ms
     CGroup: /system.slice/system-systemd\x2dcryptsetup.slice

Nov 17 15:36:35 debian systemd-cryptsetup: Volume crypt_nvme1 already active.
Nov 17 15:36:35 debian systemd-cryptsetup: Volume crypt_nvme0 already active.
Notice: journal has been rotated since unit was started, output may be incomplete.

● systemd-cryptsetup@crypt_nvme0.service - Cryptography Setup for crypt_nvme0
     Loaded: loaded (/etc/crypttab; generated)
     Active: active (exited) since Sun 2024-11-17 15:36:35 PST; 5min ago
       Docs: man:crypttab(5)
             man:systemd-cryptsetup-generator(8)
             man:systemd-cryptsetup@.service(8)
    Process: 895 ExecStart=/lib/systemd/systemd-cryptsetup attach crypt_nvme0 /dev/disk/by-uuid/63780057-f91e-426d-9be3-84383fd9b534 none luks (code=exited, status=0/SUCCESS)
   Main PID: 895 (code=exited, status=0/SUCCESS)
        CPU: 5ms

Nov 17 15:36:35 debian systemd-cryptsetup: Volume crypt_nvme0 already active.

● cryptsetup.target - Local Encrypted Volumes
     Loaded: loaded (/lib/systemd/system/cryptsetup.target; static)
     Active: active since Sun 2024-11-17 15:36:35 PST; 5min ago
       Docs: man:systemd.special(7)

● blockdev@dev-mapper-crypt_nvme1.target - Block Device Preparation for /dev/mapper/crypt_nvme1
     Loaded: loaded (/lib/systemd/system/blockdev@.target; static)
     Active: active since Sun 2024-11-17 15:36:35 PST; 5min ago
       Docs: man:systemd.special(7)

ls -l /dev/disk/by-uuid/

total 0
lrwxrwxrwx 1 root root 10 Nov 17 15:36 15767954-1ec3-44aa-b1e3-b890ca937277 -> ../../dm-0
lrwxrwxrwx 1 root root 15 Nov 17 15:36 63780057-f91e-426d-9be3-84383fd9b534 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Nov 17 15:36 A490-28B5 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 Nov 17 15:36 c434a425-6552-4036-ae34-4f8c1c728d9a -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 15 Nov 17 15:36 D2D5-D83C -> ../../nvme1n1p1

mount | grep nvme

/dev/mapper/crypt_nvme0 on / type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache=v2,commit=120,subvolid=256,subvol=/@)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,nosuid,nodev,noexec,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

How to run cryptsetup luksFormat non-interactively. When LUKS formatting a partition, I recieve the message # cryptsetup luksFormat /dev/sdb WARNING! ======== This will overwrite data on /dev/sdb irrevocably. Are you sure? (Type uppercase yes): YES Followed by Enter passphrase: **How can I automatically answer YES to the question Are you sure ?**

I just received a new USB flash drive, and set up 2 encrypted partitions on it. I used dm-crypt (LUKS mode) through cryptsetup. With an additional non-encrypted partition, the drive has the following structure: - /dev/sdb1, encrypted, hiding an ext4 filesystem labelled "Partition 1". - /dev/sdb2, encrypted, hiding another ext4 filesystem, labelled "Partition 2". - /dev/sdb3, clear, visible ext4 filesystem labelled "Partition 3". Because the labels are attached to the ext4 filesystems, the first two remain completely invisible as long as the partitions haven't been decrypted. This means that, in the meantime, the LUKS containers have no labels. This is particularly annoying when using GNOME (automount), in which case the partitions appear as "*x GB Encrypted*" and "*y GB Encrypted*" until I decide to unlock them. This isn't really a blocking problem, but it's quite annoying, since I really like my labels and would love to see them appear even when my partitions are still encrypted. Therefore, is there a way to attach labels to dm-crypt+LUKS containers, just like we attach labels to ext4 filesystems? Does the dm-crypt+LUKS header have some room for that, and if so, how can I set a label? *Note that I don't want to expose my ext4 labels before decryption, that would be silly. I'd like to add other labels to the containers, which could appear while the ext4 labels are hidden.*

How do I ensure that an external, BitLocker encrypted NTFS drive is automatically decrypted and mounted at boot time on a Linux system?

I have Debian 12 with full disk encryption. Cryptsetup unlocks the volume with linux kernel version 6.1.0-28, but fails with any later version as follows.

Please unlock disk sdXY_crypt: **********
No key available with this passphrase.
cryptsetup: ERROR: sdXY_crypt: cryptsetup failed, bad password or options?

In the timeframe exactly between kernels 6.1.0-28 and 6.1.0-29, I installed VeraCrypt for use with containers. I have never used it to encrypt any disk volume. AFAIK VeraCrypt doesn't alter kernel configuration, but I mention it as a potential reason for the problem. What is the problem? How to troubleshoot and fix it?

I am trying to recover my data from a 8 year old configuration. 8 years is the last time I tried to mount this configuration but the computer died. The configuration is thus: - LUKS encryption on top of - A volume group on top of - RAID10 (4 drives) + RAID1 (2 drives) Linux found the RAIDs and rebuilt them. It also found the volume group and assembled it naming it "blob" which was what it was. The only problem is, when I went to luksOpen it said that the header was missing on /dev/mapper/vg-blob. Sure enough, hexdump revealed the first bytes on the drive were actually just zeroes. So I went looking for the LUKS header it and found it.

# strings -t d -n 4 /dev/mapper/vg-blob | grep LUKS
2097152 LUKS

2097152 bytes in which by my math (2097152 / 1024 / 1024) is exactly 2MB. What are the odds? So I used losetup -o 2097152 /dev/loop0 /dev/mapper/vg-blob and luksDumped /dev/loop. LUKS said there was a valid header! But how? Tried the passwords I expected it to be, but nope. I'm at a weird crossroads. - Is it the volume group that is not correct causing a weird 2MB offset (They are 8 years old. Were formats different then?). Thus THIS is the point of attack that needs to be corrected? - Did I just forget my password and I had it everything is okay despite a 2MB offset in LUKS header? Do I just need to bring up past events to try and remember? Notably, I can see my .bash_history from the dead machine. I always opened it with cryptsetup luksOpen /dev/mapper/vg-blob crypt-blob. Either way my data feels like it's hanging in the balance. Edits: **luksDump**

# cryptsetup luksDump /dev/loop0 
LUKS header information for /dev/loop0

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      1e 75 ff 04 c6 0a a8 9b c5 cd 7e d3 a2 ea 1c 8f cd 8f 17 0a 
MK salt:        c5 eb 06 2a e6 50 ce 30 36 83 3e 4b 89 2c fe 94 
                9e ad d6 1f ad 77 f4 f5 d2 96 89 a2 1e 52 a7 fa 
MK iterations:  43125
UUID:           bfb21fd9-67cc-4c41-bdd1-af38af7d4355

Key Slot 0: ENABLED
        Iterations:             172042
        Salt:                   a7 61 b1 00 12 59 42 80 5d 62 89 9d 52 db e0 47 
                                a3 39 11 1f bf 06 02 34 46 3e 47 2d 26 db 21 f7 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

I'm using Almalinux in case that's relevant here. We use LUKS2 on the local disk, with LVM on top - so /dev/sda1 and 2 are unencrypted, but /dev/sda3 is encrypted and used for the OS. We also use clevis/tang to do automatic decrypt (and this is working fine). When we build via kickstart, we set a temporary password when encrypting and building - and then when we have finished the initial build, we use ansible to set good quality passwords in line with our vaulting/security practices. So that involves a script that does the equivalent of: cryptsetup luksOpen -S 0 --test-passphrase /dev/sda3 && cryptsetup luksChangeKey -S0 --force-password --batch-mode (And of course the 'default' build password is tested for, and replaced with one from our key management system). This has started failing recently, and I'm a little perplexed as to what might be going wrong. It definitely works on our initial 'build', which uses a slightly out of date build image, but then we dnf update to the current revision, and now we cannot seem to luksChangeKey or luksAddkey any more. # Adding new keyslot 2 by passphrase, volume key provided by passphrase (-1). # Selected keyslot 2. # Keyslot 0 priority 1 != 2 (required), skipped. # Keyslot 1 priority 1 != 2 (required), skipped. # Trying to open LUKS2 keyslot 0. # Running keyslot key derivation. # Reading keyslot area [0x8000]. # Acquiring read lock for device /dev/sda3. # Opening lock resource file /run/cryptsetup/L_8:3 # Verifying lock handle for /dev/sda3. # Device /dev/sda3 READ lock taken. # Reusing open ro fd on device /dev/sda3 # Device /dev/sda3 READ lock released. # Verifying key from keyslot 0, digest 0. # Keyslot 2 assigned to digest 0. # Trying to allocate LUKS2 keyslot 2. # Found area 548864 -> 806912 # Running argon2id() benchmark. # PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 72 ms) # PBKDF benchmark: memory cost = 227555, iterations = 4, threads = 4 (took 264 ms) # PBKDF benchmark: memory cost = 1048576, iterations = 6, threads = 4 (took 1982 ms) # Benchmark returns argon2id() 6 iterations, 1048576 memory, 4 threads (for 512-bits key). # JSON does not fit in the designated area. # Not enough space in header json area for new keyslot. # Rolling back in-memory LUKS2 json metadata. # Releasing crypt device /dev/sda3 context. # Releasing device-mapper backend. # Closing read only fd for /dev/sda3. Command failed with code -1 (wrong or missing parameters). I'm wondering if anyone's able to help me understand what's going wrong here, and thus what I need to do to remedy it. Is there a 'initial header size' option I can specify on our builds? Or a parameter to cryptsetup? Or am I "just" finding a bug? (But I'm not convinced that something as widely used as cryptsetup is going to have a 'no one can change their passwords' sort of bug) This is how the LUKs header looks on an example host. LUKS header information Version: 2 Epoch: 5 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: Label: (no label) Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2id Time cost: 9 Memory: 1048576 Threads: 4 Salt: AF stripes: 4000 AF hash: sha256 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 1: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: pbkdf2 Hash: sha256 Iterations: 1000 Salt: AF stripes: 4000 AF hash: sha256 Area offset:290816 [bytes] Area length:258048 [bytes] Digest ID: 0 Tokens: 0: clevis Keyslot: 1 Digests: 0: pbkdf2 Hash: sha256 Iterations: 105025 Salt: Digest: Am I missing something profound? As said, I am _certain_ this works if I don't 'upgrade' the box to a newer kernel, and so my current workaround is to build it, manually re-key it, and then continue to update it, but this seems ... suboptimal. cryptsetup versions 2.6.0 and 2.7.2 head -c 1M /dev/sda3 | strings -n 128 reformatted: { "keyslots": { "0": { "type": "luks2", "key_size": 64, "af": { "type": "luks1", "stripes": 4000, "hash": "sha256" }, "area": { "type": "raw", "offset": "32768", "size": "258048", "encryption": "aes-xts-plain64", "key_size": 64 }, "kdf": { "type": "argon2id", "time": 7, "memory": 1048576, "cpus": 4, "salt": "(removed)" } }, "1": { "type": "luks2", "key_size": 64, "af": { "type": "luks1", "stripes": 4000, "hash": "sha256" }, "area": { "type": "raw", "offset": "290816", "size": "258048", "encryption": "aes-xts-plain64", "key_size": 64 }, "kdf": { "type": "pbkdf2", "hash": "sha256", "iterations": 1000, "salt": "(removed)" } } }, "tokens": { "0": { "type": "clevis", "keyslots": [ "1" ], "jwe": { "ciphertext": "(removed)", "encrypted_key": "", "iv": "(removed)", "protected": "", "tag": "(removed)" } } }, "segments": { "0": { "type": "crypt", "offset": "16777216", "size": "dynamic", "iv_tweak": "0", "encryption": "aes-xts-plain64", "sector_size": 512 } }, "digests": { "0": { "type": "pbkdf2", "keyslots": [ "0", "1" ], "segments": [ "0" ], "hash": "sha256", "iterations": 88086, "salt": "(removed)", "digest": "(removed)" } }, "config": { "json_size": "12288", "keyslots_size": "16744448" } } Edit2: The plot thickens: luksHeaderBackup then a restore fails. But killing 'slot 0' and adding a key works still. (Assuming the 'slot 1' you can extract, but in my cases clevis-luks-pass works well enough)

In Linux in Bash i run a script with some cryptsetup calls like --luks2-metadata-size=16k --luks2-keyslots-size=256k .... luksFormat .... that brings Warning outputs. I know and understand, but i will these Warnings not see at the screen. How can i suppress them, but show error messages?

i will create some write once read many files. i need only one key for open the file and for me, there is no reason to change in the future the key. the header will stored on a different place, and goes not out of my safe house, but the date does. i will have a minimum header size, how to do this? cryptsetup is version 2.7.5 should i use luksFormat --type luks1 to get a 2MiB header? or what does --luks2-metadata-size and --luks2-keyslots-size do? how to understand these both options?

I've got a system with LUKS partitions. I'd like to convert them to LUKS2 to see if I can simplify my setup using partition labels. When I run cryptsetup convert --type LUKS2 it seems to work correctly

# cryptsetup convert  --type luks2

WARNING!
========
This operation will convert  to LUKS2 format.


Are you sure? (Type uppercase yes): YES

But then when I attempt to unlock the volume it breaks:

# /usr/local/bin/unlock_password.sh | cryptsetup -v luksOpen  PartB
Command failed with code -1 (wrong or missing parameters).

Converting back to LUKS 1 fixes it

# cryptsetup convert  --type luks1

WARNING!
========
This operation will convert  to LUKS1 format.


Are you sure? (Type uppercase yes): YES
# /usr/local/bin/unlock_password.sh | cryptsetup -v luksOpen  PartB
Key slot 0 unlocked.
Command successful.

Does anyone know why this could happen? It looks like the conversion didn't run correctly on the keyslot, or maybe the input handler is different for LUKS2 and it can't accept my (large, base64) password. My old version of cryptsetup is 2.0.4 if that matches up with known bugs. PS. I have also added a second key-slot with a new random key file. It also stops working when I convert to LUKS2 so it looks like, with my current environment, I cannot convert to LUKS2.

I'm trying to create a multiboot usb drive for Debian images including a live system, netinst, and DVD-1 iso. I've got as far as creating the partitions 1. EFI fat32 2. Boot luks2 3. ISOs luks2 Then I install grub targeting the efi and boot partitions, add a vmlinuz and initrd to the boot partition along with a custom grub.cfg. Grub successful unlocks the boot partition and then runs the kernel. However, at this point I can't get the kernel to unlock the ISOs partition where the iso images are. As far as I understand it, the initrd file downloaded from: https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/hd-media/ does not include support for cryptsetup, nor does any other initrd image I've tried. It looks like I need to edit or make my own. My host system (also Debian) is able to unlock a luks partition so it is obviously possible, but I don't know the steps to take to set this up on a usb drive. My grub.cfg menuentries look a bit like:

# Workaround for "out of memory" error
rmmod tpm

menuentry "Install" {
   set isofile="/debian-${VERSION}-amd64-${installer}.iso"
   set options="cryptdevice=UUID=${cryptuuid}:luks root=/dev/mapper/luks quiet splash"
   linux /vmlinuz iso-scan/filename=$isofile $options
   initrd /initrd.img
}

menuentry "Live" {
    loopback loop ($root)$isofile
    linux (loop)/live/vmlinuz boot=live findiso=$isofile
    initrd (loop)/live/initrd.img
}

At the moment the iso-scan fails to find the iso image and it appears that the 3rd partition is never unlocked. I'm a little bit over my head with creating a custom initrd and am not sure where to start. A lot of the documentation assumes you are running commands on the local system for the local system. EDIT: I've had some success using debootstrap and then chroot, installing a few things and then using mkinitramfs, however it doesn't load properly > Gave up waiting for root file system device. Common problems: ... ALERT! /dev/mapper/luks does not exist. Dropping to a shell!

When using a full disk encryption, an unencrypted /boot partition is usually required to store bootloader and pre-boot environment. These initcpio or initramfs images need to be loaded before decryption happens, thus they are accessible to the (evil maid) attacker, who can replace them with their own, or sneakily modify them to replace included ssh server or tty console to leak the decryption passphrase/key to the outside world. What would be the ideal way to prevent (or detect) tampering with contents of /boot? Rolling our own signing key, signing the /boot images and hoping there are no bugs within motherboard implementations' of BIOS, secure boot & security passphrases that would allow (evil maid) attacker to enroll their own key? PGP signing the images, and null-ing the memory and stopping the system when we detect system was unlocked & loaded by initcpio/initramfs with incorrect signature? Even TPM tools (like Clevis) only provide protection once system is already set-up and running. How would one ensure trust once TPM has been cleared, such as after firmware upgrade? Or is the only reliable protection providing our own /boot externally each time we want to boot the system after a power-off?

With cryptsetup I will create some LUKS encrypted files with detached header. In the files I will write once and read repeatedly. I do not need to change any key. How can the size of the header be kept as small as possible?

Oh wise and powerful linux gurus, bless this humble wannabe linux admin with your knowledge! I am attempting to remove the luks encryption on my rhel 7.9 device in order to facilitate upgrading to 8.10 (inherited device from previous admin with no documentation and do not wish to rebuild and lose its configs) It does use lvm and best I can tell each of the 5 LV's within the Volume group are encryted with luks 1 /dev/mapper/rhel-00 /dev/mapper/rhel-01 /dev/mapper/rhel-03 /dev/mapper/rhel-04 /dev/mapper/rhel-05 Following the suggestions in the answer linked below I booted from a rhel 7.9 live cd into rescue environment, did not mount the host filesystem (went straight to shell), ran vgchange -ay *vgname*, and then executed cryptsetup-reencrypt --decrypt /path/to/device. This succeeded on each of them except /dev/mapper/rhel-00 which prompts for the passphrase, then returns to shell prompt with no errors nor progress. cryptsetup status for the device just returns to shell prompt as well cryptsetup luksDump does give output I dont believe I am fatfingering the passphrase as it accepts it and does not give an error like it does when I intentionally enter a wrong one. Ill update with information as needed but direction would help as I cannot easily pull data off at the moment. https://unix.stackexchange.com/a/606231