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"
Created attachment 10985 [details] Copy of current /boot/grub2/grub.cfg
Created attachment 10986 [details] Output of ls -al /boot | sort
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) => lewyssmithAssignee: bugsquad => tmb
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 => RESOLVEDResolution: (none) => INVALID
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.