Comment 39 for bug 54002

Scott,

nobody does mount by UUID. Neither *BSD, Solaris, AIX, HP-UX, Tru64 does it. These Unix derivatives have pretty smart engineering teams around. That should tell you something...

As for the valid configurations:

Category A (Will probably never work):

1. loopback mounts (eg. crypto root) -> kills secure mobile devices
2. network mounts (eg. nfs root or raid with nbd) -> kills one half of thin client setups
3. layered mounts (eg. unionfs) -> kills the other half of thin client setups and one half of embedded devices
4. tmpfs root -> kills the other half of embedded devices

Category B (Probably resolveable but changes expected behaviour)

5. disaster recovery with replicated root file systems (eg. rsync): there the UUIDs of both filesystem have to be different, otherwise they wouldn't be unique -> kills quite common DR strategy and effectively kills the use in corporate server environments
6. bare metal recovery: restore tape backup to newly installed system will result in a unbootable setup because UUID no longer matches... -> a support nightmare, effectively kills the use in corporate desktop environments

Category C (Has severe side-effects)

7. systems with SAN/iSCSI storage: udev will scan all devices it sees to determine the UUID. this is likely to take a long time ((I know of hosts with several hundred SAN storage volumes assigned to them) and prone to disrupting the operation of other hosts (since Linux does not honor SCSI reservation)-> this kills the enterprise server setups.