Recently, Somebody Somewhere wrote these words
> Declan Moriarty wrote:
>
> >On the basis that udev-059 should have improved things, (but didn't);
> >udev-060 should have fixed that (but didn't); So udev-061 must work...
>
> And our survey said...."possibly not" :) Try udev-062!
Right!
Udev-062 went in (over a misbehaving udev-058). Over a couple of
reboots, I discovered the recovery procedure for udev.
It seems I had done a chroot into the new system, run udev, and then
shut down, or else the ramdisk failed to load, so I had a bucketful of
nodes in /dev.
/etc/rc.d/init.d/udev was crapping out quite early and noiselessly in
the script. This bit
start)
# Don't attempt to populate the /dev directory when
# something
# else has already set it up.
[ -f /dev/.udev.tdb ] && exit 0
is now deprecated as they have junked the database. It is also very weak
programming. ps -e |grep udev might be a better way to go about it, or
check for a few nodes that udev makes. The solution proved to be unmount
the ramdisk, rm -rf in dev/*, make nodes for console, and null, and
reboot.
What hapopens if the power fails on a udev enabled box :-o?
There is another catch. If hotplug is started, it tries to touch a file
/var/log/<something> but can't as the root filesystem is read only.
So now if I start hotplug, it loads radeonfb which gives me a gay screen
setting, gigabytes of overcurrent messages, and the cursor on all
screens. Why I can't land the cursor on all screens anyhow is beyond me,
but if Bill Gates thought us anything, it is that 'progress' isn't
always forward :-/. Why is it that the solution on this box is always
not to run hotplug?
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
