Re: [Bug-xorriso] ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

i wrote:
> > this is the xorriso run for producing a layout like "isohybrid --uefi"

Florian Pelz wrote:
> No, it still gets stuck. :(

Then it must be something inside the EFI partition which makes the
Macbook firmware dismiss the partition for booting.


> The GPT partition GUID is different each time I repeat the process.

This can be avoided by setting environment variable SOURCE_DATE_EPOCH
to the same value in each production run.
(I just tested that this works as expected.)


Well, i am out of ideas how the Guix ISO layout or content differs from
the stuff in Debian ISOs, so that an EFI implementation dismisses the
former and accepts the latter.

It really does not look like an issue with partitioning.
I don't think that it goes deeper into the boot equipment than the
files in the EFI partition.

Maybe GRUB experts have ideas what to examine there. After all it is
grub-mkrescue which fails to produce a recognizable partition, whereas
Debian's effort with (most probably) grub-mkimage can do the trick.
grub-mkrescue uses grub-mkimage, too, afaik. So it probably is about
some magic ingredient to the production of the EFI start programs or
the FAT image file.

We could ask at debian-cd mailing list whether the problem rings a bell
from a past problem fix.
(I am subscribed there and ready to assist with technical details about
 our findings.)


Next mail from Florian:
> Boot gets stuck on x86_64 Guix images only, but the one i686 I tried
> did not show up in the boot menu.  I believe bootx64.efi is run for
> x86_64 and is the culprit.

This fits into my findings if EFI looks into the EFI partitions
and dismisses those without its CPU specific flavor of start program.

Can you get EFI to confess that the x86_64 USB stick indeed has a
recognizable EFI partition ?


> I could try burning a DVD and attempt to boot from it.

On DVD the El Torito boot equipment should lead EFI to the same partition
image as the partition table should do on USB stick.
But a try cannot harm.


> It would also be interesting to find out how to change the
> bootx64.efi’s code and make it display debug information in some way.

The highest control layer is
  http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c
The name "BOOTX64.EFI" appears in
  http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-install.c
Somewhere inbetween must be its source. :o)

------------------------------------------------------------------------

For now i say thanks for three found bugs in my own software, during
this discussion:

- Environment variable SOURCE_DATE_EPOCH did not affect synthetic files.
  Thanks to Florian and Ludovic for pointing out the non-reproducibility
  issue.
  Fixed by libisoburn 5b62c55
  Workaround for Guix and currently released versions of xorriso:
  Give the ISO root directory fixed atime, mtime, and ctime by xorriso
  command -alter_date. (Would work with future xorriso versions, too.)

- SIGSEGV happened if "-boot_image grub grub2_mbr=" was used and no
  El Torito boot image was defined.
  This one i found by a bad backslash while testing my xorriso run
  proposals to Florian.
  Fixed by libisofs 4b21386
  No workaround needed because no usable result can emerge anyways.

- I was unable yesterday to get "isohybrid --uefi" layout when using GRUB
  equipment for BIOS. I thought it was possible. My grub-mkrescue argument
  filter script falsely promises to do it.
  Still unresolved.
  Workaround was to use body parts of a real isohybrid ISO.

------------------------------------------------------------------------

Have a nice day :)

Thomas