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. -- LVM/MD root filesystem not found by uuid https://launchpad.net/bugs/54002 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
