When the kernel prints out this message:
hde: hde1 < hde5 hde6 hde7 hde8 hde9 hde10 hde11 >
That indicates that it has a device driver that is prepared to access the internal hard disk as a block device, and it knows about the partitions. That's good!
However, a userspace program that wants to access one of those devices, say for example "mount," needs to access the device using a node file like /dev/hde11 (because that's how device drivers in UNIX systems are invoked, by accessing node files. Well, or running ioctls. Never mind about that.)
We can either create /dev/hde11 ourselves, manually; or we can use udev. Udev is awesome, and we have to set it up for the final system anyway, so maybe it would be a good idea to include it in ssbl as well.
The way udev works is: you start a daemon called udevd, which listens for "netlink uevents" from the kernel driver core...these events are apparently dispatched over a UNIX domain socket. Looking at the udev man pages (got the udev source handy? look in $UDEV_SOURCE_DIR/udev for the man pages udev.7, udevadm.8, udevd.8), it looks like the process we want is something like:
- start "udevd --daemon" so that it is listening for kernel events and will handle them.
- run "udevadm trigger" which will ask the kernel to please send event messages for all devices it currently knows about -- because at the time the kernel first sent out the events, udevd was not running and they fell on the floor.
- At this point, udevd starts busily creating device nodes based on the rules in /etc/udev.d or whatever, so a naive observer would think "excellent, time to proceed with my important init script work!"...BUT a slightly less naive observer would say "what happens if udevd hasn't gotten around to creating /dev/hde11 by the time that the init script tries to mount it?" -- Aha, good point, there's a race condition. So:
- run "udevadm settle" which blocks until all events have been handled.
- kill udevd so that no userspace programs started in SSBL are still running when we pole-vault into the final system.
- proceed with the business of mounting the real root fs...
Looking at the udev readme, we need to ensure that the kernel has sysfs, unix domain sockets, and networking all enabled. /proc and /sys have to be mounted with those specific names. These group names must exist in the SSBL /etc/group:
disk cdrom floppy tape audio video lp tty dialout kmem
...probably it would be a good idea for you to stop reading this page and go read the udev readme and man pages...so to encourage you to do this, I shall stop writing.