[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: Daniel Kiper
Subject: Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Date: Wed, 15 May 2019 11:45:23 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, May 14, 2019 at 08:04:01AM +0200, Thomas Schmitt wrote:
> 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.

Again, this is an FDD 2880K image and there is no MBR there. Your
interpretation is wrong. I think that simply some Macbooks have issues
with such FDD images.

> 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 kind of image is used on MS ISO Win image? FDD or HDD one? If FDD
then you cannot interpret boot sector as MBR. This is wrong.

> > 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.

Again, on what type of image? FDD or HDD?

> > 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.

I would not do that blindly. First of all look at mformat code and check
why above mentioned data is not zeroed. If this is not obvious ask
authors about that. Please CC grub-devel then too.

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

If mkfs.fat images work on Macbooks then I would leave mformat as
default and add an option to switch between mformat and mkfs.fat.
Or we can try to create HDD image using mformat. Or both.


reply via email to

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