All of lore.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:04 UTC|newest]

Thread overview: 39+ 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
     [not found]     ` <4949FD67.6040906-l3A5Bk7waGM@public.gmane.org>
2008-12-18 20:12       ` Jeremy Katz
     [not found]         ` <1229631131.13174.23.camel-T9xAYgMuJli44ywRPIzf9A@public.gmane.org>
2008-12-19  8:21           ` Hannes Reinecke
     [not found]             ` <494B5979.3080606-l3A5Bk7waGM@public.gmane.org>
2008-12-19 17:08               ` Jeremy Katz
     [not found]                 ` <44C50A6A-0FDB-4BF0-8B8B-CD9DAC7B7ED4-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-19 20:05                   ` Seewer Philippe
     [not found]                     ` <494BFE7E.8090301-omB+W0Dpw2o@public.gmane.org>
2008-12-19 20:41                       ` Jeremy Katz
2008-12-23 11:32                       ` Till Maas
2009-01-07 16:14                   ` Hannes Reinecke
2008-12-19  7:41       ` Seewer Philippe
2008-12-19  7:41         ` Seewer Philippe
     [not found]         ` <494B5031.5080306-omB+W0Dpw2o@public.gmane.org>
2008-12-19  8:18           ` Bernhard Walle
2008-12-19  8:18             ` Bernhard Walle
     [not found]             ` <20081219091841.207bc951-Hxm9IJOWyO+kWa+peg0mPg@public.gmane.org>
2008-12-19 13:55               ` Hannes Reinecke
2008-12-19 13:55                 ` Hannes Reinecke
     [not found]                 ` <494BA7CE.2020007-l3A5Bk7waGM@public.gmane.org>
2008-12-19 15:27                   ` Theodore Tso
2008-12-19 15:27                     ` Theodore Tso
     [not found]                     ` <20081219152708.GE9871-3s7WtUTddSA@public.gmane.org>
2008-12-19 16:56                       ` Jeremy Katz
2008-12-19 16:56                         ` Jeremy Katz
     [not found]                         ` <9C4F1B7D-CCBC-48D7-8624-9A7C314C1590-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-20 13:50                           ` Daniel Pittman
2008-12-20 13:50                             ` Daniel Pittman
     [not found]                             ` <87skojrm5e.fsf-zvVxMF7wGoXk1uMJSBkQmQ@public.gmane.org>
2008-12-20 18:22                               ` Dave Jones
2008-12-20 18:22                                 ` Dave Jones
2009-01-07 16:04                                 ` Hannes Reinecke [this message]
     [not found]   ` <20081217190700.GA15377-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2008-12-18  7:36     ` Hannes Reinecke
2008-12-17 19:31 ` Neil Horman
2008-12-18  9:27   ` Loïc Grenié
     [not found]   ` <20081217193151.GA7356-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2008-12-17 19:48     ` Jeremy Katz
     [not found]       ` <1229543309.28858.163.camel-T9xAYgMuJli44ywRPIzf9A@public.gmane.org>
2008-12-17 20:17         ` Neil Horman
2008-12-17 20:29         ` Kay Sievers
     [not found]           ` <ac3eb2510812171229g57eee496o6ad9e2fa97609455-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-17 21:06             ` Neil Horman
     [not found]               ` <20081217210645.GC7356-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2008-12-17 21:15                 ` David Zeuthen
     [not found]                   ` <1229548507.1229.4.camel-v34h5/LVXhbZaaYASwVUlg@public.gmane.org>
2008-12-17 21:22                     ` Neil Horman
2008-12-18 14:07             ` Karel Zak
2008-12-18  9:27     ` Loïc Grenié
     [not found] ` <1229540094.28858.150.camel-T9xAYgMuJli44ywRPIzf9A@public.gmane.org>
2008-12-17 19:07   ` Christoph Hellwig
2008-12-17 19:31   ` Neil Horman
  -- strict thread matches above, loose matches on Subject: below --
2008-12-17 18:54 Jeremy Katz

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.