[lsb-discuss] request that a command be added to LSB Commands andUtilities

[Theodore Tso]

On Tue, Nov 06, 2007 at 02:58:39PM -0800, Wichmann, Mats D wrote:
> 
> I don't know if LSB can help.  I sympathize; I've been bitten
> by the distro-1 style, which is a real pain in the (bleep)
> when you need to make an initrd for the kernel you're about
> to boot, and thus not the one you're running.  Isn't this
> the normal case anyway?  yet I've had a system where that's
> very hard to do....
> 
> You could certainly try proposing a common syntax, and
> if people think it's a good idea we can certainly find
> someplace to publish it even if it's not the somewhat
> application-oriented "LSB Specification"...

Actually, the best thing we could do is see if we could get the
various distros who have their own mkinitrd's, and see if we can unify
not only the syntax, but also the *implementation*.  I don't know if
the RHEL5 initrd will drop you into a busybox shell if it can't find
the root filesystem, but I know for certain that the RHEL4 one does
not --- and if you try to replace the RHEL4 kernel with a modern
kernel, on systems with the MPT Fusion SCSI controller, (such as the
IBM blades), the SCSI probing changed from synchronous to asynchronous
when if the SCSI controller is loaded as a module, so the RHEL4 initrd
would fail to boot with a modern kernel --- and there was no way in
the world to debug the !@#@! problem.  And with it taking
approximately 30 minutes to do a hard-reset, scsi disk scan, and
reboot, watch the initrd fail, and then boot back into the stock RHEL4
kernel, fairly quickly I was cursing the RHEL4 initrd's implementation
pretty soundly, and wishing that I could use Debian's mkinitrd
implementation, which would drop you into a busybox shell so you can
debug initrd failures.  I ended up wasting a whole day on this problem
before I figured out that using a kernel with the device driver
compiled in worked around the problem.

It would be nice if we could get the various mkinitrd's systems
unified, with the distro's all using the same upstream package, thus
making it easier for users who want to upgrade to the latest kernel to
also be able to upgrade the mkinitrd when the kernel behavior changes
in such a way as to invalidate the mkinitrd; maybe this would be a
nice thing to integrate into util-linux-ng?

Anyway, it's not strictly speaking a LSB issue, but it sure would be
nice if we could get some people interested in unifying the various
initrd systems and taking the best features from each....  (Me, I deal
with the problem by refusing to do kernel development work on RHEL
except when my job requires it.  I find the Debian/Ubuntu mkinitrd to
be much more.... civilized.  :-)

						- Ted