udev in initrd

[Jeremy Katz]

On Wed, 2004-07-14 at 11:33 +0200, Harald Hoyer wrote:
> Jeremy Katz wrote:
> > 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).
> 
> I think, I sent the bind patch to you months ago :)

Yeah, I thought I had remembered seeing something but wasn't sure.  It
wasn't in this set of patches at least, so I just quickly did it
again :)

> > Further improvements/enhancements that I think are really needed to make
> > this more robust and more integrated.  
> > 
> > * 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)
> 
> Hmm, ok.

Keep in mind I'm paranoid about initrd failures and they're nearly
impossible to debug.  So as much as I can foolproof against the kernel
or some utility changing out from under me, the happier I am.  I'll go
ahead and do this piece later today.

> > * 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.
> 
> Haven't tested it, but /sbin/init and rc.sysinit prior to start_udev may need some of these?

Right, but we run udevstart in the initrd, too.  So if the code to
create them is all in udevstart (and we have rc.sysinit call udevstart
instead of the start_udev wrapper), then everything should still get
created at the same times and not have any newer problems.  Or if it
can, I'm missing something entirely (not impossible)

> > * 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
> 
> would be cool!

Okay -- do you want to look at this or would you rather I do so?

> > * Any reason why udevstart can't be done after rhgb starts to avoid text
> > seen before the graphical boot?
> 
> You may see some udev messages, if root is mounted (ro) at the time modules are loaded,
> which trigger hotplug events.

Right, but for udev to be set as the hotplug handler, then it got set
from the initrd and you're using a ramfs dev.  In which case /dev is not
going to be read-only.  Do you have an example case?  And the downside
here is that it makes the rhgb details pop open instead of remaining
hidden?

It just seems a shame to be adding more messages that are going to be
potentially confusing before rhgb starts up.  It also makes it look like
something is broken since you get the console font loading ([OK]), then
welcome to fedora, then starting udev ([ok]).  The space between these
just looks and feels awkward.

> > * 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.
> 
> huh?
> /sbin/udev.glibc.static 488096
> /sbin/udev.klibc.static  58056

Hrmm, I wonder what was up with my build last night.  Still doesn't seem
implausible to do glibc instead of klibc.

> plus
> /home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-add.c:250: warning: Using
>   'getgrnam' in statically linked applications requires at runtime the shared li
> braries from the glibc version used for linking
> udev-add.o(.text+0x5ce):/home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-a
> dd.c:236: warning: Using 'getpwnam' in statically linked applications requires
> at runtime the shared libraries from the glibc version used for linking
> 
> ok, these could be patched out...

Yeah, no reason the static version really has to have these.  Or the
errors can be ignored (the shared libs are only needed for complex NSS
stuff)

> > * 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).
> 
> Thought about that, too. Sounds ok to me, as long as /etc/udev/udev.conf
> is sourceable by bash.

Looks like it is and that you already made this change.

Jeremy