> Yep, I know it. > > Add udev to make-fai-nfsroot.conf. In sid udev is creating the > devices in /dev. Currently it seems that FAI has a minor bug, because > we use /etc/init.d/udev start to start the udev daemon, but since > start-stop-daemon is faked by fai it will not start at all.
I'm not sure if that's solution. udev is Kernel 2.6 only, and I need to have kernel 2.4 because of some ancient SCO software that I run, which run's under iBCS, which is kernel 2.4 only. So adding udev to the packages would populate the /dev of the FAI CD, but would it populate the /dev of the target? My trick to use copy a "bigger" devices.tar.gz to my fai-server helped me making the FAI CD work. But to get the devices into the kernel 2.4 target, I added the devices.tar.gz also to /usr/local/share/fai/files and added this scripts/10-devices: --------------------------- #!/bin/sh set -x cd $target tar xzf /fai/files/devices.tar.gz test -e $target/dev/hda || \ $ROOTCMD sh -c "cd /dev; ./MAKEDEV generic-i386" exit 0 --------------------------- I also have a 10-install-packages, which, besides other things, install the kernel-image-2.6.27-2-686. The populated /tmp/target/dev device must exist at this time, because the postinst script of this .deb calls mkinitrd, which wants to have a /dev/hda. All of this hackery make me wonder if the "add udev" would help me to get /dev populated both in the FAI CD and in the target. However, *IF* adding udev is the solution to the problem, then this bug is still valid, the fai-server shipped "make-fai-nfsroot.conf" file should should then mention udev :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]