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

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

[Cameron, Steve]

Alan Cox wrote:

> On Mer, 2003-04-16 at 03:00, Stephen Cameron wrote:
> > The task for the binary driver distributor becomes to figure out which
> > of these multiple errata kernels found in /boot corresponds to the 
> > /lib/modules directory, so we can drop the binary driver that was
> > made for that errata kernel in there, and not a driver made for the
> > wrong kernel.
> 
> if its an rpm based distro
> 
> 	rpm -qf /lib/modules/[version]/something
> 
> will tell you which kernel owns the file.
[...]

Yep. I thought of that too, which is why I had also written:

steve> Also, rpm -qf to try to id the RPM from which some /lib/modules file
steve> or vmlinuz won't necessarily work, as rpm can report they belong to 
steve> multiple RPMs in certain cases.

I think it's the use of "--force" option to RPM that causes this,
or else, faulty RPMs.  It's not so easy to make a well-behaved
RPM.  Having tried myself, sometimes I think maybe RPM 
really stands for "Revolting Pile of Manure". (no offense ;-) Of 
course I'm probably trying to bend it do a job for which perhaps 
it is not so well suited.

-- steve

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

[Alan Cox]

On Mer, 2003-04-16 at 16:58, Cameron, Steve wrote:
> I think it's the use of "--force" option to RPM that causes this,
> or else, faulty RPMs.  It's not so easy to make a well-behaved
> RPM.  Having tried myself, sometimes I think maybe RPM 
> really stands for "Revolting Pile of Manure". (no offense ;-) Of 
> course I'm probably trying to bend it do a job for which perhaps 
> it is not so well suited.

Only --force allows the same file to be owned by two packages. Otherwise
RPM throws a fit about it. People who use --force I file in the same
category as overclockers, CB amp hackers and the like 8)

At that point the answer basically is what is being run depends on 
precisely what order it was forced and how. Its probably not sanely
computable.

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

[Henning P. Schmiedehausen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>Only --force allows the same file to be owned by two packages. Otherwise

No. Look at this:

% rpm -qf /usr/lib/libamanda-2.4.4.so
amanda-client-2.4.4-2t
amanda-server-2.4.4-2t

%  rpm -ql amanda-client | grep libamanda
/usr/lib/libamanda-2.4.4.so
/usr/lib/libamanda.so
% rpm -ql amanda-server | grep libamanda
/usr/lib/libamanda-2.4.4.so
/usr/lib/libamanda.so

rpm allows this if both rpms supply an identical file. Which they do
(they're cut from the same SRPM). It's not nice but it definitely
works without --force. I never use --force on rpm.

This is on RedHat 7.3 with rpm-4.0.4-7x.18

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

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

[Perez-Gonzalez, Inaky]

> From: Kristofer T. Karas [mailto:ktk@enterprise.bidmc.harvard.edu]
>
> I have a worse problem.  :-)   I often run several instances of the
> identically version-numbered kernel, all available from the LILO boot
> menu, each instance having a different .config or perhaps compiled with
> a different gcc.  If each instance wants to share
> /lib/modules/[sameversion]/... then I've got a problem.

I solve that appending to EXTRAVERSION ... 2.5.66.5.2-rtfutex is the
latest build of the 20+ 2.5.66 slightly different kernels I have 
installed in the same machine for testing. And they all have different
module directories.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

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

[Kristofer T. Karas]

On Wed, 2003-04-16 at 10:21, Alan Cox wrote:
> if its an rpm based distro
> 	rpm -qf /lib/modules/[version]/something
> will tell you which kernel owns the file.
> 
> Its a horrible thing to need to do however

I have a worse problem.  :-)   I often run several instances of the
identically version-numbered kernel, all available from the LILO boot
menu, each instance having a different .config or perhaps compiled with
a different gcc.  If each instance wants to share
/lib/modules/[sameversion]/... then I've got a problem.  Ditto for
userspace programs compiled against /usr/include/linux and
/usr/include/asm, where I want the compiled program to correspond very
closely with the currently running kernel.  So...

