Bug 586451
| Summary: | e2fsck should wipe start of disk (similar to mkfs) if recovering from superblock backup | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Milan Broz <mbroz> |
| Component: | e2fsprogs | Assignee: | Eric Sandeen <esandeen> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | esandeen, josef, jsarenik, kzak, oliver, pvrabec |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-07-05 18:33:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Milan Broz
2010-04-27 15:57:44 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. -Eric 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. 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. :) > 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).
|