Hi Emily,
this is rather unfortnate. But I think something else went wrong
here. When I run e2fsck on a luks loop-file, it correctly
recognizes there is no ext2/3/4 system in there:
------
root@gate:~/f/luks# e2fsck /dev/loop0
e2fsck 1.41.12 (17-May-2010)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop0
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
root@gate:~/f/luks#
-------
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
