Very limited information is shown when updates are available
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
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.
Last edited by ptemmerman; 11-13-2008 at 02:43 AM.
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.
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.
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.
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.
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.
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.
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.
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.
...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.
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
Last edited by ptemmerman; 11-27-2008 at 10:48 AM.
Reason: typo
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.