Red Hat Bugzilla – Bug 125671
kernel-unsupported concept is broken
Last modified: 2007-11-30 17:07:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040527
Description of problem:
Previous versions of Red Hat, and Fedora Core understand the idea of
making it easy for customers to run legacy hardware.
With the advent of kernel-unsupported, I've started getting lots of
reports from the people my team supports of having problems that
magically go away if we tell them "install kernel-unsupported".
We've got one major customer that does a repackage of Red Hat Enterprise
and who wants to just make kernel-unsupported part of that default
install. Apparently it's a non-trivial question to rpm-list to learn
how to call rpmlib in such a way that we guarantee that
kernel-unsupported is installed before kernel.
We opened bug ID 123505 to complain that "you're just supposed to know
to install kernel-unsupported" is insufficient documentation for how
to get PCMCIA working properly.
I can understand the desire to try and start fresh and make a clean
break with legacy hardware. But that desire should take a back seat
to graceful switch over of customers from the old Red Hat to the new.
As near as I can tell this was just someone's clever idea of an
arbitrary set of distinctions to make between current and legacy, and
that the actual effect is a bunch of obscure failures for loyal Red
Hat customers as they switch to Enterprise.
PLEASE give serious consideration to getting rid of
kernel-unsupported. The alternatives to doing so would be:
1. Review the PCMCIA support and fix up the broken depencies.
2. Review the list of legacy hardware and move back into kernel
those items that were common in the past few years.
3. EXTENSIVE documentation of where installs, and configurations fail
to clue customers into the new lore of, "Did your driver used to be
found? Try installing kernel-unsupported."
My personal opinion is that kernel-unsupported was an interesting
approach but that experience shows it was a mistake and it should be
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Attempt to configure PCMCIA
1. Attempt to use, say advansys.o driver.
The whole concept of kernel-unsupported was not taken lightly. It was
a well-intentioned approach which tried to strike a balance between
usefulness and support burden. We carefully went through each module
and reviewed its overall enterprise product readiness and applicability.
Ultimately we have finite resources to develop, test and support. To
some extent, everything we ship becomes a support liability. The
concept of kernel-unsupported is to accommodate end-users where things
"just work" and to be able to differentiate those components from the
fully supported items. For example, the testing performed on each
update primarily consists of the supported packages. We are unable to
test the nearly infinite permutations and combinations of items in
The end result is that we will please a set of end-users, and others
will walk away with a less than ideal perception. However we felt
that there would have been even more disgruntled end users if we
didn't have kernel-unsupported at all. Supporting everything is not a
practical option for us.
For later releases we are focusing more on laptop features. Hopefully
the user experience there will be improved.
Thank you for the speedy response.
The kernel-unsupported concept would have appeared as if more thought were given to it
1. There was easy-to-find documentation listing the de-supported device drivers.
2. The de-support of those device drivers was done between versions of RHE, not during
the rest of the rocky road from RH9.
3. If bug ID 123505 had been properly followed up with either a corrected set of
dependencies or at the very least, a correction to the PCMCIA portion of the install to
actually mention kernel-unsupported.
4. There was documentation of how to gracefully force an install of kernel-unsupported
before the kernel RPM.
Having been supporting desktop Linux for 5 years, and laptop linux for 2 years (all built
out of Red Hat) and desktop Unix since we pioneered large scale deployment of desktop
Unix in 1990, I very much appreciate the issue of making what is and is not supported
In the fullness of time you will discover that you must explicitly wean customers off of
what was supported before, and you must do extra work to migrate them off of things that
were not really supported, but which they ended up relying upon.
Understand this: Your roll-out of kernel-unsupported has created problems for our site
here at MIT that is migrating 1000 desktops to Red Hat Enterprise, and which has LEGACY
support of laptops.
Waiting for a subsequent version of Red Hat with improved laptop support is just as viable
an option to us as switching to SuSE.
You could provide help to us if you got someone to look at and clean up the broken
dependencies in the PCMCIA support as reported in Bug ID 123505.
At the present time, on our own, we have kludged a way to force-install kernel-
unsupported, because our customers expect this stuff to work and to be migrated
explicitly in spite of how Red Hat has chosen to do it.
I am concerned you are too wedded to your concept of kernel-unsupported and that you
are not listening adequately to what needs to be done now to help your customers migrate
to Enterprise. At the very least you need to produce a clearer pointer to release notes that
names all the drivers moved into kernel-unsupported.
I am reopening this bug because, if you ARE going to keep going with kernel-
unsupported, then you need to correct the inadequate documentation of it.
I must apologize for my somewhat unpleasant tone here.
I've been a bit overwhelmed. In comparison to the uneventful migrations from
7.1 to 7.2 to 8.x to 9, my team has had to confront many things that used to work
that we perceive as broken for reasons that we as outsiders do not understand.
Then when I review the explanation my differing experience leads me to bewilderment
as the design tradeoffs are so different from the ones my team would have made.
(Or in some cases, did make when we confronted the issue earlier than you guys did.)
Digging more into this issue, and thinking very hard about it,
it seems to me that there is more than a documentation issue.
There is the sub-case of unsupported devices that are possibly used
to hold root filesystems. Only those devices need be constrained
to install before kernel and to be carefully managed to be installed
before kernel updates so that initrd does the right thing.
If we're lucky, all the others can be installed as an afterthought.
Although it would generate more complexity to have more than the one
giant bucket of unsupported modules, having TWO, one with a hook to
guarantee the initrd constraint is obeyed might be of significant
value to the architecture.
Shipping PCMCIA support that is broken unless kernel-unsupported is
present still seems to me have been an easily remedied quality control
To repeat something I've said in the sibling case to this one
where the PCMCIA support issue itself is being worked:
People here at MIT tell me that this problem has been "solved" by the deletion
of the kernel-unsupported RPM from RHEL 4, and associated with that deletion the
loss of a fair number of device drivers that used to be just hunky dory under
Could someone at the Red Hat side please follow up with maybe a pointer to a
white paper that makes explicit 3 categories of action taken on
1. Now supported.
2. Never gonna be supported.
3. In process of being supported.
Or is it the case that we should just make our own list consisting of:
"Anything you don't see in the modules now is never gonna be supported".
As unhappy as I would be to see that list of drivers, explicit closure here
would be a good thing.
Thanks in advance,
MIT Linux Platform Coordinator
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.
There are SO many better ways to have handled this.
A friend who is active in the Fedora community helped me find people who actually read bug reports, and
who are interested in working through these issues. It's Red Hat's inability to respond in a timely and
helpful way to issues like this that drive people to Ubuntu.