Bug#731709: Preliminary patch for EFI boot support in live-build

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> It's not about a particular version of xorriso, but about the set of
> command-line options that we use depending on the xorriso version

No regression then. :)

Were the problems with CD/DVD or with USB sticks ?


> In our tests, there are more computers where EFI boot works (from an USB
> key) when we use
> "-eltorito-alt-boot --efi-boot boot/efi.img -append_partition 2 0x01
> binary/boot/efi.img"
> compared to when we use "-eltorito-alt-boot -e boot/efi.img
> -isohybrid-gpt-basdat".
> In particular a number of macbook.

The novelty is in the existence of GPT, which might confuse the
firmware by its nested partitions.
Further the location and partition type of MBR partition 2 differs.
The new type is 0xef and partition 2 is inside partition 2.

GRUB2's grub-mkrescue lets xorriso write strictly disjoint
partition tables. But the ISOLINUX/GRUB2 mix according to Matthew
Garrett's http://mjg59.dreamwidth.org/11285.html prescribes the
FAT (for EFI) and HFS+ (for "some" Macs) partitions to sit inside
the ISO image.  Thus their partitions sit inside partition 1,
which claims the whole ISO and is mountable.
(Note: debian-cd does not include a HFS+ filesystem.)
GRUB2 grub-mkrescue produces no mountable ISO partition. One
has to mount the base device, which is unusual with USB sticks.

It would be interesting to learn whether the Mac firmwares take
offense from the existence of GPT, from the MBR partition type 0xef,
or from partition nesting.

There are known but diffuse problems with Macs and BIOS+EFI
capable ISOs. Ubuntu offers BIOS-only images for EFI Macs.
See Colin Watson's answer to
  http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image


Experiment proposals for those who have a vulnerable Mac at hand:

- Remove GPT from a "worse" ISO:
    iso="....iso"
    backup_gpt=$(expr $(isosize "$iso") / 512 - 1)
    dd of="$iso" conv=notrunc if=/dev/zero bs=512 seek=1 count=63
    dd of="$iso" conv=notrunc if=/dev/zero bs=512 seek=$backup_gpt count=1

  Does it boot now ?

- Change the type of MBR partition 2 in a "better" ISO.
  Since the partitions are disjoint and only an MBR is present,
  program fdisk should do.
  Alternatively write byte 0xef = 0357 at position 466:
    echo $'\357' | dd of="$iso" bs=1 conv=notrunc seek=466 count=1

  Does the image get unbootable by this ?
  To verify proper manipulation: Does it get bootable again by
    echo $'\001' | dd of="$iso" bs=1 conv=notrunc seek=466 count=1

- In a "better" ISO's MBR move the end of partition 1 after the end
  of partition 2.
  I could not find a command in fdisk which would do that. So one
  would have to learn start and size of partition 2 by e.g. fdisk,
  compute a new end block address after partition 2, and write
  the result as little-endian 32-bit number into bytes 458 to 461
  of the ISO.
  If there is interest in this test, i could write a little C
  program which does this.

  Does the image get unbootable by this ?
  To verify proper manipulation: Does it get bootable again by
  writing the old end address into partition slot 1 ?

 
Have a nice day :)

Thomas