F17 bogus "could not detect partitions" error

[Adam Williamson]

On Fri, 2012-03-16 at 14:16 -0600, Chris Murphy wrote:
> 
> On Mar 16, 2012, at 12:54 PM, Adam Williamson wrote:
> >> 
> > As far as the error message goes, it seems correctly written to me. It's
> > a generic error message which is displayed any time anaconda (and hence
> > parted) is unable to make any sense at all of a disk's layout. It
> > therefore *has* to be pretty generic, because it could be displayed in
> > many situations. (It *is* displayed if you install with a completely
> > unformatted disk connected, for instance).
> 
> Except it's not even remotely a generic message. It's a very specific
> message saying the problem is due to one of three things, none of
> which are true.

It doesn't say that. It says the problem "could be" due to one of those
three things; 'could' naturally implies that there are also other
unspecified possibilities. That's entirely different.

> > It does in fact countenance the possibility that the three possibilities
> > it offers are not actually the case. That's what the "If not" at the
> > start of the second sentence means. What the message is telling you is
> > "this might just be a blank disk, but if you know it's not a blank disk,
> > if you continue with the installation, we're going to blow any data
> > that's on it away".
> 
> Interpreting "if not" in this manner is linguistically clumsy at best.
> It's certainly obscure. Obscurity, and causing user confusion, is the
> hallmark of poor UI.

That's the only way I can think of interpreting it, and I used to
proofread stuff for a living. The intent of the message has always been
clear to me.

> 
> >> So those are the facts. Next it's a question on how to improve the
> >> result, or at the very least not produce totally bogus error messages
> >> that don't tell the user what the problem really is, or how to fix it.
> > 
> > I don't think it is a bogus message, for the reason cited above.
> > Remember to look at things from anaconda's point of view here.
> 
> I could hardly care less what anaconda's point of view is. I care
> about the end user's point of view first.

We're talking about how to 'fix the bug' here, assuming there is one at
all. As far as I can see, the only actual identified bugs here are in
Windows (not nuking the GPT disk label when it creates a new MS-DOS
label, leaving the disk in an entirely non-standard configuration) and
parted (not being able to read this particular cracktastic,
Microsoft-produced disk layout). What I'm saying is that you have to
understand that, so far as anaconda is concerned, it really doesn't know
this particular scenario you described from *any other scenario* where
parted is telling it that it couldn't make any sense of the partition
table. All anaconda knows is that it's stuck looking at a nonsensical
partition table. It has no idea what's wrong with the partition table.

> 
> > The state anaconda is in when it posts this message is the state of
> > having given up on making any sense of what the hell is on the disk in
> > question.
> 
> A state that Fedora/anaconda is responsible, in part, for having
> created in the first place by choosing to go with GPT on BIOS
> hardware; without a contingency for exactly the current situation.
> 
> The state of this disk is such that no linux distro that depends on
> parted can install along side Windows. And there is no GUI method out
> of this situation without blowing away the other operating system.
> That's just crazy - I don't see how this can be defended as
> reasonable.
> 
> 
> 
> > It has tried its hardest, but nothing doing.
> 
> That's debatable. 

I'm describing the *current situation*, not arguing about how it could
possibly be improved. The point I'm trying to get you to understand is
that you have identified one specific scenario here, but the code path
you're hitting in anaconda is one that handles many other scenarios in
addition to this one. You can't consider this situation in isolation in
analyzing what anaconda is doing. You're only going to fully understand
what's actually going on, and therefore be able to propose a good 'fix',
if you grok that.

> Why list three specific things which are definitely not true, but fail
> to list (a coherent variation of) the parted error message, which
> suggests the disk previously used GPT but now uses MBR?

Because those are by far the most common situations in which people hit
this point in anaconda. Parsing error messages from underlying tools is
a tricksy bit of business at best, and I think the kind of thing
anaconda has been trying hard to get away from doing. Tools like parted
rarely consider their error message to be 'api stable', after all. A big
focus of the anaconda team recently has been trying to eliminate
over-tricksy, fragile code and not to write any more of it.

The scenario you've identified is clearly a problem, and we can
certainly consider how to fix it. I'm just trying to make sure you
understand that the message you're seeing in anaconda is one that is
also displayed in _all sorts of other scenarios_.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net