Bug 24785

Summary:	uname sometimes returns a wrong kernel name
Product:	Mageia	Reporter:	Juergen Harms <juergen.harms>
Component:	RPM Packages	Assignee:	Thomas Backlund <tmb>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	lewyssmith
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	coreutils-8.31-1.mga7.src.rpm	CVE:
Status comment:
Attachments:	Copy of current /boot/grub2/grub.cfg Output of ls -al /boot \| sort

Description Juergen Harms 2019-05-07 22:27:46 CEST

Description of problem:

The name of the kernel (1) effectivley active (as - for instance - displayed with ls -l "/boot/vmlinuz") and (2) given by "uname -s" can be different.

For instance, right now my Mageia-7 beta-3 system has been updated to kernel 5.1.0-desktop-1.mga, but uname displays 5.1.0-desktop-0.rc7.2.mga7 as the name of the active kernel (which had been previously active); looking at /boot/vmlinuz, this is not correct - and this persists through further kernel upgrades.

This problem only happens if the system has been booted by activating the top-level boot-menu item "Mageia" (my system uses grub2 uefi) - if the system is launched by hitting the sub-menu item of "Advanced options for Mageia" which targets kernel 5.1.0-desktop-1.mga, uname will provide the correct name (these names of items and sub-items of the boot menu are the default generated by the Mageia install procedure).

This may sound far-fetched, but can be a serious source for confusion, see also https://bugs.mageia.org/show_bug.cgi?id=24692

Complementary observations
--------------------------
1. "uname -a" also provides a date; that date looks like the date when the corresponding kernel had been installed - if the indicated kernel is not correct, the date of the installation of the incorrect kernel name.

2. I am using a laptop (Tuxedo Book BC1507) and a desktop computer (HP EliteDestop 800 G4) - this problem manifests itself on both machines.

3. Cauldron had (on one of these machine) been installed from Mageia-7 beta-1 and underwent a long series of kernel updates - most of them being correctly reflected by uname, but not all. It is only now that I (believe to) understand: the "frozen" kernel names - those incorrectly and insistingly reported by uname - are the ones where I had done a fresh install (and where therefore the boot record had been re-written).

Version-Release number of selected component (if applicable):

How reproducible:
See conditions mentioned above

Steps to Reproduce:
1. install a Mageia cauldron system
2. maintain it until the kernel has been upgraded a couple of times
3. compare output of "uname -s" and of "ls -a /boot/vmlinuz"

Comment 1 Juergen Harms 2019-05-07 22:31:07 CEST

Created attachment 10985 [details]
Copy of current /boot/grub2/grub.cfg

Comment 2 Juergen Harms 2019-05-07 22:34:07 CEST

Created attachment 10986 [details]
Output of ls -al /boot | sort

Comment 3 Lewis Smith 2019-05-08 17:05:07 CEST

I wonder whether the base of this is the fact of having 2 kernels at the same nominal version:
 5.1.0-desktop-0.rc7.2.mga7
 5.1.0-desktop-1.mga7
because there is no confusion with the earlier 5.0.7-desktop-4.mga7 .
All the /boot/vmlinuz[-desktop] etc symbolic links are correct for the latest kernel.

I suspect a Grub2 problem.
The first Grub2 menu entry "Mageia (5.1.0-desktop-1.mga7) 7 beta-3" seems to go incorrectly to 5.1.0-desktop-0.rc7.2.mga7 ; when this is shown by uname, it is I think the kernel in use.
As you say in comment 0, other menu entries seem consistent with the versions in their captions, and load & disply (uname) the expected kernel.

Grub2 has no registered maintainer, so am assigning in the first instance to tmb.

CC: (none) => lewyssmith
Assignee: bugsquad => tmb

Comment 4 Thomas Backlund 2019-05-08 17:34:32 CEST

The date of "uname -a" is kernel build time, not install time

And the version that you see in "uname -r" or "uname -a" is _always_ matching the running kernel.

And the reason for you "version mismatch" in grub2 boot menu is that you have some custom stuff in:

/etc/grub.d/11_custom_proxy
/etc/grub.d/12_linux_proxy

So whatever writes those is messing your menus , its not part of default Mageia setup ...

For example the:

/etc/grub.d/11_custom_proxy

States:
menuentry "Mageia (5.1.0-desktop-1.mga7) 7 beta-3 ( on nvme0n1p14)"

but uses the -rc7.2 kernel and initrd: 
linuxefi /boot/vmlinuz-5.1.0-desktop-0.rc7.2.mga7
initrdefi /boot/initrd-5.1.0-desktop-0.rc7.2.mga7.img

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Comment 5 Juergen Harms 2019-05-09 18:26:25 CEST

Thank you Thomas. I now realise that my principal fault was to interpret the link in /boot/vmlinuz as an indication of the name of the kernel effectively loaded; I now remembered that using /proc/cmdline is a proper way to get this information: that confirms that there has always been a match with the result provided by uname, and that the real problem was that the effectively loaded kernel was not the one I expected.