FS#25727 - [linux] uname -r reporting schema

Attached to Project: Arch Linux
Opened by Gerhard Brauer (GerBra) - Tuesday, 23 August 2011, 11:16 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 24 August 2011, 22:22 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
uname -r shows "3.0-ARCH" on package linux 3.0.2-1. Shoudn't this not be: 3.0.2-ARCH?

Current i have a piece of code which tests for kernel revision:
--------
static int getmountver(void) {
struct utsname name;
int maj, mid, rev;
int ver;

if (uname(&name)) {
errexit(1, _("Cannot get kernel release\n"));
}
if (sscanf(name.release, "%d.%d.%d", &maj, &mid, &rev) != 3) {
errexit(2, _("Cannot convert kernel release \"%s\" to number\n"), name.release);
}
ver = maj*0x10000 + mid*0x100 + rev;
if (ver < 0x20100)
return 2;
if (ver < 0x20328)
return 3;
if (ver < 0x2051F)
return 4;
return 5;
}
---------------------

Funktion uname gives name.release which seems a triple with major.minor.patchlevel. The prog breaks here on scanf with errexit (String ARCH is not a dezimal).
I wonder if this function (uname) is a common used function and make problems also in other packages.

But this is a piece of very old code, so maybe there a actually better possibilities to ask/check for the kernel version...

So: any reason why uname -r reports 3.0-ARCH instead 3.0.2-ARCH ?
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 24 August 2011, 22:22 GMT
Reason for closing:  Not a bug
Additional comments about closing:  User just needed a nudge in the right direction.
Comment by Gerhard Brauer (GerBra) - Tuesday, 23 August 2011, 11:27 GMT
"The prog breaks here on scanf with errexit (String ARCH is not a dezimal)."

It breaks on: errexit(2, _("Cannot convert kernel release \"%s\" to number\n"), name.release);
Comment by Karol Błażewicz (karol) - Tuesday, 23 August 2011, 12:21 GMT
IIRC it's 3.0-ARCH so that the modules don't need to be rebuilt on every minor kernel release (or something ;P).
Comment by Tobias Powalowski (tpowa) - Tuesday, 23 August 2011, 12:36 GMT
Thats correct.
Comment by Gerhard Brauer (GerBra) - Tuesday, 23 August 2011, 13:21 GMT
Ok, makes sense....

Any hint for a common patch in such situations? The code is from old (2005) source from ncpfs. Do we have other packages where a patch exists to bypass such situations?
I'm not a c developer, so i could only make a dirty patch (i would try sscanf != 2 and remove rev var from the sum to build ver ...)
Or a replacement for uname lib function?
Comment by Dave Reisner (falconindy) - Tuesday, 23 August 2011, 13:40 GMT
Initialize your variables to zero before referencing them with sscanf. Example attached.
   un.c (0.5 KiB)
Comment by Gerhard Brauer (GerBra) - Wednesday, 24 August 2011, 11:41 GMT
Thanks Dave.
With your hints we were able to make a user, who must work with Novell OS (uhuhh) happy again ;-)

From my point (and with this special problem) the thread is solved... Don't know if it makes any sense to keep it open for further reference.
Comment by Karol Błażewicz (karol) - Wednesday, 24 August 2011, 22:21 GMT
You can request closure of this bug report. It will still be available for future reference as the closed bug reports are searchable just like the open ones.

Loading...