Today the kernel was updated to 3.5.0-2. However, this has caused a breakage in compiling the VirtualBox Guest Additions.
So, I wanted to go back to 3.4.6-2 and downgrade kernel-headers.
I was under the impression that "yum downgrade" would result in going back on version. But, the downgrade resulted in installing kernel-headers-3.3.4-5 and I could not find the kernel-headers-3.4.6-2 package anywhere.
I don't think this is "normal" but don't know the best wait to report the problem. Of course I'll report the breakage in 3.5.0-2 but how about the missing kernel-headers-3.4.6-2 ?
On 03/08/12 07:27, Ed Greshko wrote:
Today the kernel was updated to 3.5.0-2. However, this has caused a breakage in compiling the VirtualBox Guest Additions.
So, I wanted to go back to 3.4.6-2 and downgrade kernel-headers.
I was under the impression that "yum downgrade" would result in going back on version.
http://koji.fedoraproject.org/koji/buildinfo?buildID=333970
Handy to bookmark: http://koji.fedoraproject.org/koji/
On 08/03/2012 02:32 PM, Frank Murphy wrote:
On 03/08/12 07:27, Ed Greshko wrote:
Today the kernel was updated to 3.5.0-2. However, this has caused a breakage in compiling the VirtualBox Guest Additions.
So, I wanted to go back to 3.4.6-2 and downgrade kernel-headers.
I was under the impression that "yum downgrade" would result in going back on version.
http://koji.fedoraproject.org/koji/buildinfo?buildID=333970
Handy to bookmark: http://koji.fedoraproject.org/koji/
Thanks Frank.... At least I can download 3.4.6-2 now... But, I still wonder why the downgrade skips over it.... ?
On Fri, 03 Aug 2012 14:36:32 +0800, Ed Greshko wrote:
On 08/03/2012 02:32 PM, Frank Murphy wrote:
On 03/08/12 07:27, Ed Greshko wrote:
Today the kernel was updated to 3.5.0-2. However, this has caused a breakage in compiling the VirtualBox Guest Additions.
So, I wanted to go back to 3.4.6-2 and downgrade kernel-headers.
I was under the impression that "yum downgrade" would result in going back on version.
http://koji.fedoraproject.org/koji/buildinfo?buildID=333970
Handy to bookmark: http://koji.fedoraproject.org/koji/
Thanks Frank.... At least I can download 3.4.6-2 now... But, I still wonder why the downgrade skips over it.... ?
It isn't available in the repo(s) anymore. 3.5.0-2 has replaced 3.4.6-2 in the updates repo.
The 3.5.0 breakage is already reported, it's supposed to be fixed in the next VirtualBox release. Now that it's affecting F17 and not just Rawhide, hopefully that will be expedited.
On 08/03/2012 04:39 PM, Andre Robatino wrote:
The 3.5.0 breakage is already reported, it's supposed to be fixed in the next VirtualBox release. Now that it's affecting F17 and not just Rawhide, hopefully that will be expedited.
Yes, I did find that an implemented the workaround.'
I was more curious about the downgrade issue.....having never tried it before. Seems as if "downgrade" doesn't really mean what it says in "man yum" since the repos only contain the latest update to a package in the "updates" repo and the initial release package in the "release" repo.
On 03/08/12 09:48, Ed Greshko wrote:
I was more curious about the downgrade issue.....having never tried it before. Seems as if "downgrade" doesn't really mean what it says in "man yum" since the repos only contain the latest update to a package in the "updates" repo and the initial release package in the "release" repo.
I find a local.repo a very handy solution (yum-plugin-local) , used in conjunction with a script to keep only relevant rpms.
On Fri, Aug 03, 2012 at 04:48:13PM +0800, Ed Greshko wrote:
I was more curious about the downgrade issue.....having never tried it before. Seems as if "downgrade" doesn't really mean what it says in "man yum" since the repos only contain the latest update to a package in the "updates" repo and the initial release package in the "release" repo.
As I understand it, downgrade still requires the original rpm. So it first looks in the local yum cache, if not available looks for it on the repo.
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
On Fri, 3 Aug 2012 12:26:43 +0200, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
IMO, the community would be served better if they tried packages from updates-testing early and more often.
Individual users may keep copies of installed packages, e.g. via yum-plugin-local or by saving Yum cache contents, but evaluating updates-testing should be the primary way to check new updates for bugs.
Am 03.08.2012 12:38, schrieb Michael Schwendt:
On Fri, 3 Aug 2012 12:26:43 +0200, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
IMO, the community would be served better if they tried packages from updates-testing early and more often.
this does not help anything if there are fatal bugs reported which stops boot like https://bugzilla.redhat.com/show_bug.cgi?id=843826 and ignored in a way that since yesterday kernel 3.5 is in stable repos for F17
adn yes i installed the first 3.5 MINUTES after it was built on koji on a for me very important machine and reported the bug
On 03.08.2012, Reindl Harald wrote:
adn yes i installed the first 3.5 MINUTES after it was built on koji on a for me very important machine
An important machine should only be updated (stable or not - whatever) with a complete and functional backup prior to updating. New code doesn't only contain improvements, but introduces new bugs and flaws, too.
Am 03.08.2012 14:54, schrieb Heinz Diehl:
On 03.08.2012, Reindl Harald wrote:
adn yes i installed the first 3.5 MINUTES after it was built on koji on a for me very important machine
An important machine should only be updated (stable or not - whatever) with a complete and functional backup prior to updating. New code doesn't only contain improvements, but introduces new bugs and flaws, too.
please do not explain me my world :-)
important for me is not important for customers if it goes down i take it to the office a make a dd-dump back
my point was that i am testing many fedora-packages often long before updates-testing is seeing them and it doe snot help much if maintainers say "hm bugreport, however i push to stable"
and YES the 3.5.x currently in F17 stable is a problem 3.4.7 for F16 is a security update
so until someone knows what is going wrong in 3.5 the right decision would have been build 3.4.7 for F17 too instead psuh blindly 3.5 out - and after such decisions someone is wondering why people start ranting? __________________
https://bugzilla.redhat.com/show_bug.cgi?id=806548 https://bugzilla.redhat.com/show_bug.cgi?id=805317
2012-03-24 13:02:57 EDT 3.3.0-2.fc16 2012-05-03 12:00:53 EDT 3.3.4-3.fc17
nobody cared and fixed more than a month later 3.3.0 was a few days later pushedto stable repos __________________
i have ALWAYS backups of all important things by having each machine twice on different locations and sychronous and after 15 years in this business, the last 4 running over 20 production servers on Fedora doing all dist-upgrades from F9-F16 on them and having not lost any bit of data in my life it seems that i know waht i am doing :-)
On Fri, 03 Aug 2012 15:16:31 +0200, Reindl Harald wrote:
my point was that i am testing many fedora-packages often long before updates-testing is seeing them and it doe snot help much if maintainers say "hm bugreport, however i push to stable"
and YES the 3.5.x currently in F17 stable is a problem 3.4.7 for F16 is a security update
so until someone knows what is going wrong in 3.5 the right decision would have been build 3.4.7 for F17 too instead psuh blindly 3.5 out - and after such decisions someone is wondering why people start ranting?
Ranting alone isn't helpful. While it may be that somebody reads your messages, it could be more productive to talk to Fedora QA and find out what they think about the issue --> http://fedoraproject.org/wiki/QA
If you can hold your horses, you might even try to mail Adam Williamson privately.
On Fri, Aug 3, 2012 at 9:16 AM, Reindl Harald h.reindl@thelounge.net wrote:
so until someone knows what is going wrong in 3.5 the right decision would have been build 3.4.7 for F17 too instead psuh blindly 3.5 out - and after such decisions someone is wondering why people start ranting?
If there's one thing I know, it's that new kernels aren't pushed out blindly. If anything, I think our kernel team is doing a great job of being open about what they're working on, when they're planning on pushing out a new kernel, and looking at user feedback. They even have (bi-weekly, if I remember correctly) IRC meetings to reach out to more people for feedback. It makes me wonder whether or not you follow what they're doing, or are just assuming that they pushed 3.5 out blindly, to use your words.
Also, let me once again point out that ranting won't get you very far here. If you have a problem with the kernel, kindly try to get in touch with one of the kernel developers and then exercise some patience while they work to resolve the issue. Remember -- people work in Fedora because they're passionate about it. Ranting in the users list typically doesn't make them any more passionate about solving your problem, and frankly, often causes the exact opposite reaction.
-- Jared Smith
Am 04.08.2012 13:14, schrieb Jared K. Smith:
On Fri, Aug 3, 2012 at 9:16 AM, Reindl Harald h.reindl@thelounge.net wrote:
so until someone knows what is going wrong in 3.5 the right decision would have been build 3.4.7 for F17 too instead psuh blindly 3.5 out - and after such decisions someone is wondering why people start ranting?
If there's one thing I know, it's that new kernels aren't pushed out blindly.
how else is it explained that there is a bugreport and the reaction of the kernel-maintainer is "not my component", re-assigns it and pushs the kernel to stable
and even if it is the intel-driver and not the kernel-package this is a DISTRIBUTION and as long nobody could figure out what is going wrong 3.4.7 is the way to go
If anything, I think our kernel team is doing a great job of being open about what they're working on, when they're planning on pushing out a new kernel, and looking at user feedback.
this is all fine but if there is a report that update from 3.4 to 3.5 breaks boot all this does not help you
same happended with 3.3 where one single configure flag made the difference and we had over weeks creaping boot and partly completly unsuccessful
Also, let me once again point out that ranting won't get you very far here.
you missed the point where my answer came
it was a diret reaction to "IMO, the community would be served better if they tried packages from updates-testing early and more often" while i see how much it serves me better to use updates-testing over years all the time and now the second time a kernel-update made it to stable while ignoring my bugreports
On Fri, 03 Aug 2012 12:46:41 +0200, Reindl Harald wrote:
Am 03.08.2012 12:38, schrieb Michael Schwendt:
On Fri, 3 Aug 2012 12:26:43 +0200, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
IMO, the community would be served better if they tried packages from updates-testing early and more often.
this does not help anything if there are fatal bugs reported which stops boot like https://bugzilla.redhat.com/show_bug.cgi?id=843826 and ignored in a way that since yesterday kernel 3.5 is in stable repos for F17
1) Ticket history reveals that there has been a very quick response by davej: https://bugzilla.redhat.com/show_activity.cgi?id=843826 So, your bug report has not been ignored, albeit reassigned to a different component without any comment. Hot potatoe...
In retrospect, I cannot tell whether davej should not have submitted 3.5.0-2.fc17 as a test update three days later, knowing that 3.5.0-1.fc17 causes problems. It looks like there is disagreement about the problem you've reported.
2) You could have left negative karma on the test-update: https://admin.fedoraproject.org/updates/FEDORA-2012-11323/kernel-3.5.0-2.fc1...
3) Nobody claims that the current way Fedora Testing is done, would be bullet-proof. IMO, it's a known problem that some updates are rushed out and should spend much more time in testing.
bodhi - 2012-08-01 18:25:37 This update has been pushed to testing bodhi - 2012-08-01 21:44:56 This update has reached the stable karma threshold and will be pushed to the stable updates repository
This is ridiculous! One of Fedora's weak spots. :-(
This particular kernel is also an example of a "karma fight" within bodhi, with several testers ignoring the guidelines, unfortunately:
http://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Previously_repor...
They voted +1, compensating previous -1 votes. :-(
Am 03.08.2012 16:02, schrieb Michael Schwendt:
On Fri, 03 Aug 2012 12:46:41 +0200, Reindl Harald wrote:
Am 03.08.2012 12:38, schrieb Michael Schwendt:
On Fri, 3 Aug 2012 12:26:43 +0200, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
IMO, the community would be served better if they tried packages from updates-testing early and more often.
this does not help anything if there are fatal bugs reported which stops boot like https://bugzilla.redhat.com/show_bug.cgi?id=843826 and ignored in a way that since yesterday kernel 3.5 is in stable repos for F17
- Ticket history reveals that there has been a very quick response
by davej: https://bugzilla.redhat.com/show_activity.cgi?id=843826 So, your bug report has not been ignored, albeit reassigned to a different component without any comment. Hot potatoe...
yes, but xorg-x11-drv-intel-2.20.1-1.fc17.x86_64 works fine with kernels before 3.5 and the hardware i use in the bugreport is not exotic
In retrospect, I cannot tell whether davej should not have submitted 3.5.0-2.fc17 as a test update three days later, knowing that 3.5.0-1.fc17 causes problems. It looks like there is disagreement about the problem you've reported.
but the problem is there
i have TWO of this machines, both doe snot boot until "nomodeset" as kernel-param with 3.5 which results in something like 800x600 resultion on a 25" LED what makes it impossible for me to do anything after some medical operations on my eyes, even no debug
This particular kernel is also an example of a "karma fight" within bodhi, with several testers ignoring the guidelines, unfortunately:
http://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Previously_repor...
They voted +1, compensating previous -1 votes. :-(
and this is unacceptable behavior
if every koji build would give a link to the karma page it would be easier to give bad carma, but as long this is not easy possible it has to be enough that i test a koji-build long before it reaches updates-testing and report a bug to prevent make it to stable
holy hell it is even not possible to give "bad karma" with fedoa-easy-karma in the state i reported the bug
_______________________________________
i had installed on both of my machines any kernel-update since F14 partly ones which never did reach stable from koji
after that having one which does not bot at atll, report it and become the yum-response below shot time after is a bad joke
3.4 is not EOL proven by the 3.4.7 update for F16 in updates-testing i even rolled out to production machines last night after internal tests because it has a security-flag
so the way to go after get a report 3.5.x F17 does not boot on standard intel-hardware the way to go is hold back 3.5 for F167 stable and update F17 to 3.4.7 for now
========================================================================================================================= Package Arch Version Repository Größe ========================================================================================================================= Installieren: kernel x86_64 3.5.0-2.fc17 updates 26 M kernel-devel x86_64 3.5.0-2.fc17 updates 7.5 M Aktualisieren: kernel-headers x86_64 3.5.0-2.fc17 updates 846 k
Vorgangsübersicht ========================================================================================================================= Installieren 2 Packages Upgrade 1 Package
Gesamte Downloadgröße: 34 M Ist dies in Ordnung? [j/N] :n
On Fri, 03 Aug 2012 16:14:20 +0200, Reindl Harald wrote:
- Ticket history reveals that there has been a very quick response
by davej: https://bugzilla.redhat.com/show_activity.cgi?id=843826 So, your bug report has not been ignored, albeit reassigned to a different component without any comment. Hot potatoe...
yes, but xorg-x11-drv-intel-2.20.1-1.fc17.x86_64 works fine with kernels before 3.5 and the hardware i use in the bugreport is not exotic
Let's not talk past eachother. I didn't claim there was no bug. Only davej could tell why a 3.5.0 kernel test-update has been offered inspite of this early-warning bug report.
All I understand is that the Fedora test-update process does not guarantee that the update -- if pushed to stable -- will be free of bugs and free of regression for everyone.
It will need some project policies to determine whether a single user's bug report could block an update, or whether maintainers are permitted to overrule bug reporters => sometimes trade-off decisions are necessary. Current testing only scratches the surface. It could be that 3.5.0 fixes many more issues than it causes regression.
In retrospect, I cannot tell whether davej should not have submitted 3.5.0-2.fc17 as a test update three days later, knowing that 3.5.0-1.fc17 causes problems. It looks like there is disagreement about the problem you've reported.
but the problem is there
Repeating that again and again is nothing else than going in circles. Sure, this problem affects you personally. However, more interesting is to figure out what has gone wrong related to the bug report and how to avoid failures like that in the future (e.g. with a more restrictive update policy and disabled karma automatism in bodhi for some packages). Humans make mistakes. It can happen that if a bug report is not clear and concise, its impact is not recognized.
On Fri, Aug 03, 2012 at 12:38:13PM +0200, Michael Schwendt wrote:
On Fri, 3 Aug 2012 12:26:43 +0200, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
IMO, the community would be served better if they tried packages from updates-testing early and more often.
Individual users may keep copies of installed packages, e.g. via yum-plugin-local or by saving Yum cache contents, but evaluating updates-testing should be the primary way to check new updates for bugs.
Well the comment about trying packages from updates-testing is always true. I often try to do that, but sometimes it is not possible because you might want to have an extremely reliable system for a couple of months or so. You hold off updates that require reboots or logouts and soon your local cache is outdated, and a future downgrade fails.
On 08/03/2012 03:26 AM, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
By default, yum keeps the most recent 3 kernels installed. How often do you think users need to downgrade past that?
On 3 August 2012 19:14, Joe Zeff joe@zeff.us wrote:
On 08/03/2012 03:26 AM, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
By default, yum keeps the most recent 3 kernels installed. How often do you think users need to downgrade past that?
But not the kernel headers, or indeed any other package.
On 08/03/2012 01:09 PM, Ian Malone wrote:
On 3 August 2012 19:14, Joe Zeff joe@zeff.us wrote:
On 08/03/2012 03:26 AM, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
By default, yum keeps the most recent 3 kernels installed. How often do you think users need to downgrade past that?
But not the kernel headers, or indeed any other package.
I was under the impression that they were kept until the kernel they applied to was removed. And, as I understand it, the headers for each kernel are kept in a separate directory named after the version. If they're not kept (and my understanding of their location is correct) then you should be able to get them back if needed, without downgrading the kernel.
Am 03.08.2012 22:41, schrieb Joe Zeff:
On 08/03/2012 01:09 PM, Ian Malone wrote:
On 3 August 2012 19:14, Joe Zeff joe@zeff.us wrote:
On 08/03/2012 03:26 AM, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
By default, yum keeps the most recent 3 kernels installed. How often do you think users need to downgrade past that?
But not the kernel headers, or indeed any other package.
I was under the impression that they were kept until the kernel they applied to was removed
how comes that you do not look what yum does?
kernel AND kernel-devel are installed in multiple version kernel-headers are UPDATED only, this is not new
[root@buildserver:~]$ rpm -qa | grep kernel kernel-headers-3.4.7-1.fc16.x86_64 kernel-3.4.4-4.fc16.x86_64 kernel-3.4.7-1.fc16.x86_64
Joe Zeff wrote:
I was under the impression that they were kept until the kernel they applied to was removed. And, as I understand it, the headers for each kernel are kept in a separate directory named after the version. If they're not kept (and my understanding of their location is correct) then you should be able to get them back if needed, without downgrading the kernel.
kernel-headers != kernel-devel
The kernel-headers package is for GLIBC usage and contains header files located in /usr/include. Please see "rpm -ql kernel-headers" output. You only have this package installed if you installed glibc-devel and only installed glibc-devel if you are compiling software. This is not installed as part of a default Fedora install. Only one kernel-headers package is maintained on your system.
The kernel-devel package is for compiling kernel modules and indeed these development files are in kernel version specific directory names. You will have a matching kernel-devel package for each kernel package installed if you have installed kernel-devel. Like kernel-headers kernel-devel must be manually installed by the user.