[dm-crypt] Suddenly unable to access encrypted LUKS partition

[dm-crypt] Suddenly unable to access encrypted LUKS partition

[ampica]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

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).
To make the story short and simple, since yesterday I've been suddenly unable to decrypt my LVM on LUKS partition and started having "No key available with this passphrase" despite the correctness of the passphrase. Needless to say I made several attempts and checks and made sure the password is correct. If you want to have a look at logs and see all details I simply redirect you to the posts I made on Reddit https://www.reddit.com/r/archlinux/comments/e76se0/unable_to_access_encrypted_luks_partition_wrong/ and on the Arch Linux forum https://bbs.archlinux.org/viewtopic.php?id=251218.

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.

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.

Best Regards,
Andrea Piccione

[-- Attachment #2: Type: text/html, Size: 2536 bytes --]

Re: [dm-crypt] Suddenly unable to access encrypted LUKS partition

[Chris Murphy]

On Sun, Dec 8, 2019 at 12:06 PM <ampica@protonmail.com> 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

Re: [dm-crypt] Suddenly unable to access encrypted LUKS partition

[Arno Wagner]

Hi Andrea,

Do you have a header backup from before this happened?

Regards,
Arno

On Sun, Dec 08, 2019 at 00:41:27 CET, ampica@protonmail.com 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
>    ([1]https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_
>    system#LVM_on_LUKS).
> 
>    To make the story short and simple, since yesterday I've been suddenly
>    unable to decrypt my LVM on LUKS partition and started having "No key
>    available with this passphrase" despite the correctness of the
>    passphrase. Needless to say I made several attempts and checks and made
>    sure the password is correct. If you want to have a look at logs and
>    see all details I simply redirect you to the posts I made on Reddit
>    [2]https://www.reddit.com/r/archlinux/comments/e76se0/unable_to_access_
>    encrypted_luks_partition_wrong/ and on the Arch Linux forum
>    [3]https://bbs.archlinux.org/viewtopic.php?id=251218.
> 
>    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.
> 
>    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.
> 
>    Best Regards,
> 
>    Andrea Piccione
> 
> References
> 
>    1. https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS
>    2. https://www.reddit.com/r/archlinux/comments/e76se0/unable_to_access_encrypted_luks_partition_wrong/
>    3. https://bbs.archlinux.org/viewtopic.php?id=251218

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Suddenly unable to access encrypted LUKS partition

[Carl-Daniel Hailfinger]

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@protonmail.com> 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