Re: Dracut -- Cross distribution initramfs infrastructure

Re: Dracut -- Cross distribution initramfs infrastructure

[Christoph Hellwig]

On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote:
> As davej started talking about a few months ago at Kernel Summit and
> LPC, there's a lot of duplication between distros on the tools used to
> generate the initramfs as well as the contents and how the initramfs
> works.  Ultimately, there's little reason for this not to be something
> that is shared and worked on by everyone.  Added to this is the fact
> that everyone's infrastructures for this have grown up over a long-ish
> period of time without significant amounts of reworking for the way that
> the kernel and early boot works these days.
> 
> Therefore I've started on a new project, dracut, to try to be a new
> initramfs tool that can be used across various distributions.  From the
> README...

It looks like Hannes has also been working on a new, modular initramfs
for a while:

	http://git.kernel.org/?p=linux/kernel/git/hare/mkinitrd.git;a=summary

I hope you guys can get together and agree on one implementation..
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Neil Horman]

On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote:
> As davej started talking about a few months ago at Kernel Summit and
> LPC, there's a lot of duplication between distros on the tools used to
> generate the initramfs as well as the contents and how the initramfs
> works.  Ultimately, there's little reason for this not to be something
> that is shared and worked on by everyone.  Added to this is the fact
> that everyone's infrastructures for this have grown up over a long-ish
> period of time without significant amounts of reworking for the way that
> the kernel and early boot works these days.
> 
> Therefore I've started on a new project, dracut, to try to be a new
> initramfs tool that can be used across various distributions.  From the
> README...
> 
> Unlike existing initramfs's, this is an attempt at having as little as
> possible hard-coded into the initramfs as possible.  The initramfs has
> (basically) one purpose in life -- getting the rootfs mounted so that we
> can transition to the real rootfs.  This is all driven off of device
> availability.  Therefore, instead of scripts hard-coded to do various
> things, we depend on udev to create device nodes for us and then when we
> have the rootfs's device node, we mount and carry on. This helps to keep
> the time required in the initramfs as little as possible so that things
> like a 5 second boot aren't made impossible as a result of the very
> existence of an initramfs.  It's likely that we'll grow some hooks for
> running arbitrary commands in the flow of the script, but it's worth
> trying to resist the urge as much as we can as hooks are guaranteed to
> be the path to slow-down.
> 
> Also, there is an attempt to keep things as distribution-agnostic as
> possible.  Every distribution has their own tool here and it's not
> something which is really interesting to have separate across them. So
> contributions to help decrease the distro-dependencies are welcome.
> 
> The git tree can be found at git://fedorapeople.org/~katzj/dracut.git
> for now.  See the TODO file for things which still need to be done and
> HACKING for some instructions on how to get started using the tool.
> There is also a mailing list that is being used for the discussion --
> initramfs-u79uwXL29TaiAVqoAR/hOA@public.gmane.org  
> 
> Currently, there are a few Fedora-isms which have crept in just as a
> result of it being the shortest path to solving some problems, but I'm
> actively trying to get those out sooner rather than later as well as
> getting to where I'm using it to boot my laptop.
> 
> Comments and discussion welcome
> 
> Jeremy
> 

Not that I don't think a unifying tool to create an initramfs is a bad idea
(quite the contrary, I think it would be great), but I'd like to point out that
one of your underlying premises is a bit shaky.  That an initramfs has one
purpose, that being to get the rootfs mounted, isn't entirely accurate.  Kdump
and various embedded systems being the prime examples here.  Many embedded
systems run entirely out of the initramfs, and contain all the code they need to
do so in them.  Additionally, kdump in most environments, attemps to capture
core files entirely from the initramfs as well, operating under the assumption
that the rootfs may not be functioning properly after a crash.  By and large
these initramfs images tend to be larger and offer a more typical (if not
standard) user operating environment.  I'm looking at your tree now, and it
looks like a good start on standardizing the initramfs for the nominal case.  Do
you have plans to include (or are you interested in including) support for
alternate infrastructure (like busybox instead of nash), interactive setup, etc?

Regards
Neil
 
-- 
/****************************************************
 * Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
 * Software Engineer, Red Hat
 ****************************************************/
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Hannes Reinecke]

Christoph Hellwig wrote:
> On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote:
>> As davej started talking about a few months ago at Kernel Summit and
>> LPC, there's a lot of duplication between distros on the tools used to
>> generate the initramfs as well as the contents and how the initramfs
>> works.  Ultimately, there's little reason for this not to be something
>> that is shared and worked on by everyone.  Added to this is the fact
>> that everyone's infrastructures for this have grown up over a long-ish
>> period of time without significant amounts of reworking for the way that
>> the kernel and early boot works these days.
>>
>> Therefore I've started on a new project, dracut, to try to be a new
>> initramfs tool that can be used across various distributions.  From the
>> README...
> 
> It looks like Hannes has also been working on a new, modular initramfs
> for a while:
> 
> 	http://git.kernel.org/?p=linux/kernel/git/hare/mkinitrd.git;a=summary
> 
> I hope you guys can get together and agree on one implementation..

Thanks hch for pointing this out.

We definitely should get together to hammer our one implementation.
Having different scripts for every distributions is a PITA.

I'm not saying my implementation is the greatest on earth, so
if anyone has any better suggestions I'm all ears.

If anyone is interested I can give a short overview of it.
As per normal, proper documentation is about to be written RSN.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +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 initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Jeremy Katz]

(dropping lkml again)

On Thu, 2008-12-18 at 08:36 +0100, Hannes Reinecke wrote:
> Christoph Hellwig wrote:
> > On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote:
> >> Therefore I've started on a new project, dracut, to try to be a new
> >> initramfs tool that can be used across various distributions.  From the
> >> README...
> > 
> > It looks like Hannes has also been working on a new, modular initramfs
> > for a while:
> > 
> > 	http://git.kernel.org/?p=linux/kernel/git/hare/mkinitrd.git;a=summary
> > 
> > I hope you guys can get together and agree on one implementation..
> 
> Thanks hch for pointing this out.
> 
> We definitely should get together to hammer our one implementation.
> Having different scripts for every distributions is a PITA.

Indeed -- but as davej noticed, going with one distro's implementation
is unlikely to fly and so we need to start over

> I'm not saying my implementation is the greatest on earth, so
> if anyone has any better suggestions I'm all ears.

I had actually looked at it some a couple of months ago when the
discussion started, but it looked like the same thing that an
initramfs/initrd has always been -- piles of shell scripts that are
strung together based on what the system building the initramfs looks
like.  The problem is that you then a) have a fair bit of system
dependence in the initramfs b) spend a lot of time running shell
scripts. 

By instead moving to where we're basing everything off of uevents we can
hopefully move away from the massive shell scripts of doom, speed up
boot and also maybe get to where a more general initramfs can be built
_with the kernel_ instead of per-system.

