grub-devel
[Top][All Lists]
Advanced

[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: Mon, 20 May 2019 14:35:55 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, May 16, 2019 at 02:18:51PM +0200, Thomas Schmitt wrote:
> 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.

Yeah, could you ask mformat folks about that?

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

Yep but on the other hand we have to not break anything which works right now.

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

After some thinking I have an itching to add the "-k" option to the
mformat. However, I am not convinced that this should go into the
release. There is a chance that we will break other platforms and fix
the only one. So, I would suggest to make this as a known issue and fix
it after the release. Does it make sense?

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

Could you ask him about that? Please keep grub-devel in the loop.

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

I am not sure I understand. Which GPT do you refer to?

Daniel



reply via email to

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