GNOME Bugzilla – Bug 681970
Fix f16 autoinstall regression
Last modified: 2016-03-31 13:56:11 UTC
Commit 169a4f51 tried to avoid the need to use remote repositories for f16 automatic installs by making it not use the QXL driver. However, this does not work as expected, and the QXL driver will be used regardless of whether it's mentioned or not in the kickstart file. Given that the QXL driver is buggy on f16 images, better to revert this for now, especially as f16 is still a supported fedora release. This reverts commit 169a4f51f4480c052a3f6e14378d9074162eaac4.
Created attachment 221347 [details] [review] Revert "express,fedora: Don't use remote repos for F16"
Review of attachment 221347 [details] [review]: What was the bug in QXL driver in F16 again?
The only thing I could find is https://bugzilla.redhat.com/show_bug.cgi?id=804834 , https://bugzilla.gnome.org/show_bug.cgi?id=672420 doesn't have much details about the actual issue unfortunately.
I thought this bug/patch was result of you trying F16 installation and facing the issue.
Anyway, I'm not at all interested in keeping hacks around for support of F16 for our F18 branch. The bug itself is in F16 installer and I have obviously cared more than maintainers of fedora installer.
(In reply to comment #4) > I thought this bug/patch was result of you trying F16 installation and facing > the issue. I've only checked that I got the qxl driver in the f16 install, which is buggy
(In reply to comment #5) > Anyway, I'm not at all interested in keeping hacks around for support of F16 > for our F18 branch. The bug itself is in F16 installer and I have obviously > cared more than maintainers of fedora installer. And why? You've just added crappy non-working code to master instead of a tested non-invasive fix for the fedora 16 issue. The fedora 16 code had basically no maintainance cost, and the new code is broken, I see no reason not to go back to the old code. Can you point at any actual maintainance cost at keeping a supported fedora distro working?
Stop re-opening bugs unless you have some new information to share that will change my mind.
Well, the current code is doubly buggy, f16 is broken, and the code is not doing what it says it's doing, sorry about that, and sorry for filing a bug about it.
In case it's not clear, 169a4f51f added "// F16 ships buggly QXL package and spice-vdagent package so simply not install those on F16 and older" which is simply not working.
Created attachment 221449 [details] [review] fedora: remove broken f16 workaround The changes introduced by 169a4f were not only dubious, they were also untested and thus broken. According to my testing, the QXL driver will be installed by default on f16 automatic installations, even with the changes from commit 169a4f, while the purpose of this commit was to avoid installing the QXL driver on these systems. Let's remove this non-working code, less code is better :) and let's hope the people testing Fedora 16 will Boxes will not get a too bad experience if they don't realize they have to upgrade their system immediately after install.
For the record, I really the initial revert is the best solution. Commit 169a4f5 is about dropping support for f16 since this will be nearly obsolete by the time GNOME 3.6 ships. However, what this commit does is replace a fedora16-specific workaround with another fedora16-specific workaround, it's not dropping support for it. Moreover, the new code is not working (the QXL driver is installed), and is making things work less good with f16. It has the side-effect of making f16 automatic installs faster, but since the initial assumption is that we are no longer interested in best-of-the-class f16 support, we could as well avoid spending any time on this issue, and just keep the existing (before 169a4f5) code as is.
It would make sense to disallow any automated installation of f16 from now on, and give a fat warning about the hanging issues with f16, also saying that it is not supported anymore.
Latest patch pushed with some changes to commit log.
(In reply to comment #13) > It would make sense to disallow any automated installation of f16 from now on, > and give a fat warning about the hanging issues with f16, also saying that it > is not supported anymore. Keeping two facts in mind: 1. We use QXL device for new VM only when libosinfo says the OS supports it. 2. The work-around we had was half-baked: It only worked for exress installations. I'd modify libosinfo db to not reflect that QXL is not supported by F16 (which isn't exactly a lie anyway).
If this change had been thought out at all, and if a real discussion had been possible about it, one could have wondered if "The version of xorg-x11-drv-qxl shipped in F16 installation DVD causes temporary hangs that lasts for enough number of seconds for libvirt to timeout." could be related to https://bugzilla.redhat.com/show_bug.cgi?id=819617 , which would make this issue much less severe. Since it seems it was more important to rush that patch in , and then to aggressively wave away any discussion attempt about it, this hasn't come up so far.