Jeremy

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Hannes Reinecke]

Hi Jeremy,

Jeremy Katz wrote:
> (dropping lkml again)
> 
> On Thu, 2008-12-18 at 08:36 +0100, Hannes Reinecke wrote:
>> We definitely should get together to hammer our one implementation.
>> Having different scripts for every distributions is a PITA.
> 
> Indeed -- but as davej noticed, going with one distro's implementation
> is unlikely to fly and so we need to start over
> 
>> I'm not saying my implementation is the greatest on earth, so
>> if anyone has any better suggestions I'm all ears.
> 
> I had actually looked at it some a couple of months ago when the
> discussion started, but it looked like the same thing that an
> initramfs/initrd has always been -- piles of shell scripts that are
> strung together based on what the system building the initramfs looks
> like.  The problem is that you then a) have a fair bit of system
> dependence in the initramfs b) spend a lot of time running shell
> scripts. 
> 
Granted for both points. However, I tried to get the information
from the running system by querying programs / sysfs directly and
_not_ relying on any configuration scripts. So that should alleviate
point a) slightly.
b) is, sadly, true.

> By instead moving to where we're basing everything off of uevents we can
> hopefully move away from the massive shell scripts of doom, speed up
> boot and also maybe get to where a more general initramfs can be built
> _with the kernel_ instead of per-system.
> 
Believe me, I tried. But it's _hard_, if not impossible.

One thing we should clarify, though:
What is the overall goal of dracut?
Should it create an streamlined initramfs, containing as little code
as possible and booting exactly on the system it was created on?
(IE creating a SUSE-style initramfs)
Or should it create a build-once-run-everywhere initramfs?

If you were going with the former, you face the challenge that you
have to initialize the root fs _only_, and skipping all other systems.
Hence you have the challenge to include the required udev rules only.
And, most obviously, you have to _detect_ the root fs. And make sure
to configure the underlying block devices properly.
And suddenly you end up with zillions of bash code, just to detect the
root fs.

If you were to go with the build-once-run-everywhere approach, you'd
have the advantage that you could copy the udev configuration over.
And in theory you could then configure the entire system with udev.
Well, after someone fixed up LVM to work properly with udev, that is.
But the problem here is: it's quite impractical to include support
for every possible configuration. Normal block devices, ok.
LVM, MD, sure. Multipath, yes, of course. iSCSI ... yes, but,
should we include _all_ NIC modules? Do we even _ship_ all of them?
And which network modules to we need? Netfilter? VPN support?

So either we include _all_ kernel modules (which consume at the
last count 82 MByte) or make a shortcut here and there.
Which goes against the initial goal of the build-once-run-everywhere
approach.

I do agree the latter approach is more appealing, but so
far I haven't found a proper solution for the kernel module
problem.

No, I favour a completely different approach: Link the required
modules into the kernel. 
When we run the mkinitrd prg (or whatever it's called) to create
the initrd, we will be detecting the modules which are required
to boot the kernel and mount the rootfs.
If it were now possible to link these modules into the kernel
directly via some 'ld' magic, we could get away with loading
just one kernel image without any initramfs. No modprobe,
nothing. That would be _fast_. And we would be having the
advantage that we could kexec into the 'normal' boot image
with initramfs if this 'single shot' approach doesn't work.

Oops. That was longer than expected. Anyway.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +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 initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Jeremy Katz]

On Dec 19, 2008, at 3:21 AM, Hannes Reinecke wrote:
> Jeremy Katz wrote:
>> (dropping lkml again)
>> On Thu, 2008-12-18 at 08:36 +0100, Hannes Reinecke wrote:
>> By instead moving to where we're basing everything off of uevents  
>> we can
>> hopefully move away from the massive shell scripts of doom, speed up
>> boot and also maybe get to where a more general initramfs can be  
>> built
>> _with the kernel_ instead of per-system.
> Believe me, I tried. But it's _hard_, if not impossible.

Nothing that's easy is fun or worth spending time on :-)

> One thing we should clarify, though:
> What is the overall goal of dracut?
> Should it create an streamlined initramfs, containing as little code
> as possible and booting exactly on the system it was created on?
> (IE creating a SUSE-style initramfs)
> Or should it create a build-once-run-everywhere initramfs?

Build-one-run-everywhere.  In fact, until yesterday, it really  
couldn't be built on the system it was to be booted on. :)

> If you were going with the former, you face the challenge that you
> have to initialize the root fs _only_, and skipping all other systems.
> Hence you have the challenge to include the required udev rules only.
> And, most obviously, you have to _detect_ the root fs. And make sure
> to configure the underlying block devices properly.
> And suddenly you end up with zillions of bash code, just to detect the
> root fs.

Yep.  I think we all know what this looks like

> If you were to go with the build-once-run-everywhere approach, you'd
> have the advantage that you could copy the udev configuration over.
> And in theory you could then configure the entire system with udev.
> Well, after someone fixed up LVM to work properly with udev, that is.
> But the problem here is: it's quite impractical to include support
> for every possible configuration. Normal block devices, ok.
> LVM, MD, sure. Multipath, yes, of course. iSCSI ... yes, but,
> should we include _all_ NIC modules? Do we even _ship_ all of them?
> And which network modules to we need? Netfilter? VPN support?

As my last mail said, I suspect that once we start talking about some  
of the network boot methods, you have to "buy-in" as they do have a  
non-trivial cost.  Including all the network modules, though, really  
isn't much worse than all the storage drivers.  Actually, I think it  
was better the last time I checked.

> So either we include _all_ kernel modules (which consume at the
> last count 82 MByte) or make a shortcut here and there.
> Which goes against the initial goal of the build-once-run-everywhere
> approach.

Well, you don't need _all_.  I've yet to come up with a convincing  
reason to want the sound drivers for example :)

And yes, everywhere is really more like everywhere(*) -- the stock  
config being "local block devices" but with the ability to expand out  
and support the more esoteric cases.

> I do agree the latter approach is more appealing, but so
> far I haven't found a proper solution for the kernel module
> problem.

Kernel modules compress well and modprobe supports loading gzipped  
modules.  That helps the size aspect at least somewhat

> No, I favour a completely different approach: Link the required
> modules into the kernel. When we run the mkinitrd prg (or whatever  
> it's called) to create
> the initrd, we will be detecting the modules which are required
> to boot the kernel and mount the rootfs.
> If it were now possible to link these modules into the kernel
> directly via some 'ld' magic, we could get away with loading
> just one kernel image without any initramfs. No modprobe,
> nothing. That would be _fast_. And we would be having the
> advantage that we could kexec into the 'normal' boot image
> with initramfs if this 'single shot' approach doesn't work.

You still have to have an initramfs as you aren't going to have the  
logic for LVM activation in the kernel.  Or to handle resume from  
hibernate.  Or dm-crypt.  Etc.  So an initramfs is really something  
akin to a requirement for non-trivial systems.  And the speed really  
isn't a fundamental factor of dealing with an initramfs.  I was  
actually quite surprised by how fast I was able to boot with a dracut- 
generated initramfs

Jeremy
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Seewer Philippe]

