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. 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. 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? 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
