[dm-crypt] Is my LUKS header corrupted?

[dm-crypt] Is my LUKS header corrupted?

[Greg Laun]

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

I have a LUKS-encrypted hard drive partition that is showing the following
behavior on Kubuntu 19.04:

1. If I enter the correct passphrase, Kubuntu drops into emergency mode. If
I enter the incorrect passphrase, Kubuntu asks for the passphrase again.

2. If I run cryptsetup luksOpen <target device> myName with the correct
passphrase, it tells me "No key available with this passphrase."

Does anybody know what would account for this behavior? How is Kubuntu's UI
layer able to take a different code path based on the correct passphrase if
dm-crypt no longer recognizes the passphrase?

Is it possible there are arguments to luksOpen that I can pass to have the
passphrase recognized again?

The passphrase worked 4 days ago. The machine was powered down accidentally
by an unruly toddler, but I'm not sure if that's enough to corrupt the LUKS
header.

Thanks for any help/info!
Greg

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

Re: [dm-crypt] Is my LUKS header corrupted?

[Arno Wagner]

2. would indicate a corrupt header, but 1. is really strange.
Unless Kubuntu has done something they really should not do,
namely adding their own passphrase checksum, I have no idea
how that behavior could happen.

Unless there is some large ssd-sector caused corruption,
the LUKS header should not get corrupted by powering things
down. It never gets written in normal operation and there is 
a safety-distance to the data area. 

Regards,
Arno

On Wed, Apr 24, 2019 at 12:42:08 CEST, Greg Laun wrote:
>    I have a LUKS-encrypted hard drive partition that is showing the
>    following behavior on Kubuntu 19.04:
>    1. If I enter the correct passphrase, Kubuntu drops into emergency
>    mode. If I enter the incorrect passphrase, Kubuntu asks for the
>    passphrase again.
>    2. If I run cryptsetup luksOpen <target device> myName with the correct
>    passphrase, it tells me "No key available with this passphrase."
>    Does anybody know what would account for this behavior? How is
>    Kubuntu's UI layer able to take a different code path based on the
>    correct passphrase if dm-crypt no longer recognizes the passphrase?
>    Is it possible there are arguments to luksOpen that I can pass to have
>    the passphrase recognized again?
>    The passphrase worked 4 days ago. The machine was powered down
>    accidentally by an unruly toddler, but I'm not sure if that's enough to
>    corrupt the LUKS header.
>    Thanks for any help/info!
>    Greg

> _______________________________________________
> 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] Is my LUKS header corrupted?

[Michael Kjörling]

On 24 Apr 2019 14:08 +0200, from arno@wagner.name (Arno Wagner):
> 2. would indicate a corrupt header, but 1. is really strange.
> Unless Kubuntu has done something they really should not do,
> namely adding their own passphrase checksum, I have no idea
> how that behavior could happen.

1. would seems to me to *possibly* indicate a corrupted file system.
Running a *read-only* fsck from within that emergency mode shell may
be advised, just to see if there's significant metadata damage within
the container. Also check how the file system is mounted when the
system drops into emergency mode; read-only or read/write.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [dm-crypt] Is my LUKS header corrupted?

[Arno Wagner]

On Wed, Apr 24, 2019 at 14:14:43 CEST, Michael Kjörling wrote:
> On 24 Apr 2019 14:08 +0200, from arno@wagner.name (Arno Wagner):
> > 2. would indicate a corrupt header, but 1. is really strange.
> > Unless Kubuntu has done something they really should not do,
> > namely adding their own passphrase checksum, I have no idea
> > how that behavior could happen.
> 
> 1. would seems to me to *possibly* indicate a corrupted file system.
> Running a *read-only* fsck from within that emergency mode shell may
> be advised, just to see if there's significant metadata damage within
> the container. Also check how the file system is mounted when the
> system drops into emergency mode; read-only or read/write.

Makes sense to me. 2. may be due to keymap or locale problems,
especially when the test was done in that emergency shell. In 
that case, the LUKS header may well be fine and the filesystem 
within the LUKS container may be damaged instead. And that can
happen on a hard power-off.

