[CentOS] RFI: Information for Centos 4 unsupported kernels

[William L. Maltby]

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
-- 
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.centos.org/pipermail/centos/attachments/20060621/73f7df1a/attachment.sig>