Bug 586451 - e2fsck should wipe start of disk (similar to mkfs) if recovering from superblock backup
Summary: e2fsck should wipe start of disk (similar to mkfs) if recovering from superbl...
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-27 15:57 UTC by Milan Broz
Modified: 2013-03-01 04:09 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-07-05 18:33:19 UTC
Type: ---

Attachments (Terms of Use)

Description Milan Broz 2010-04-27 15:57:44 UTC
Description of problem:

An admin mistake(tm), which create LUKS device over existing ext3, and then uses
fsck to repair data.
After taht, on disk it still remains LUKS signature (first sector, LUKS is of course unusable because keyslots are destroyed).

Version-Release number of selected component (if applicable):

How reproducible:

# mke2fs -j /dev/sdb
# cryptsetup luksFormat /dev/sdb 

# e2fsck -fy /dev/sdb
e2fsck 1.41.11 (14-Mar-2010)           
e2fsck: Superblock invalid, trying backup blocks...
Resize inode not valid.  Recreate? yes             

# mount /dev/sdb /mnt/tst/
mount: unknown filesystem type 'crypto_LUKS'

(mount -t ext3 is ok, but once time I even saw that journal was lost and only ext2 was possible - but that's probably another problem)

# hexdump -C -n 4 /dev/sdb
00000000  4c 55 4b 53                                       |LUKS|

Expected results:
If user really want recreate fs structure here, fsck should wipe the same area on disk to remove possible old signatures to not counfuse utilities later.

Comment 1 Eric Sandeen 2010-05-14 16:05:01 UTC
Hm, maybe fsck should -always- check for data in the should-be-zero area, but in that case it might be best to require a -F force of some sort ... I think there's the risk that another admin error (tm) pointed e2fsck at something that's not extN, and e2fsck just happened to find enough signature to go start trying to "fix" things ... then we would have a problem in the other direction.


Comment 2 Eric Sandeen 2010-07-05 18:07:44 UTC
I'm on the fence here.  If the partition has findable signatures for both LUKS and extN, how/when/why should e2fsck decide that -it- is the rightful owner?  What if the mistake is made pointing e2fsck at something that really -is- LUKS?

It seems to me that perhaps it is better to make cryptsetup destroy other filesystem signatures so that e2fsck won't touch it.

Tougher for the admin who made the mistake, but such is life, you asked to repurpose the block device to LUKS...

I guess if e2fsck -does- carry on as it does today, though, it makes sense to zero it out.

Comment 3 Eric Sandeen 2010-07-05 18:33:19 UTC
Well, here's the thing though.  The data you're talking about:

# hexdump -C -n 4 /dev/sdb
00000000  4c 55 4b 53                                       |LUKS|

is actually before the filesystem, and may well be in use by other things - like grub.

For example if grub lived in the partition, and then the admin ran e2fsck which did as you propose, it'd leave the system unbootable.

I think that in this case it is up to the savvy administrator to use various tools at their disposal to fix the mess; I don't think e2fsck can know for sure what to do in this case.

I'm willing to be re-convinced, if you have a good argument, though.  :)

Comment 4 Milan Broz 2010-07-05 18:37:07 UTC
> What if the mistake is made pointing e2fsck at something that really -is- LUKS?

LUKS during format wipes fisrst 4k and (if not overrided to use another keyslot) and formats (==wipes) first keyslot, it is usually area from 4k - 64k (or more, depends on key size).

So after LUKS format there is no ext2/3/4 signature left if first ~64k of device:-)

If you change anything there (even one bit change in kesylot), LUKS is unusable anyway. So we can either disable that ext fs recovery completely or it should wipe LUKS area (first two sectors is enough).

Note You need to log in before you can comment on or make changes to this bug.