On Sun, Dec 8, 2019 at 12:06 PM <ampica@xxxxxxxxxxxxxx> wrote: > > Hello, > > I'm sorry to be the latest user which had a problem with the LUKS header but I'm really desperate to recover my data and contacting this mailing list is my last hope at this point. > > I use a dual-boot setup on a Lenovo T480 with Windows 10 and Arch Linux on the same SSD drive, Arch is encrypted with LVM on LUKS as described in the Arch Wiki (https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS). I'm not an expert with LUKS2, but semi-expert when it comes to file systems and data loss. My top recommendation is to make no changes, i.e. no writes to the drive in question. In my experience, user panic leads to increasingly desperate attempts to regain access, and the ensuing repair attempts that write changes to the drive ends up making the problem worse, often inducing data loss. I would spend the waiting time to write up a log that reconstructs the exact sequence of events from the time you last successfully had access to your data. If you have a spare drive big enough, you could also spend the time making a block copy, being super deliberate to not F up the command and inadvertently get the source/destination wrong (yep, panic is bad, be deliberate instead). > As suggested in the FAQ and forums, I tried several things, like using the keyslot check tool and analyzing the hexdump command output (no evident damage from both), tried decrypting the header on another system with the same result and filtered out all other possible problems like keyboard layout, user error and system specific configuration. The only relevant thing to say is that last time I shut down my laptop before facing the issue I updated the linux kernel to 5.4.2 and run "mkinitcpio -p linux" but I didn't notice anything unusual respect to other times in the output from command line. Even though you've checked keyboard layout, this really does smell like a keymapping problem, which often doesn't trigger until the initramfs is regenerated which would have happened with a kernel update. Any keyboard (physical hardware) changes? Any change to the desktop environment default language, and/or default keyboard layout? Any other users or are you the sole user of this system? It might be useful to compare the oldest initramfs for this installation (even one only in backups if you have /boot backups) with the current one, using lsinitrd, and see if there's some clue about what may have changed. > I've really no clue on what happened since I didn't do anything accidentally. I'm already on the "Acceptance" phase but I still have that 0.01% hope left to recover my system, so any help or suggestion is really much appreciated. If you need more information, please let me know (I've no problem sharing my LUKS header and passphrase for a further analysis). Thank you very much in advance for everything. Don't panic! Based on your description so far, recovery still seems decently likely. -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
