On Tue, Jul 15, 2008 at 04:42:52PM -0700, Linus Torvalds wrote:
quoted text
> On Tue, 15 Jul 2008, david@lang.hm wrote:
> >
> > becouse the tools that wrote the initrd already put the modules in. I don't
> > maintain those tools, they came with the distro. we're just asking to not
> > require those tools to be updated immediatly.
> 
> But mkinitrd (which is the _only_ thing that people tend to use to write 
> initrd's - is there even anything else) has already been doing this for 
> years, as has been pointed out several times.

Actually, there is also mkinitramfs (which is what Debian and Ubuntu
use), and Yaird (Yet Another mkinitrd).  Also, the distro's tend to
heavily customize mkinitrd in general, so there is no guarantee that
just because two distro's use some tool that happens to be named
mkinitrd that the two tools have much in common with each other....

This is highly unfortunate, and I've often argued that we probably
would have been better off if we had included an mkinitrd tool as part
of the kernel sources to make life easier instead of having every
single distro do their own thing; it would also make it easier to run
a newer kernel on an older enterprise distro --- I remember the pain
trying to make a 2.6.16 kernel boot on a RHEL4 base system two years
ago; I don't want to even think about what would happen with something
more modern at this point.

quoted text
> If it's literally just an issue of an mkinitrd that is too damn old, why 
> don't we just make that test at kernel build time. *EXACTLY* the same way 
> we test for compilers that are too old, and refuse to build with them?

For one reason, because there's more than one mkinitrd.  FC9 ships
with mkinitrd 6.0.52; OpenSuSE ships with mkinitrd 2.1, and the
sources don't look even vaguely similar to one another.  For example,
Red Hat's mkinitrd uses nash, which is a maddingly useless shell that
made it near-impossible to debug why a 2.6.16 kernel wasn't booting on
a RHEL-4 system on a LS-21 blade.  OpenSuSE's mkinitrd ships with
bash, and Debian/Ubuntu will give you a busybox shell, which makes
life *much* easier to debug when you're trying to figure out why your
latest bleeding edge kernel isn't able to mount the root partition out
of initrd.

						- Ted

P.S.  For bonus points, it would be nice if initrd's included fsck,
since it then it would be possible to safely fsck the root partition
and not require a reboot if the root partition was modified.  But
given that every single distro seems to ship their own initrd, not to
mention their own init scripts, it's hard to try to push for this sort
of change.  The amount of distro-specific engineering work probably
makes it not worth it.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/