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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