Jeremy Katz wrote:
[snip]
> Well, you don't need _all_.  I've yet to come up with a convincing 
> reason to want the sound drivers for example :)
Error messages read aloud? I've always wanted to hear 'kernel panic!' 
instead of just reading it :-)

> And yes, everywhere is really more like everywhere(*) -- the stock 
> config being "local block devices" but with the ability to expand out 
> and support the more esoteric cases.

Hmmm... if we are realle talking about integrating this _into_ the 
kernel why not introduce something like <Mi> "Build as module, integrate 
into initramfs?" into kernel config?

[snip]
>> No, I favour a completely different approach: Link the required
>> modules into the kernel. When we run the mkinitrd prg (or whatever 
>> it's called) to create
>> the initrd, we will be detecting the modules which are required
>> to boot the kernel and mount the rootfs.
>> If it were now possible to link these modules into the kernel
>> directly via some 'ld' magic, we could get away with loading
>> just one kernel image without any initramfs. No modprobe,
>> nothing. That would be _fast_. And we would be having the
>> advantage that we could kexec into the 'normal' boot image
>> with initramfs if this 'single shot' approach doesn't work.
> 
> You still have to have an initramfs as you aren't going to have the 
> logic for LVM activation in the kernel.  Or to handle resume from 
> hibernate.  Or dm-crypt.  Etc.  So an initramfs is really something akin 
> to a requirement for non-trivial systems.  And the speed really isn't a 
> fundamental factor of dealing with an initramfs.  I was actually quite 
> surprised by how fast I was able to boot with a dracut-generated initramfs

To be honest I'd really like some magic to tie a module back into the 
kernel for really fast bootup.

On the other hand, "early-userspace" is necessary as stated. As a 
further suggestion: Why not restrict initramfs really to the "only 
mount-/" problem domain. On failures or errors, a fallback ram-image 
could be used and switchroot'ed into normally like any other root which 
would then do the job. I think this would solve the 
busybox/user-needs-shell problem as well, which could reside in the 
ram-image.


Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Jeremy Katz]

On Dec 19, 2008, at 3:05 PM, Seewer Philippe wrote:
> Jeremy Katz wrote:
> [snip]
>>
>> And yes, everywhere is really more like everywhere(*) -- the stock  
>> config being "local block devices" but with the ability to expand  
>> out and support the more esoteric cases.
>
> Hmmm... if we are realle talking about integrating this _into_ the  
> kernel why not introduce something like <Mi> "Build as module,  
> integrate into initramfs?" into kernel config?

Mostly because we have to walk before we can run. :)

> [snip]
> On the other hand, "early-userspace" is necessary as stated. As a  
> further suggestion: Why not restrict initramfs really to the "only  
> mount-/" problem domain. On failures or errors, a fallback ram-image  
> could be used and switchroot'ed into normally like any other root  
> which would then do the job. I think this would solve the busybox/ 
> user-needs-shell problem as well, which could reside in the ram-image.

I've similarly thought that this could be a good way to take care of  
things like the kdump case which while they use an initramfs are  
really a more specialized install image that should be mounted as a  
rootfs.

Jeremy
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Till Maas]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

On Friday 19 December 2008 21:05:18 Seewer Philippe wrote:
> Jeremy Katz wrote:
> [snip]
>
> > Well, you don't need _all_.  I've yet to come up with a convincing
> > reason to want the sound drivers for example :)
>
> Error messages read aloud? I've always wanted to hear 'kernel panic!'
> instead of just reading it :-)

This may be also helpful for blind people.

Regards,
Till

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: Dracut -- Cross distribution initramfs infrastructure

[Hannes Reinecke]

Hi Jeremy,

Jeremy Katz wrote:
> On Dec 19, 2008, at 3:21 AM, Hannes Reinecke wrote:
>> Jeremy Katz wrote:
>>> (dropping lkml again)
>>> On Thu, 2008-12-18 at 08:36 +0100, Hannes Reinecke wrote:
>>> By instead moving to where we're basing everything off of uevents we can
>>> hopefully move away from the massive shell scripts of doom, speed up
>>> boot and also maybe get to where a more general initramfs can be built
>>> _with the kernel_ instead of per-system.
>> Believe me, I tried. But it's _hard_, if not impossible.
> 
> Nothing that's easy is fun or worth spending time on :-)
> 
Truly spoken :-)

>> One thing we should clarify, though:
>> What is the overall goal of dracut?
>> Should it create an streamlined initramfs, containing as little code
>> as possible and booting exactly on the system it was created on?
>> (IE creating a SUSE-style initramfs)
>> Or should it create a build-once-run-everywhere initramfs?
> 
> Build-one-run-everywhere.  In fact, until yesterday, it really couldn't 
> be built on the system it was to be booted on. :)
> 
Ah.

>> If you were going with the former, you face the challenge that you
>> have to initialize the root fs _only_, and skipping all other systems.
>> Hence you have the challenge to include the required udev rules only.
>> And, most obviously, you have to _detect_ the root fs. And make sure
>> to configure the underlying block devices properly.
>> And suddenly you end up with zillions of bash code, just to detect the
>> root fs.
> 
> Yep.  I think we all know what this looks like
> 
Indeed.

>> If you were to go with the build-once-run-everywhere approach, you'd
>> have the advantage that you could copy the udev configuration over.
>> And in theory you could then configure the entire system with udev.
>> Well, after someone fixed up LVM to work properly with udev, that is.
>> But the problem here is: it's quite impractical to include support
>> for every possible configuration. Normal block devices, ok.
>> LVM, MD, sure. Multipath, yes, of course. iSCSI ... yes, but,
>> should we include _all_ NIC modules? Do we even _ship_ all of them?
>> And which network modules to we need? Netfilter? VPN support?
> 
> As my last mail said, I suspect that once we start talking about some of 
> the network boot methods, you have to "buy-in" as they do have a 
> non-trivial cost.  Including all the network modules, though, really 
> isn't much worse than all the storage drivers.  Actually, I think it was 
> better the last time I checked.
> 
>> So either we include _all_ kernel modules (which consume at the
>> last count 82 MByte) or make a shortcut here and there.
>> Which goes against the initial goal of the build-once-run-everywhere
>> approach.
> 
> Well, you don't need _all_.  I've yet to come up with a convincing 
> reason to want the sound drivers for example :)
> 
Don't let this hear the folks from disability support :-)
For the same reason I've ended up having to include USB
modules as occasionally someone has to enter a password
and might have a USB keybord.

