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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
