Very limited information is shown when updates are available
 

Hi folks,

I'm using CentOS 5.2 here, for the second time this week a popup was shown (by the Package Updater) that there was a new kernel update.
Since it's the second time this week, I really want to know what is wrong with the previous kernel, in order to decide whether it's worth the pain of having to reboot, and recompile any kernel modules.
Anyway, the dialog has a nice button that says "Update Details". When clicking on this, what I see is:

That doesn't make me any smarter if you ask me!

So, I was wondering, what's the best way to figure out the fixes that were applied to a package? Preferably without having to browse on the net.

I've read about yum-security which adds a new option to yum that allows you to list and retrieve security updates and additional information.
Reference: http://www.redhatmagazine.com/2008/0...-yum-security/

Unfortunately, yum list-sec did not list anything.
This either means that it is not supported by the CentOS repositories or that the kernel update is not security related.

Edit: I also tried yumex, but that doesn't give any more information either.

Any input is welcome.

Install a lot of yum plugins

or See the Fedora wiki documentation on software management

Don't know if by that you mean "can't get on the 'net" or if you mean "don't want to surf Google for the next 2 hours" but I would recommend seeing if CentOS/Red Hat/Fedora has a changelog on that update; RH-based distros are usually really good with documentation.

Hi Zeno,

I actually meant that I'm not willing to google for each package update on Google, just to know what they actually fixed.
I mean, if I would like a full changelog, then I'm ok with looking it up on the internet. But in my case I just want to know whether the update is critical or not. And that, I think, is something that should be provided in my update program, rather than me having to google for it. Although, thanks for the tip. Until I can't find another way of doing it, I guess I'll just stick with your solution.

To give yum access to any additional repository you have to add the repository location to your yum configuration. If a package is available for CentOS as an RPM, than chances are good that there is also a repo for it.

However, security is about trust, and it takes a lot of trust for taking packages for granted from some repo, and even more for taking them granted if they are not even part of a known repo. In case of doubt compile the software from source code - even so you will need to trust the developers.

Regular kernel updates are not a bad idea. If you want to minimize downtime, then schedule all system updates to a once-per-week session at a time with the lowest overall traffic.

As a general rule in terms of security, I agree. However, I also agree with the OP in that it's a pain to have to recompile modules every time you update the kernel if said update is unnecessary. I know current versions of VMware Workstation won't install on kernels > 2.6.26 as of this writing, for example. On the desktop, a number of people running Nvidia graphics cards ran into a brick wall after upgrading to 2.6.26 when it was first released. Yes, that's an issue with proprietary software but when an IT dept. has already made the investment, it can be a problem.

On the other hand, it beats the _other_ way of going about it: Attempting to fix proprietary software incompatibility by buying more proprietary software, like with a certain *cough* other OS. :rolleyes:

Not familiar with CentOS, or yum, or RHEL, but I'd be mighty surprised if that update forces you to recompile any kernel modules. It almost certainly is a security update which means you'd be pretty damn foolish to ignore it.

Rick

The standard Centos/RHEL installs do not come with any proprietary drivers. Unfortunately to use most of the features on current (or even not so current) hardware one needs to use the proprietary drivers/modules. Since they usually have to be built against the current running kernel, you see the issue. The advent of akmods (and similar solutions) has lessened this issue for those drivers that have been "converted". Akmods automatically recompile the modules (locally) whenever a new kernel is found at boot. Examples of this are things like video drivers, wifi, raid, etc.

Well, after updating the kernel my VMWare Server stops working.
I need to recompile the vmware modules in order to get it working again.
Same thing happens with my ATI module (fglrx).
Am I doing something wrong then?

No, that is just the way it works. It is late but I think the akmods (or similar) solutions are available for Centos too(at least I think my Nvidia driver is set up that way, but it could be on my Fedora box). It should be available for the ATi driver and VMware is popular enough now that it may even be available for it as well.

Don't bet on it.
Just upgraded Workstation from 6.5 to 6.5.1 because...wait for it...I couldn't upgrade my kernel to 2.6.27 because VMware wouldn't compile modules!!

I didn't see anything akmod-related in the 6.5.1 changelog, and until 2.6.28 comes out we may never know. Then again the problem going from .26 to .27 was related to a deprecated syscall that was removed, so that may or may not be a problem any longer. My personal experience in the last 24 hours involved changing a pointer in ../init.d/vmware from /sbin/lsmod to /bin/lsmod and everything built after that. YMMV.

Kernel updates for mission-critical iron are few and far-between; VMware knows this and they have little vested interest in keeping up with such rapid change as you find in, say a desktop/workstation environment. Fortunately for us there's VirtualBox/Bochs/Qemu, some of which may work for your particular situation, or not. Personally, while VirtualBox is more well-rounded in terms of resource-usage, it floors one core on my CPU when running Vista. Go figure.

The akmods( and the other solutions like them) are not usually made by the driver maker. They are usually made by a packager. But you are right in that using 6.5 on a .27 kernel would break the akmod(just like the regular install of 6.5). The akmods do not do anything you could not do yourself, they just automate the process.

Thanks for your input lazlow.

I've been taking a look into those akmods, and it seems they are included in the RPM Fusion repository (which is a merge of Dribble, Livna and something else). --> http://rpmfusion.org/Packaging/KernelModules/Akmods
Although, when I do yum search akmods, nothing appears. Also, seems for example that the ATI driver is called akmod-fglrx, but that doesn't list either.

Any idea what I'm missing here? I'm running Centos 5.2 x86

You might look under dkms, which was the other(older) method that I can never remember the name of(your link mentions it).

DKMS is there (in elep repository). Although, from what I've read, it's more complicated than akmods.
And isn't it strange that akmods, which I think is considered to be the default solution in the rpm fusion repository (according to the link) is not available.