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 eliminated. -wdc Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Attempt to configure PCMCIA 1. Attempt to use, say advansys.o driver. Additional info:
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 kernel-unsupported. 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 if: 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 clear. 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 failure.
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 RHEL 3. 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 kernel-unsupporte modules: 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, -William Cattey 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: http://www.redhat.com/security/updates/errata/ 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.