Current status of dracut.
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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Dave Jones
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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Dave Jones
* 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?
Quoted 1 line
Dave
Regards,
Cascardo.
Quoted 8 lines · Dave Jones
Quoted 2 lines · Dave Jones
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
Quoted 6 lines
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.
Quoted 4 lines
* 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/initneeds to become
Right. /sbin/init had it with sysvinit, but Scott was against adding it in upstart. Feel free to restart that discussion
Quoted 3 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Jeremy Katz
Quoted 3 lines · Dave Jones
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.
Quoted 8 lines
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.dor similar to say "these rules matter for booting" as opposed to the full set of rules in/lib/udevor 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): ac3eb2510902021209j2de84cc7ue4538b3685d071e5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 7 lines · Kay Sievers
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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 20 lines · Dave Jones
Quoted 7 lines · Kay Sievers
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"
Quoted 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Jeremy Katz
Quoted 4 lines · Dave Jones
Quoted 2 lines · Dave Jones
Things that still need doing include, but are not limited to..
Quoted 6 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 4 lines
* 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/initneeds to becomeRight.
/sbin/inithad 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).
Quoted 8 lines
Quoted 3 lines
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.
Quoted 3 lines
I do think that there needs to be
/lib/udev/initrules.dor similar to say "these rules matter for booting" as opposed to the full set of rules in/lib/udevor 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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · Dave Jones
* 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/initneeds to become#!/bin/sh
/usr/sbin/loadpolicy
/sbin/realinitThoughts?
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · 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.
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20090202174600.GA7193-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org
Quoted 3 lines
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
Signature · 6 lines
- Thiago Galesi -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 82ecf08e0902021116v592da5aye9f20d545d0be06e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 5 lines · Thiago Galesi
Quoted 3 lines
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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · 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.
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · maximilian attems
Quoted 2 lines · 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.
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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Dave Jones
'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.
Signature · 5 lines
maks -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines · Dave Jones
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/sdaetc), 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
Signature · 5 lines
maks -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · maximilian attems
Quoted 4 lines · Dave Jones
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/sdaetc), 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.
Quoted 8 lines
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.gitSignature · 1 line
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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Dave Jones
"why not use the ubuntu one?"
debian and ubuntu share the same codebase ;D
good question!
Quoted 1 line
"why not use the suse one?"
haha so you omit nash because it's no fun.
Quoted 2 lines
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.
Quoted 3 lines
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.
Signature · 5 lines
maks -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html