Question on UUIDs...

[MultimediaMan]

OK: I've noticed a bit of "Mangling" of UUID ordering/rendering in iPXE, Observed in Asus Gen4 or later Motherboards, and HP's ProLiant Enterprise Servers (G5, G6, G7, G8)

"The true" UUID in BIOS/PXE is:

Code:

1F00B3E0-00C6-0800-2C4A-BCAEC5280EAD

as rendered in the BIOS, PXE UNDI, OS and the iLO information header

But when iPXE Renders it, we get this:

Code:

e0b3001f-c600-0008-2c4a-bcaec5280ead

Is this by design or a vendor BIOS implementation issue?

Thanks in Advance!

M^3

[robinsmidsrod]

This seems like an endian issue. I think you should report this as a bug on the mailing-list.

[MultimediaMan]

Horrible Hack, but it works...

Most current Enterprise-grade HP Servers have a bug with iPXE. The UUID iPXE reads is malformed from what it actually is.

I've put this up in the ipxe-devel lists, and so far no good workaround has been found... So, server-side, I have done a few things to rectify this. I'm not a very good perl scripter (yet), but this is a script which may be useful to people experiencing issues with UUIDs which are mismatched...

Windows Batch Script:

Code:

@ECHO OFF

:: Script to Fix Broken BIOS UUIDs
::
:: Desired result: Two UUIDs; one using the Actual UUID and one with the reverse ENDIAN of the Actual expressed as a lowercase UUID.
::
:: Actual UUID String:    1F00B3E0-00C6-0800-2C4A-BCAEC5280EAD
:: iPXE UUID String:    e0b3001f-c600-0008-2c4a-bcaec5280ead
::
:: Usage UUID-Gen.cmd %1
:: Where %1 = Actual UUID

SETLOCAL

SET ACTUAL_UUID=%1
SET STANZA0=UNKNOWN& SET STANZA1=UNKNOWN& SET STANZA2=UNKNOWN& SET STANZA3=UNKNOWN& SET STANZA4=UNKNOWN
SET S-T0=UNKNOWN& SET S-T1=UNKNOWN& SET S-T2=UNKNOWN& SET S-T3=UNKNOWN

FOR /F "tokens=1,2,3,4,5 delims=- usebackq" %%a IN (`ECHO %ACTUAL_UUID%`) DO SET STANZA0=%%a& SET STANZA1=%%b& SET STANZA2=%%c& SET STANZA3=%%d& SET STANZA4=%%e

::STANZA0_TRANSPOSITION
SET S-T0=%STANZA0:~0,-6%& SET S-T1=%STANZA0:~2,-4%& SET S-T2=%STANZA0:~4,-2%& SET S-T3=%STANZA0:~6%

::STANZA0_FIX_ENDIAN-NESS
SET STANZA0-NEW=%S-T3%%S-T2%%S-T1%%S-T0%

::STANZA1_TRANSPOSITION
SET S-T0=%STANZA1:~0,-2%& SET S-T1=%STANZA1:~2%

::STANZA1_FIX_ENDIAN-NESS
SET STANZA1-NEW=%S-T1%%S-T0%

::STANZA2_TRANSPOSITION
SET S-T0=%STANZA2:~0,-2%& SET S-T1=%STANZA2:~2%

::STANZA2_FIX_ENDIAN-NESS
SET STANZA2-NEW=%S-T1%%S-T0%

::RE-ASSEMBLE_STRING
SET TRANSPOSED_UUID=%STANZA0-NEW%-%STANZA1-NEW%-%STANZA2-NEW%-%STANZA3%-%STANZA4%

::FIXED_UUID
CALL :LOWERCASE TRANSPOSED_UUID
CALL :LOWERCASE ACTUAL_UUID
GOTO END

:LOWERCASE
:: Subroutine to convert a variable VALUE to all lower case.
FOR %%i IN ("A=a" "B=b" "C=c" "D=d" "E=e" "F=f" "G=g" "H=h" "I=i" "J=j" "K=k" "L=l" "M=m" "N=n" "O=o" "P=p" "Q=q" "R=r" "S=s" "T=t" "U=u" "V=v" "W=w" "X=x" "Y=y" "Z=z") DO CALL SET "%1=%%%1:%%~i%%"
GOTO:EOF

:END
CLS
ECHO.
ECHO %ACTUAL_UUID%
ECHO %TRANSPOSED_UUID%
ENDLOCAL

[robinsmidsrod]

Here is a quick test I created in Perl to reverse the hex part of the three first parts, which is what seems to be the issue. https://gist.github.com/4419556

I'm still curious how you identify this type of UUID from other equipment that is identified correctly. Do you use something else from the SMBIOS to help you out?

[MultimediaMan]

Here is what the BIOS says:

HP iLO3 IPMI Console:

Code:

Serial Number: USExxxxxxx
UUID: 39333835-3431-5355-xxxx-xxxxxxxxxxxx

RedHat 6.3 Server x86_64 DMIDECODE Output:

Code:

