grub-devel
[Top][All Lists]
Advanced

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

Re: [RFT] nested partition issues


From: Grégoire Sutre
Subject: Re: [RFT] nested partition issues
Date: Tue, 02 Nov 2010 16:58:15 +0100
User-agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.9.2.9) Gecko/20100927 Lightning/1.0b3pre Lanikai/3.1.3

Hi,

The main issue at hand is that, to support NetBSD, we need a working
grub-setup for the (very common) case where the NetBSD disklabel is placed
in an MSDOS partition.

If we need to add yet other ``strcmp (..._partmap->name, ...)'' tests to
grub-setup, then we likely have bad abstractions.


Actually now we follow the actual nesting of partitions. Even though
net-/openbsd label metadate is placed inside a partition it still
describes the whole disk as is manifested by it having entries for
partitions not contained inside the partition containing label metadata.
E.g.
(hd0,netbsd6) may be physically contained within (hd0,msdos3) but still
be described inside the label present in second sector (hd0,msdos2).
Place of metadata is secondary to deciding what the nesting of
partitions is. Primary criteria is what this metadata describes.

So, basically, as soon as a disklabel uses absolute offsets, this disklabel
must be viewed as a top-level disklabel?

I'm afraid that this will make things more complicated than they should
be.  But that's just me.


This is, of course, very unfortunate design but since we support NetBSD
we need such hacks. It's better than being faced with the problems of
kind "My XYZOS handles my partition scheme perfectly but GRUB doesn't
see half of partitions."

I did not see reports of such problems (for NetBSD partitions) since I
merged the code to ``external'' partitions [1].  Could you please point me
to such reports?

In the previous implementation, if partition e: in a NetBSD disklabel is
discarded, it's because e: describes an ``external'' partition.  This
external partition is (in all useful cases) described in another partition
map, where it is properly nested, hence it will be found by GRUB.

Grégoire

[1] http://lists.gnu.org/archive/html/grub-devel/2010-07/msg00109.html



reply via email to

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