1

I have a very unusual condition, perhaps a partial update or unknown condition.

#>uname -a
Linux sip02 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l GNU/Linux

#>uname -r
4.14.30-v7+

#>ls /lib/modules/`uname -r`/
/bin/ls: cannot access '/lib/modules/4.14.30-v7+/': No such file or directory

#>depmod
depmod: ERROR: could not open directory /lib/modules/4.14.30-v7+: No such file or directory
depmod: FATAL: could not search modules: No such file or directory

#>/bin/ls -shal /lib/modules/
total 16K
4.0K drwxr-xr-x  4 root root 4.0K Apr 26 02:31 .
4.0K drwxr-xr-x 16 root root 4.0K Mar 25 18:32 ..
4.0K drwxr-xr-x  3 root root 4.0K Apr 26 02:31 4.14.34+
4.0K drwxr-xr-x  3 root root 4.0K Apr 26 02:31 4.14.34-v7+

uname reports 4.14.30-v7+ but available modules are for 4.14.34-v7+.

How can I synchronize/update 'uname'? Who is telling the truth?

fcm
  • 1,789
  • 2
  • 16
  • 30

4 Answers4

3

Stefan's problem could be a bit like mine. I installed raspbian stretch on SD card but then did that thing of putting the root file system on usb and changing /boot.cmdline.txt to point to it. What happened with me it seems is that the /boot filesystem it was looking at (/boot in the rootfs on the usb) was different to the real /boot on the SD. I mounted /dev/mmcblk0p1 on /boot , reran those bootloader/kernel reinstalls and then everything matched up (umame -r and /lib/modules). If you haven't done the usb thing then this wont help ......

Kevin Williams
  • 31
  • 2
  • Thanks Kevin, that might be an interesting hint. My root system is not on another USB-device, but my */boot/cmdline.txt* is also modified, as I am having a fulldisc-encryption on my system. – Stefan Wegener Mar 14 '19 at 10:19
2

The situation you described may be the result of a failed or incomplete upgrade.

However your solution is likely to cause other problems

"In normal circumstances there is NEVER a need to run rpi-update as it always gets you to the leading edge firmware and kernel and because that may be a testing version it could leave your RPi unbootable". https://www.raspberrypi.org/forums/viewtopic.php?p=916911#p916911 Even the rpi-update documentation now warns "Even on Raspbian you should only use this with a good reason. This gets you the latest bleeding edge kernel/firmware."

sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel will put it back to the latest supported kernel/bootcode.

PS The current supported kernel is 4.14.34

PPS The recommended kernel/bootcode upgrade also cleans up the modules, and does not leave a trail of obsolete modules like rpi-update

Milliways
  • 54,718
  • 26
  • 92
  • 182
1

I had the same problem - the kernel was behind the /lib/modules revision:

# openhabian@openHABianPi:~$ uname -r
4.14.79-v7+
# openhabian@openHABianPi:~$ ls /lib/modules
4.14.98+  4.14.98-v7+

The recommended upgrade listed above solved this and updated my kernel to 4.14.98-v7+

gooman
  • 11
  • 1
  • I am having exactly the same problem (even with the same versions like you) but the "sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel"-solution did not work for me. I also had no error messages and returncode 0 when performing the upgrade... – Stefan Wegener Mar 13 '19 at 16:26
  • The proffered solution also didn't work by itself for me, but I found that once I rebooted the result returned by uname -r and /lib/modules synced up again. – zeitkunst May 26 '19 at 16:49
0

I have run into the same issue - also the "--reinstall" did not work for me. At a certain point it came to my mind that I use an internal SD card to boot into my system, which completely resides on an SSD (including an own /boot, which is mounted).

So just in case anyone has this configuration (separate SD card for booting), please make sure to first boot the correct partition into /boot (e.g. /dev/mmcblk0p1) before trying "apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel".

It worked for me.

Hndrk
  • 1
  • What do you mean with "*please make sure to first boot the correct partition into /boot (e.g. /dev/mmcblk0p1)*"? How should I make it sure? – Ingo Jul 09 '19 at 10:11