I just ran an update with zypper that installed a new kernel, 2.6.27.23-0.1. From all I can tell, this kernel is running and booting just fine, but uname -r tells me that I am running 2.6.27.19-3.2-default, and a system info screenlet says the same. I am a little baffled, since I cannot find this 2.6.27.19 kernel on my hard drive, nor in /boot/grub/menu.lst. This problem existed already before the kernel update, when I was presumably running 2.6.27.21, but I had just assumed that the next kernel update would fix it. I couple of months ago I had to roll back the update from 2.6.27.19 to 2.6.27.21 because it broke my wireless.
Which kernel am I actually running, and how can I make uname -r report that accurately, if that is indeed the problem?
did zypper ref and zypper lu - here’s the output of zypper lu:
yace@sabre:~> sudo zypper lu
Loading repository data...
Reading installed packages...
S | Repository | Name | Version | Arch
--+------------+------------+------------+-----
v | Java | subversion | 1.6.2-10.1 | i586
doesn’t say anything about the kernel I can see…
Yes, of course I have rebooted, and I am sure I booted to the new kernel from the grub menu. Like I say, I had this problem under the previous kernel as well (or before this kernel update), ever since I had to roll back a kernel update a couple of months ago because it broke my wireless. Things now appear to be the same as they were then, i.e. it has been saying 2.6.21.19-3.2 ever since March or so…
Can you show us the output of:
rpm -qa | grep kernel
Things not working after a kernel update are 99% drivers. Mostly the new driver versions appear a couple of days after the kernel update. So either you have been warned during update that these modules were going to be removed, but continued and installed the new kernel, which would mean that ‘uname -r’ shows it, or it did not install at all.
If you look in the folder /lib/modules you should find a folder for the new kernel.
… I don’t see any 2.6.27-19 in there…
and here are some highlights of the long and lovely /boot/grub/menu.lst, composed all but entirely by yast2 without any regard to human collaboration. It is too long to post in its entirety, but I generally just leave it on 0 timeout and default 1, so the last 100 entries should be irrelevant. here is the beginning:
# Modified by YaST2. Last modification on Tue Jun 9 22:30:36 BST 2009
default 1
timeout 0
##YaST - generic_mbr
gfxmenu (hd0,0)/boot/message
##YaST - activate
###Don't change this comment - YaST2 identifier: Original name: linux###
title Trace -- openSUSE 11.1 - 2.6.27.23-0.1 (trace)
root (hd0,0)
kernel /boot/vmlinuz-2.6.27.23-0.1-trace root=/dev/sda1 resume=/dev/sda2 usbcore.autosuspend=1 rw quiet splash=silent showopts vga=0x311
initrd /boot/initrd-2.6.27.23-0.1-trace
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.1 - 2.6.27.23-0.1 (default)
root (hd0,0)
kernel /boot/vmlinuz-2.6.27.23-0.1-default root=/dev/sda1 resume=/dev/sda2 usbcore.autosuspend=1 rw quiet splash=silent showopts vga=0x311
initrd /boot/initrd-2.6.27.23-0.1-default
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.1 - 2.6.27.23-0.1 (default)
root (hd0,0)
kernel /boot/vmlinuz-2.6.27.23-0.1-default root=/dev/sda1 showopts ide=nodma apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe
initrd /boot/initrd-2.6.27.23-0.1-default
…etc… There are entries for all the 2.6.27.23 kernels, then 2.6.27.21, etc. and about 30 entries in, there is indeed a series of entries for 2.6.27.19, e.g.:
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.1 - 2.6.27.19-3.2 (default)
root (hd0,0)
kernel /boot/vmlinuz-2.6.27.19-3.2-default root=/dev/sda1 resume=/dev/sda2 usbcore.autosuspend=1 rw quiet splash=silent showopts vga=0x311
initrd /boot/initrd-2.6.27.19-3.2-default
I am booting from default… that should be entry 1 in the menu (i.e. the first position in the list would be entry 0)
Why all those entries: Good question! I delete them from time to time, but Yast puts them back in whenever it updates my kernel. I will clean those up and see if that helps.
Why all those kernels: because I was saved from a disastrous crash a couple months ago caused by shutting down during a kernel update. The thing that saved me was a kernel out of the zillions that had not been updated. Similarly, if something breaks on a driver update, etc., and I am travelling and don’t have time to fix it, I have a quick-and-dirty alternative.
On a related note: how come I have modules for the 2.6.27.23 series and 2.6.27.19 series, but almost none for 2.6.27.21?
I completely agree… Same with me here.
Updated today and see exactly(!) the same.
Even on my disk, there is absolutely no left overs of the older kernel (no RPM, no kernel files, no boot menu entries), EXCEPT for some update kernel-modules that got reused by the new kernel as “weak-updates”. These are
lirc*, omnibook, kqemu, hci_usb
Just solved it… and made a mistake:
Trying to debug the reason on uname, I found gdb telling me uname was not a valid executable(!?) and the debuginfo package would not fit to it…
So I reinstalled (the same version) of coreutils (which contains uname) and now it shows me the correct version string.
@adpads: Maybe there is somebody who wants to diagnose this issue. So you should create a copy of /bin/uname before you reinstall coreutils package.
Thanks to all! I have updated coreutils (don’t know why yast offered me an update to coreutils 6.12-32.10 when system should have been theoretically up to date). Will reboot and see if that fixes the problem.
For anyone that wants to troubleshoot this issue, here is my old /bin/uname:
#!/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
Update:
All I was able to find was some hints about the “MREL” names that are used in that script. They lead to Redhat Linux! Are you sure you are running a clean openSuSE 11.1?