And I'm quite convinced you can find a setup for nearly
every driver included in the kernel.

And as you admitted we won't be including _all_ modules,
so we don't _actually_ support the 'built-once-run-everywhere'
approach.

So we should be focussing on the 'build-once-run-mostly-everywhere'
approach to enable the trivial systems to boot.
And add a API / Extension something for the non-trivial systems.

> And yes, everywhere is really more like everywhere(*) -- the stock 
> config being "local block devices" but with the ability to expand out 
> and support the more esoteric cases.
> 
>> I do agree the latter approach is more appealing, but so
>> far I haven't found a proper solution for the kernel module
>> problem.
> 
> Kernel modules compress well and modprobe supports loading gzipped 
> modules.  That helps the size aspect at least somewhat
> 
Agreed.

>> No, I favour a completely different approach: Link the required
>> modules into the kernel. When we run the mkinitrd prg (or whatever 
>> it's called) to create
>> the initrd, we will be detecting the modules which are required
>> to boot the kernel and mount the rootfs.
>> If it were now possible to link these modules into the kernel
>> directly via some 'ld' magic, we could get away with loading
>> just one kernel image without any initramfs. No modprobe,
>> nothing. That would be _fast_. And we would be having the
>> advantage that we could kexec into the 'normal' boot image
>> with initramfs if this 'single shot' approach doesn't work.
> 
> You still have to have an initramfs as you aren't going to have the 
> logic for LVM activation in the kernel.  Or to handle resume from 
> hibernate.  Or dm-crypt.  Etc.  So an initramfs is really something akin 
> to a requirement for non-trivial systems.  And the speed really isn't a 
> fundamental factor of dealing with an initramfs.  I was actually quite 
> surprised by how fast I was able to boot with a dracut-generated initramfs
> 
No, you don't. Those systems I'd consider non-trivial and should be handled
from a 'real' initramfs.
The trivial system would be one where just loading a module will make the device
appear (ie simple ATA / SCSI systems).

Once you need something more or different you'll have to use a proper initramfs.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +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 initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Seewer Philippe]

Hannes Reinecke wrote:
[snip]
> If anyone is interested I can give a short overview of it.
Please do so, would be appreciated.

Cheers,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Bernhard Walle]

* Seewer Philippe [2008-12-19 08:41]:
>
> Hannes Reinecke wrote:
> [snip]
> > If anyone is interested I can give a short overview of it.
> Please do so, would be appreciated.

A good start is the manual page in section 5:
http://git.opensuse.org/?p=projects/mkinitrd.git;a=blob_plain;f=man/mkinitrd.5.txt;hb=7583c3cc047edc3e8f1a06e8b7925bd27ac0228c

(The git.kernel.org and the opensuse.org repos are basically the same,
we just switched to opensuse.org after the internal maintainership has
been transferred from Hannes to myself because it was easier to add
new users there. The opensuse.org git repo site didn't exist when the
kernel.org mkinitrd repo was created.)

Anyway:

The basic idea is to have most stuff not in the main 'mkinitrd' script
but in modules. Each module has (normally) a setup script part that is
executed when the initrd is created, and a boot part that is executed
when the initrd is running. For example, NFS root is in the 'nfs-util'
package, not in 'mkinitrd'. Same for iSCSI. Or the kdump part is
not in the main mkinitrd but in our 'kdump' package [1]. So the main
initrd  package is quite small but still very flexible.

It's also flexible enough to use Busybox as module that resides in the
'busybox' package and can then be enabled with -F busybox (feature)
when building the initrd.

Only documentation is at the current time a bit weak, one has to fiddle
some stuff from the sources when writing new modules. But that's easy
to fix. :-)

Hannes may explain more ...



    Bernhard

[1] hg clone http://freehg.org/u/bwalle/kdump/
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Hannes Reinecke]

Hi all,

Bernhard Walle wrote:
> * Seewer Philippe [2008-12-19 08:41]:
>> Hannes Reinecke wrote:
>> [snip]
>>> If anyone is interested I can give a short overview of it.
>> Please do so, would be appreciated.
> 
> A good start is the manual page in section 5:
> http://git.opensuse.org/?p=projects/mkinitrd.git;a=blob_plain;f=man/mkinitrd.5.txt;hb=7583c3cc047edc3e8f1a06e8b7925bd27ac0228c
> 
> (The git.kernel.org and the opensuse.org repos are basically the same,
> we just switched to opensuse.org after the internal maintainership has
> been transferred from Hannes to myself because it was easier to add
> new users there. The opensuse.org git repo site didn't exist when the
> kernel.org mkinitrd repo was created.)
> 
> Anyway:
> 
> The basic idea is to have most stuff not in the main 'mkinitrd' script
> but in modules. Each module has (normally) a setup script part that is
> executed when the initrd is created, and a boot part that is executed
> when the initrd is running. For example, NFS root is in the 'nfs-util'
> package, not in 'mkinitrd'. Same for iSCSI. Or the kdump part is
> not in the main mkinitrd but in our 'kdump' package [1]. So the main
> initrd  package is quite small but still very flexible.
> 
> It's also flexible enough to use Busybox as module that resides in the
> 'busybox' package and can then be enabled with -F busybox (feature)
> when building the initrd.
> 
> Only documentation is at the current time a bit weak, one has to fiddle
> some stuff from the sources when writing new modules. But that's easy
> to fix. :-)
> 
> Hannes may explain more ...
> 
Yes, quite so. The design principles are as follows:

The goal of the initrd is to activate and mount the root fs.
And the root fs _only_. Every other system should be configured
once the main system is running.

So mkinitrd has two parts:
a) Detect the configuration of the rootfs and create the
   initramfs
b) Configure the rootfs on boot.

Therefore there are two distinct script types:

setup-XXX.sh - run during initrd creation time to detect
  and record the configuration

boot-XXX.sh - run during boot to configure the subsystem

The setup scripts have these tasks:
- Detect the rootfs
- Unwind the storage stack and record the configuration
  on each level
- Copy the required contents into the initramfs
- Pack initramfs for use

The boot scripts have these tasks:
- Initial configuration (create required device nodes, start udev)
- Configure the storage stack
- fsck and mount the root fs

So basically the boot scripts have to be called in reverse
order to the setup scripts.
To ensure the order is preserved during each run I've
introduced some 'stages', which are run consecutively.
These stages are documented in mkinitrd.5

The neat thing here is that we've split off each
configuration into small scripts, which will be called
if present. This allows for a pretty modular setup
and avoid the massive requirement setting of an
monolithic script.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +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 initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Theodore Tso]

On Fri, Dec 19, 2008 at 02:55:26PM +0100, Hannes Reinecke wrote:
>
> The goal of the initrd is to activate and mount the root fs.
> And the root fs _only_. Every other system should be configured
> once the main system is running.

