[dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data
emilyw at MIT.EDU
Thu Dec 27 07:12:09 CET 2012
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt