Current status of dracut.

Current status of dracut.

[Dave Jones]

Things have gotten a little quiet on this front lately, so I thought
I'd drop a state-of-dracut report, and see if that spurs some discussion.

The current code at git://fedorapeople.org/~katzj/dracut.git
is just over 600 lines of shell script, and manages to generate an
initramfs capable of mount root filesystems on raw disk (/dev/sda etc),
and lvm (/dev/mapper/..)

It's also capable of encrypted root, using the plymouth graphical
stuff we have in Fedora.  As can be noted in the FIXME's, this is
currently hardcoded.

If for some reason the root fs cannot be mounted, it drops you
to a bash shell with some tools that may be useful for diagnostics.

Things that still need doing include, but are not limited to..

- thaw from hibernate support
- root on mdraid/dmraid
- get switchroot into util-linux (then nash can die forever)
- test generated initramfs works on other distros
  It'd be great to hear feedback on how people get on trying out
   what's there so far.
  There's definitly still some redhat'isms in there (*cough* libexec *cough*)
  that need to be conditionalised or eradicated.
- network root (nfs/nbd/iscsi)
- get 'make initrd' in the kernel
  My thinking on this one is to get something included fairly soon
  .30/.31 timeframe that just supports the disk based roots,
  and worry about network root later.
  At ~600 lines, it's fairly easy to come up to speed on it quickly.
  As it gets more featureful, this won't be the case.
  Also, going to lkml with "here's a few thousand lines of shell, please merge"
  probably isn't going to be met with a warm reception.

  One noticable change in development after this happens will be new
  changes going into a kernel git tree, instead of dracut.git
  It may still be useful to have the same changes going into a standalone tree,
  but I'll think that over some more when it happens.

	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: Current status of dracut.

[Dave Jones]

On Mon, Feb 02, 2009 at 11:37:08AM -0500, Dave Jones wrote:

 > Things that still need doing include, but are not limited to..
 > 

A few more things..

The current Fedora mkinitrd generates initrds in the ~3MB range.
A dracut generated image is ~17MB.
At least part of this problem is that we're including a ton of kernel
modules.  We could probably be smarter about our initial selection,
and trim out the really unlikely cases.
I think it's safe to say no-one cares about root on i2o for example.

The TODO in the git for some other pointed questions.

* NetworkManager vs dhclient for network based roots.
  I think the latter makes more sense, otherwise we end up
  sucking hal and all its dependancies into the image too.
  When the real rootfs starts up NM it should be able to dtrt.

* selinux policy loading.
  I don't think there's any real reason this has to be in the initrd.
  Though it means that either upstart or whatever init you use has to
  do it, or your /sbin/init needs to become

  #!/bin/sh
  /usr/sbin/loadpolicy
  /sbin/realinit

Thoughts?

Finally, the udev rules currently in dracut are kind of hacky.
It'd be good to just have a set of rules provided by the
system udev that we can drop in there.

	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: Current status of dracut.

[Thadeu Lima de Souza Cascardo]

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

On Mon, Feb 02, 2009 at 11:57:36AM -0500, Dave Jones wrote:
> * NetworkManager vs dhclient for network based roots.
>   I think the latter makes more sense, otherwise we end up
>   sucking hal and all its dependancies into the image too.
>   When the real rootfs starts up NM it should be able to dtrt.

Any reason why not to use kernel level autoconfiguration?

> 	Dave

Regards,
Cascardo.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Current status of dracut.

[Jeremy Katz]

On Monday, February 02 2009, Dave Jones said:

> On Mon, Feb 02, 2009 at 11:37:08AM -0500, Dave Jones wrote:
>  > Things that still need doing include, but are not limited to..
>  > 
> 
> A few more things..
> 
> The current Fedora mkinitrd generates initrds in the ~3MB range.
> A dracut generated image is ~17MB.

17?  I'm seeing along the lines of 7 on my box

> The TODO in the git for some other pointed questions.
> 
> * NetworkManager vs dhclient for network based roots.
>   I think the latter makes more sense, otherwise we end up
>   sucking hal and all its dependancies into the image too.
>   When the real rootfs starts up NM it should be able to dtrt.

The reason to use NetworkManager is so that the same configuration
engine, etc can be used as on the real system.  Otherwise, we're
Inventing Something Else (tm).

That said, I don't think that NetworkManager or its stack of deps are to
where they can sanely be used in the initramfs yet and it may be quite
some time before they are.
 
> * selinux policy loading.
>   I don't think there's any real reason this has to be in the initrd.
>   Though it means that either upstart or whatever init you use has to
>   do it, or your /sbin/init needs to become

Right.  /sbin/init had it with sysvinit, but Scott was against adding it
in upstart.  Feel free to restart that discussion

> Finally, the udev rules currently in dracut are kind of hacky.
> It'd be good to just have a set of rules provided by the
> system udev that we can drop in there.

Yep.  Kay and I had a very brief discussion about it before the
holidays.  And, eg, the dm/lvm rules that are there are almost entirely
there because those tools don't ship sane rules themselves.  If they
did, we could just suck them in.

I do think that there needs to be /lib/udev/initrules.d or similar to
say "these rules matter for booting" as opposed to the full set of rules
in /lib/udev or the hard-coded list of rules files currently present

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: Current status of dracut.

[Kay Sievers]

On Mon, Feb 2, 2009 at 20:50, Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Monday, February 02 2009, Dave Jones said:

>> Finally, the udev rules currently in dracut are kind of hacky.
>> It'd be good to just have a set of rules provided by the
>> system udev that we can drop in there.
>
> Yep.  Kay and I had a very brief discussion about it before the
> holidays.  And, eg, the dm/lvm rules that are there are almost entirely
> there because those tools don't ship sane rules themselves.  If they
> did, we could just suck them in.
>
> I do think that there needs to be /lib/udev/initrules.d or similar to
> say "these rules matter for booting" as opposed to the full set of rules
> in /lib/udev or the hard-coded list of rules files currently present

We are using the same rules as in the real root since we use udev in
initramfs. Only one initramfs specific rule is created on-the-fly by
the initramfs itself, based on the vales from the boot command line.

I'm not against adding such a directory, but what kind of rules do you
think would go there? I'm at the moment not sure, that they would need
to be different.

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: Current status of dracut.

[Dave Jones]

On Mon, Feb 02, 2009 at 09:09:16PM +0100, Kay Sievers wrote:

 > We are using the same rules as in the real root since we use udev in
 > initramfs. Only one initramfs specific rule is created on-the-fly by
 > the initramfs itself, based on the vales from the boot command line.
 > 
 > I'm not against adding such a directory, but what kind of rules do you
 > think would go there? I'm at the moment not sure, that they would need
 > to be different.

The LVM case for example, to auto-assemble volume groups.

What we have now is..

SUBSYSTEM!="block", GOTO="lvm_end"
ACTION!="add|change", GOTO="lvm_end"

KERNEL!="sr*", IMPORT{program}="vol_id --export $tempnode"
ENV{ID_FS_TYPE}=="LVM2_member", RUN+="/sbin/lvm vgscan", RUN+="/sbin/lvm vgchange -ay"

LABEL="lvm_end"

which isn't great..


dmraid is another case.

	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: Current status of dracut.

[Kay Sievers]

On Mon, Feb 2, 2009 at 21:14, Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, Feb 02, 2009 at 09:09:16PM +0100, Kay Sievers wrote:
>
>  > We are using the same rules as in the real root since we use udev in
>  > initramfs. Only one initramfs specific rule is created on-the-fly by
>  > the initramfs itself, based on the vales from the boot command line.
>  >
>  > I'm not against adding such a directory, but what kind of rules do you
>  > think would go there? I'm at the moment not sure, that they would need
>  > to be different.
>
> The LVM case for example, to auto-assemble volume groups.
>
> What we have now is..
>
> SUBSYSTEM!="block", GOTO="lvm_end"
> ACTION!="add|change", GOTO="lvm_end"
>
> KERNEL!="sr*", IMPORT{program}="vol_id --export $tempnode"
> ENV{ID_FS_TYPE}=="LVM2_member", RUN+="/sbin/lvm vgscan", RUN+="/sbin/lvm vgchange -ay"
>
> LABEL="lvm_end"
>
> which isn't great..
>
>
> dmraid is another case.

Yeah, but don't we want auto-assembly in the real rootfs too? Which
would be the same rules again in both cases.

Besides that we really want the dm guys to fix their stuff, to work
properly on modern systems, after all these years. :)

Cheers,
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: Current status of dracut.

[Dave Jones]

On Mon, Feb 02, 2009 at 02:50:09PM -0500, Jeremy Katz wrote:
 > On Monday, February 02 2009, Dave Jones said:
 > 
 > > On Mon, Feb 02, 2009 at 11:37:08AM -0500, Dave Jones wrote:
 > >  > Things that still need doing include, but are not limited to..
 > >  > 
 > > 
 > > A few more things..
 > > 
 > > The current Fedora mkinitrd generates initrds in the ~3MB range.
 > > A dracut generated image is ~17MB.
 > 
 > 17?  I'm seeing along the lines of 7 on my box

you're right.  I was looking at an ungzipped image.
 
 > > * selinux policy loading.
 > >   I don't think there's any real reason this has to be in the initrd.
 > >   Though it means that either upstart or whatever init you use has to
 > >   do it, or your /sbin/init needs to become
 > 
 > Right.  /sbin/init had it with sysvinit, but Scott was against adding it
 > in upstart.  Feel free to restart that discussion

with the two line init, upstart doesn't need to change
(other than the executable changing name).

 > > Finally, the udev rules currently in dracut are kind of hacky.
 > > It'd be good to just have a set of rules provided by the
 > > system udev that we can drop in there.
 > 
 > Yep.  Kay and I had a very brief discussion about it before the
 > holidays.  And, eg, the dm/lvm rules that are there are almost entirely
 > there because those tools don't ship sane rules themselves.  If they
 > did, we could just suck them in.

*nod*  The hack we have now isn't pretty, but works at least.

 > I do think that there needs to be /lib/udev/initrules.d or similar to
 > say "these rules matter for booting" as opposed to the full set of rules
 > in /lib/udev or the hard-coded list of rules files currently present

I'm curious if any other distros have already solved this and are
shipping rules that aren't upstream yet?

	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: Current status of dracut.

[Bill Nottingham]

Dave Jones (davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org) said: 
> * selinux policy loading.
>   I don't think there's any real reason this has to be in the initrd.
>   Though it means that either upstart or whatever init you use has to
>   do it, or your /sbin/init needs to become
> 
>   #!/bin/sh
>   /usr/sbin/loadpolicy
>   /sbin/realinit
> 
> Thoughts?

While you can do the latter, it means that init (whatever version)
is packaged differently on distros wheter or not they support
SELinux. That's a little bizarre.

Bill
--
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: Current status of dracut.

[Sam Ravnborg]

On Mon, Feb 02, 2009 at 11:37:08AM -0500, Dave Jones wrote:
> Things have gotten a little quiet on this front lately, so I thought
> I'd drop a state-of-dracut report, and see if that spurs some discussion.

How about sending commit mails to this list to make development
a bit more visible?

	Sam
--
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: Current status of dracut.

[Thiago Galesi]

>
> How about sending commit mails to this list to make development
> a bit more visible?

I second this! Will make things development to follow IMHO

-- 
-
Thiago Galesi
--
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: Current status of dracut.

[Dave Jones]

On Mon, Feb 02, 2009 at 05:16:05PM -0200, Thiago Galesi wrote:
 > >
 > > How about sending commit mails to this list to make development
 > > a bit more visible?
 > 
 > I second this! Will make things development to follow IMHO

I'll look into hooking this up.

	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: Current status of dracut.

[maximilian attems]

On Mon, Feb 02, 2009 at 11:37:08AM -0500, Dave Jones wrote:
> Things have gotten a little quiet on this front lately, so I thought
> I'd drop a state-of-dracut report, and see if that spurs some discussion.
 
how about sending a patch series so
one can do a proper review!?

it seems a bit to early to push it without anyone outside
having seen a bit.


--
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: Current status of dracut.

[Dave Jones]

On Mon, Feb 02, 2009 at 10:32:58PM +0100, maximilian attems wrote:
 > On Mon, Feb 02, 2009 at 11:37:08AM -0500, Dave Jones wrote:
 > > Things have gotten a little quiet on this front lately, so I thought
 > > I'd drop a state-of-dracut report, and see if that spurs some discussion.
 >  
 > how about sending a patch series so
 > one can do a proper review!?
 > 
 > it seems a bit to early to push it without anyone outside
 > having seen a bit.

'anyone outside' ? It's been public since day 1 at the git repo in the mail.

	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: Current status of dracut.

[maximilian attems]

On Mon, Feb 02, 2009 at 05:10:07PM -0500, Dave Jones wrote:
> 
> 'anyone outside' ? It's been public since day 1 at the git repo in the mail.
> 
as are all many other initramfs solutions.

no banana on this one.

-- 
maks
--
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: Current status of dracut.

[maximilian attems]

On Mon, 02 Feb 2009, Dave Jones wrote:

> The current code at git://fedorapeople.org/~katzj/dracut.git
> is just over 600 lines of shell script, and manages to generate an
> initramfs capable of mount root filesystems on raw disk (/dev/sda etc),
> and lvm (/dev/mapper/..)

btw why do we need dracut at all?
your blog has vague allusion against initramfs-tools,
which is much better tested and has seen the field.

beside having more features and flexibility it does not hardcode udev usage,
nor bash, why should it not be considered at first!?

# initramfs-tools repo
git clone git://git.debian.org/kernel/initramfs-tools.git
 
-- 
maks
--
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: Current status of dracut.

[Dave Jones]

On Mon, Feb 02, 2009 at 10:41:43PM +0100, maximilian attems wrote:
 > On Mon, 02 Feb 2009, Dave Jones wrote:
 > 
 > > The current code at git://fedorapeople.org/~katzj/dracut.git
 > > is just over 600 lines of shell script, and manages to generate an
 > > initramfs capable of mount root filesystems on raw disk (/dev/sda etc),
 > > and lvm (/dev/mapper/..)
 > 
 > btw why do we need dracut at all?
 > your blog has vague allusion against initramfs-tools,
 > which is much better tested and has seen the field.
 > 
 > beside having more features and flexibility it does not hardcode udev usage,
 > nor bash, why should it not be considered at first!?
 > 
 > # initramfs-tools repo
 > git clone git://git.debian.org/kernel/initramfs-tools.git
 >  
 > -- 
 > maks
---end quoted text---

"why not use the ubuntu one?"
"why not use the suse one?"

they all have some good and bad tradeoffs. Distro X has feature Y
which no-one else does. etc.

When the project began we spent some time looking at what everyone
else already does, and "lets start over and hope others participate"
seemed more attractive than taking an existing one and bending it to fit.

	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: Current status of dracut.

[maximilian attems]

On Mon, Feb 02, 2009 at 05:01:20PM -0500, Dave Jones wrote:
> 
> "why not use the ubuntu one?"

debian and ubuntu share the same codebase ;D
good question!

> "why not use the suse one?"

haha so you omit nash because it's no fun.
 
> they all have some good and bad tradeoffs. Distro X has feature Y
> which no-one else does. etc.

starting from zero was also the path that initramfs-tools took.
as initrd-tools written by Xu didn't scale up to all the new root ways.
the flexibility and framework is although much better thought,
it seems to me on a quick look.
 
> When the project began we spent some time looking at what everyone
> else already does, and "lets start over and hope others participate"
> seemed more attractive than taking an existing one and bending it to fit.

well
the trouble is dracut is carrying already some design decisions,
that make it currently a big nogo.

beside from formal questions as commit accesses to interested devs.

please be more precise what speaks against initramfs-tools.

-- 
maks
--
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