Wrong Linux Kernel Version reported by uname -a

English Install/Boot/Login
21

I have just had the same problem – uname returned the wrong kernel version – on openSUSE 11.1 after an update of coreutils from Evergreen (I suppose the latter is the cause). Downgrading the coreutils to the original version from release dvd solved the problem.
The /bin/uname was replaced by a symbolic link:

~> ls -l /bin/uname
lrwxrwxrwx 1 root root 30 Сен 29 12:17 /bin/uname -> /usr/lib/build/helper/uname.sh

~> cat  /usr/lib/build/helper/uname.sh
#!/bin/bash

OUTPUT=`uname.bin $*`

if test -f /.kernelversion ; then
  MREL=`cat /.kernelversion`
fi

if test -z "$MREL" -a -L /usr/src/linux -a -d /usr/src/linux ; then
    MREL=$( shopt -s nullglob; set -- /lib/modules/*-default /lib/modules/* ; basename $1 )
fi

if test -z "$MREL" -a -f /usr/src/linux/Makefile ; then
    MREL=`grep "^VERSION = " /usr/src/linux/Makefile 2> /dev/null | sed -e "s/VERSION = //"`
    MREL=$MREL.`grep "^PATCHLEVEL = " /usr/src/linux/Makefile 2> /dev/null | sed -e "s/PATCHLEVEL = //"`
    MREL=$MREL.`grep "^SUBLEVEL = " /usr/src/linux/Makefile 2> /dev/null | sed -e "s/SUBLEVEL = //"`
fi

if test -z "$MREL" ; then
MREL=`grep UTS /usr/include/linux/version.h 2> /dev/null | sed -ne "s/.*\"\(.*\)\".*/\1/p;q"`
fi

if test -n "$MREL" ; then
    echo $OUTPUT | sed -e "s/[0-9]\.[0-9]\.[0-9]-.0-9a-zA-Z_]*/$MREL/"
else
    echo $OUTPUT
fi

Though the /bin/uname that I see in a package /var/cache/zypp/packages/openSUSE_Evergreen_11.1/x86_64/coreutils-6.12-32.11.1.x86_64.rpm has another date stamp.

Thank you for people who replied in this thread! It helped.

P.S. Do I have to check something else related to this problem on my PC to be shure it’s ok?

22

I looked at a 64-bit machine that’s on 11.1 and Evergreen and I see no such symlink, everything is normal:

$ rpm -q coreutils
coreutils-6.12-32.11.1
$ ls -l /bin/uname
-rwxr-xr-x 1 root root 23192 2011-09-12 20:39 /bin/uname

The directory /var/lib/build doesn’t exist. Nothing in the cache, coreutils was installed several months ago. Are you sure you didn’t get your uname symlink from somewhere else, perhaps by compiling your own kernel or kernel packages?

23

Yes, that’s true. I looked in the /bin directory and found that the file /bin/uname from the coreutils of Evegreen has been installed into /bin/uname.bin. The modification date of the symlink coincided with that of some packages related to build, though I didn’t find to which package the link belongs. Was it created when the “build” command was run?
Or maybe /bin/uname was substituted by the link to the mentioned script when I installed something related to the build package. Then when I updated the coreutils it didn’t overwrite /bin/uname but rather copied the file it contained to /bin/uname.bin. After reinstalling the previous version of coreutils the file was however replaced.
Actually I have updated coreutils again and everything is ok with the uname.

24

UPD. I compiled metacity just at the date around the symlink was created, but nothing related to the kernel. Perhaps using build enchained the symlink creation.
And the coincidence (I discovered the problem after the coreutils was updated) made me suppose it might be the reason. In fact, is it normal that it didn’t replace the symlink when updating? Maybe.

25

Looking through the thread again I found that my problem is the same as for cmaessen.

26

On 2011-12-16 05:56, Nickkoz wrote:
>
> Looking through the thread again I found that my problem is the same as
> for -cmaessen-.

Just notice that evergreen has its own mail list where you can ask and
report those problems.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)