[CentOS] RFI: Information for Centos 4 unsupported kernels
William L. Maltby
BillsCentOS at triad.rr.comWed Jun 21 12:15:02 UTC 2006
- Previous message: [CentOS] RFI: Information for Centos 4 unsupported kernels
- Next message: [CentOS] RFI: Information for Centos 4 unsupported kernels
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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-0001.sig>
- Previous message: [CentOS] RFI: Information for Centos 4 unsupported kernels
- Next message: [CentOS] RFI: Information for Centos 4 unsupported kernels
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the CentOS mailing list