help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub rescue


From: Chris Murphy
Subject: Re: Grub rescue
Date: Sun, 24 Mar 2013 15:51:46 -0600

On Mar 24, 2013, at 1:56 PM, David WE Roberts <address@hidden> wrote:
> Is there any reason why GPT support could not be included as standard?
> 
> I am probably swimming in a very restricted pool, but it seems that the 
> main two disc partitioning schemes at the moment are MBR and GPT so if I 
> can update core.img with a GPT handler then it mustn't be too hard to ship 
> this as standard.

What you're talking about is more practical on UEFI systems where core.img 
appears as an EFI boot services application. Since the resulting grubx64.efi is 
stored as a file on the EFI System partition, it's limited to the free space on 
that partition, which is between 100MB-200 typically. Whereas the MBR gap on 
MBR disks is at best 1MB with a modern partitioner. And on GPT, the issue is 
you need to prequalify the specific BIOS with GPT since some BIOS firmware 
implementations get sand in their crack over GPT.

> Perhaps nobody else is trying to add a big disc to a dual boot 
> configuration and change it from MBR to GPT.

If the big disk is just a data disk, it should be GPT from the outset. 
Conversion may have some slight benefit as GPT is more well specified than MBR, 
has backup structures, and use CRC to validate the header. But as a boot disk, 
unless otherwise tested, on BIOS hardware MBR should be used. On UEFI hardware 
GPT should be used. Depending on firmware, you have a totally different 
core.img anyway.


Chris Murphy


reply via email to

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