convert flat /dev/ to dynamic udev, Eeek!

Debian 4.0 just made "stable." In 3.1 we had the traditional /dev directory with a node for every device you might ever need, simple but inefficient. Kernel.org told us about two years ago they would move to a dynamic /dev, mounted in a tmpfs, with device nodes created on demand by a udevd daemon responding to "device events" from the kernel. This means you can't boot straight to root on a hard disk any more: with udev you have to use an initial RAMdisk file system image. If you install Debian 4.0 fresh, you get a udev system. A custom initrd.img-2.6 is created when you install the kernel from the linux-image-2.6 package, and update-grub knows what to do about it.

Replacing one Debian base with the next, on a working system, is called dist-upgrade. Debian boasts you can do it remotely, with only one reboot, and no other downtime. Therefore if you do everything "the Debian Way" and make no mistakes, you never have to reinstall, and you never have to touch the machine again except to change the hardware.

Four out of five of my Debian systems went through dist-upgrade properly. I did it through SSH, without ever touching the consoles, just to make sure it worked. (Can you do that with MS-Windows?) The fifth machine has an unused disk controller in a PCI slot, and this caused udev to assign different names to the drives than they had before. Initrd.img has the old names in it, because the old system built it. Apparently I lucked out the first four times. When the fifth machine boots, kernel can't find root, and panics. Luckily I kept the old kernel and my static /dev directory, and 4.0 runs well enough on that.

Folks over in debian-user advise to lock down the device assignments using unique drive identifiers fished out of the device info in /proc or /sys (or from /dev/disk/by-uuid/ on a live-CD that uses udev). The identifiers go in /etc/fstab and /boot/grub/menu.lst instead of the traditional device names.

This is totally user-unfriendly. I can't imagine any of my customers getting though it, or even trying to walk them through it on the phone. What's supposed to happen to a udev system when you add in a disk controller? The installer doesn't lock the names down. So I wonder how the user-friendly Debian-derived systems like PClinuxOS and Ubuntu handled the transition. Are you running udevd with a bunch of static /dev/ nodes just in case? In your /boot/grub/menu.lst kernel lines, is root a device name or some other identifier?