From: Hannes Reinecke <hare@suse.de>
To: Dave Jones <davej@redhat.com>,
Daniel Pittman <daniel@rimspace.net>,
Jeremy Katz <katzj@redhat.com>, Theodore Tso <tytso@mit.edu>,
initramfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Dracut -- Cross distribution initramfs infrastructure
Date: Wed, 07 Jan 2009 17:04:50 +0100 [thread overview]
Message-ID: <4964D2A2.2010109@suse.de> (raw)
In-Reply-To: <20081220182254.GA2996@redhat.com>
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)
next prev parent reply other threads:[~2009-01-07 16:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 18:54 Dracut -- Cross distribution initramfs infrastructure Jeremy Katz
2008-12-17 19:07 ` Christoph Hellwig
2008-12-18 7:36 ` Hannes Reinecke
2008-12-19 7:41 ` Seewer Philippe
2008-12-19 8:18 ` Bernhard Walle
2008-12-19 13:55 ` Hannes Reinecke
2008-12-19 15:27 ` Theodore Tso
2008-12-19 16:56 ` Jeremy Katz
2008-12-20 13:50 ` Daniel Pittman
2008-12-20 18:22 ` Dave Jones
2009-01-07 16:04 ` Hannes Reinecke [this message]
2008-12-17 19:31 ` Neil Horman
2008-12-18 9:27 ` Loïc Grenié
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4964D2A2.2010109@suse.de \
--to=hare@suse.de \
--cc=daniel@rimspace.net \
--cc=davej@redhat.com \
--cc=initramfs@vger.kernel.org \
--cc=katzj@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox