Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner <arno@wagner.name>]

On Fri, Dec 28, 2012 at 03:46:45PM +0100, Sven Eschenberg wrote:
> I think these are the 2 most common sources, when something like this
> happens.
> 
> It would be interesting to know though:
> 
> Did the device ever hold an ext filesystem?
> What was done before creating the luks container?
> 
> My best guess is, that the 'raw' device still had an intact secondary
> superblock, which was found and used.

My thoughts also.

> Are logs/console messages from the fsck run available, that could shed
> some light on this?
> 
> I wonder how fsck checks for a superblock. I still assume, that chances of
> having encrypted data in the right block on disk looking like a correct
> ext-superblock is next to zero.

The ext2 superblock magic number seems to be 0xEF53. That is a bit 
short but still only gives something like 1 in 65536 probability of 
misdetection in encrypted data. I think we can rule that out 
for the moment. 

> Regards
> 
> -Sven
> 
> BTW: Since Arno mentioned the confusion problem and I saw a md (devmapper)
> name in the initial post, avoid md metadata v1.0 format if possible. Even
> though it is clear to us humans, that a readable md metadata can not
> possibly be inside the luks container, it's your best chance of ending up
> with another desaster. Arno, could this be something for the FAQ?

I am thinking about a "basic LUKS setup" section for the FAQ 
that is more in the nature of a mini-howto. Things like blanking
a previously used partition before a LUKS install seem to be 
not obvious to many people. Step-by-step instructions may help.

Arno
 
> 
> On Thu, December 27, 2012 10:52, Arno Wagner wrote:
> > Hi Emily,
> >
> >
> > I think your partition could have contained old ext4 superblocks that
> > were not erased. Or ext2fsck was run with some kind of --force option.
> > In both cases, what you saw is user error.
> >
> > In particular, any partition should be compeltely erased before
> > a new filesystem or LUKS container is put on it, specifically
> > to avoid an unfortunate event like you had. Typically, recognizing
> > what is in a partitition is reliable. But if two different
> > things get mixed (LUKS + ext4), a repair tool, that must be
> > less careful about requiring correct signatures, could get confused.
> >
> > Arno
> >
> >
> >
> >
> >
> > On Thu, Dec 27, 2012 at 01:12:09AM -0500, Emily Williams wrote:
> >> Today I made a rather large mistake, running fsck.ext4 on the raw volume
> >> (/dev/sdk1) instead of the mapped volume
> >> (/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible
> >> to
> >> recover from this once it is done and the cryptosetup lukeOpen
> >> passphrase
> >> no longer works.
> >>
> >> I'd like to avoid this ever happening in the future. Is there any way to
> >> put in safeguards to minimize the chance of this ever happening again?
> >>
> >> I've found very few references to this problem after a lot of searching
> >> -
> >> below is one I did find that at least made me think I wasn't going crazy
> >> -
> >> so I'm guessing I'm just doing something silly that makes fsck.ext4
> >> think
> >> that the raw volume is actually something it should take a whack at
> >> fixing,
> >> instead of saying something sensible like "that doesn't look like an
> >> ext4
> >> filesystem, go away", which as far as I can see should be the case -
> >> it's
> >> encrypted, so it shouldn't "look like" anything except crypto_luks
> >> metadata
> >> and random data in no discernible format. And yet fsck.ext4 seems to be
> >> behaving as though it sees an ext4 filesystem with errors.
> >>
> >> From: poptones
> >> Subject: (not LUKS) why did fsck on an encrypted source work?
> >> Date: 2005-11-15 06:26:26 GMT (7 years, 6 weeks, 5 hours and 28 minutes
> >> ago)
> >>
> >> Accidentally (yes, I was still a little rattled from the earlier
> >> mistake) I
> >> ran this on /dev/md0 instead of /dev/mapper/md0. After a couple of hours
> >> it
> >> began the final pass and I saw it report moving files - about 20,000
> >> object
> >> moved to /lost&found.
> >>
> >> Somewhat perplexed and confused, and learning not to play with new toys
> >> when overtired,
> >> -Emily
> >
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://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
> > ----
> > One of the painful things about our time is that those who feel certainty
> > are stupid, and those with any imagination and understanding are filled
> > with doubt and indecision. -- Bertrand Russell
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://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
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell