Re: Several GNU projects wondering about the reason for mformat partition table

[Alain Knaff]

Hi,

On 20/05/2019 18:52, Thomas Schmitt wrote:
> Hi,
> 
> in the course of a problem search between GRUB, Guix, and xorriso we found
> the trigger of a problem with some old Macbook EFI firmware in a gesture
> of mformat.
> Line 1375 of
>   
> http://svn.savannah.gnu.org/viewvc/mtools/trunk/mformat.c?revision=506&view=markup
> has
> 
>   /* install fake partition table pointing to itself */
> 
> Now we are wondering for which use case there is this MBR partition table
> entry starting with LBA 0 and claiming the whole device.
> 
> The SVN at savannah shows that this gesture was introduced with revision 4
> in may 2002 by "aknaff". My hope is that this was you and that you can tell
> grub-devel (Cc'ed) more about the motivation.
> 

This was indeed me.

As far as I remember this was indeed intended as a convenience when
moving removable disks (Zip, Jaz or similar) from platforms that expect
the device to be partitions to platforms that expect it to be unpartitioned.

A platform that expects the disk to be unpartitioned would just ignore
this mini partition table.

A platform that expects the disk to be partitioned would see this
partition table, follow the "link" to the first partition, and then
again fall on the same sector and continue.

> ---------------------------------------------------------------------------
> In case you are curious about the motivation of this mail:
> 
> Our particular use case is to create a FAT filesystem image for use as EFI
> system partition in ISO 9660 images on USB sticks.
> grub-mkrescue runs mformat to create this image and then uses mcopy to
> populate it with EFI start programs. See
>   http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n812
> 
> The partition entry with start LBA 0 caused the EFI firmware to get stuck,
> probably looping endlessly. Experiments with dd reveiled that the partition
> entry was to blame, and in it the start LBA 0.
> 
> This is clearly a firmware bug and obviously fixed in later models of
> Macbooks. Nevertheless we care for old oddball hardware.
> 
> So the question is which of these alternatives to choose:
> 
> - Keep the partition entry because its removal could break some other
>   EFI firmware's boot process.
> 
> - Overwrite the partition table in bytes 446 to 509 of the mformat result
>   by zeros before populating it with files.
> 
> - Use mformat option -k to avoid production of the partition table.
> 
> I personally have scruples to omit the other fields which get written
> if option -k is not present. Is there anything written with (!keepBoot)
> which we need for a vanilla FAT filesystem to be recognizable or usable ?

In the next release I'll provide a new option to just skip this
partition table, but still initialize the other fields (jump at
beginning of boot sector, mformat "banner", 0xaa55 boot signature,
physdrive, mtools boot code, zeroing out unused bytes)

If all goes well, I expect to make this new release by the end of the month

> 
> ---------------------------------------------------------------------------
> 
> Have a nice day :)
> 
> Thomas
> 

Thanks, same to you.

Alain