>From what I could tell, the UUID was simply never tracked down. I didn't investigate too much -- net user-visible result is, the machine hangs in the initramfs for several minutes before it finally concludes that it couldn't find anything to mount the root filesystem with.
It could be that the UUID code doesn't know to track RAID at all, and only looks at devices that were available at kernel boot time, before the initramfs? What I can tell you is that they're just about completely redundant for RAID configurations, among other things. If I already have an mdadm.conf which I'm using to build the cluster -- or a crypttab which I'm using to build the md-crypt device -- or even some md kernel autodetection, based on UUIDs and metadata stored in the physical volumes... In all of these cases, the actual device I am mounting is going to be the same, every time, as it is hardcoded *somewhere* -- the underlying physical volumes may or may not have been setup by UUID. If they have, then why do UUID stuff twice? If they're setup by /dev/sd*, then there's not much point in using UUIDs higher up the chain. As for assigning someone else to the bug, at the very least, it was an email that I found in the source file in question. Still, if I wasn't supposed to do that, I apologize. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
