Hi,
this may sound stupid, but; - I'd like to install unsupported x86/i386 smp kernel because I need some support (for eg. dual booting for r/w files for winXP) etc. I'm now using 4.3 latest smp kernel. (I've tested that x86 still runs better than x86_64 like I was told in January. Thanks for the advice.)
Questions: Is there any documentation for how to install unsupported smp kernel so that'll be able to do normal updates (like I've been updating until now without features of unsupprted kernel) ? I've downloaded the kernel files (107), how should I install them (yes, I know how to install rpm files but; but for grub, for updating, for upgrading etc.) ? After updating kernel few times with normal updating processes there lies in grub many older kernel. Is there any process to delete them or do I have to do it manually ?
If this is too boring to others or outside the topics of this mailing list, please reply straightly to me.
For the CentOs Team many thanks of superb distro (used in many of our servers without any problems, and we'll have them more in near future).
Regards, Kari
On Tue, 2006-06-20 at 22:32 +0300, Kari Salovaara wrote:
Hi,
this may sound stupid, but;
- I'd like to install unsupported x86/i386 smp kernel because I need
some support (for eg. dual booting for r/w files for winXP) etc. I'm now using 4.3 latest smp kernel. (I've tested that x86 still runs better than x86_64 like I was told in January. Thanks for the advice.)
Questions: Is there any documentation for how to install unsupported smp kernel so that'll be able to do normal updates (like I've been updating until now without features of unsupprted kernel) ? I've downloaded the kernel files (107), how should I install them (yes, I know how to install rpm files but; but for grub, for updating, for upgrading etc.) ?
You can edit the file /etc/yum.conf.d/CentOS-Base.repo and enable the CentOSPlus repo ... find the [centosplus] section and set:
enabled=1
also I would recommend setting this in the centosplus section:
includepkgs=kernel kernel-devel kernel-smp kernel-smp-devel kernel-hugemem kernel-hugemem-devel kernel-largesmp kernel-largesmp-devel
and I would recommend this in the [base] and [updates] sections:
exclude=kernel kernel-devel kernel-smp kernel-smp-devel kernel-hugemem kernel-hugemem-devel kernel-largesmp kernel-largesmp-devel
The exclude and includepkgs lines above are all on one line ... and this will allow upgrades of kernels only from CentOSPlus in the future.
If you are getting other packages from centosplus ... include them in the lines as well.
After updating kernel few times with normal updating processes there lies in grub many older kernel. Is there any process to delete them or do I have to do it manually ?
Yes, you need to remove old kernels ... as they are not removed by upgrades. (The old kernel may need to be booted in a problem, so yum will install new kernels).
After rebooting on a new kernel, I remove the ones I don't want to save by doing:
rpm -qa | grep kernel | sort
then
rpm -e kernel-xxxx kernel-devel-xxxx
(substitute the kernels you want to get rid of)
There is a yum-plugin somewhere to keep only n kernels ... I have never used it, but it might work too.
If this is too boring to others or outside the topics of this mailing list, please reply straightly to me.
For the CentOs Team many thanks of superb distro (used in many of our servers without any problems, and we'll have them more in near future).
You are welcome
Thanks, Johnny Hughes
On Wed, 2006-06-21 at 05:47 -0500, Johnny Hughes wrote:
On Tue, 2006-06-20 at 22:32 +0300, Kari Salovaara wrote:
Hi,
this may sound stupid, but;
- I'd like to install unsupported x86/i386 smp kernel because I need
some support <snip>
Questions: Is there any documentation for how to install unsupported smp kernel so that'll be able to do normal updates (like I've been updating until now without features of unsupprted kernel) ?
I see Johnny does not say "yes" or "no". :-) Maybe a topic for an intro somewhere or a FAQ, although AFAICT it has not made it to FAQ status. I feel like this Q has enough widespread application that it may deserve more than a "check the archives" solution, which your post provides.
I've downloaded the kernel files (107), <snip>
After rebooting on a new kernel, I remove the ones I don't want to save by doing:
rpm -qa | grep kernel | sort
<OT> Since I have *my* habitual way of doing things (less typing) I do want to be sure that I'm not risking something by assuming that rpm can handle a "selector" just because it happened to provide good results on my small test. So I thought I'd ask.
"They" say "Necessity is the mother of invention". Being who/what I am, I assert "Laziness is the mother of invention". So ...
Why not this,
rpm -qa kernel*|sort # Laziness trumping readability here, no # spaces. But that's not my main point.
instead of what you demonstrate. I tried it on my own (admittedly parochial) small setup and achieved identical results. I am concerned that my lack of breadth, such as your and other setups might have, may not produce identical results like mine.
I have discovered over the years that often a certain way of doing things are remnants of early learning (older less capable OSs, picked up while learning packages like bash, ...), ingrained habit, temporary insanity (esp. when dire results result ;-) and have effects that may be unwanted: introducing increased opportunity for error in the typing, adding unnecessary load to the system (my speedy little red sporty car and Yammy YZF 750 give away my reason for this concern), taking longer to type the command. Uh, I *guess* n00bs learning by example would also be a valid concern?
Anyway, to keep from getting on my soap box, I'll mention my pet peeve and then quit.
# My favorite variation on this next line is cat <file_xyz cat file_xyz | first_command_in_pipeline rest_of_pipeline
instead of
# Here is a shorter line, with valid use of I/O redirection first_command_in_pipeline <file_xyz rest_of_pipeline
Again, since I have *my* habitual way of doing things (less typing) I do want to be sure that I'm not risking something by assuming that rpm can handle the "selector" just because it happened to provide good results on my small test. </OT>
then
rpm -e kernel-xxxx kernel-devel-xxxx
(substitute the kernels you want to get rid of)
Extending the OP's question slightly, if we have multiple <pkg X> installed (presuming something else might be handled as is the kernel) and it comes via the normal yum/repo route, should we use yum to remove unneeded versions? My thought is that yum should be safer since it shows additional information and offers a chance to change our mind.
<snip>
TIA
On Wed, 2006-06-21 at 08:15 -0400, William L. Maltby wrote:
On Wed, 2006-06-21 at 05:47 -0500, Johnny Hughes wrote:
On Tue, 2006-06-20 at 22:32 +0300, Kari Salovaara wrote:
<snip>
After rebooting on a new kernel, I remove the ones I don't want to save by doing:
rpm -qa | grep kernel | sort
<snip>
Why not this,
rpm -qa kernel\*|sort # Laziness trumping readability here, no # spaces. But that's not my main point.instead of what you demonstrate. I tried it on my own (admittedly
<snip>
Well, I haven't dug heavily into the docs, but ran a small quick test while investigating a "fubar'd rpm db" that Karan and Ralph caught. There does appear a difference in output in the two styles of rpm query, depending on install at this limited stage of investigation. Is it an advantage or disadvantage? POV/immediate need will determine that I quess.
My lazy version first.
[root@wlmlfs08 ~]# rpm -qa rpm* | sort >/tmp/tmp ; cat /tmp/tmp rpm-4.3.3-11_nonptl.i386 rpm-4.3.3-13_nonptl.i386 rpm-build-4.3.3-11_nonptl.i386 rpm-build-4.3.3-13_nonptl.i386 rpmdb-CentOS-4.2-0.20051011.i386 rpmdb-CentOS-4.3-0.20060314.i386 rpm-devel-4.3.3-11_nonptl.i386 rpm-devel-4.3.3-13_nonptl.i386 rpmforge-release-0.3.4-1.el4.rf.i386 rpm-libs-4.3.3-11_nonptl.i386 rpm-libs-4.3.3-13_nonptl.i386 rpm-python-4.3.3-11_nonptl.i386 rpm-python-4.3.3-13_nonptl.i386 [root@wlmlfs08 ~]#
The suggested version next and a diff at the end.
[root@wlmlfs08 ~]# rpm -qa|grep rpm|sort >/tmp/tmp2;cat /tmp/tmp2; \
diff /tmp/tmp /tmp/tmp2
redhat-rpm-config-8.0.32.1-1.noarch rpm-4.3.3-11_nonptl.i386 rpm-4.3.3-13_nonptl.i386 rpm-build-4.3.3-11_nonptl.i386 rpm-build-4.3.3-13_nonptl.i386 rpmdb-CentOS-4.2-0.20051011.i386 rpmdb-CentOS-4.3-0.20060314.i386 rpm-devel-4.3.3-11_nonptl.i386 rpm-devel-4.3.3-13_nonptl.i386 rpmforge-release-0.3.4-1.el4.rf.i386 rpm-libs-4.3.3-11_nonptl.i386 rpm-libs-4.3.3-13_nonptl.i386 rpm-python-4.3.3-11_nonptl.i386 rpm-python-4.3.3-13_nonptl.i386 0a1
redhat-rpm-config-8.0.32.1-1.noarch
[root@wlmlfs08 ~]#
The grep version has the (dis?)advantage of including things not directly a part of the hunt we were conducting. So for scripting purposes, it seems that the grep version may have some caveats. But for "hoomon" investigation, this may be a desirable feature.
This doesn't definitively answer my Q, but gives me an optimism that the abbreviated form I use a *lot* may be safe. A look at the docs should confirm. I'll not post on this again unless I see something different.
<snip sig stuff>
On Wed, 2006-06-21 at 08:15 -0400, William L. Maltby wrote:
On Wed, 2006-06-21 at 05:47 -0500, Johnny Hughes wrote:
On Tue, 2006-06-20 at 22:32 +0300, Kari Salovaara wrote:
Hi,
this may sound stupid, but;
- I'd like to install unsupported x86/i386 smp kernel because I need
some support <snip>
Questions: Is there any documentation for how to install unsupported smp kernel so that'll be able to do normal updates (like I've been updating until now without features of unsupprted kernel) ?
I see Johnny does not say "yes" or "no". :-) Maybe a topic for an intro somewhere or a FAQ, although AFAICT it has not made it to FAQ status. I feel like this Q has enough widespread application that it may deserve more than a "check the archives" solution, which your post provides.
There is a readme here:
http://mirror.centos.org/centos/4/centosplus/Readme.txt
That and my instructions should be plenty good enough. How you resolve this issue is way to varied to try and cover it completely ... examples:
1. You way want all the centosplus updates and not need to do anything except exclude items from [base] and [updates] repos.
2. You may want to use protectbase plugin and protect centosplus from the other centos repos
3. You may be using something like yum-plugins-priorities to assign a lower priority to centosplus than base and updates ... so you only need to use exclude= in centosplus to remove packages that you don't want to see ... but don't need any includepkgs= anywhere.
The bottom line is that there is documentation provided for yum in many places, and people who want to administer a CentOS box should become familiar with:
http://wiki.centos.org/PackageManagement/Yum
and this:
http://mirror.centos.org/centos/4/docs/html/yum/
and this:
http://wiki.centos.org/Repositories
and maybe this:
http://mirror.centos.org/centos/4/docs/html/yumex/
Then to use centosplus they should read this:
http://mirror.centos.org/centos/4/centosplus/Readme.txt
If in doubt, start on the centos-4 docs page:
http://mirror.centos.org/centos/4/docs/
or the CentOS wiki:
I've downloaded the kernel files (107), <snip>
After rebooting on a new kernel, I remove the ones I don't want to save by doing:
rpm -qa | grep kernel | sort
<OT> Since I have *my* habitual way of doing things (less typing) I do want to be sure that I'm not risking something by assuming that rpm can handle a "selector" just because it happened to provide good results on my small test. So I thought I'd ask.
"They" say "Necessity is the mother of invention". Being who/what I am, I assert "Laziness is the mother of invention". So ...
Why not this,
rpm -qa kernel\*|sort # Laziness trumping readability here, no # spaces. But that's not my main point.instead of what you demonstrate. I tried it on my own (admittedly parochial) small setup and achieved identical results. I am concerned that my lack of breadth, such as your and other setups might have, may not produce identical results like mine.
I have discovered over the years that often a certain way of doing things are remnants of early learning (older less capable OSs, picked up while learning packages like bash, ...), ingrained habit, temporary insanity (esp. when dire results result ;-) and have effects that may be unwanted: introducing increased opportunity for error in the typing, adding unnecessary load to the system (my speedy little red sporty car and Yammy YZF 750 give away my reason for this concern), taking longer to type the command. Uh, I *guess* n00bs learning by example would also be a valid concern?
Anyway, to keep from getting on my soap box, I'll mention my pet peeve and then quit.
# My favorite variation on this next line is cat <file_xyz cat file_xyz | first_command_in_pipeline rest_of_pipeline
instead of
# Here is a shorter line, with valid use of I/O redirection first_command_in_pipeline <file_xyz rest_of_pipeline
Again, since I have *my* habitual way of doing things (less typing) I do want to be sure that I'm not risking something by assuming that rpm can handle the "selector" just because it happened to provide good results on my small test.
</OT>
Should be just fine ... I just said what I did ... not that it is the best or even a good way to do it :)
then
rpm -e kernel-xxxx kernel-devel-xxxx
(substitute the kernels you want to get rid of)
Extending the OP's question slightly, if we have multiple <pkg X> installed (presuming something else might be handled as is the kernel) and it comes via the normal yum/repo route, should we use yum to remove unneeded versions? My thought is that yum should be safer since it shows additional information and offers a chance to change our mind.
I personally never EVER use yum to remove anything ... as it resolves dependencies and recommends sometime tens of packages to remove.
I use yum to install / upgrade packages, I feel much more comfortable resolving my own dependencies when removing packages :) (that is just a personal bias).
-
Johnny Hughes -
Kari Salovaara -
William L. Maltby