All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Is my LUKS header corrupted?
Date: Wed, 24 Apr 2019 14:08:25 +0200	[thread overview]
Message-ID: <20190424120825.GA11429@tansi.org> (raw)
In-Reply-To: <CAApG7_rajZY+=cFP2MfKocNM53yX7G16gf8c-1xrimRNX3TfZg@mail.gmail.com>

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

  reply	other threads:[~2019-04-24 12:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 10:42 [dm-crypt] Is my LUKS header corrupted? Greg Laun
2019-04-24 12:08 ` Arno Wagner [this message]
2019-04-24 12:14   ` Michael Kjörling
2019-04-24 13:51     ` Arno Wagner
2019-04-24 19:35 ` Heinz Diehl
2019-04-25 11:04   ` Greg Laun
2019-04-25 18:06     ` Arno Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190424120825.GA11429@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.