[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schmitt
Subject: Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Date: Mon, 13 May 2019 23:55:06 +0200


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

> 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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]