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

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

Hi,

Daniel Kiper wrote:
> may I ask you to write a summary of your findings,

A Macbook took offense from the MBR partition table entry in the EFI FAT
image which grub-mkrescue produces by help of mformat(1).
Vladimir stated that this partition table entry is not intentional and
that the information in block 0, which would be missing after using mformat
option -k, is probably not needed.

Vladimir's proposal to look into the EFI partitions of MS-Windows ISOs
led to the insight that their MBR partition table space is filled with
cleartext. I.e. not-zero is usual. Credibly looking partition table entry
starting at LBA 0 is not usual.

(Further we learned that Microsoft has its own protocol implemented in EFIs
 by which they boot USB sticks with MBR partitioning and no partition of
 type 0xEF.)


> what works and what does not

The only thing that was found to not work is a MBR partition entry 1 which
starts at LBA 0. Probably it needs to have non-zero block count and non-zero
type.


> how the issue should be fixed

Safest seems to be not to change the mformat run in grub-mkrescue but
rather to postprocess its result, e.g. before the run of mcopy which
populates the image.
Postprocessing would mean to zeroize the whole range of MBR partition
table entries. That's bytes 446 to 509 of the FAT image.


> why this fix should land in the upcoming release.

It may well wait until the start of the next release cycle, although i deem
it easy to test and of low risk. Most Linux distros have zeros where i
propose to put them. They make their EFI images by mkfs.fat(8).


Have a nice day :)

Thomas