OK, so I've done a bit of digging. As of SMBIOS 2.6 (released in 2008), the first three fields of the UUID are well-defined as being encoded in little-endian. Before that, they could be encoded in "network byte order" (i.e. big-endian) if people felt like it.
Presumably enough people did feel like it, as dmidecode specifically has different code paths for pre-2.6 and post-2.6 SMBIOS versions; it will decode pre-2.6 UUIDs as big-endian and post-2.6 UUIDs as little-endian. (The comment in the dmidecode source code at [0] explains this pretty well.) And, you've guessed it, Azure reports a pre-2.6 version of SMBIOS. (To be precise, 2.3, which was released in _1999_; Azure is old skool cool). This explains the difference between the kernel-reported UUID (always little-endian) and the dmidecode-reported UUID (big-endian on Azure, but little-endian on most modern systems). [0] https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L415 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1551419 Title: Fix UUID endianness patch breaks cloud-init on Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1551419/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
