Emily,
This seems it would be an easy mistake to make, especially if one's
working on an unfamiliar system or multiple heterogeneous systems or
after a long time during which dm-crypt has been working, as it should,
transparently and its presence is forgotten. I could see myself making
the same mistake. So thanks for bringing up the issue.
This will likely be the least knowledgeable reply you'll get, so please
defer to any other replies.
I would think that the most assured method to prevent this mistake would
need to be from the side of fsck itself. So I would rename fsck to
something else, say fsck.bin. Then a shell script would call fsck.bin
after first checking the device specified. One check I can think of
would consist of an attempt to mount the specified device to a temporary
mountpoint. Only if the mount succeeds, after the device is unmounted,
would fsck.bin be called. Of course each of the various
fsck.{filesystem} executables should get this sort of wrapping.
True, this is a bit of a cludge. And there's probably two or three more
elegant cludges possible. And a true fix would need to be incorporated
into all the fsck.{filesystem} executables themselves. But that would
probably take awhile to happen and then flow out to all the distros.
Something like the above might serve the purpose until all that happens.
On 12/27/2012 01:12 AM 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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
