udev in initrd

[Jeremy Katz]

So, I've sat down and spent a while looking at this and looking at udev
itself.  I still think that udev could be simpler by dictating policies
and not leaving everything up in the air for the user to decide, but I'm
tired of having that argument as it's seemingly a dead end at this
point.

On Fri, 2004-07-09 at 15:31 +0200, Thomas Woerner wrote:
> This is a minimal version without udev-persistent support and no busybox. It is using 
> the normal nash initrd environment.

This looks a lot better to me.  A couple of patches are missing on the
mkinitrd side to a) add bind mount support to nash and b) to use nash
mount properly.  Attached the patch to this mail (mkinitrd-
bindmount.patch).

> - To use udev in initrd, set USE_UDEV and UDEV_INITRD in /etc/sysconfig/udev.
>    udev will then use the normal /dev directory and will generate devices in there.

If we're putting the patches in and we want udev to be the default,
let's go ahead and set it up as such.

> - To get this ramfs /dev to your system, set UDEV_KEEP_DEV. Setting UDEV_KEEP_DEV
>    also sets UDEV_RAMFS. /dev will be bind-mounted to your root directory, then.
>    - Unset udev_owner in /etc/udev/udev.conf to get normal persimissions. Newer udev
>      packages are not setting device ownerships or permissions, if the device already
>      exists. But this is needed if you are keeping your /dev, because udev will
>      generate devices with root ownership (there is no other user in initrd) and
>      udevstart in rc.sysinit will not set correct permissions, then.

The same is true with these.

Further improvements/enhancements that I think are really needed to make
this more robust and more integrated.  

* Having all of the udev scripts getting copied as part of the mkinitrd
seems like it has a probability of causing spurious warnings/failures.
Luckily, this isn't needed and we can just do the next bit (which I'd
still like to lose, but could live with)
* Changing the mkinitrd copying to just copy /etc/udev/udev.conf seems
to work, but I'd really like to avoid that copy if we can.  Can we have
udev default to our defaults so that we're a bit more robust (and then I
can avoid copying the config file).  Also, this could help avoid some
strange user experiences if the file disappears for whatever reason.
* I think that leaving the standard device creation for the /dev of the
initrd even if using udev is probably not completely crazy.  Then, if
udev fails for some reason, you might still have a chance of things
working.  We could add a simple testCommand to nash and then only do
this if some obvious, always created dev node from udev didn't get
created if we want to avoid doing it always (/dev/ram0 springs to mind
since if you're in an initrd, you obviously have to have ramdisk
support)
* Why is the creation of /dev/fd, /dev/stdin, /dev/stdout, /dev/kcore,
etc duplicated between mkinitrd and start_udev?  Both run udevstart and
I don't see a real reason why we can't just have udevstart make these
links and reduce a little bit of duplication.
* The pam_console_setowner stuff really needs to just be a patch to
pam_console_apply and then use that.  Otherwise, we have a second copy
of that code to maintain and fix bugs in.  Nalin didn't seem against
this when I mentioned it to him at dinner
* Any reason why udevstart can't be done after rhgb starts to avoid text
seen before the graphical boot?
* I'd rather not use klibc if we can help it.  Mostly because
maintaining another libc strikes me as a poor idea (I want to get rid of
dietlibc :)  Ironically, both udevstart and udev are slightly smaller
when statically linked with glibc instead of klibc.
* Not really necessary, but some people might appreciate a "don't create
device nodes" option and then just keep using their static /dev.
Obviously, this would imply UDEV_INITRD=no.  Also, if we're buying into
a dynamic, this isn't going to be the default.
* The duplication between /etc/udev/udev.conf and /etc/sysconfig/udev
strikes me as a potential source of confusion.  The config files are
roughly the same syntax, let's just use one of them (and then we can
have the other be a symlink if we really feel it's necessary, but I'd
lean against not).  

None of these looks particularly difficult to implement, but it's after
midnight and I'm not sure if I'll get any further before going to bed
and wanted to get this out tonight.  If no one else does, I'll probably
look at a few of them tomorrow.

There are also going to be other things that I'm sure are going to start
breaking...  I know there are places where we rely on "access device,
autoload module" working that are likely to break (sound and some
operations with loopback devices off the top of my head, probably
others).  Not sure what to do about these cases at the moment.  And I'm
completely staying away from the persistent names for right now; let's
get the simple case first and then we can go back and forth about
persistent names :)

Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkinitrd-bindmount.patch
Type: text/x-patch
Size: 1372 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040714/ce8ce3d8/attachment.bin>