RE: How to identify contents of /lib/modules/*

[Cameron, Steve]

[e-mail] wrote:

> The truth is, the kernel rpms for this distro are not designed to be 
> installed side by side, they really ought to be upgraded (meaning the 
> old stuff gets removed, so there's no ambiguity). Do you actually 
> have customers that are installing multiple kernels and moving /lib/modules 
> dirs around? (I know we do this in our labs, and you may too, but I 
> can't imagine too many customers doing this...)

Yes, the RPMs in question overwrite the currently used kernel.... 
(then of course, the user is rather amazed and disgusted at the 
nerve of this RPM.   The next time he has such an RPM to install 
he remembers this event, and saves off his old kernel and 
/lib/modules directory before the RPM can destroy it.)

> > Also note, I can't just figure out which is the _running_ kernel  [...]
? Hmm... I'm not sure how feasible that's going to be... 

The problem case here is this one:

1) You have a brand new machine, with a brand new disk controller.
You install the OS, use a driver diskette for the brand new
disk controller.  The driver diskette is made for the default
kernel installed by the base media.  

2) You install a new errata kernel (because let's suppose the one on the CD
has known security problems, or something.)  However, you cannot 
reboot yet because the new errata kernel does not contain a driver which 
understands your new controller.

3) Install RPM driver for the new controller.  The RPM cannot rely on 
the running kernel, because you don't care about the running kernel,
you care about the errata kernel that you just installed, but which is
not yet running.

So feasible or no, we must try.  (Anyway, I think I have something
that will work, it's just kinda ugly, is all, and I was hoping
there was a beter way.)

> Is there any chance that SuSE (oops, let the cat out of the bag ;) 

I never said SuSE.  (Excellent guess though. :-)

> would accept your driver(s) into their distribution, or

Yes, that's no problem.  But it's always too late.
There will always be the case that we must support old
kernels that were deployed before the hardware that we're
trying to support.  And by "support" I also mean that
some level of testing has occurred, so this isn't possible.

Thanks for your thoughts on the matter.

-- steve