Re: Dracut -- Cross distribution initramfs infrastructure

[Hannes Reinecke]

Dave Jones wrote:
> On Sun, Dec 21, 2008 at 12:50:21AM +1100, Daniel Pittman wrote:
>
>  > One of the features of the Debian / Ubuntu initramfs infrastructure,
>  > which sounds remarkably like your design (or vice-versa), is that it
>  > drops all the "standard" drivers into the initramfs.
>  > 
>  > This is, to me, worth several minutes of additional boot time, in terms
>  > of flexibility: being able to modify the hardware and be confident that
>  > the appropriate drivers are in place already makes life much, much
>  > easier.
>
> There's another reason this is really useful.
> If something goes wrong, remotely debugging a users initrd right is
> a lot easier if you know what it looks like.  Right now, in Fedora for eg,
> where we generate an initrd for each users system at runtime, we need
> to get a copy of the generated initrd, and pull it apart just to find
> out what modules ended up in there, what didn't, and then somehow
> try to work backwards to try and figure out how the generator got into
> that state.  After doing this for five years, let me tell you it's
> _really_ _really_ painful.
Whom do you tell.

I ended up on adding lots of shell escapes; everytime something goes
wrong you'll be dropped into a shell, which will resume execution
of the initrd once exited.
Quite handy for fixing up most things.

>  > (In practice I doubt this adds more than a second or five to boot time;
>  >  certainly, it takes no longer to get to rootfs mounted than the RHEL 4
>  >  systems that have nothing but what is essential in the initrd...)
>
> At least in theory, with a kernel-event/udev driven system, the additional
> modules shouldn't cause any additional boot time. There wouldn't be
> events generated to cause them to be loaded, so they'd just be taking
> up space.  And the additional load time for a bigger initrd should be
> really lost in the noise of the overall boot.
One can but hope. You certainly will notice a load time increase if the size
of the initrd increases by orders of magnitude.
Plus kdump / kexec will need to be configured to have more memory available.

Actually, I do like the callout idea:
Have the initrd configure a 'standard' system, and add some API which will
allow you to hook in additional scripts / services / whatever to configure
non-standard systems.
Which then can be distributed by the individual packages / vendors.
And then we would have a small common initramfs which well could be included
with the kernel sources.

Cheers,

Hannes
--
Dr. Hannes Reinecke		      zSeries & Storage
hare@xxxxxxx			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/