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).