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@xxxxxxxx > >> http://www.saout.de/mailman/listinfo/dm-crypt > > > > > > -- > > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > > 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@xxxxxxxx > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
