On Tue, 2005-07-12 at 12:41 +0100, Declan Moriarty wrote: > 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.
Ok, yes, that makes sense in hindsight - you've effectively been running a static /dev. I'm guessing the DVD drive wasn't installed at the time the entries were created, or maybe you just didn't have the ide-cd driver built. > /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. My understanding from what was said on the HAL list is that they're not scrapping the database entirely, they're just drastically reducing the amount of stuff put in it. So, the absence of the .udev.tbd directory may not be a reliable indicator - it might be that udev hasn't run yet, or it could be it had nothing it wanted to store. Still, the script probably should at least print out a notification message, rather than exit silently and pretend everything was fine. > What hapopens if the power fails on a udev enabled box :-o? Exactly the same as any time the box is shut down, I should think. Remember, all of /dev is maintained in RAM on the tmpfs mount, so it's automatically cleaned up as soon as the machine powers off. I've been in that position quite a few times lately while trying to get a wireless card working (drivers causing lockups), and never had any problems with udev. Simon.
signature.asc
Description: This is a digitally signed message part
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
