Re: udev in initrd

[Harald Hoyer <harald redhat com>]

Jeremy Katz wrote:
> What helpers specifically?  Can we simplify these to not require lots of
> additional tools?  Or use a scheme that doesn't require lots of
> different additional tools?  We don't necessarily have to support every
> conceivable naming scheme in the world for within the initrd.

right, but we have to give the user the freedom of choice here also.

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

well, /sbin/busybox and /sbin/busybox-initrd are linked dynamically to 
glibc. As I now recognized, that dietlibc is only available on i386, we 
may think of using klibc or pulling in the whole glibc (as we do on 
s390). More freedom in initrd is IMHO a good thing, and we really can 
spare some MB these days.

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

console, null, zero are not really needed, they get created by udev. If 
the loop kernel module would provide its kernel interfaces in /sys, then 
that would also be not necessary.
Why should we hide basic operations like
        ln -snf /proc/self/fd /dev/fd
        ln -snf /proc/self/fd/0 /dev/stdin
        ln -snf /proc/self/fd/1 /dev/stdout
        ln -snf /proc/self/fd/2 /dev/stderr
        ln -snf /proc/kcore /dev/core
behind some obscure compiled-in nash feature?

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

It does not brake root=LABEL, cause we patched busybox-mount to cope 
with mount-by-label. /dev/root is as ugly, as compiled-in nash device 
creating.

> > 8) mount system root on /sysroot
> > 9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
> > 10) change root to /sysroot and initrd to /sysroot/initrd
> > 11) umount /initrd/proc
> > 12) umount /initrd/dev [UDEV_KEEP_DEV="yes"]
>
>
> Having the case of using udev in your initrd but not using it for /dev
> on your installed system seems like a fairly ridiculous case that just
> complicates things.  Either you're using udev for the system or not.
> This then lets us drop out the /etc/sysconfig/udev handling from within
> mkinitrd.

Well, if you want persistent ownerships and special devices for which 
the kernel does not provide an interface, you may want to keep /dev on a 
harddisk. Freedom of choice again.

Harald

Attachment: signature.asc
Description: OpenPGP digital signature