public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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)

  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