Hello, I was a bit surprised about why I was still booting on an older kernel 6.1 on a remote machine even if I was sure to have properly installed a newer 6.6 one some weeks ago. Then I saw that, for some reason, grub-mkconfig puts the older 6.1.x kernel at first, making them chosen at boot time (except if I manually select another). Maybe that is caused by some preference for /boot/vmlinuz-* (old) naming over the one currently used by latest installkernel package /boot/kernel. # ls -l /boot/ total 75408 drwxr-xr-x 3 root root 4096 ene 29 19:46 cacdef0d1ca791dd0c8db8a058960b1c -rw-r--r-- 1 root root 149463 jul 14 2023 config-6.1.38-gentoo -rw-r--r-- 1 root root 149458 ago 27 2023 config-6.1.47-gentoo -rw-r--r-- 1 root root 149469 ago 27 2023 config-6.1.47-gentoo.old -rw-r--r-- 1 root root 149432 nov 27 13:50 config-6.1.57-gentoo drwxr-xr-x 6 root root 4096 mar 10 13:31 grub -rw-r--r-- 1 root root 9312544 ene 29 20:39 kernel-6.6.13-gentoo -rw-r--r-- 1 root root 9322048 feb 18 22:57 kernel-6.6.17-gentoo -rw-r--r-- 1 root root 9331712 mar 10 13:21 kernel-6.6.21-gentoo drwxr-xr-x 3 root root 4096 ene 29 19:46 loader -rw-r--r-- 1 root root 3164632 jul 14 2023 System.map-6.1.38-gentoo -rw-r--r-- 1 root root 3167049 ago 27 2023 System.map-6.1.47-gentoo -rw-r--r-- 1 root root 3167049 ago 27 2023 System.map-6.1.47-gentoo.old -rw-r--r-- 1 root root 3169406 nov 27 13:50 System.map-6.1.57-gentoo -rw-r--r-- 1 root root 8895504 jul 14 2023 vmlinuz-6.1.38-gentoo -rw-r--r-- 1 root root 9008048 ago 27 2023 vmlinuz-6.1.47-gentoo -rw-r--r-- 1 root root 9008080 ago 27 2023 vmlinuz-6.1.47-gentoo.old -rw-r--r-- 1 root root 9016112 nov 27 13:50 vmlinuz-6.1.57-gentoo # LC_ALL=C grub-mkconfig -o /boot/grub/grub.cfg Generating grub configuration file ... Found theme: /boot/grub/themes/starfield/theme.txt Found linux image: /boot/vmlinuz-6.1.57-gentoo Found linux image: /boot/vmlinuz-6.1.47-gentoo Found linux image: /boot/vmlinuz-6.1.47-gentoo.old Found linux image: /boot/vmlinuz-6.1.38-gentoo Found linux image: /boot/kernel-6.6.21-gentoo Found linux image: /boot/kernel-6.6.17-gentoo Found linux image: /boot/kernel-6.6.13-gentoo Adding boot menu entry for UEFI Firmware Settings ... done [ebuild R ] sys-boot/grub-2.12-r2:2/2.12-r2::gentoo USE="fonts mount nls sdl themes truetype -device-mapper -doc -efiemu -libzfs (-test) -verify-sig" GRUB_PLATFORMS="efi-64 pc -coreboot -efi-32 -emu -ieee1275 (-loongson) -multiboot -qemu (-qemu-mips) -uboot -xen -xen-32 -xen-pvh" 0 KiB [ebuild R ~] sys-kernel/installkernel-28::gentoo USE="grub systemd -dracut -refind -systemd-boot -uki -ukify" 0 KiB Thanks Thanks a lot
Created attachment 887249 [details] Generated grub.cfg
Created attachment 887250 [details] /etc/default/grub
The order is determined by piping the *full path* for each kernel image through the "version_sort" function with the 'r" (reverse) flag. https://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/10_linux.in?h=grub-2.12#n201 version_sort just calls "sort -V -r". https://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkconfig_lib.in?h=grub-2.12#n203 The letter "k" comes before the letter "v", so "vmlinuz" gets sorted after "kernel", and then gets moved to the top in reverse order. If you want to see an improvement here, please send a patch upstream.
Do you know why they have this complex algorithm for sorting? I see it was even updated for the 2.12 version. On the other hand, the much simpler one used for NetBSD would simply work (util/grub.d/10_netbsd.in), as it simply relies on "ls -t" for the sorting. I have also seen that other distributions rely on different sorting tools (but we cannot rely on them as they are for RPM distros). I wonder then about other reasons that I don't know for upstream wanting this behavior... even if I can see some old posts in multiple distribution forums with users hitting similar issues with the ordering.
(In reply to Pacho Ramos from comment #4) The algorithm isn't really that complex. It sorts based on file name. Using ls -t would sort based on modification time instead. I don't know of any reason to prefer one method over the other.
I suspect 10_linux and 10_netbsd use different sorting methods simply because they were written by different people. Relevant commits: Switch from random order to sorted by name for Linux https://git.savannah.gnu.org/cgit/grub.git/commit/?id=57f9639766e7e40a796b2df06591942b6fdaa7b4 NetBSD support added https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0d2c20c6f15ec8c7bcc1e7f30c7f9e0f561deb2f Optimized sorting for Linux https://git.savannah.gnu.org/cgit/grub.git/commit/?id=99e05ab555f013b5ce45a3fd04f8ccd5f4e5bf95
(In reply to Mike Gilbert from comment #5) > (In reply to Pacho Ramos from comment #4) > I don't know of any reason to prefer one method over the other. Well, the advantage of ensuring that the latest installed kernel is used is that I think it is what most of us expect to happen just after compiling and installing an updated kernel. For example, I remember that I hit a similar issue when installing a Gentoo machine from the Gentoo Live DVD. I was surprised about why I was still having some drivers for the mouse not working even if I was adding the support for it. At the end, I realized that the original non-changed kernel was still being used by default at boot time.
