Installed kernel does not match `uname -a`

krsmith28p · 2018-01-11 11:03:37

Mod Note: split from https://forums.bunsenlabs.org/viewtopic.php?id=4505 -HoaS

As a user of the stock kernel, following on from message #32 is the advice then, to update the kernel, as per the linked guide (but crossed out instruction - or is that my browser?) or to wait for the stock kernel to be fixed. I guess use-case will be the determining factor.
I dual boot with arch, so I can afford to wait and keep my BL install as simple as possible -
BL~$ grep TABLE_ISO /boot/config-$(uname -r)
BL-$ [ie no output]
BL~$ uname -a
Linux debianBL 4.5.0-0.bpo.2-amd64 #1 SMP Debian 4.5.3-2~bpo8+1 (2016-05-13) x86_64 GNU/Linux
(desktop up to date (update && upgrade) in BL as at date Thu 11 Jan 10:47:31 GMT 2018 )

Arch (same machine) gives
$ zgrep TABLE_ISO /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y
~>$ uname -a
Linux arch-b 4.14.12-1-ARCH #1 SMP PREEMPT Fri Jan 5 18:19:34 UTC 2018 x86_64 GNU/Linux

Not sure if the info helps any!
K

Last edited by Head_on_a_Stick (2018-01-16 19:18:37)

Head_on_a_Stick · 2018-01-12 06:56:23

krsmith28p wrote:

As a user of the stock kernel
[...]
BL~$ grep TABLE_ISO /boot/config-$(uname -r)
BL-$ [ie no output]
BL~$ uname -a
Linux debianBL 4.5.0-0.bpo.2-amd64 #1 SMP Debian 4.5.3-2~bpo8+1 (2016-05-13) x86_64 GNU/Linux
(desktop up to date (update && upgrade) in BL as at date Thu 11 Jan 10:47:31 GMT 2018 )

Erm, that's _not_ our stock kernel and it isn't up to date either

I'm guessing that you have somehow removed the linux-image metapackage and instead installed a single, fixed kernel version — this is not a good idea and will leave your system vulnerable.

Can we please see the output of:

apt-cache policy linux-image-amd64

As you can see from the build date, your kernel is over six months old and needs to be updated ASAP.

krsmith28p · 2018-01-16 11:17:02

Erm, that's _not_ our stock kernel and it isn't up to date either
I'm guessing that you have somehow removed the linux-image metapackage and instead installed a single, fixed kernel version — this is not a good idea and will leave your system vulnerable.
Can we please see the output of:
apt-cache policy linux-image-amd64
As you can see from the build date, your kernel is over six months old and needs to be updated ASAP.

That's a little worrying - I have not deliberately made any kernel changes
$ apt-cache policy linux-image-amd64
linux-image-amd64:
Installed: 3.16+63+deb8u1
Candidate: 3.16+63+deb8u1
Version table:
4.9+80+deb9u2~bpo8+2 0
100 http://ftp.debian.org/debian/ jessie-backports/main amd64 Packages
100 http://httpredir.debian.org/debian/ jessie-backports/main amd64 Packages
*** 3.16+63+deb8u1 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
3.16+63 0
500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages

I also tried this on my laptop which has a BL install - with exactly the same result. Plus I've installed onto my daughters machines for Uni.....