System Information
        Manufacturer: HP
        Product Name: ProLiant DL380 G7
        Version: Not Specified
        Serial Number: USExxxxxxx
        UUID: 39333835-3431-5355-xxxx-xxxxxxxxxxxx
        Wake-up Type: Power Switch
        SKU Number: 583914-B21
        Family: ProLiant
        Family: ProLiant

Windows Server 2008R2 SP1 WMIC CSPRODUCT GET UUID:

Code:

UUID
39333835-3431-5355-xxxx-xxxxxxxxxxxx

This is the Adapter attempting to PXE: Note malformed UUID/GUID

[IMG=http://imageshack.us/a/img560/9313/380pxe.jpg][/IMG]

And iPXE Reporting more of the same:

[IMG=http://imageshack.us/a/img138/7412/380ipxe.jpg][/IMG]

It is not restricted to Intel NICs: I have observed this with Broadcom, Emulex, Intel and QLogic 1GbE and 10GbE adapters.

Best,

M^3

[robinsmidsrod]

I wouldn't expect it to be related to the adapter, as it is information that is coming from the BIOS of the machine, not from the network card. Are these HP machines the only ones you've seen it on?

[MultimediaMan]

(2013-01-03 09:56)robinsmidsrod Wrote:  I wouldn't expect it to be related to the adapter, as it is information that is coming from the BIOS of the machine, not from the network card. Are these HP machines the only ones you've seen it on?

I have observed this on Hyper-V Virtual machines, Dell Generation 12 (R720, R720XD, R820), HP Gen7 and Gen8 (every model to date). I'll let you know on IBM... I have three to rack this week.

[Alexandru Bordei]

I had the same issue recently, on HP DL120 G7. Didn't had it on Dell PE R200 nor any IBM's. Anyway what I did was to tweak the uuid a bit:
It now works as it should. I also added a touppercase conversion since i've seen that some BIOSes return it lower case and some uppercase.
I'm not sure what impact this has on other machines though due to endianess. I hope i'll have the time to look at how dmidecode reads it.

I hope it helps.

Code:

diff --git a/src/core/uuid.c b/src/core/uuid.c
index 27a249d..d4deda3 100644
--- a/src/core/uuid.c
+++ b/src/core/uuid.c
@@ -21,7 +21,7 @@ FILE_LICENCE ( GPL2_OR_LATER );

#include <stdint.h>
#include <stdio.h>
-#include <byteswap.h>
+#include <ctype.h>
#include <ipxe/uuid.h>

/** @file
@@ -39,13 +39,18 @@ FILE_LICENCE ( GPL2_OR_LATER );
char * uuid_ntoa ( const union uuid *uuid ) {
        static char buf[37]; /* "00000000-0000-0000-0000-000000000000" */

-       sprintf ( buf, "%08x-%04x-%04x-%04x-%02x%02x%02x%02x%02x%02x",
-                 be32_to_cpu ( uuid->canonical.a ),
-                 be16_to_cpu ( uuid->canonical.b ),
-                 be16_to_cpu ( uuid->canonical.c ),
-                 be16_to_cpu ( uuid->canonical.d ),
+       sprintf ( buf, "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",
+                 uuid->canonical.a[3], uuid->canonical.a[2],
+                 uuid->canonical.a[1], uuid->canonical.a[0],
+                 uuid->canonical.b[1], uuid->canonical.b[0],
+                 uuid->canonical.c[1], uuid->canonical.c[0],
+                 uuid->canonical.d[1], uuid->canonical.d[0],
                  uuid->canonical.e[0], uuid->canonical.e[1],
                  uuid->canonical.e[2], uuid->canonical.e[3],
                  uuid->canonical.e[4], uuid->canonical.e[5] );
+       int i=0;
+       do
+           buf[i]=toupper(buf[i]);
+       while (buf[i++]);
        return buf;
}
diff --git a/src/include/ipxe/uuid.h b/src/include/ipxe/uuid.h
index 5de56b9..88a0a15 100644
--- a/src/include/ipxe/uuid.h
+++ b/src/include/ipxe/uuid.h
@@ -15,13 +15,13 @@ union uuid {
        /** Canonical form (00000000-0000-0000-0000-000000000000) */
        struct {
                /** 8 hex digits, big-endian */
-               uint32_t a;
+               uint8_t a[4];
                /** 2 hex digits, big-endian */
-               uint16_t b;
+               uint8_t b[2];
                /** 2 hex digits, big-endian */
-               uint16_t c;
+               uint8_t c[2];
                /** 2 hex digits, big-endian */
-               uint16_t d;
+               uint8_t d[2];
                /** 12 hex digits, big-endian */
                uint8_t e[6];
        } canonical;

[robinsmidsrod]

Alexandru: I would suggest you post that patch on the mailing-list. Maybe someone else might need it as well, and if it looks good it might be included (if it's correct and all).

[mcb30]

For the benefit of anyone who finds this page by searching, this issue should be fixed by commit 9e896d0. An explanation can be found on the mailing list at http://lists.ipxe.org/pipermail/ipxe-dev...02338.html.

Michael