udev in initrd

Thomas Woerner twoerner at redhat.com
Wed Jun 2 10:33:07 UTC 2004


Jeremy Katz wrote:
> On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote:
> 
>>There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
>>udev in initrd with persistent devices.
> 
> 
> Note, all of my comments here are just from looking at the changes and
> not actually trying them yet.  I'll try to get to that later tonight,
> though.
> 

Have you tried it out, yet? :-)

> 
>>Thus the new mkinitrd is using busybox for the initrd with udev support. 
>>Disabling udev results in a normal initrd with nash. It is easy to modify 
>>mkinitrd to build the normal initrd with busybox.
> 
> 
> Hmmm, this uglifies mkinitrd a lot.  Having two completely separate
> paths for the initrd is completely unmaintainable for the long-term.  I
> think that I'd rather cut the busybox down to just the minimal set of
> tools needed and then still use nash as the base shell.  And actually,
> getting it so that we're using the main busybox instead of
> busybox-initrd would be nice (I need to look at the anaconda specific
> config differences so that I can try to merge those to not require a
> weird subpackage).  This would be especially as there are a few
> "features" in nash that aren't going to be in a standard shell (things
> like handling of quiet mode, the simple mkdmnod present, etc)
> 

This is a test package. I patched mkinitrd to use busybox for udev support
only, the non-udev version is the working fallback for the user.

nash is not needed anymore with busybox::ash and busybox::linuxrc. Why using 
and maintaining an own tool if there is nearly the same in busybox, already?

> 
>>udev initrd - using busybox and ramfs
>>-------------------------------------
>>1) mount /proc and /sys
>>2) mount /dev as ramfs
>>3) create initial devices (eg: console, null, zero, loopX) and links for std
>>    files
> 
> 
> This looks/feels a little ugly.  But there's probably some shell that
> could make it a little bit cleaner.
> 

Why not make this transparent for the user? It is not useful to hide this 
information - it is not a secret.

> 
>>4) start udev, use udevsend as hotplug
>>5) load modules (eg. controller, filesystem)
>>6) umount /sys
>>7) locate root device
> 
> 
> I don't like this at all.  For one thing, doesn't it currently break
> with root=LABEL=/?  Is there a reason not to just use /dev/root here as
> we currently do?
> 

/dev/root might be nice to look at, but it is not necessary and transparent at 
all. The real boot device is available and can be used directly. LABEL=X is 
also supported in the busybox::mount test version.


Thomas

-- 
Thomas Woerner, Software Developer     Phone: +49-711-96437-0
Red Hat GmbH                           Fax  : +49-711-96437-111
Hauptstaetterstr. 58                   Email: twoerner at redhat.com
D-70178 Stuttgart                      Web  : http://www.redhat.de/





More information about the fedora-devel-list mailing list