Bug 492040

Summary:	kexec-tools needs fsck.ext2 and fsck.ext3 commands in busybox
Product:	[Fedora] Fedora	Reporter:	Sam Varshavchik <mrsam>
Component:	busybox	Assignee:	Ivana Varekova <varekova>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	10	CC:	dvlasenk, varekova
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:	2009-03-31 13:47:54 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 Sam Varshavchik 2009-03-25 01:52:08 UTC

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 13:36:08 UTC

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 13:39:13 UTC

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.