Don't forget resuming from hibernation....

And of course, activating and mounting the root filesystem can be
quite complicated --- it can involve loading driver modules,
activiating md and/or lvm, prompting for a password, setting up
networking (dhcp, routing, dns) for iSCSI and/or NFS/AFS/Lustre/et.al,
the equivalent setup for Fiber Channel attached disks, etc.  If
there's any cryptography involved, the user may need to be prompted
for a password and/or key and/or fingerprint scan to unlock TPM unit
to access the key, etc.

There may also be times when it is useful to operate on the root
filesystem in some way before it is mounted; in most cases the
operation can bedone on a filesystem mounted read-only, yes --- but at
the cost of needing to reboot afterwards if the root filesystem needs
to be modified by said userspace tool.

Finally, note that part the discussion at the Kernel Summit, and also
what David Jones was looking to work at, was to do something that
could included as part of the kernel sources.  The idea is that as
responsibility for early boot is moved from the kernel, an mkinitramfs
which is fixed and distributed by the distribution might not work with
a newer kernel.org kernel.  So the idea that was explored was adding a
common mkinitramfs with basic functionality into kernel sources, with
the ability for distributions to add various "value add" enhancements
if they like.  This way if the kernel wants to move more functionality
(for example, in the area of resuming from hibernation) out of the
kernel into initramfs, it can do so without breaking the ability of
older distributions from being able to use kernel.org kernels.

So IMHO, it's important not only that the distributions standardize on
a single initramfs framework, but that framework get integrated into
the kernel sources.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Jeremy Katz]

On Dec 19, 2008, at 10:27 AM, Theodore Tso wrote:
> On Fri, Dec 19, 2008 at 02:55:26PM +0100, Hannes Reinecke wrote:
>>
>> The goal of the initrd is to activate and mount the root fs.
>> And the root fs _only_. Every other system should be configured
>> once the main system is running.
>
> Don't forget resuming from hibernation....

I haven't, although I haven't sat down to implement it yet.

> And of course, activating and mounting the root filesystem can be
> quite complicated --- it can involve loading driver modules,
> activiating md and/or lvm, prompting for a password, setting up
> networking (dhcp, routing, dns) for iSCSI and/or NFS/AFS/Lustre/et.al,
> the equivalent setup for Fiber Channel attached disks, etc.  If
> there's any cryptography involved, the user may need to be prompted
> for a password and/or key and/or fingerprint scan to unlock TPM unit
> to access the key, etc.

Well, driver modules should be being loaded by udev.  Period.  If  
something requires a manual modprobe, that's a bug IMHO.  The other  
stuff, while non-trivial, is surprisingly doable from udev rules.

> There may also be times when it is useful to operate on the root
> filesystem in some way before it is mounted; in most cases the
> operation can bedone on a filesystem mounted read-only, yes --- but at
> the cost of needing to reboot afterwards if the root filesystem needs
> to be modified by said userspace tool.

I think that once you start getting into this realm, though, you end  
up with an incredibly over-complicated and slow initramfs.  If we  
instead focus on keeping things "fast", the reboot afterwards isn't  
that costly.

> Finally, note that part the discussion at the Kernel Summit, and also
> what David Jones was looking to work at, was to do something that
> could included as part of the kernel sources.  The idea is that as
> responsibility for early boot is moved from the kernel, an mkinitramfs
> which is fixed and distributed by the distribution might not work with
> a newer kernel.org kernel.  So the idea that was explored was adding a
> common mkinitramfs with basic functionality into kernel sources, with
> the ability for distributions to add various "value add" enhancements
> if they like.  This way if the kernel wants to move more functionality
> (for example, in the area of resuming from hibernation) out of the
> kernel into initramfs, it can do so without breaking the ability of
> older distributions from being able to use kernel.org kernels.
>
> So IMHO, it's important not only that the distributions standardize on
> a single initramfs framework, but that framework get integrated into
> the kernel sources.

Yeah, Dave and I have talked a fair bit about that.  It's just  
significantly easier to get something going _outside_ of the kernel  
sources and then work towards integrating it.  The plus side of  
integrating it is that the existing bits to generate a built-in  
initramfs can go away.

Jeremy
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Daniel Pittman]

Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> On Dec 19, 2008, at 10:27 AM, Theodore Tso wrote:
>> On Fri, Dec 19, 2008 at 02:55:26PM +0100, Hannes Reinecke wrote:
>>>
>>> The goal of the initrd is to activate and mount the root fs.
>>> And the root fs _only_. Every other system should be configured
>>> once the main system is running.

[...]

>> There may also be times when it is useful to operate on the root
>> filesystem in some way before it is mounted; in most cases the
>> operation can bedone on a filesystem mounted read-only, yes --- but at
>> the cost of needing to reboot afterwards if the root filesystem needs
>> to be modified by said userspace tool.
>
> I think that once you start getting into this realm, though, you end
> up with an incredibly over-complicated and slow initramfs.  If we
> instead focus on keeping things "fast", the reboot afterwards isn't
> that costly.

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.

(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...)


So, it would certainly be my hope — with my systems administration hat
on — that your proposed system would support that similar operation as
an option, at least.

Personally, I think it makes the right default: better correct than
fast, but obviously tastes vary there.

Regards,
        Daniel
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Dave Jones]

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.

 > (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.

	Dave

-- 
http://www.codemonkey.org.uk
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: Dracut -- Cross distribution initramfs infrastructure

[Jeremy Katz]

(Removing lkml from the cc)

On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote:
> Not that I don't think a unifying tool to create an initramfs is a bad idea
> (quite the contrary, I think it would be great), but I'd like to point out that
> one of your underlying premises is a bit shaky.  That an initramfs has one
> purpose, that being to get the rootfs mounted, isn't entirely accurate.  Kdump
> and various embedded systems being the prime examples here.  Many embedded
> systems run entirely out of the initramfs, and contain all the code they need to
> do so in them.  Additionally, kdump in most environments, attemps to capture
> core files entirely from the initramfs as well, operating under the assumption
> that the rootfs may not be functioning properly after a crash.  By and large
> these initramfs images tend to be larger and offer a more typical (if not
> standard) user operating environment.  

While I'd like to think that embedded systems are not going to do
something custom, you, I and everyone else know that's unlikely. ;-)

The kdump case is one that I think is at least reasonable to get to
eventually (and also, installer initramfsen), but I think that getting
the cases of "initramfs for booting a system" consolidated first makes
the most sense.  

> I'm looking at your tree now, and it
> looks like a good start on standardizing the initramfs for the nominal case.  Do
> you have plans to include (or are you interested in including) support for
> alternate infrastructure (like busybox instead of nash), interactive setup, etc?

Well, the use of nash right now is due to the fact that there isn't
historically any switchroot utility shipped in util-linux.  Hopefully
we'll get something there and then the only user of nash that's there
right now can go away.  

busybox, etc are really all just extra pain as compared to using real
system utilities... once you accept that you're dynamically linked,
you're better off just maintaining one set of the utilities as opposed
to having one set in coreutils and one set in busybox.

Jeremy

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Neil Horman]

