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