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

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- 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 --]