Arno


> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
>   “The most dangerous thought that you can have as a creative person
>               is to think you know what you’re doing.” (Bret Victor)
> _______________________________________________
> 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] Is my LUKS header corrupted?

[Heinz Diehl]

On 24.04.2019, Greg Laun wrote: 

> I have a LUKS-encrypted hard drive partition that is showing the following
> behavior on Kubuntu 19.04:
[.....]

I would suggest trying to open the device after booting from an
external system, e.g. a Fedora or Arch linux boot disk. Just to rule
out it isn't Kubuntu doing something weird.

Re: [dm-crypt] Is my LUKS header corrupted?

[Greg Laun]

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

Thanks everyone for replying.

It turns out the behavior was different than what I thought. On boot,
Kubuntu drops into emergency mode after three password tries. After that if
you exit emergency mode without rebooting, Kubuntu prompts for the
passphrase again and drops into the emergency shell again after a single
try. I was trying different versions of the passphrase and must have been
oscillating between three of them in a way that made it appear that Kubuntu
could detect the correct phrase. Then once I got into the emergency shell I
must have been reconfirming the passphrase I thought worked.

I should have mentioned in my first post that I did try booting into an
Arch boot disk and was unable to open the disk with the same passphrase.

The good news is that I was just using the wrong passphrase. Over the
weekend I had been wrestling with a second LUKS disk that I know to be
corrupted and got the two passphrases confused.

Sorry! And thanks again for all the replies.

On Wed, Apr 24, 2019 at 3:39 PM Heinz Diehl <htd+ml@fritha.org> wrote:

> On 24.04.2019, Greg Laun wrote:
>
> > I have a LUKS-encrypted hard drive partition that is showing the
> following
> > behavior on Kubuntu 19.04:
> [.....]
>
> I would suggest trying to open the device after booting from an
> external system, e.g. a Fedora or Arch linux boot disk. Just to rule
> out it isn't Kubuntu doing something weird.
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
>

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

Re: [dm-crypt] Is my LUKS header corrupted?

[Arno Wagner]

Well, goot to know you got your data bak.

Regards,
Arno

On Thu, Apr 25, 2019 at 13:04:57 CEST, Greg Laun wrote:
>    Thanks everyone for replying.
>    It turns out the behavior was different than what I thought. On boot,
>    Kubuntu drops into emergency mode after three password tries. After
>    that if you exit emergency mode without rebooting, Kubuntu prompts for
>    the passphrase again and drops into the emergency shell again after a
>    single try. I was trying different versions of the passphrase and must
>    have been oscillating between three of them in a way that made it
>    appear that Kubuntu could detect the correct phrase. Then once I got
>    into the emergency shell I must have been reconfirming the passphrase I
>    thought worked.
>    I should have mentioned in my first post that I did try booting into an
>    Arch boot disk and was unable to open the disk with the same
>    passphrase.
>    The good news is that I was just using the wrong passphrase. Over the
>    weekend I had been wrestling with a second LUKS disk that I know to be
>    corrupted and got the two passphrases confused.
>    Sorry! And thanks again for all the replies.
> 
>    On Wed, Apr 24, 2019 at 3:39 PM Heinz Diehl <[1]htd+ml@fritha.org>
>    wrote:
> 
>      On 24.04.2019, Greg Laun wrote:
>      > I have a LUKS-encrypted hard drive partition that is showing the
>      following
>      > behavior on Kubuntu 19.04:
>      [.....]
>      I would suggest trying to open the device after booting from an
>      external system, e.g. a Fedora or Arch linux boot disk. Just to rule
>      out it isn't Kubuntu doing something weird.
>      _______________________________________________
>      dm-crypt mailing list
>      [2]dm-crypt@saout.de
>      [3]https://www.saout.de/mailman/listinfo/dm-crypt
> 
> References
> 
>    1. mailto:htd+ml@fritha.org
>    2. mailto:dm-crypt@saout.de
>    3. https://www.saout.de/mailman/listinfo/dm-crypt

> _______________________________________________
> 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