[grub-setup] New procedure to choose the embedding area

[grub-setup] New procedure to choose the embedding area

[Grégoire Sutre]

Hi,

[ This is an extended summary of discussions that took place on irc. ]

The current version of grub-setup requires an msdos or gpt partitioning
scheme, and is not compatible with hybrid partitioning schemes (i.e. two
top-level disklabels).

Some disklabels have a specific partition type for bootstrap code, e.g.
gpt and bsd.  Apple partitions have a type that is actually a string (32
chars), so we could use a specific type for grub bootstrap code (e.g.
`Grub_Bootstrap' or simply `Grub').  Maybe there are other disklabels
(among those supported by GRUB) with a specific partition type for boot
partitions.

As you know, there isn't a specific partition type for bootstrap code in
msdos disklabels.  The current implementation of grub-setup embeds after
the MBR when the detected disklabel is msdos.  But this is fragile:
many tools do not hesitate to write in this area regardless of what is
there.

Ideally, grub-setup should use a dedicated boot partition if it finds
one, and embed after the MBR only as a last resort.  Still, we must be
careful with dedicated boot partitions when there are several top-level
disklabels: the disklabel containing the dedicated boot partition could
be obsolete (e.g. a leftover from some prior installation).  In that
case, we may overwrite user data when embedding in the boot partition.
So we should check that the boot partition does not overlap another
partition.

To sum up, the new procedure to select the embedding area would be:

  1. FOREACH top-level partition p    /* i.e. p->parent == NULL */
  2.    IF p is a dedicated (gpt|bsd|apple|...) boot partition AND
           p does not overlap with another top-level partition
  3.    THEN
  4.       return p
     /* No appropriate top-level dedicated boot partition. */
     /* Handle the standard msdos case as an exception. */
  5. IF the disk contains a single top-level disklabel, and this
        disklabel is an msdos one
  6. THEN
  7.    return [1, n-1] where n is the minimal start sector of the
                        top-level partitions
     /* Do not try to be too smart...  Abort! :-) */
  8. explain to the user why no embedding area could be found
  9. return NULL

The first FOREACH loop discards nested partitions, so it would miss for
instance a dedicated boot partition (hd0,msdos2,bsd7).  It would
instead try to embed in the post-MBR gap, which may fail or be more
risky than in the nested dedicated boot partition.

What do you think regarding this issue?  Should we accept any dedicated
boot partition, even if it is nested?

This message is only a proposition, and I look forward to your comments
and suggestions.

Grégoire

Re: [grub-setup] New procedure to choose the embedding area

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

On 06/11/2010 12:25 AM, Grégoire Sutre wrote:
> Hi,
>
> [ This is an extended summary of discussions that took place on irc. ]
>
> The current version of grub-setup requires an msdos or gpt partitioning
> scheme, and is not compatible with hybrid partitioning schemes (i.e. two
> top-level disklabels).
>
> Some disklabels have a specific partition type for bootstrap code, e.g.
> gpt and bsd.  Apple partitions have a type that is actually a string (32
> chars), so we could use a specific type for grub bootstrap code (e.g.
> `Grub_Bootstrap' or simply `Grub').  Maybe there are other disklabels
> (among those supported by GRUB) with a specific partition type for boot
> partitions.
>
> As you know, there isn't a specific partition type for bootstrap code in
> msdos disklabels.  The current implementation of grub-setup embeds after
> the MBR when the detected disklabel is msdos.  But this is fragile:
> many tools do not hesitate to write in this area regardless of what is
> there.
>
> Ideally, grub-setup should use a dedicated boot partition if it finds
> one, and embed after the MBR only as a last resort.  Still, we must be
> careful with dedicated boot partitions when there are several top-level
> disklabels: the disklabel containing the dedicated boot partition could
> be obsolete (e.g. a leftover from some prior installation).  In that
> case, we may overwrite user data when embedding in the boot partition.
> So we should check that the boot partition does not overlap another
> partition.
>
> To sum up, the new procedure to select the embedding area would be:
>
>  1. FOREACH top-level partition p    /* i.e. p->parent == NULL */
>  2.    IF p is a dedicated (gpt|bsd|apple|...) boot partition AND
>           p does not overlap with another top-level partition
>  3.    THEN
>  4.       return p
>     /* No appropriate top-level dedicated boot partition. */
>     /* Handle the standard msdos case as an exception. */
>  5. IF the disk contains a single top-level disklabel, and this
>        disklabel is an msdos one
>  6. THEN
>  7.    return [1, n-1] where n is the minimal start sector of the
>                        top-level partitions
>     /* Do not try to be too smart...  Abort! :-) */
>  8. explain to the user why no embedding area could be found
>  9. return NULL
>
> The first FOREACH loop discards nested partitions, so it would miss for
> instance a dedicated boot partition (hd0,msdos2,bsd7).  It would
> instead try to embed in the post-MBR gap, which may fail or be more
> risky than in the nested dedicated boot partition.
>
> What do you think regarding this issue?  Should we accept any dedicated
> boot partition, even if it is nested?
>
I've just restructured grub-setup for an easy of new embedding zones.
The trouble is to decide whether we have the right to embed into X or Y
when we install to Z or T. Currently following rules apply:
1) if installing to hd0 and hd0 is MSDOS-table, you can use MBR gap, if
there is no other top-level partition table.
2) if installing to hd0 and hd0 is GPT, you can use BIOS boot partition,
if there is no other top-level partition table.
New rules will be added in accordance with the governing bodies of
relevant partmaps and filesystems or consensus-based if no such body
exists. Rules I'd recommend are (based on discussion of ZFS and sunpc case):
3) If /boot is on MyFS, you can use MyFS embedding zone (currently only
FAT, Reiser and ZFS have it) if /boot and bootsector are on the same drive
4) If /boot is in MyPart you can embed in special partition on MyPart,
in this case we need a way to ensure no 2 bootloaders will fight for the
same embedding zone
> This message is only a proposition, and I look forward to your comments
> and suggestions.
>
> Grégoire
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]