On Wed, Dec 17, 2008 at 02:48:29PM -0500, Jeremy Katz wrote:
> (Removing lkml from the cc)
> 
> On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote:
> > Not that I don't think a unifying tool to create an initramfs is a bad idea
> > (quite the contrary, I think it would be great), but I'd like to point out that
> > one of your underlying premises is a bit shaky.  That an initramfs has one
> > purpose, that being to get the rootfs mounted, isn't entirely accurate.  Kdump
> > and various embedded systems being the prime examples here.  Many embedded
> > systems run entirely out of the initramfs, and contain all the code they need to
> > do so in them.  Additionally, kdump in most environments, attemps to capture
> > core files entirely from the initramfs as well, operating under the assumption
> > that the rootfs may not be functioning properly after a crash.  By and large
> > these initramfs images tend to be larger and offer a more typical (if not
> > standard) user operating environment.  
> 
> While I'd like to think that embedded systems are not going to do
> something custom, you, I and everyone else know that's unlikely. ;-)
> 
Agreed :)

> The kdump case is one that I think is at least reasonable to get to
> eventually (and also, installer initramfsen), but I think that getting
> the cases of "initramfs for booting a system" consolidated first makes
> the most sense.  
> 
Absolutely, thats fine with me.  I just didn't want everyone to assume that
getting to the rootfs was the only thing that initramfs' did.  Adding kdump
support later is well and good. 


> > I'm looking at your tree now, and it
> > looks like a good start on standardizing the initramfs for the nominal case.  Do
> > you have plans to include (or are you interested in including) support for
> > alternate infrastructure (like busybox instead of nash), interactive setup, etc?
> 
> Well, the use of nash right now is due to the fact that there isn't
> historically any switchroot utility shipped in util-linux.  Hopefully
> we'll get something there and then the only user of nash that's there
> right now can go away.  
> 
Thats true, and a small part of the reason that most kdump implementations use
busybox.

> busybox, etc are really all just extra pain as compared to using real
> system utilities... once you accept that you're dynamically linked,
> you're better off just maintaining one set of the utilities as opposed
> to having one set in coreutils and one set in busybox.
> 
I'm not so sure I agree with that, but I'll not turn this thread into that
argument :).  Suffice it to say, That if we can cram ifconfig, sed, awk, lsmod,
modprobe, bash, cp, grep, reboot, halt, ps, kill, and pivot_root and a few other
utils into less than 1.8MB of space, switching might be worthwhile.

Neil

> Jeremy
> 
> 

-- 
/****************************************************
 * Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
 * Software Engineer, Red Hat
 ****************************************************/

Re: Dracut -- Cross distribution initramfs infrastructure

[Kay Sievers]

On Wed, Dec 17, 2008 at 20:48, Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote:
>> Not that I don't think a unifying tool to create an initramfs is a bad idea
>> (quite the contrary, I think it would be great), but I'd like to point out that
>> one of your underlying premises is a bit shaky.  That an initramfs has one
>> purpose, that being to get the rootfs mounted, isn't entirely accurate.  Kdump
>> and various embedded systems being the prime examples here.  Many embedded
>> systems run entirely out of the initramfs, and contain all the code they need to
>> do so in them.  Additionally, kdump in most environments, attemps to capture
>> core files entirely from the initramfs as well, operating under the assumption
>> that the rootfs may not be functioning properly after a crash.  By and large
>> these initramfs images tend to be larger and offer a more typical (if not
>> standard) user operating environment.
>
> While I'd like to think that embedded systems are not going to do
> something custom, you, I and everyone else know that's unlikely. ;-)
>
> The kdump case is one that I think is at least reasonable to get to
> eventually (and also, installer initramfsen), but I think that getting
> the cases of "initramfs for booting a system" consolidated first makes
> the most sense.

Maybe Bernhard Walle, who currently maintains the SUSE initramfs, can
possibly take care of that. He's is working on kdump stuff.

>> I'm looking at your tree now, and it
>> looks like a good start on standardizing the initramfs for the nominal case.  Do
>> you have plans to include (or are you interested in including) support for
>> alternate infrastructure (like busybox instead of nash), interactive setup, etc?
>
> Well, the use of nash right now is due to the fact that there isn't
> historically any switchroot utility shipped in util-linux.  Hopefully
> we'll get something there and then the only user of nash that's there
> right now can go away.

SUSE uses a small binary run-init copied from klibc:
  http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/kinit/run-init/run-init.c;hb=HEAD
 Maybe it's time to add something like that to util-linux? Karel?

> busybox, etc are really all just extra pain as compared to using real
> system utilities... once you accept that you're dynamically linked,
> you're better off just maintaining one set of the utilities as opposed
> to having one set in coreutils and one set in busybox.

Busybox is nice as an option to be able to rescue/hack. It should
definitely be provided as an optional "plugin" for people who need it.
But there is no chance to depend on it by default, for the very same
reason klibc, or any other libc is not an option.

Full-featured distros who make their money with support, can just not
afford to support tools compiled differently from the tools in the
real rootfs. SUSE used klibc for one release, and stopped doing that
immediately, because you go crazy if you run into problems with bootup
problems on cutomer setups you can not reproduce with the tools from
the real rootfs.

We need to use tools in initramfs which will not work realibly, or not
at all, with other libcs. We will have one dynamic glibc there anyway,
so there is no valid reason to also use any single statically linked
binary, or any other libc by default. Really, it's just nice to use
the same environment in the real root and in initramfs, and you also
get the smallest possible size that way, if you need to include only a
single "advanced" tool.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Neil Horman]

On Wed, Dec 17, 2008 at 09:29:51PM +0100, Kay Sievers wrote:
> On Wed, Dec 17, 2008 at 20:48, Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote:
> >> Not that I don't think a unifying tool to create an initramfs is a bad idea
> >> (quite the contrary, I think it would be great), but I'd like to point out that
> >> one of your underlying premises is a bit shaky.  That an initramfs has one
> >> purpose, that being to get the rootfs mounted, isn't entirely accurate.  Kdump
> >> and various embedded systems being the prime examples here.  Many embedded
> >> systems run entirely out of the initramfs, and contain all the code they need to
> >> do so in them.  Additionally, kdump in most environments, attemps to capture
> >> core files entirely from the initramfs as well, operating under the assumption
> >> that the rootfs may not be functioning properly after a crash.  By and large
> >> these initramfs images tend to be larger and offer a more typical (if not
> >> standard) user operating environment.
> >
> > While I'd like to think that embedded systems are not going to do
> > something custom, you, I and everyone else know that's unlikely. ;-)
> >
> > The kdump case is one that I think is at least reasonable to get to
> > eventually (and also, installer initramfsen), but I think that getting
> > the cases of "initramfs for booting a system" consolidated first makes
> > the most sense.
> 
> Maybe Bernhard Walle, who currently maintains the SUSE initramfs, can
> possibly take care of that. He's is working on kdump stuff.
> 
I do to, thats why I brought it up :)

