Comment 8 for bug 1551419
Revision history for this message
| Dan Watkins (oddbloke) wrote Re: Fix UUID endianness patch breaks cloud-init on Azure | #8 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
OK, I'm shifting this back to linux, because I think that the commit that was backported is fixing a problem in a commit that _wasn't_ backported, therefore causing the issue. Here are the details:
In 95be58df7 [0], support for SMBIOS 3 was added, which introduces a third version field (i.e. 3.2.1 vs. 2.9); as a result, dmi_ver is converted from a u16 and a u32, and when it's read in, it's left-shifted 8 bits. (i.e. version 2.6 goes from 0x0206 to 0x020600). The endian-ness checks are updated to match the shifted number (i.e. if SMBIOS version >= 0x020600, little-endian, otherwise big-endian). This patch has NOT been backported to trusty.
In ff4319dc7 [1], it was identified that this left-shifting happened in the wrong place, and so it was moved to happen in a different place. Simple enough. However, this patch HAS been backported to trusty, despite the fact it is fixing behaviour that wasn't backported.
Crucially, though, the commit containing the backport [2] introduced the left-shifting _without_ changing the endian-ness checks. This means that the trusty kernel _always_ detects the SMBIOS version as being greater than 2.6, which means on older versions of SMBIOS (like the one in use on Azure), it returns the version with incorrect endian-ness.
[0] https:/
[1] https:/
[2] http://