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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
