Bug 492040 - kexec-tools needs fsck.ext2 and fsck.ext3 commands in busybox
kexec-tools needs fsck.ext2 and fsck.ext3 commands in busybox
Product: Fedora
Classification: Fedora
Component: busybox (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Ivana Varekova
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-24 21:52 EDT by Sam Varshavchik
Modified: 2009-04-01 09:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-31 09:47:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sam Varshavchik 2009-03-24 21:52:08 EDT
The mkdumprd from kexec-tools creates a busybox-based initrd image with an init script that issues "fsck.ext3" and "fsck.ext2" commands, which seem to be currently disabled in busybox-1.10.3-4.

See bug 476368, comment #32.
Comment 1 Ivana Varekova 2009-03-31 09:36:08 EDT
For now fsck.ext3 and fsck.ext2 applets are disabled in busybox package so they can't be added (upstream disabled them and the reason is it is too problematic to maintain them).
Comment 2 Denys Vlasenko 2009-04-01 09:39:13 EDT
I want to expand on this.

busybox used to have e2fs tools. They are still retained in the tree in e2fsprogs/old_e2fsprogs/*, including e2fsck.c, but they are disabled (it's impossible to select then in menuconfig).

However, e2fsck is NOT a thing you would want to treat lightly. It's a filesystem repair tool. It needs to know filesystem structure in every fine detail. It needs to take intelligent decisions in order to repair it, or at least to not damage it even further.

IOW, e2fsck must be written and maintained by e2fsck developer team.

Sure, technically it's possible to snatch a copy of source code, "busyboxify" it and use. The question is, what will happen next? e2fsck is presumably evolving. Bugs are discovered and fixed. Support for ext3, ext4, ext999 is added. Repairing algorithm gets better.

Nothing of this will happen in busybox's applet unless someone will actively maintain it.

And this means that busybox's e2fsck will have unfixed bugs. It will know nothing about, say, e4fsck, and if such filesystem will be given to it to "repair", hell knows how much worse it will be after that "repair".

That will be bad.

Unless busybox project commits developer resources to actively maintain e2fsprogs, it's better to NOT have e2fsck in it.

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