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