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
