Quoting Evan Dandrea ([email protected]): > Thanks for chasing this upstream. > > No, an always-changing UUID defeats the purpose for us. We need a means > of providing a key for users to see their crash data, persisted across > installs.
A suggestion upstream was to use the uuid of the root filesystem. I'm not sure things can happen in the right order for that, but I can give that a shot. > > Not all platforms have a notion of platform UUID so as Ubuntu > > supports more architectures, this problem would have to be dealt > > with eventually. > > Sure, and in architectures that do not have a platform UUID, such as > ARM, we'll have to use a combination of other hardware identifiers (such > as mac addresses) to fill the gap. See bug 963007 for one conversation > on that. > > But we ultimately need something that ties back to that machine. If you're going to have to do that anyway, can you use the root fs uuid? Would that supplant the need for this qemu patch? You said our end-users need this. Historically are all of the people who will need this using either libvirt or testdrive? Can we simply hack testdrive to do this for us? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959308 Title: kvm does not generate a system uuid by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/959308/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
