Re: initrd/initramfs: we discussed enough, let's take some action now :)

[Erik van Konijnenburg <ekonijn@xs4all.nl>]

On Sat, Oct 15, 2005 at 06:15:04PM +0200, Jonas Smedegaard wrote:
> On Sat, 15 Oct 2005 16:34:57 +0200 Erik van Konijnenburg <ekonijn@xs4all.nl> wrote:
> > On Sat, Oct 15, 2005 at 08:57:31AM +0200, Sven Luther wrote:
> > > On Sat, Oct 15, 2005 at 08:47:57AM +0200, Erik van Konijnenburg wrote:
> > > > On Fri, Oct 14, 2005 at 12:53:41PM +0200, Jonas Smedegaard wrote:

> I believe -n means "nonzero string" (not "null string"), and the
> oppposite of -z (not a geeky variation of -z). At least that's the
> explanation in the manpage of test in Debian sid currently.

You're right of course, but note how plausible the -n lie was;
With [ "$aap" = "" ] notation, you don't have to think about -n vs -z...

> > With a bit of hand-waving, there are two broad approaches:
> > * require the user to upgrade to 2.6 *somehow* before upgrading to
> > yaird
> > * extend yaird with a universal-boot mode.

> The first option is really a "ignore the issue and hope someone else
> deals with it".
> 
> One of the reasons I find yaird interesting is exactly that it is an
> alternative. If a problem shows with a kernel, you can try installing a
> different kernel to see if the problem goes away. Similarly if a
> ramdisk-generator lacks a feature you can switch to an alternative
> generator that handles this particular feature.
> 
> As Jeff explained earlier, initramfs-tools aims to "being stupid"[1] and
> just provide a framework for other packages to hook script snippets
> onto. Yaird seems to aim at "being smart" and contain enough
> intelligence itself about all features it wants to support.
> 
> I would really like to have the choice of both approaches, also for
> less common tasks like switching from 2.4 or preparing an alien bootup
> (either for different hardware or for diskless clients).

Good argument for separate implementations, but note that for the
universal boot image, both mkinitramfs and yaird need to come up
with an initscript that does udev and then mdadm, lvm and what have you.

For this use case, the only difference is whether the cpio file
is written by a perl script or by a shell script; all the intelligence
is at boot time, not at build time.
This makes the difference between the two approaches too small to
be of much interest to Debian.  For yaird, on the other hand, 
adding an udev-based template would make it a much more complete
package.

> Oh, and btw, Erik: Please have a look at
> http://wiki.debian.org/InitrdReplacementOptions and consider improving
> it. :-)

Good overview; I added some datapoints to it.

Erik