I confess the output means little to me. What could I have done ? (So I don't do it again)
Thanks
K

krsmith28p · 2018-01-16 11:41:00

Actually I'm wrong - The laptop does report this:

krsmith28p wrote:

$ apt-cache policy linux-image-amd64
linux-image-amd64:
Installed: 3.16+63+deb8u1
Candidate: 3.16+63+deb8u1
Version table:
4.9+80+deb9u2~bpo8+2 0
100 http://ftp.debian.org/debian/ jessie-backports/main amd64 Packages
100 http://httpredir.debian.org/debian/ jessie-backports/main amd64 Packages
*** 3.16+63+deb8u1 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
3.16+63 0
500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages

but uname -a reports 3.16.51-3+deb8u1 dated 8 Jan 2018

I confess the output means little to me. What could I have done ? (So I don't do it again)

I googled - if i understand correctly "***" means 'installed', so is uname reporting a different kernel is running from the one installed?
Even on my laptop why does uname report 3.16.51-3 not 3.16+63 - or is that a different numbering convention?

Head_on_a_Stick · 2018-01-16 19:28:50

krsmith28p wrote:

why does uname report 3.16.51-3 not 3.16+63

3.16+63 is for the linux-image-amd64 metapackage and this doesn't actually contain the kernel image but instead always lists the current kernel version as a dependency; the current package that contains the actual kernel is indeed 3.16.51-3 so everything there looks fine to me.

In respect of your desktop, you must be booting into an old kernel version.

Which bootloader (or bootmanager) are you using and how is it configured?

Have you updated the bootloader configuration since updating the kernel version?

BunsenLabs will do this automatically but it will only take effect if BL "controls" the boot process — this will be the case if BunsenLabs was the last operating system to install a bootloader to either the MBR of the hard drive (for non-UEFI systems) or the NVRAM of the motherboard (for UEFI systems).

krsmith28p · 2018-01-16 21:28:53

In respect of your desktop, you must be booting into an old kernel version.
Which bootloader (or bootmanager) are you using and how is it configured?

That may be well be the case - it also boots Linux Mint which my son is currently playing a steam game on, and Mint 'owns' Grub.

grub.cfg entry for BunsenLabs says "vmlinuz-4.5.0-0.bpo.2-amd64". I suspect this should be 4.9 not 4.5. based on the version table reported by "apt-cache policy linux-image-amd64"

When he's done I'll try updating grub. I could reboot from my ssh session, but that might be considered underhand.

Thanks

K

krsmith28p · 2018-01-17 10:26:11

OK thanks for explanations and guidance.
My BL install now reports the right kernel, and

BL-$ grep TABLE_ISO /boot/config-$(uname -r) 
 CONFIG_PAGE_TABLE_ISOLATION=y

Updating Mint's grub wasn't enough on its own,

mint-# grub-mkconfig -o /boot/grub/grub.cfg

did not find BunsenLabs newer kernel.

I put an entry in /etc/grub.d/40_custom

menuentry "BunsenLabs on sda1" {
    set root=(hd0,1)
        linux /vmlinuz root=/dev/sda1 ro quiet
        initrd /initrd.img
}

If I understand correctly, (following another grub-update), this starts the newest kernel on the partition it refers to (hd0,1). It should keep up with any future changes, therefore.
I may not be immune from Spectre, but feel a whole heap happier security for other vulnerabilities are now in the running kernel....
Thanks again
K

Head_on_a_Stick · 2018-01-17 20:50:56

krsmith28p wrote:

Updating Mint's grub wasn't enough on its own,
mint-# grub-mkconfig -o /boot/grub/grub.cfg
did not find BunsenLabs newer kernel.

Oh really? That's a bit worrying

krsmith28p wrote:

If I understand correctly, (following another grub-update), this starts the newest kernel on the partition it refers to (hd0,1).

Not quite — that entry is using the symlinks that Debian maintains from the current running kernel & intrd to the root directory.

This is advantageous because it means that the entry does not have to be changed every time the kernel is updated.

It may be worth adding another stanza so that you can boot the old kernel version as well (just in case there are any problems with a new kernel):

menuentry "BunsenLabs (old kernel)" {
    set root=(hd0,1)
        linux /vmlinuz.old root=/dev/sda1 ro quiet
        initrd /initrd.img.old
}

jr2 · 2018-01-18 01:09:14

<ot>

Head_on_a_Stick wrote:

...using the symlinks that Debian maintains from the current running kernel & intrd to the root directory.
This is advantageous because it means that the entry does not have to be changed every time the kernel is updated.

Hooray for abstraction!
</ot>

Head_on_a_Stick · 2018-01-18 06:57:38

jr2 wrote:

Hooray for abstraction!

I can't say I agree in this case — symlinks are an abomination against the FHS 8o

I much prefer the technique employed by Arch & Alpine Linux — their kernel images are just called "vmlinuz" (vmlinuz-vanilla in Alpine's case) with no version numbers so there's no need for any silly soft links 8)

Sorry for the OT, OP.

We'll stop now

krsmith28p · 2018-01-22 08:33:01

Every wrinkle means I learn a little more each time....

Thanks
K

#1 2018-01-11 11:03:37

Installed kernel does not match `uname -a`

#2 2018-01-12 06:56:23

Re: Installed kernel does not match `uname -a`

#3 2018-01-16 11:17:02

Re: Installed kernel does not match `uname -a`

#4 2018-01-16 11:41:00

Re: Installed kernel does not match `uname -a`

#5 2018-01-16 19:28:50

Re: Installed kernel does not match `uname -a`

#6 2018-01-16 21:28:53

Re: Installed kernel does not match `uname -a`

#7 2018-01-17 10:26:11

Re: Installed kernel does not match `uname -a`

#8 2018-01-17 20:50:56

Re: Installed kernel does not match `uname -a`

#9 2018-01-18 01:09:14

Re: Installed kernel does not match `uname -a`

#10 2018-01-18 06:57:38

Re: Installed kernel does not match `uname -a`

#11 2018-01-22 08:33:01

Re: Installed kernel does not match `uname -a`

Board footer