> >> I'm looking at your tree now, and it
> >> looks like a good start on standardizing the initramfs for the nominal case.  Do
> >> you have plans to include (or are you interested in including) support for
> >> alternate infrastructure (like busybox instead of nash), interactive setup, etc?
> >
> > Well, the use of nash right now is due to the fact that there isn't
> > historically any switchroot utility shipped in util-linux.  Hopefully
> > we'll get something there and then the only user of nash that's there
> > right now can go away.
> 
> SUSE uses a small binary run-init copied from klibc:
>   http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/kinit/run-init/run-init.c;hb=HEAD
>  Maybe it's time to add something like that to util-linux? Karel?
> 
> > busybox, etc are really all just extra pain as compared to using real
> > system utilities... once you accept that you're dynamically linked,
> > you're better off just maintaining one set of the utilities as opposed
> > to having one set in coreutils and one set in busybox.
> 
> Busybox is nice as an option to be able to rescue/hack. It should
> definitely be provided as an optional "plugin" for people who need it.
> But there is no chance to depend on it by default, for the very same
> reason klibc, or any other libc is not an option.
> 
> Full-featured distros who make their money with support, can just not
> afford to support tools compiled differently from the tools in the
> real rootfs. SUSE used klibc for one release, and stopped doing that
> immediately, because you go crazy if you run into problems with bootup
> problems on cutomer setups you can not reproduce with the tools from
> the real rootfs.
> 
This is all hyperbolie.  Yes, its nice to be able to use the same tools and the
same environment, but busybox works perfectly well in a kdump environment.  I've
used busybox in Fedora and RHEL, and since RHEL5 and FC-6 shipped, I've
encounted I think 3 bugs that dealt with minor differences in how busybox worked
from the rootfs tools

> We need to use tools in initramfs which will not work realibly, or not
> at all, with other libcs. We will have one dynamic glibc there anyway,
> so there is no valid reason to also use any single statically linked
> binary, or any other libc by default. Really, it's just nice to use
> the same environment in the real root and in initramfs, and you also
> get the smallest possible size that way, if you need to include only a
> single "advanced" tool.
> 
busybox is dynamically linked now too, so C library issues are irrelevant at
this point.  And busybox provides, at my last count 255 utilities in the Fedora
build.  Compare that to the cumulative size of all the corresponding individual
utilities and see who comes out taking up less space.

Neil

> Thanks,
> Kay
> 

-- 
/****************************************************
 * Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
 * Software Engineer, Red Hat
 ****************************************************/
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[David Zeuthen]

On Wed, 2008-12-17 at 16:06 -0500, Neil Horman wrote:
> > Busybox is nice as an option to be able to rescue/hack. It should
> > definitely be provided as an optional "plugin" for people who need it.
> > But there is no chance to depend on it by default, for the very same
> > reason klibc, or any other libc is not an option.
> > 
> > Full-featured distros who make their money with support, can just not
> > afford to support tools compiled differently from the tools in the
> > real rootfs. SUSE used klibc for one release, and stopped doing that
> > immediately, because you go crazy if you run into problems with bootup
> > problems on cutomer setups you can not reproduce with the tools from
> > the real rootfs.
> > 
> This is all hyperbolie.  

Hardly. Having to support two different C libraries in a real production
environment, for reasons like "just because we can" and "it's about
freedom" is not something I ever want this project to see or support. In
there lies madness.

FWIW, as Kay said, it's fine to have an unsupported "--with-busybox" or
whatever option but please don't think that people using it can expect
any kind of real support or attention to their bug reports.

     David

Re: Dracut -- Cross distribution initramfs infrastructure

[Neil Horman]

On Wed, Dec 17, 2008 at 04:15:07PM -0500, David Zeuthen wrote:
> On Wed, 2008-12-17 at 16:06 -0500, Neil Horman wrote:
> > > Busybox is nice as an option to be able to rescue/hack. It should
> > > definitely be provided as an optional "plugin" for people who need it.
> > > But there is no chance to depend on it by default, for the very same
> > > reason klibc, or any other libc is not an option.
> > > 
> > > Full-featured distros who make their money with support, can just not
> > > afford to support tools compiled differently from the tools in the
> > > real rootfs. SUSE used klibc for one release, and stopped doing that
> > > immediately, because you go crazy if you run into problems with bootup
> > > problems on cutomer setups you can not reproduce with the tools from
> > > the real rootfs.
> > > 
> > This is all hyperbolie.  
> 
> Hardly. Having to support two different C libraries in a real production
> environment, for reasons like "just because we can" and "it's about
> freedom" is not something I ever want this project to see or support. In
> there lies madness.
> 
Either I wasn't clear, or you didn't read closely enough.  I don't use two
different c libraries, We use the same C library everywhere, busybox included.
Which is not to say you have to do that.  You can certainly use a different
library, and I agree with you there, to use two different C libraries in the
same system is rather insane.  But I don't do that, and unless you are _that_
constrained for space, you don't need to.

> FWIW, as Kay said, it's fine to have an unsupported "--with-busybox" or
> whatever option but please don't think that people using it can expect
> any kind of real support or attention to their bug reports.
> 
Seea above.
>      David
> 
> 
> 

-- 
/****************************************************
 * Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
 * Software Engineer, Red Hat
 ****************************************************/

Re: Dracut -- Cross distribution initramfs infrastructure

[Karel Zak]

On Wed, Dec 17, 2008 at 09:29:51PM +0100, Kay Sievers wrote:
> On Wed, Dec 17, 2008 at 20:48, Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote:
> >> Not that I don't think a unifying tool to create an initramfs is a bad idea

 I'm personally very happy to see that someone is trying to work on
 distro-independent solution. Really.

> >> looks like a good start on standardizing the initramfs for the nominal case.  Do
> >> you have plans to include (or are you interested in including) support for
> >> alternate infrastructure (like busybox instead of nash), interactive setup, etc?
> >
> > Well, the use of nash right now is due to the fact that there isn't
> > historically any switchroot utility shipped in util-linux.  Hopefully

 util-linux-ng is open for arbitrary low-level stuff that makes sense
 for more distributions.