I "fixed" this problem by creating /lib/modules/BootsAs/,
/usr/include/BootsAs/, etc.  Then, rc.sysinit looks in /proc/cmdline to
figure out what I typed at LILO, greps through /etc/lilo.conf to find
the physical /boot/[xyzzy].vmlinux that was booted, and it creates
symlinks so /lib/modules/[sameversion] -> /lib/modules/BootsAs/[xyzzy]
and so on.  This is also a win when you have several LILO targets that
point to the same kernel.

Kris -- running heavily hacked Slackware.

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

[Cameron, Steve]

Paul.Clements@steeleye.com 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

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

[Paul Clements]

On Wed, 16 Apr 2003, Stephen Cameron wrote:

> A certain major linux distribution distributes a number of binary 
> kernels, errata kernels, which all report the exact same thing 
> via "uname -r".  These kernels may differ by only a little
> (only the .config file is different in some small way) or by 
> a lot (binary drivers for one don't work (panic) on another).

We've run into the same problems here, with this *unnamed* major Linux distro ;) We distribute pre-compiled versions of open source 
drivers that contain additional features or bug fixes that aren't in the standard/included drivers...

 
> The task for the binary driver distributor becomes to figure out which
> of these multiple errata kernels found in /boot corresponds to the 
> /lib/modules directory, so we can drop the binary driver that was
> made for that errata kernel in there, and not a driver made for the
> wrong kernel.

I think you just have to assume that the running kernel is the one that gets its module upgraded (or installed). And that the /lib/modules directory that is in the standard location for that kernel (i.e., it hasn't been moved somewhere else in preparation for installing another kernel) is the one corresponding to the running kernel. This is what we do in our installation process... no one has complained about this behavior as far as I know. I don't know that there's any other sane way to handle this... :/

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

 
> This seems like a lot of contortions to go through and I'm wondering
> if there's a simpler way to identify the contents of /lib/modules, 
> aside from the 'uname -r' type string, and I just missed it.

Have you tried "cat /proc/version" ? It's got the build date of the kernel in it...

 
> Also note, I can't just figure out which is the _running_ kernel
> (by checksumming /boot/vmlinuz, cross-checked against /etc/lilo.conf
> or grub conf file, because in certain situations the running kernel
> is only there to install another kernel.  And we want to provide
> the option to install the driver for all the kernels on the system
> that we can (reliably) find.)

Hmm... I'm not sure how feasible that's going to be... Maybe you could just ask customers to run the setup script (or whatever you install with) once they're booted on the kernel that they intend to run the system on? Either that or maybe they just have to tell the setup which kernels they want modules installed for (maybe you give them a proposed list, based upon checking the system)?

Is there any chance that SuSE (oops, let the cat out of the bag ;) would accept your driver(s) into their distribution, or
is this proprietary HP stuff? They've been very helpful in accepting various patches from us...


Anyway, I don't know if any of that helped... this really is a nasty situation to have to deal with... I'm not sure there's any perfect solution... you're probably just going to have to make some assumptions and intelligent guesses and hope for the best!

Good luck...

--
Paul

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

[Jeremy Jackson]

You should definitely mention this to your distribution creator.  IMHO, it's
seriously broken if uname -r isn't distinct.  Debian is unfortunately a
victim of this; I have modded my kernel-image source package to *fix* it.  I
don't recall RedHat having this problem, but other RPM based I don't know.
Can you say what your distro is?

Cheers,

Jeremy
----- Original Message -----
From: "Stephen Cameron" <steve.cameron@hp.com>
To: <linux-kernel@vger.kernel.org>
Sent: Tuesday, April 15, 2003 10:00 PM
Subject: How to identify contents of /lib/modules/*


>
> Hi, here's a problem I'm having, perhaps someone has some smart idea...
>
> A certain major linux distribution distributes a number of binary
> kernels, errata kernels, which all report the exact same thing
> via "uname -r".  These kernels may differ by only a little
> (only the .config file is different in some small way) or by
> a lot (binary drivers for one don't work (panic) on another).

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

[Dominik Kubla]

Am Mittwoch, 16. April 2003 16:21 schrieb Alan Cox:
...
> if its an rpm based distro
>
> 	rpm -qf /lib/modules/[version]/something
>
> will tell you which kernel owns the file.
>
> Its a horrible thing to need to do however

And it's

	dpkg -S|--search /lib/modules/[version]/something

for dpkg-based distributions. 

Regards,
  Dominik
-- 
Those who can make you believe absurdities can make you commit
atrocities.    (Francois Marie Arouet aka Voltaire, 1694-1778)

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

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Wed, 2003-04-16 at 04:00, Stephen Cameron wrote:
> Hi, here's a problem I'm having, perhaps someone has some smart idea...
> 
> A certain major linux distribution distributes a number of binary 
> kernels, errata kernels, which all report the exact same thing 
> via "uname -r".  These kernels may differ by only a little
> (only the .config file is different in some small way) or by 
> a lot (binary drivers for one don't work (panic) on another).

this is what modversions are for ;)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Alan Cox]

On Mer, 2003-04-16 at 03:00, Stephen Cameron wrote:
> The task for the binary driver distributor becomes to figure out which
> of these multiple errata kernels found in /boot corresponds to the 
> /lib/modules directory, so we can drop the binary driver that was
> made for that errata kernel in there, and not a driver made for the
> wrong kernel.

if its an rpm based distro

	rpm -qf /lib/modules/[version]/something

will tell you which kernel owns the file.

Its a horrible thing to need to do however

How to identify contents of /lib/modules/*

[Stephen Cameron]

Hi, here's a problem I'm having, perhaps someone has some smart idea...

A certain major linux distribution distributes a number of binary 
kernels, errata kernels, which all report the exact same thing 
via "uname -r".  These kernels may differ by only a little
(only the .config file is different in some small way) or by 
a lot (binary drivers for one don't work (panic) on another).

I seem to be in the business of distributing binary drivers to customers,
like it or not.  Since there already exist multiple incompatible
errata kernels that all share the same uname -r and hence the same
directory for modules, and since all these errata kernels *might*
be found on a single machine in /boot.... (only one of which is likely
to be viable, since there is only one /lib/modules directory for
them all)...

The task for the binary driver distributor becomes to figure out which
of these multiple errata kernels found in /boot corresponds to the 
/lib/modules directory, so we can drop the binary driver that was
made for that errata kernel in there, and not a driver made for the
wrong kernel.

So far, the best idea I have come up with is to construct a database
of checksums of all the *.o files in the various /lib/modules directories
that come with the various errata kernels, then compare that database
against what is actually found in /lib/modules.  (note, the results will
likely never match _exactly_, since binary driver distributors like myself
can drop .o files in /lib/modules, and alos, this distribution doesn't use
the symbol name checksums, so identical *.o files appear occasionally in
/lib/modules for different errata kernels.)  Then count which errata kernel 
matches the most *.o files, and assume that must be the one (and probably
should have some minimum numver to match, lest the user have only kernels
we know nothing about)

This seems like a lot of contortions to go through and I'm wondering
if there's a simpler way to identify the contents of /lib/modules, 
aside from the 'uname -r' type string, and I just missed it.

Also note, I can't just figure out which is the _running_ kernel
(by checksumming /boot/vmlinuz, cross-checked against /etc/lilo.conf
or grub conf file, because in certain situations the running kernel
is only there to install another kernel.  And we want to provide
the option to install the driver for all the kernels on the system
that we can (reliably) find.)

Also, rpm -qf to try to id the RPM from which some /lib/modules file
or vmlinuz won't necessarily work, as rpm can report they belong to 
multiple RPMs in certain cases.

Thanks for any other ideas.

-- steve