Is there some simple way of setting yum to save previous versions of the kernel so that I can go back easily when new kernels cause problems? more than the two default, say maybe 5?
On 4/18/07, Richard A. Hogaboom hogaboom@ll.mit.edu wrote:
Is there some simple way of setting yum to save previous versions of the kernel so that I can go back easily when new kernels cause problems? more than the two default, say maybe 5?
Been answered many times on this list. I went back through my cache of GMail and found an old message regarding this subject. Here's a snippet:
"As you know, FC4 doesn't have this.
In FC5, there is a /etc/yum/pluginconf.d directory and a installonlyn.conf file:
[main] enabled=1 # this sets the number of package versions which are kept tokeep=2
Fairly obviously, changing 1 to 0 will disable the plugin, and changing 2 to (say) 5 will mean you keep that many more kernels."
By the way, you might make use of the FAQ at Fedora Forums or Google Search.
-- Richard A. Hogaboom Group 65 - Advanced Networks and Applications MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02420 781-981-0276 hogaboom@ll.mit.edu
On 4/18/07, Kam Leo kam.leo@gmail.com wrote:
On 4/18/07, Richard A. Hogaboom hogaboom@ll.mit.edu wrote:
Is there some simple way of setting yum to save previous versions of the kernel so that I can go back easily when new kernels cause problems? more than the two default, say maybe 5?
Been answered many times on this list. I went back through my cache of GMail and found an old message regarding this subject. Here's a snippet:
"As you know, FC4 doesn't have this.
In FC5, there is a /etc/yum/pluginconf.d directory and a installonlyn.conf file:
[main] enabled=1 # this sets the number of package versions which are kept tokeep=2
Fairly obviously, changing 1 to 0 will disable the plugin, and changing 2 to (say) 5 will mean you keep that many more kernels."
By the way, you might make use of the FAQ at Fedora Forums or Google Search.
The responses were to change the value of "tokeep". You can also change "enable=1" to "enable=0" or totally remove the installonlyn plugin. (Go to the bottom of http://docs.fedoraproject.org/yum/en/sn-yum-customizing.html for details.)
After a quick exchange with the Red Hat QA/developer, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237203 , I realized the default installation of the installonlyn plugin is the problem. RHEL installations need the plugin. Fedora Core users do not. Why? Because the lifespan of a FC distro is short (approximately 18 months). The number of kernel updates within that time is not large. The majority of FC'ers will have upgraded to the next FC release before their disk runs out of space from kernel installs. Just disable or remove installonlyn. You are better off without it.
Kam Leo wrote:
After a quick exchange with the Red Hat QA/developer, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237203 , I realized the default installation of the installonlyn plugin is the problem. RHEL installations need the plugin. Fedora Core users do not. Why? Because the lifespan of a FC distro is short (approximately 18 months). The number of kernel updates within that time is not large. The majority of FC'ers will have upgraded to the next FC release before their disk runs out of space from kernel installs. Just disable or remove installonlyn. You are better off without it.
This is not strictly true. As the numbers of installed kernels grows on your system, it takes yum longer (and longer) to complete dependency transactions, especially those involving the kernel. I once had 7 kernels installed at the same time, and it took forever (it seemed) to install anything, or even to remove anything. As I started to remove old kernels, things started to improve. So, manage your kernels wisely.
On 4/20/07, Kevin J. Cummings cummings@kjchome.homeip.net wrote:
Kam Leo wrote:
After a quick exchange with the Red Hat QA/developer, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237203 , I realized the default installation of the installonlyn plugin is the problem. RHEL installations need the plugin. Fedora Core users do not. Why? Because the lifespan of a FC distro is short (approximately 18 months). The number of kernel updates within that time is not large. The majority of FC'ers will have upgraded to the next FC release before their disk runs out of space from kernel installs. Just disable or remove installonlyn. You are better off without it.
This is not strictly true. As the numbers of installed kernels grows on your system, it takes yum longer (and longer) to complete dependency transactions, especially those involving the kernel. I once had 7 kernels installed at the same time, and it took forever (it seemed) to install anything, or even to remove anything. As I started to remove old kernels, things started to improve. So, manage your kernels wisely.
-- Kevin J. Cummings
Strange? I have been using yum as a speedy alternative to up2date for a long time. I have not noticed any lag in yum's performance as the number of installed kernels increased. Should I have noticed this lag on my old P3-133 which still has FC3 installed or is the lag just buried in the noise with the repository delays? If there is a lag it is not noticeable on my K6-2 450 MHz system with FC6.
Richard A. Hogaboom wrote:
Is there some simple way of setting yum to save previous versions of the kernel so that I can go back easily when new kernels cause problems? more than the two default, say maybe 5?
In /etc/yum/pluginconf.d/installonlyn.conf. change tokeep=2 to tokeep=5.
Mikkel
On Wednesday 18 April 2007, Mikkel L. Ellertson wrote:
In /etc/yum/pluginconf.d/installonlyn.conf. change tokeep=2 to tokeep=5.
Unless some one can tell us which service to restart the only way I know of for this to take hold and actually work is to reboot the system.
linuxmaillists@charter.net wrote:
On Wednesday 18 April 2007, Mikkel L. Ellertson wrote:
In /etc/yum/pluginconf.d/installonlyn.conf. change tokeep=2 to tokeep=5.
Unless some one can tell us which service to restart the only way I know of for this to take hold and actually work is to reboot the system.
There is no service. This file is read by yum every time it is run. If you change it, the next time you run yum, it should pick up the new value. I routinely change this from 2 to 5 on all of my machines.
Kevin J. Cummings wrote:
In /etc/yum/pluginconf.d/installonlyn.conf. change tokeep=2 to tokeep=5.
Unless some one can tell us which service to restart the only way I know of for this to take hold and actually work is to reboot the system.
There is no service. This file is read by yum every time it is run. If you change it, the next time you run yum, it should pick up the new value. I routinely change this from 2 to 5 on all of my machines.
Have you ever actually needed to go back to something earlier than the kernel you were running when the update picked up the next one?
Les Mikesell wrote:
Kevin J. Cummings wrote:
In /etc/yum/pluginconf.d/installonlyn.conf. change tokeep=2 to tokeep=5.
Unless some one can tell us which service to restart the only way I know of for this to take hold and actually work is to reboot the system.
There is no service. This file is read by yum every time it is run. If you change it, the next time you run yum, it should pick up the new value. I routinely change this from 2 to 5 on all of my machines.
Have you ever actually needed to go back to something earlier than the kernel you were running when the update picked up the next one?
Yes, I have. Sometimes, the support modules for the new kernel are net yet available, and if I'm testing the previously new kernel, and it fails for me after installing the newest one, I need to go back to the previous one which actually worked.
Kevin J. Cummings wrote:
Yes, I have. Sometimes, the support modules for the new kernel are net yet available, and if I'm testing the previously new kernel, and it fails for me after installing the newest one, I need to go back to the previous one which actually worked.
You may want to install something like the fedorakmod extension, so that you are not offered the new kernel until the modules you need are available. Also, if you have booted to an older version of hte kernel, have newer versions of the kernel installed, and update the kernel, the oldest of the newer versions will be removed, and not the running kernel.
Mikkel
On 4/18/07, Les Mikesell lesmikesell@gmail.com wrote:
Kevin J. Cummings wrote:
In /etc/yum/pluginconf.d/installonlyn.conf. change tokeep=2 to tokeep=5.
Unless some one can tell us which service to restart the only way I know of for this to take hold and actually work is to reboot the system.
There is no service. This file is read by yum every time it is run. If you change it, the next time you run yum, it should pick up the new value. I routinely change this from 2 to 5 on all of my machines.
Have you ever actually needed to go back to something earlier than the kernel you were running when the update picked up the next one?
-- Les Mikesell lesmikesell@gmail.com
Yes, kernel-2.6.19-1.2895.fc6 broke PS/2 mouse functionality on some systems, one of which belonged to me. It took an additional three updates before an updated kernel was released which fixed the problem on my system. To date some users report their PS/2 mouse is still broken.
Since FC5 I have made it a practice of setting "tokeep" to 5. I do not maintain 5 kernels, but I keep the threshold at 5 for events such as the one above.
Kam Leo wrote:
In /etc/yum/pluginconf.d/installonlyn.conf. change tokeep=2 to tokeep=5.
Unless some one can tell us which service to restart the only way I know of for this to take hold and actually work is to reboot the system.
There is no service. This file is read by yum every time it is
run. If
you change it, the next time you run yum, it should pick up the new value. I routinely change this from 2 to 5 on all of my machines.
Have you ever actually needed to go back to something earlier than the kernel you were running when the update picked up the next one?
Yes, kernel-2.6.19-1.2895.fc6 broke PS/2 mouse functionality on some systems, one of which belonged to me. It took an additional three updates before an updated kernel was released which fixed the problem on my system. To date some users report their PS/2 mouse is still broken.
But at least on my FC5 system set to keep 2 kernels, it kept the one I was running and the new one being installed. There were many that would not boot, but they were replaced each time instead of the older one that I kept having to choose to boot.
Since FC5 I have made it a practice of setting "tokeep" to 5. I do not maintain 5 kernels, but I keep the threshold at 5 for events such as the one above.
Another response mentioned a situation where a kernel ran well enough to install the next broken one, but a problem was noticed later. In that scenario you would need more than two.
Kam Leo wrote:
Yes, kernel-2.6.19-1.2895.fc6 broke PS/2 mouse functionality on some systems, one of which belonged to me. It took an additional three updates before an updated kernel was released which fixed the problem on my system. To date some users report their PS/2 mouse is still broken.
Since FC5 I have made it a practice of setting "tokeep" to 5. I do not maintain 5 kernels, but I keep the threshold at 5 for events such as the one above.
But the kernel you are running will be kept regardless of the setting. I have had it happen a few times where there have been several kernel updates before I got around to rebooting the machine. So I had a kernel or two that had never been booted removed, while the older version I was running was still installed.
Mikkel
My computers are running FC6 and gnome. One of them, A, is connected to the stereo. Everything works fine on A but I want to control the sound remotely, from B. So, while logged on to B, I ssh to A and start up xmms. I get the message:
"Couldn't open audio (on A). Please check that your soundcard is configured properly, you have the correct output plugin selected, no other program is blocking the soundcard."
I get this error only if no one has already logged on to A directly, without having gone through ssh. If someone is logged on to A (at A) and then I ssh from B to A and start xmms, it plays normally.
Why is this and is there some workaround? Thanks for the help!
Jerry
Gerhard Magnus wrote:
My computers are running FC6 and gnome. One of them, A, is connected to the stereo. Everything works fine on A but I want to control the sound remotely, from B. So, while logged on to B, I ssh to A and start up xmms. I get the message:
"Couldn't open audio (on A). Please check that your soundcard is configured properly, you have the correct output plugin selected, no other program is blocking the soundcard."
I get this error only if no one has already logged on to A directly, without having gone through ssh. If someone is logged on to A (at A) and then I ssh from B to A and start xmms, it plays normally.
Why is this and is there some workaround? Thanks for the help!
Jerry
What you are running into is a permission problem caused by the way console.perms works. When a user logs into the console, (local login) they are given "ownership" of a bunch of non-sharable devices. When they log out, the "ownership" goes back to the default user - root in most cases. Logging in over ssh in not a console login, so permissions are not changed.
If you want to see the default setup, take a look at /etc/security/console.perms and the files in /etc/security/console.perms.d. You can also look at the console.perms man page.
Mikkel
Richard A. Hogaboom wrote:
Is there some simple way of setting yum to save previous versions of the kernel so that I can go back easily when new kernels cause problems? more than the two default, say maybe 5?
Unless it has changed recently, the one you are running during the install of the new one is the one that is kept - so even if the next 4 kernels won't boot for you, you'll still have the one that does work. I'm not sure how it makes this decision, but that was what I saw through most of the life of FC5 where the update kernels wouldn't work on one of my machines until I did a bios upgrade.
Richard A. Hogaboom said the following on 04/18/2007 11:44 AM Pacific Time:
Is there some simple way of setting yum to save previous versions of the kernel so that I can go back easily when new kernels cause problems? more than the two default, say maybe 5?
http://dailypackage.fedorabook.com/index.php?/archives/23-Wednesday-Why-Fedo...
-
Gerhard Magnus -
John Poelstra -
Kam Leo -
Kevin Cummings -
Les Mikesell -
linuxmaillists＠charter.net -
Mikkel -
Richard A. Hogaboom