RE: gcc bug causes parted to write bad GPT entries

[Matt_Domsch]

> Agreed.  This is making my brain hurt; the guid is on disk in
> little-endian order.  disk_gpt.c swaps to local cpu order 
> when it reads
> them, and back to LE when it writes them.  That's good, but 
> the libuuid
> code, which can be used to unparse them, looks like it 
> interprets the 16
> byte block it is passed as a uuid in big endian order (regardless of
> local cpu byte order).  libuuid is used to generate unique 
> UUIDs for the
> partitions too.  That should mean the unique partition IDs written by
> parted are wrong byte order on LE machines.  That does indeed 
> seem to be
> the case; if I run uuidgen a few times, I get strings like
> 
> a9e984b7-3c7b-4f1c-8764-f941fdaf6775
> 
> where this    ^    digit is always a 4
> 
> libuuid forces that to 4 as part of its generating process.  
> So, on disk
> that should be in LE format, and so the 8th byte (offset 7) of the
> unique guid should be 0x4?.  But it isn't, on my disks it is the 7th
> byte that always has a value 0x4?.
> 
> Am I confused, or is the code broken in the way it interacts with
> libuuid?

Blame Intel.

The RFC says guids are in big-endian byte order.  libuuid does it this way.
Intel's EFI Spec references that RFC, then proceedes to make it
little-endian in their spec and sample implementation (which all the BIOSes
use).  So it's got to be Intel's broken way, but that may mean we can't use
libuuid as-is...

I didn't realize this whole mess until David Mosberger suggested I rewrite
efi_guid_t to be an array of bytes instead of a struct of fields, and I
haven;t had the time to try to sort it all out again.

-Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001! (IDC Mar 2002)