grub-mkrescue: Problem with MBR partition table at start of EFI partition

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

Hi,

this is about how exactly to solve a diagnosed and worked-around problem.

Guix is one of the few distros which make their installation ISOs by
help of grub-mkrescue. The EFI boot manager of an old Macbook got stuck
when such an ISO was presented on USB stick. I.e. it not only did not
boot the ISO but showed no other EFI partitions either.

A Debian Live 9 ISO does not impose such a problem.
The same Guix ISO on DVD rather than USB stick works well, too.

The owner of the machine is Florian Pelz (Cc'ed). He characterizes it as:
  MacBook Pro (13-inch, Mid 2010)
MacOS Yosemite reports:
  Model Name:            MacBook Pro
  Model Identifier:      MacBookPro7,1
  Boot ROM Version:      MBP71.003F.B00
  SMC Version (system):  1.62f7

During a longish bug hunt it turned out that the decisive difference
is the first block of the FAT filesystem image which Debian creates by
mkfs.fat whereas grub-mkrescue creates it by mformat.

The mformat-made image has an MBR partition table entry which claims the
whole image as partition 1:

  Device            Boot Start   End Sectors  Size Id Type
  /mnt/iso/efi.img1 *        0  2879    2880  1.4M  1 FAT12

If this partition entry is zeroed, then the EFI boot manager works even
when the USB stick with this modified ISO is plugged in.

Actually it suffices to change the start LBA from 0 to 1, so that the
partition does not start by the partition table. (I count this as proof
of an endless loop in EFI while it is exploring something like
extended partitions. Strange is that the main MBR partition 1 of the
Debian ISO points to that main MBR, too. So it seems to harm only in
sub partition tables. We repacked the Guix ISO to MBR rather than GPT.
Still stuck.)

The EFI FAT image in Debian Live 9 has no partition table entry in block 0.

Production of the partition entry can be suppressed by mformat option -k.
But then block 0 of the result is not marked as MBR and also causes
program "file" to give out a very sparse characterization:

  DOS floppy 2880k

Here is the "file" report about an image made without -k:

  DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MTOO4018",
  sectors/cluster 2, root entries 240, sectors 5760 (volumes <=32 MB) ,
  sectors/FAT 9, sectors/track 36,
  serial number 0x6c528b1f, unlabeled, FAT (12 bit), followed by FAT

An image made by a modified grub-mkrescue with mformat option -k
worked well for Florian Pelz.

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

Questions:

1: Is there any use for the partition entry in the EFI partition of a
   grub-mkrescue ISO ?

2: Is there any use for the information which mformat does not insert
   if option -k is set ?

If the partition entry is not needed but the other MBR-like bytes are
needed:

3: Is there a good example in GRUB util sources about how to open a file,
   seek to its byte 446, and write 16 zero bytes starting there ?
   (I'd like to propose a patch for grub-mkrescue.c which zeros the
    partition entry directly after the mformat run.)

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


Have a nice day :)

Thomas