According to upstream release notes, there were API/ABI changes with OFED stuff. If userspace is not updated accordingly, it is very likely that there will be breakage.
There were several other things in the upstream release notes that I don't see mentioned anywhere with this kernel release (examples: ext4dev, bonding+ipv6). Are there plans to do this? As the release is already syncing to mirrors, I suspect the answer is "no".
I can't agree with this new policy, and I hope these comments demonstrate why.
On 09/15/2009 09:00 PM, Jason Parker wrote:
According to upstream release notes, there were API/ABI changes with OFED stuff. If userspace is not updated accordingly, it is very likely that there will be breakage.
can you point at the specific issues you have run into ?
Karanbir Singh wrote:
On 09/15/2009 09:00 PM, Jason Parker wrote:
According to upstream release notes, there were API/ABI changes with OFED stuff. If userspace is not updated accordingly, it is very likely that there will be breakage.
can you point at the specific issues you have run into ?
Cluster Suite is working no more after tonight's update. Look at: https://www.centos.org/modules/newbb/viewtopic.php?post_id=85577&topic_i...
I had to download older rpms and manually downgrade to yesterday's configuration. New 2.6.18-164.el5 kernel too was preventig cman from working properly.
Best regards, Stefano Stagnaro.
On 09/16/2009 11:23 AM, Stefano Stagnaro wrote:
I had to download older rpms and manually downgrade to yesterday's configuration. New 2.6.18-164.el5 kernel too was preventig cman from working properly.
What is the actual problem here ? there is a cman update along with the kernel updates as well. Are you saying that the new cman is unhappy with something in the new kernel ?
on 9-15-2009 1:00 PM Jason Parker spake the following:
According to upstream release notes, there were API/ABI changes with OFED stuff. If userspace is not updated accordingly, it is very likely that there will be breakage.
There were several other things in the upstream release notes that I don't see mentioned anywhere with this kernel release (examples: ext4dev, bonding+ipv6). Are there plans to do this? As the release is already syncing to mirrors, I suspect the answer is "no".
I can't agree with this new policy, and I hope these comments demonstrate why.
Upstream and CentOS always recommend that all packages get updated, not just the kernel.
Scott Silva wrote:
on 9-15-2009 1:00 PM Jason Parker spake the following:
According to upstream release notes, there were API/ABI changes with OFED stuff. If userspace is not updated accordingly, it is very likely that there will be breakage.
There were several other things in the upstream release notes that I don't see mentioned anywhere with this kernel release (examples: ext4dev, bonding+ipv6). Are there plans to do this? As the release is already syncing to mirrors, I suspect the answer is "no".
I can't agree with this new policy, and I hope these comments demonstrate why.
Upstream and CentOS always recommend that all packages get updated, not just the kernel.
I'm confused. Normally there's a period before a CentOS point release when there are no updates to the old release. Today I see that CentOS 5.3 updates repository includes kernel 2.6.18-164 and some other new packages.
Is there a new policy of backporting updates? I don't recall seeing an announcement to that effect.
Ron
On 09/16/2009 10:04 AM, Ron Yorston wrote:
Is there a new policy of backporting updates? I don't recall seeing an announcement to that effect.
'backporting' is perhaps not the right term here, these are just packages that are built along the same codepath. For people who run CentOS-5 and are not looking to reinstall with 5.4, hese are just regular updates.
I'll try and get a more comprehensive writeup and post that later in the day today.
On 09/15/2009 09:00 PM, Jason Parker wrote:
I can't agree with this new policy, and I hope these comments demonstrate why.
I just realised that it might have been you on irc last night, but you left before we could actually have a conversation.
In principle what you are saying here is not something that anyone disputes. However, the packages that are out there now are all security updates - and the EL* platform runs as a single package stream. If there are specific features that need >= versions of userland or deps of anykind, those are reflected in the package Requirements
In this case, and specially the openfabrics code, we did some testing to make sure that nothing breaks and only pushed these packages out into the public repo's after that. If there are specific breakages, lets look at resolving those.
Overall, I think its important we get the security updates out to as many people as possible - so long as we dont break things.
Jason Parker wrote:
According to upstream release notes, there were API/ABI changes with OFED stuff. If userspace is not updated accordingly, it is very likely that there will be breakage.
There were several other things in the upstream release notes that I don't see mentioned anywhere with this kernel release (examples: ext4dev, bonding+ipv6). Are there plans to do this? As the release is already syncing to mirrors, I suspect the answer is "no".
I can't agree with this new policy, and I hope these comments demonstrate why.
Vaguely related to this, I have some systems I installed from Scientific Linux, another RHEL clone, but satisfying needs that CentOS didn't at the time I did the installation.
Recently, I discovered yum-autoupdates running. It automatically downloads and installs updates.
It's my view that the responsibility for applying updates to systems I administer is mine and mine alone. I might choose to use something like yum-autoupdates to download them (highly improbable in my case), but not even Microsoft does it without the owners' explicit consent.
Here is one simple reason:
If I download and install some updates, and then something breaks, there is some prospect I might connect the events. If I don't know about the changes, I have no chance.
Downloading updates is one, on my C4 systems I have a cron job that does just that, using up2date.
I have not, so far as I can recall, had a serious breakage on any RHEL clone that resulted in the system not booting, but there were several Fedora kernels terminally incompatible with, first, a laptop. and later some HP desktops.
However sure I am that RH and CentOS (or the SL folk or that matter) test their stuff, it's my call as to whether it's fit for my use.
I trust CentOS won't follow the path of inflicting updates on users in that manner. Even automatically downloading changes should not be done without consent, user may have preferences as to time of day (bandwidth management) and repos used. Some might have local repos mirrored from official ones, I've certainly done that at times.
I've updated my repo configurations to update from CentOS, and all seems well.
On Tue, Sep 22, 2009 at 09:20:16AM +0800, John Summerfield wrote:
I trust CentOS won't follow the path of inflicting updates on users in that manner. Even automatically downloading changes should not be done without consent, user may have preferences as to time of day (bandwidth management) and repos used. Some might have local repos mirrored from official ones, I've certainly done that at times.
The sane default is for automatic updates to be enabled. If you are an on-top-of-things admin who likes or needs greater specific control, you know to disable them. Those users who aren't, however, get some level of protection.
-
Jason Parker -
John Summerfield -
Karanbir Singh -
Matthew Miller -
Ron Yorston -
Scott Silva -
Stefano Stagnaro