On Fri, Jan 22, 2010 at 07:03:21PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> > This can be done by extending "has_partitions" to be set to "yes" in those
> > specific partition types. The implementation should be the least intrusive
> > possible, taking into account that this kind of situations are an oddity
> > rather than the norm.
> >
> >
> Partition types are easily screwed. Why not just check for the presence
> of the label?
I have a feeling I already explained this somewhere. Doesn't seem to be in
this thread, maybe on IRC? Anyway, it won't hurt to ellaborate on it...
First of all, the whole label type proliferation problem is inherently
impossible to resolve by technical means. Labels overlap each other,
they can coexist without any garantee that the user expects them to be
there at all or include meaningful data.
You *can't* reliably check for any partition label. Partitions include a
set of arbitrary data. Sometimes they will match one of the probes,
sometimes more than one. GRUB has no way of determining if any of those
matches is correct, because only the *user* knows that.
This is a problem we already have, but it is bearable because worst case is
detecting a label where there isn't supposed to be one, or detecting a label
type different than the one user expected. With this proposal, two things
happen:
- has_partitions stops being useful. When in top level, it's relatively
easy to make assumptions about the existance of partitions. If it is
a hard disk, chances are it'll be partitioned; If it's a CDROM, chances
are it isn't (this is an unreliable check, but its purpose is to paliate
the effect of using another unreliable check, so overall it's a gain).
- False positives can be repeated ad nauseam. It can even be exploited to
force GRUB into reading several GiBs of data, effectively DoSing it.
If you look around, all approaches at dealing with this imply appliing enough
limit to keep it sane. For example, they limit the number of label types, the
recursion depth, etc.
If we're going to support *all* possible combinations, I'd rather revisit
and solve our detection problem first. Not by actually making detection
reliable (that's impossible), but by stop pretending GRUB can hide this mess
from the user. When GRUB performs guesswork, sooner or later it'll get it
wrong anyway, and the fact that it was guessing creates a false expectation
that it somehow knows the correct result. Users end up blaming GRUB for that.
So instead of supporting things like:
(hd0,1)
(hd0,2)
(ambigous; what does this mean in an hybrid MSDOS/GPT ? What about other
hybrid schemes? GRUB can't tell!)
... we could support:
(hd0,msdos1)
(hd0,gpt1)
(hd0,msdos2)
(hd0,gpt2)
whose meaning is pretty clear. Then the user can nest as much as they like,
but they will also have to deal with the problem of identifiing the labels.
Minix: (hd0,msdos1,msdos1)
Solaris: (hd0,msdos2,sun1)
*BSD: (hd0,msdos3,bsd1)
With this approach, the burden is no longer in GRUB. Then I don't care
how weird disk layouts can become, because GRUB doesn't have to probe
them. We can even support things like this if it makes users happy:
(hd0,bsd2,msdos1,sun1,apple4,msdos1)
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
