Red Hat Bugzilla – Bug 122697
Anaconda tells users their hardware isn't supported when it is.
Last modified: 2007-11-30 17:07:01 EST
Description of problem: A bad hdlist file tells customers they're installing on unsupported hardware. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106590 That isn't the cause of the problem. Version-Release number of selected component (if applicable): 9.1.1-7.RHEL How reproducible: Always Steps to Reproduce: 1.Have a bad hdlist file (mine occured from a bad training package at Global Learning Services). Actual results: A messagewindow telling customers they "machine isn't supported by this release". This is not correct and causes unnecessary confusion and support requests. Expected results: A messagewindow telling customers the real cause of the problem - eg, "bad hdlist or install tree" (or something better). Additional info:
Bad hdlist vs no viable kernel result in the same thing -- no available kernel package for your architecture in the hdlist. And realistically, if your hdlist is bad then the machine _isn't_ supported since things won't get created right.
</i>realistically, if your hdlist is bad then the machine _isn't_ supported<i> No arguments that this is an error condition, but the error message makes it sound like a hardware problem - then they contact support (I'm a contractor for Red Hat Asia Pacific). Its a pretty minor fix: how about like you put it: "No available kernel package for your architecture in the hdlist"? Cheers, Mike
That's jargon that most users don't want or need to care about. Any references to "header list" or "kernel" in user visible strings are on my list of things to kill as they don't say anything to an actual user.
Wouldn't this error message normally occur to people who've customized their install tree anyway? How about a simpler solution then? "Your installation isn't supported" "Machine" implies hardware to most people.
ping?
Any change like this is a string change (thus can't happen for RHEL3 as that would break all translations) so it's somewhat of a future item. And I'm not convinced that I agree with you yet :)
> Any change like this is a string change (thus can't happen for RHEL3 as that would break all translations) Indeed. > And I'm not convinced that I agree with you yet :) Then I must convince you! :^) You seem to want to make the language in the install simpler, and I think s/machine/installation/ makes it simpler to find out what's wrong. If my *machine* wasn't supported, I'd assume I was being told my hardware didn't meet the mimimum requirements or the Red Hat HCL. Hearing my *install* was not supported would make me think I've done something when customizing my install to make it unsupported - which is true. Thanks, Mike
The exact string is _("You are trying to install on a machine " "which isn't supported by this release of " "%s.") %(productName,) Which is very much the case -- the hardware isn't supported by this specific release. Saying "by this installation" is far more vague about what it means which is going to be more problematic for users who aren't customizing things and end up trying to install on older hardware. Does it mean that just the installer doesn't support them? The case of customizing installs is very much the rare corner case, and I'd hope that people doing it would think that they may have messed something up if the install works before they change things and then doesn't after they've done so.
As I've said, the Red Hat Hardware Compatibility List tells customers their hardware *is* supported. Fine. Support gets more calls from customers for no reason. yes, customizing installs is a corner case. No that doesn't mean we should tell customeers their hardware isn't supported when that's not the cause of the problem. You have the ability to arbitrarily close this bug with no peer review, so I'm sure you will. If that wasn't the case though I doubt you would. Ciao.
We don't support customizing installs and the string says exactly what it means to both myself and a lot of other people -- this isn't something that I end up with people not understanding and we're far better off than from before we did this (which just left people with a broken system)
- The Supported Hardware List is the canonical place that indicates whether hardware is supported. - The customer's hardware is on that list, and therefore supported. - The error is not a hardware error. It should not use the term hardware. An inaccurate error message is indeed better than a broken system. It is, however, inferior to an accurate error message. John, if you can find anyone else who disagrees with the above, please encourage them to post here.
Actually, the error uses the term 'system' rather than 'hardware', but the above points still apply.
I tend to agree with Jeremy here that this really is on the following counts: 1) Users who hit this error have most likely followed an unsupported path to create an uninstallable tree. 2) No hardware is supported without the kernel - so the statement is true 3) Installation implies an instance of running the installer, or a completed install which this really isn't the case For FC5 hdlists are dying, and as string changes aren't appropriate for update releases this really doesn't strike me as something we want to address.
"2) No hardware is supported without the kernel - so the statement is true" The fact you had to explain that to me, and that I've had to explain it to other people, means the error message is clearly suboptional. And I think that's a justification for a poor error message than an explanation - hardware is supported whether there's a kernel on it or not: there are machines that don't have RHEL installed on them (but will later), which we still call supported hardware. But hey, I don't really care if hdlists and the crappy error message are going away in future releases anyway. Thanks for your response Paul.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.