Hi, > Since this image now boots under > UEFI, UEFI is satisfied that it's found a system partition - which I was > assuming meant a valid GPT. However, I now see that an MBR partition of > type 'EF' will be up-converted to a GPT partition of type 'EF00', which I > guess is what is happening here. At leat the existence of that MBR partition is the difference between libisofs with and witout the bug fix. GPT did not change by this.
> fdisk remains unhappy with the image, but this may be a separate issue: > Warning: /home/vorlon/devel/iso/quantal-desktop-amd64.iso contains GPT > signatures, indicating that it has a GPT table. However, it does not have a > valid fake msdos partition table, as it should. Yes. That is most likely the reason why you need the MBR partition. It is a feature of mjg's layout. http://mjg59.dreamwidth.org/11285.html states "it turns out that there are some systems that refuse to BIOS-boot off GPT media. So we need an MBR partition map. The first entry covers the entire disk and is of type 0. This is important, because some EFI implementations are strict about MBR parsing - if there's an MBR with overlapping partitions, the entire MBR will be ignored. " "Why have a GPT at all? The EFI spec says that machines should boot fine from an MBR partition. Sadly, not all seem to. " > > So does it help GPT visibility to set byte 450 of the ISO image > > to the value 0xee ? (Byte count starting at 0) > That doesn't seem to make any difference in whether fdisk/gdisk are happy > with it, at least. Pity. Did you check that the manipulation really changed only byte 450(dec) from 0x00 to 0xee ? I had hoped that at least gdisk would accept this. The description hybrid.html obviously stems from gdisk documentation. I assume you do not see a valid GPT without -partition_offset either. If you see a GPT, then please correct me. In that case, the partition start at 64 blocks could indeed be the culprit that deceives gdisk. The normal way to make GPT visible would be to reduce the MBR partition table to form a "protective MBR". To achieve a protective MBR you would have to zeroize the bytes 462(dec) to 509 in the ISO image (made without -partition_offset). Then you would have to set byte 450(dec) to 0xee (again). This would possibly not boot on all systems but should at least make the GPT recognizable. Have a nice day :) Thomas -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1062737 Title: hybrid images do not include a valid GPT To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1062737/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
