-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Kulzer wrote:
> If that is your only example, then you should change your vote to: > > | particularly hated; massive nuisance causing data loss and grief: > | the modern Linux kernel!!! (asynchronous device discovery) > > Here is a simple test to demonstrate that udev takes over the name that > the kernel chooses: > > $ udevadm test $(udevadm info --query=path --name /dev/sda) | grep get_name > udev_rules_get_name: add symlink 'disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0' > udev_rules_get_name: no node name set, will use kernel name 'sda' Good point, well taken; and thank you, Florian. I love it when I'm no longer believing something that isn't true. Therefore, I wish to retract a number of my UDEV rants over the past few years :-) And I'll change my whinage to something about the scan order in the kernel. I know something had do be done to deal with changing times, and asynchronous discovery is way cool, but stuff inside the box oughta come first. And the names should stay put after the install, not just after the boot (the installer could create some UDEV rules??). It'd also be nice if the names were predictable, and maybe even had some mnemonic value. I don't think this is too much to ask... At the time of my misadventure, I was still expecting sda to be the lowest ID on the lowest SCSI bus -- there were no SATAs at the time, not around here anyway. I use UUIDs for boot and fstab now and and never rely on the /dev block device names to mean much of anything (except the ones I set myself in 10-local.rules using vendor and model -- haven't seen a disk drive serial number in udevinfo yet). I still claim, though, that the floating /dev node names has broken, or at least caused major PITA with, an awful lot of CL utilities and shell scripts. mdadm, I noticed yesterday, seems to be able to figure things out and build its RAID arrays from the correct disks, even when the /dev names are have changed since the arrays were defined. Bears looking into -- I suspect UUIDs, but one mustn't jump to conclusions :-) - -- Glenn English [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkfChwACgkQ04yQfZbbTLYAtgCcDypWVWvGQRysNUT8crkBAghU KHsAnAmG5HUx4+jPAFaxN+ZB00ChfVio =0XQW -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]