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):
Steps to Reproduce:
1.Have a bad hdlist file (mine occured from a bad training package at
Global Learning Services).
A messagewindow telling customers they "machine isn't supported by
this release". This is not correct and causes unnecessary confusion
and support requests.
A messagewindow telling customers the real cause of the problem - eg,
"bad hdlist or install tree" (or something better).
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_
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"?
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.
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)
> 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
The exact string is
_("You are trying to install on a machine "
"which isn't supported by this release of "
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.
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
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.