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

[Thomas Schmitt]

Hi,

i quoted mformat.c:
> >   /* install fake partition table pointing to itself */

Daniel Kiper wrote:
> OK, but why it is also done for FDD images?

According to its man page, mformat formats floppies. So the question
would be why it creates a partition table at all.



> > Either mformat's result is ok or it is not.

> I would say that in most cases it works but is some it does not. This
> is difficult to say right now where is the bug

Whoever is the culprit when stepping into a pitfall, grub-mkrescue should
try to avoid known bug triggers.

I understand from Vladimir's reply that he did not think of partition
tables or floppies when employing mformat in grub-mkrescue.c. He wanted
a FAT filesystem with usual entrails.
Usual is to have no data in it which look like a partition table entry
which describes a partition starting at block 0.
(Microsoft hasn't. The larger Linux distros haven't.)

So i propose the change as fine tuning of the original developer's
intention. (Vladimir will correct me if i'm wrong.)


> So, first of all I would like to understand why somebody decided to do that

As for the Macbook, my theory is that it tries to explore what it believes
to be an extended partition. Newer Macbooks are said not to make this
mistake any more.

As for mtools, binary search on
  http://svn.savannah.gnu.org/viewvc/mtools/trunk/mformat.c?view=log
yields that the comment came in with revision 4 in line 958
  
http://svn.savannah.gnu.org/viewvc/mtools/trunk/mformat.c?revision=4&view=markup
Revision 2, line 800 shows no trace of a partition table until in the
end 0xaa55 is written.
Revision 4 is from 2002 and has as commit message "3.9.8, modified files".

Committer is "aknaf", probably the same as "alainknaff" who committed
to mtools last year.
  https://savannah.gnu.org/users/alainknaff
Maybe he still can remember why he added the partition entry.

--------------------------------------------------------------------------

> > After all it is quite easy to override the ideas of grub-mkrescue
> > before the ISO gets packed up. In practice, it's preference for GPT
> > makes more problems than its preference for mformat.

> This is not good idea. I would like to see a fix or at least a kind of
> workaround in GRUB upstream.

I was not happy with Vladimir's decision to use GPT instead of MBR partition
table. (Because of non-mountable partitions and the GPT backup, which needs
to be relocated after copying the ISO onto USB stick.)
Nevertheless, if GRUB wants then GRUB gets, provided that i understand what
is desired and find a way to fiddle it into the existing libisofs code.

In the course of a few bug hunts i developed the pseudo-xorriso script which
can be put between grub-mkrescue and real xorriso by option --xorriso=.
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh
It gets to see the xorriso arguments and the temporary directory with the
prepared files. So it can modify them.

It spares grub-mkrescue the work to implement options like
  --mbr-rather-than-gpt
  --without-hfsplus-and-apm
  --in-efi-no-partition-table,
  --do-it-like-isohybrid-u
They all are more in the realm of xorriso than of GRUB. But the user can
hardly influence those aspects by adding some xorriso options to the
grub-mkrescue arguments.

The script is part of xorriso's project and mainly applies to x86 EFI
bootable ISOs. Of course it speculates that not much will change in
grub-mkrescue's relation to xorriso. I am subscribed here and hope to notice
any patch that would change the xorriso arguments or the fundamental layout
of the prepared file tree.


Have a nice day :)

Thomas