Bug 586451 - e2fsck should wipe start of disk (similar to mkfs) if recovering from superblock backup
e2fsck should wipe start of disk (similar to mkfs) if recovering from superbl...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-27 11:57 EDT by Milan Broz
Modified: 2013-02-28 23:09 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-05 14:33:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Milan Broz 2010-04-27 11:57:44 EDT
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):
e2fsprogs-1.41.11-1.fc14.x86_64

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 12:05:01 EDT
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.

-Eric
Comment 2 Eric Sandeen 2010-07-05 14:07:44 EDT
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 14:33:19 EDT
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 14:37:07 EDT
> 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.