Hide Forgot
Description of problem: In case when there is no boot manager installed in different system located on different partition, kernels gets listed in the wrong order (from oldest to newest) when generating grub.cfg with grub2-mkconfig command. The problem is that linux-boot-prober script from os-prober package is returning kernels in different order in case when 90fallback script is used, thus menu gets populated in the wrong order. The problem is that Grub's main menu gets first kernel from /boot directory and in case resque kernel is present that will be the one listed while regular kernels gets listed in a submenu from oldest to newest. Version-Release number of selected component (if applicable): grub2-tools-2.02-0.34.fc24.x86_64 os-prober-1.71-1.fc25.x86_64 How reproducible: /usr/bin/linux-boot-prober <partition-without-boot-manager> Actual results: Main grub menu gets the oldest kernel or in case when rescue kernel is present, rescue kernel gets into main menu. What makes things worse is that all entries gets same name for example 'Fedora release 26 (Rawhide) (on /dev/sdc5)'. Expected results: Kernels are listed from newest to oldest, or at least newest kernel gets into main menu. Additional info:
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
For the non-primary systems, the kernels are more or less listed in order from oldest to newest, but the order appears to be strictly alphanumeric for the whole kernel name, and not sorted numerically by the constituent parts of the release number as expected. (So that /vmlinuz-4.10.8-200.fc25.x86_64 sorts before /vmlinuz-4.9.12-200.fc25.x86_64.) This situation does not occur if grub is configured such that each system has its own grub-...cfg file, with the primary config file containing "configfile" entries pointing to each of the other systems, and if the config files for all systems are generated with GRUB_DISABLE_OS_PROBER=true. Each of the systems can be updated by grubby without need for running extra grub2-mkconfigs. See kldixon's how-to in Fedora Forum thread http://forums.fedoraforum.org/showthread.php?t=312443.
If grub is present on the other partition then it will just use that menu, but in my case I don't want a grub in another partition, in this case linux-boot-probes then uses /usr/libexec/linux-boot-probes/mounted/90fallback to find the kernels. Kernels selected by that are just pure random, $ LC_ALL=C ls -li /mnt/boot/*.img 655829 -rw-------. 1 root root 17912978 Jan 6 2017 /mnt/boot/initramfs-4.10.0-0.rc2.git2.1.fc26.x86_64.img 655802 -rw-------. 1 root root 19051393 May 28 11:57 /mnt/boot/initramfs-4.11.0-2.fc26.x86_64.img 663375 -rw-------. 1 root root 17563517 Oct 14 2016 /mnt/boot/initramfs-4.9.0-0.rc0.git7.1.fc26.x86_64.img $ sudo /usr/bin/linux-boot-prober /dev/sdb5 /dev/sdb5:/dev/sdb5::/boot/vmlinuz-4.10.0-0.rc2.git2.1.fc26.x86_64:/boot/initramfs-4.10.0-0.rc2.git2.1.fc26.x86_64.img:root=/dev/sdb5 /dev/sdb5:/dev/sdb5::/boot/vmlinuz-4.11.0-2.fc26.x86_64:/boot/initramfs-4.11.0-2.fc26.x86_64.img:root=/dev/sdb5 /dev/sdb5:/dev/sdb5::/boot/vmlinuz-4.9.0-0.rc0.git7.1.fc26.x86_64:/boot/initramfs-4.9.0-0.rc0.git7.1.fc26.x86_64.img:root=/dev/sdb5 It would be nice if in this case kernels would get sorted and possibly even that only latest kernel is used for menu.
(In reply to srakitnican from comment #3) > It would be nice if in this case kernels would get sorted and possibly even > that only latest kernel is used for menu. Since menu and sub-menus does not have any meaningful description in this case, it just says "Fedora release 26 (on /dev/sdb5)" for every entry.
(In reply to Don Swaner from comment #2) > For the non-primary systems, the kernels are more or less listed in order > from oldest to newest, but the order appears to be strictly alphanumeric for > the whole kernel name, and not sorted numerically by the constituent parts > of the release number as expected. (So that /vmlinuz-4.10.8-200.fc25.x86_64 > sorts before /vmlinuz-4.9.12-200.fc25.x86_64.) To sort this, two ideas crosses my mind: 1. Use sort -V $ ls -1 *.img | sort -r --version-sort initramfs-4.11.0-2.fc26.x86_64.img initramfs-4.10.0-0.rc2.git2.1.fc26.x86_64.img initramfs-4.9.0-0.rc0.git7.1.fc26.x86_64.img 2. Use file date $ ls -1t /mnt/boot/*initramfs*.img /mnt/boot/initramfs-4.11.0-2.fc26.x86_64.img /mnt/boot/initramfs-4.10.0-0.rc2.git2.1.fc26.x86_64.img /mnt/boot/initramfs-4.9.0-0.rc0.git7.1.fc26.x86_64.img
The grub "configfile" option is replacing the older grub chain loading method. It is no longer necessary to install grub on any other partition, but only in the EFI or MBR partition. Each system can have its own grub.cfg, possibly renamed to something like grub_F25.cfg, pointed to by a configfile entry in the primary grub.cfg. Properly set up, grubby takes care of the updates of the multiple systems and it is not necessary to ever run grub2-mkconfig, or risk grub and grub.cfg being upgraded from multiple systems. This scenario avoids the problems described in this bug report.
I agree that "configfile" approach is more elegant, but in my case is much simpler to do it this way, since this installations are mostly scratch ones. I don't want to keep using them. Besides, I usually tend to just upgrade or install them with dnf --installroot, this would make this process more complicated, because I would need to make sure /boot/efi is mounted before I upgrade the system. But thank you for the tip, didn't know about configfile before. With all that said it would still be nice if 90fallback would get either fixed, or removed if decided that is not a good approach. The way it stands right now, it looks very bad.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.