Re: how to detect a debian kernel from `uname -r`

[Andrea Arcangeli <andrea@cpushare.com>]

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.

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.

Please let me know if I can help solving this.

Thanks!