Comment # 5 on bug 1008289 from Michael Chang

We really has been using msdos table in UEFI for booting for a while, the
example product is our openSUSE USB "hybrid" iso installation image for USB and
so on, but are all created as "primary partition".

I think putting EFI System partition in MSDOS extended partition is what to
blame here, it's bogus for UEFI booting right now.

The error "GUID Partition Table Header signature is wrong: 0 !=
5452415020494645" came from efibootmgr, after that bogus boot entry created,
something looked like:

 Boot0000* opensuse 
HD(5,MBR,0x4294967194,0x0,0x0)/File(\EFI\opensuse\grubx64.efi)

0x4294967194: seems to be MBR signature
0x0, 0x0: should well be partition_start and partition_size respectively, all
zero is definitely wrong
5: partition number, makes sense as linux numbers it as /dev/sda5. But
according to UEFI spec it's also wrong.

 section "9.3.6.1 Hard Drive"

 "Partition Number: Describes the entry in a partition table, starting with
entry 1 ... Valid partition numbers for a MBR partition are [1, 4]."

Finally, referring this pending pull request makes it clear that it's a missing
piece in efibootmgr.

 https://github.com/rhinstaller/efibootmgr/pull/23

Of course, the result is a not bootable entry. 

2. The "error: not a valid root device." comes from grub2's efi chainloader. I
think you were trying to boot xen hypervisor ? Apart from that, the kernel
boots well for me which is little surprised. Depending on how it maps grub
device to underlying UEFI block_io handle, it must all count on UEFI device
path for the device being booted and the target to be chainloaded to. I think
something wrong in the firmware to present the extended partition path to grub2
or on the other hand grub2 fails to process the device path for the extended
partition in particular.