Messages in this thread | | | Date | Wed, 07 Jan 2009 17:04:50 +0100 | From | Hannes Reinecke <> | Subject | Re: Dracut -- Cross distribution initramfs infrastructure |
| |
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@suse.de +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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |