Then one of the last things I can think of:
-
reboot your computer (even if you already have, just to rule it out)
-
there’s an
aliasconfigured that is interfering with the syntax ofcryptsetup.
As I said before, I am on a fresh install & everything is from the repos, uptill now.
However, I am using the Minimal ISO. Could there be some package I am missing?
So probably no Hardware problem, but it is still weird.
On a working system, it should look like this.
I’d assume if cryptsetup is installed, and pulled in its dependencies, there shouldn’t be a problem.
To rule something out:
su -l
Then as root, with a fresh login shell, try to do it again. (Obviously without invoking “sudo” for the commands.)
@xabbu It is incredibly weird. I have a laptop running Manjaro which handles Luks2 just fine.
Been experiencing this since yesterday, on my Desktop. I thought my headers were messed & I’ve for sure lost data. But luckily I was able to recover a snapshot.
No aliases I can see…
$ alias
cp='cp -i'
df='df -h'
free='free -m'
gitu='git add . && git commit && git push'
ls='ls $LS_OPTIONS'
run-help=man
which-command=whence
I’m gonna go have dinner now. I’ll update in a little while.
For the curious: if your system is encrypted, how can you recover a “snapshot” if the header is (supposedly) damaged?
So, the header isn’t actually corrupted. I thought it might have been because all the posts on StackOverflow basically said as much for this error.
To answer your question though, it genuinely was luck. I had three containers - my actual /home drive & two backups. I’m not sure how, I’m not sure why, but one of the containers unlocked, once, from a live environment & I copied the data to an unencrypted partition.
The same container would not unlock after a reboot.
Did you try this?
But it works from a live ISO session?
Maybe this does have something to do with the Minimal system? 
Isn’t working in Live ISO either…
The live ISO session of the Minimal ISO?
Maybe you’re missing a key package. Do you have volume_key installed?
I ran badblocks just to be sure. There aren’t any.
Yes…
❯ pacman -Ss volume_key
extra/volume_key 0.3.12-7 [installed]
A library for manipulating storage volume encryption keys and storing them separately from volumes to
handle forgotten passphrases
I’m running out of ideas.
It’s only LUKS2, as LUKS1 works.
But the issue persists with a root shell and even a live ISO session.
And having cryptsetup installed, will pull in all dependencies, regardless if you create LUKS1 or LUKS2 containers.
I would see if this works on one of the standard ISO live sessions.
Alright, I’m heading out now so I’ll try this & update tomorrow. (It’ll take a lil while for the ISO to download anyway…)
Thing is though, this isn’t the first time I’m trying this. I’ve been using encryption on the same machine (and minimal ISO) for about two years now. It just suddenly stopped working two days ago.
Changes I made at the time were
- Upgrade from
linux519tolinux60 - Reset UEFI BIOS to factory defaults & then
- Enable DOCP
- Enable Virtualisation
- Enable Resizable BAR
linux60 isn’t booting on my machine. I don’t care to troubleshoot that.
I reinstalled linux519 - and that’s when my containers started failing to unlock. At first it was just the backup drive & I could still boot with my home drive. Then my home drive failed to unlock (after a few reboots). Now none of them work.
Current system is a fresh install. Fully updated as of this comment. Running linux519.
Your inxi from your first post lists Kernel 5.15 as the running Kernel. And since 5.19 is end of life and soon unsupported, did you tried Kernel 5.15?
Fresh install, so 5.15. Everything yesterday was done on that.
If I can’t figure out why linux60 doesn’t boot, I’ll probably go back to 5.15
Shot in the dark - these are the last lines output from 6.0.5:
$ cryptsetup --help
....
Default compiled-in metadata format is LUKS2 (for luksFormat action).
LUKS2 external token plugin support is compiled-in.
LUKS2 external token plugin path: /usr/lib/cryptsetup.
Default compiled-in key and passphrase parameters:
Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2id
Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
LUKS: Default keysize with XTS mode (two internal keys) will be doubled.
Can you crosscheck the LUKS2 parameters against your 5.15 and then provide the following output for the LUKS2 device failing to unlock:
# cryptsetup luksDump fakedrive.img |grep PBKDF
PBKDF: argon2id
PBKDF: argon2id
The idea is based on a flystream we have against cryptsetup.1
1 Like
@ion Okay, what in huh?!?!?
❯ ls -al fakedrive.img cr_key.bin
-rw------- 1 maazb maazb 1024 Oct 30 11:02 cr_key.bin
-rw-r--r-- 1 maazb maazb 2147483648 Oct 30 11:02 fakedrive.img
❯ sudo cryptsetup --type luks2 --pbkdf argon2id luksFormat fakedrive.img cr_key.bin
[sudo] password for maazb:
WARNING!
========
This will overwrite data on fakedrive.img irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
❯ sudo cryptsetup --key-file=cr_key.bin open fakedrive.img cr_fakedrive
No key available with this passphrase.
❯ sudo cryptsetup --type luks2 --pbkdf argon2i luksFormat fakedrive.img cr_key.bin
WARNING: Device fakedrive.img already contains a 'crypto_LUKS' superblock signature.
WARNING!
========
This will overwrite data on fakedrive.img irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
❯ sudo cryptsetup --key-file=cr_key.bin open fakedrive.img cr_fakedrive
No key available with this passphrase.
❯ sudo cryptsetup --type luks2 --pbkdf pbkdf2 luksFormat fakedrive.img cr_key.bin
WARNING: Device fakedrive.img already contains a 'crypto_LUKS' superblock signature.
WARNING!
========
This will overwrite data on fakedrive.img irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
❯ sudo cryptsetup --key-file=cr_key.bin open fakedrive.img cr_fakedrive
❯ lsblk /dev/mapper/cr_fakedrive
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
cr_fakedrive 254:0 0 2G 0 crypt
Somebody please explain what just happened…