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
