1:44 p.m.
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?
--
Richard A. Hogaboom
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood St.
Lexington, MA 02420
781-981-0276
hogaboom(a)ll.mit.edu
2:01 p.m.
On 4/18/07, Richard A. Hogaboom <hogaboom(a)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(a)ll.mit.edu
3:51 p.m.
On 4/18/07, Kam Leo <kam.leo(a)gmail.com> wrote:
On 4/18/07, Richard A. Hogaboom <hogaboom(a)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.
7:21 p.m.
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
kjchome(a)rcn.com
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://counter.li.org)
8:46 p.m.
On 4/20/07, Kevin J. Cummings <cummings(a)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.
2:07 p.m.
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
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
10:47 p.m.
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.
--
If the word following begins with
a vowel, the word you want is...
to read the rest of this, go here
http://www.wsu.edu/~brians/errors/a.html
11:11 p.m.
linuxmaillists(a)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
kjchome(a)rcn.com
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://counter.li.org)
11:49 p.m.
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(a)gmail.com
11:52 p.m.
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
kjchome(a)rcn.com
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://counter.li.org)
11:18 a.m.
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
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
1:07 a.m.
On 4/18/07, Les Mikesell <lesmikesell(a)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(a)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.
1:19 a.m.
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.
--
Les Mikesell
lesmikesell(a)gmail.com
11:14 a.m.
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
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
10:48 a.m.
New subject: sound question
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
12:26 p.m.
New subject: sound question
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
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
2:08 p.m.
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.
--
Les Mikesell
lesmikesell(a)gmail.com
2:11 p.m.
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-F...
6190
days inactive
6222
days old
17 comments
8 participants
participants (8)
-
Gerhard Magnus -
John Poelstra -
Kam Leo -
Kevin Cummings -
Les Mikesell -
linuxmaillists＠charter.net -
Mikkel -
Richard A. Hogaboom