> > busybox, etc are really all just extra pain as compared to using real
> > system utilities... once you accept that you're dynamically linked,
> > you're better off just maintaining one set of the utilities as opposed
> > to having one set in coreutils and one set in busybox.
> 
> Busybox is nice as an option to be able to rescue/hack. It should
> definitely be provided as an optional "plugin" for people who need it.
> But there is no chance to depend on it by default, for the very same
> reason klibc, or any other libc is not an option.

 Note, some tools from uti-linux-ng is possible to link against klibc,
 and the whole package should be possible to rebuild on systems with
 uClibc, but the official goal is glibc.

> We need to use tools in initramfs which will not work realibly, or not
> at all, with other libcs. We will have one dynamic glibc there anyway,
> so there is no valid reason to also use any single statically linked
> binary, or any other libc by default. Really, it's just nice to use
> the same environment in the real root and in initramfs, and you also
> get the smallest possible size that way, if you need to include only a
> single "advanced" tool.

 Yeah.

 I don't like nash too much (sorry RH:-). The single "advanced" tools
 usually suck in mainstream distributions -- it's a way how duplicate
 code, how maintain two different environments, etc... My tiny network
 router uses busybox, but I don't think that my workstation with 2GB
 of RAM has to use a special single "advanced" tool when my
 distribution includes coreutils, util-linux and udev.

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut -- Cross distribution initramfs infrastructure

[Loïc Grenié]

2008/12/17 Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>:
> On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote:

[snip]

>> Therefore I've started on a new project, dracut, to try to be a new
>> initramfs tool that can be used across various distributions.  From the
>> README...
>>
>> Unlike existing initramfs's, this is an attempt at having as little as
>> possible hard-coded into the initramfs as possible.  The initramfs has
>> (basically) one purpose in life -- getting the rootfs mounted so that we
>> can transition to the real rootfs.

[snip]

> Not that I don't think a unifying tool to create an initramfs is a bad idea
> (quite the contrary, I think it would be great), but I'd like to point out that
> one of your underlying premises is a bit shaky.  That an initramfs has one
> purpose, that being to get the rootfs mounted, isn't entirely accurate.  Kdump
> and various embedded systems being the prime examples here.  Many embedded
> systems run entirely out of the initramfs, and contain all the code they need to
> do so in them.  Additionally, kdump in most environments, attemps to capture
> core files entirely from the initramfs as well, operating under the assumption
> that the rootfs may not be functioning properly after a crash.  By and large
> these initramfs images tend to be larger and offer a more typical (if not
> standard) user operating environment.  I'm looking at your tree now, and it
> looks like a good start on standardizing the initramfs for the nominal case.  Do
> you have plans to include (or are you interested in including) support for
> alternate infrastructure (like busybox instead of nash), interactive setup, etc?

    Seconded: as a user of (various) distributions, I've come across
the following
  problem: sometimes the initramfs, for whatever reason, does not manage to
  find or mount the rootfs. In those cases I hate the developpers of
the distribution
  because there is basically nothing that can be done in the initramfs
to see, test,
  try, mount, modprobe, umount, ping, telnet, etc... Please, please, throw in a
  full-featured busybox. Here is a good compromise I use:

Currently defined functions:
        [, [[, arp, arping, ash, awk, basename, brctl, bunzip2, bzcat,
        bzip2, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp, comm,
        cp, cpio, cut, date, dc, dd, deallocvt, depmod, df, diff, dirname,
        dmesg, dos2unix, dpkg, dpkg-deb, du, dumpkmap, echo, egrep, eject,
        env, expr, false, fbset, fdflush, fdformat, fdisk, fgrep, find,
        findfs, ftpget, ftpput, grep, gunzip, gzip, halt, head, hexdump,
        hostname, hwclock, ifconfig, ifenslave, insmod, ip, ipcalc, kbd_mode,
        kill, killall, killall5, less, linux32, linux64, ln, loadfont,
        loadkmap, losetup, ls, lsmod, md5sum, microcom, mkdir, mkfifo,
        mknod, mkswap, mktemp, more, mount, mv, nice, od, openvt, patch,
        pgrep, pidof, ping, ping6, pivot_root, pkill, poweroff, printf,
        ps, pwd, readlink, reboot, reset, rm, rmdir, rmmod, route, rpm2cpio,
        rtcwake, sed, setarch, setkeycodes, sh, sha1sum, sleep, sort,
        stat, strings, stty, su, swapoff, swapon, switch_root, sync, tac,
        tail, tar, tee, telnet, test, touch, tr, traceroute, true, tty,
        udhcpc, umount, uname, uniq, unix2dos, unzip, vi, wc, wget, which,
        xargs, yes, zcat

  (linux32 and linux64 are probably not useful for general initramfs). With that
  configuration, busybox (v1.13.0.svn, x86-32 executable) is 416224 bytes long
  (dynamically linked with libc as only library needed).

          Loïc Grenié
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dracut -- Cross distribution initramfs infrastructure

[Jeremy Katz]

As davej started talking about a few months ago at Kernel Summit and
LPC, there's a lot of duplication between distros on the tools used to
generate the initramfs as well as the contents and how the initramfs
works.  Ultimately, there's little reason for this not to be something
that is shared and worked on by everyone.  Added to this is the fact
that everyone's infrastructures for this have grown up over a long-ish
period of time without significant amounts of reworking for the way that
the kernel and early boot works these days.

Therefore I've started on a new project, dracut, to try to be a new
initramfs tool that can be used across various distributions.  From the
README...

Unlike existing initramfs's, this is an attempt at having as little as
possible hard-coded into the initramfs as possible.  The initramfs has
(basically) one purpose in life -- getting the rootfs mounted so that we
can transition to the real rootfs.  This is all driven off of device
availability.  Therefore, instead of scripts hard-coded to do various
things, we depend on udev to create device nodes for us and then when we
have the rootfs's device node, we mount and carry on. This helps to keep
the time required in the initramfs as little as possible so that things
like a 5 second boot aren't made impossible as a result of the very
existence of an initramfs.  It's likely that we'll grow some hooks for
running arbitrary commands in the flow of the script, but it's worth
trying to resist the urge as much as we can as hooks are guaranteed to
be the path to slow-down.

Also, there is an attempt to keep things as distribution-agnostic as
possible.  Every distribution has their own tool here and it's not
something which is really interesting to have separate across them. So
contributions to help decrease the distro-dependencies are welcome.

The git tree can be found at git://fedorapeople.org/~katzj/dracut.git
for now.  See the TODO file for things which still need to be done and
HACKING for some instructions on how to get started using the tool.
There is also a mailing list that is being used for the discussion --
initramfs-u79uwXL29TaiAVqoAR/hOA@public.gmane.org  

Currently, there are a few Fedora-isms which have crept in just as a
result of it being the shortest path to solving some problems, but I'm
actively trying to get those out sooner rather than later as well as
getting to where I'm using it to boot my laptop.

Comments and discussion welcome

Jeremy

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html