Re: Suddenly unable to access encrypted LUKS partition
Carl-Daniel Hailfinger <[email protected]>
| Newsgroups | gmane.linux.kernel.device-mapper.dm-crypt |
|---|---|
| Message-ID | <[email protected]> |
Hi Andrea, it seems you're the second user in less than two months who was unable to access the LUKS volume after an upgrade of Arch Linux. The thread describing very similar symptoms to yours is here: https://www.spinics.net/lists/dm-crypt/msg08014.html This type of problem is usually really rare. There might be a pattern, but then again two occurrences are not a sufficiently large sample size. On 08.12.19 20:54, Chris Murphy wrote: > On Sun, Dec 8, 2019 at 12:06 PM <ampica-g/[email protected]> wrote: >> 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). I saw you made a header backup of the (possibly damaged) current state of the header already. In theory, an update triggering a GRUB reinstall to the wrong device might screw up keyslots, but AFAICS the keyslot checker should have found such a problem. Good luck! Regards, Carl-Daniel _______________________________________________ dm-crypt mailing list [email protected] https://www.saout.de/mailman/listinfo/dm-crypt