Re: how to detect a debian kernel from `uname -r`
On Sun, Jan 08, 2006 at 04:02:12AM +0100, Andrea Arcangeli wrote:
> On Wed, Sep 14, 2005 at 05:02:18PM +0200, Sven Luther wrote:
> > On Wed, Sep 14, 2005 at 04:46:04PM +0200, Andrea Arcangeli wrote:
> > > On Wed, Sep 14, 2005 at 11:18:46AM +0200, Sven Luther wrote:
> > > > On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote:
> > > > > On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote:
> > > > > > Not a good idea. Why clutter the namespace of versions in order to adapt to
> > > > > > non-debian needs. ? What is it you intent to do anyway ?
> > > >
> > > > Thanks to Bastian Blank, code was added to make your life easier,
> > > > /proc/version now shows the debian version after the kernel version as :
> > > >
> > > > (Debian 2.6.13-1)
> > > >
> > > > For example, not yet in released packages, and will not account for self
> > > > compiled kernels from the debian sources, but it should be usefull to you.
> > >
> > > Yes, that's nice thanks!
> > >
> > > Could you show me a full /proc/version?
> >
> > 10:49 < waldi> Linux version 2.6.13-1-powerpc64 (Debian 2.6.13-1)
> > (waldi@debian.org) (gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6))
> > #1 SMP Wed Sep 14 09:28:56 UTC 2005
>
> I enabled the parsing in KLive protocol 1 of the /proc/version according
> to the above format.
>
> As always in my code I'm paranoid and I added some overkill debugging
> runtime check, and (as usual) they triggered.
>
> See the SMS the server sent me:
>
> File "/home/klive/klive/server/regexp.py", line 69, in select_kernel_group_and_branch
> raise 'corrupted proc version', (version.groups(), kernel_release, kernel_proc_version)
> corrupted proc version: (('2.6.14-2-amd64-k8', 'Debian', '2.6.14-7'), '2.6.14-2-amd64-k8', 'Linux version 2.6.14-2-amd64-k8 (Debian 2.6.14-7)
> (maks@sternwelten.at) (gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)) #2 Fri Dec 30 06:24:03 CET 2005\n')
>
> The debugging check is this:
>
> if version.group(1)[:len(version.group(3))] != version.group(3):
> raise 'corrupted proc version', (version.groups(), kernel_release, kernel_proc_version)
>
> (originally it was:
>
> assert version.group(1)[:len(version.group(3))] == version.group(3)
>
> but I changed it to be more verbose after I noticed it was firing
> exceptions and rejecting packets)
>
> In short the above assert is verifying that "2.6.14-7" is a substring of
> "2.6.14-2-amd64-k8". Clearly something went wrong in the debian kernel
> build process if somebody has a "uname -r" == 2.6.14-2-amd64-k8 but the
> kernel group is 2.6.14-7.
-2 is the module ABI name (the name of the package), while -7 is the debian
revision, i have no idea where you get this from, mmm, i think i know, and
that the first example we gave you mislead you since it was -1, and that this
-1 was both the abi number and the debian revision. I guess you need to fix
your script again :)
Not the abi number is the one we guarantee you can run modules against for all
kernel versions that satisfy it, but you need to rebuild modules as soon as
this abi number changes.
> Note, I can as well delete this check from the server, but then kernels
> with uname -r == 2.6.14-2-amd64-k8 will be classified under the group
> "2.6.14-7" which sounds wrong. Currently the packet is rejected right
> away by twisted when the unhandled exception is fired by the assert.
In neither case is either -2 or -7 related to some kind of mainline kernel
patch level. The uname -r output is composed of :
2.6.14: kernel version
2: kernel module abi number
amd64-k8: the kernel flavour
While 2.6.14-7 is the debian revision of the package, and is composed of :
2.6.14: the kernel package upstream version.
7: the debian revision.
Note that it is not guaranteed that 2.6.14 here will stay at is, if we are
forced to rebuild the .orig tarball, because we had to remove some additional
material of dubious licencing situation in the kernel source for example, then
it will probably be something like 2.6.14a or 2.6.14.dfsg1 or some other
non-deterministic change.
So, i would use the uname -r output for your clasifying, and use the full
debian version (2.6.14-7) for identifying the exact version inside the above
main kernel version, and the flavour. I am not sure the abi number is
important; but your call. So to summarize, the important info is :
2.6.14 -> upstream kernel version
2 -> debian abi number
amd64-k8 -> debian flavour
2.6.14-7 -> debian package version
And none of those is really a subset of the other, altough the debian package
version is clearly the most unique and maps uniquely to both the kernel
version and the abi (but not the flavour).
Friendly,
Sven Luther
>
> Please let me know if I can help solving this.
>
> Thanks!
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
Reply to: