Created attachment 1947320 [details] Remove the %post in the .spec file that changes OUTPUT_FILE to /boot/efi/EFI/fedora/grub.cfg Description of problem: Since FC34, as per https://fedoraproject.org/wiki/Changes/UnifyGrubConfig, grub.cfg is saved into /boot/grub2/grub.cfg regardless of the UEFI or BIOS status, and /boot/efi/EFI/fedora/grub.cfg is a stub that redirects to /boot/grub2/grub.cfg. Unfortunately, grub-customizer is patched via %post to save to /boot/efi/EFI/fedora/grub.cfg on UEFI systems. Side effects: on UEFI systems with grub-customizer installed and used at least once with saving changes into /boot/efi/EFI/fedora/grub.cfg, all subsequent kernel updates will update /boot/grub2/grub.cfg, but on boot the list of kernels will be retrieved from /boot/efi/EFI/fedora/grub.cfg, which doesn't redirect anymore. Therefore, after each kernel update, the latest kernel will not show on the boot screen. After 3 kernel updates, if grub-customizer was not used to update /boot/efi/EFI/fedora/grub.cfg, the system will become unbootable, as /boot/efi/EFI/fedora/grub.cfg refers to kernels that are no longer installed. Version-Release number of selected component: 5.2.2 How reproducible: Always Steps to Reproduce: 1. Install grub-customizer. 2. Run grub-customizer and save the configuration. 3. When this becomes available, perform a kernel update. 4. Reboot and read the list of kernels shown by GRUB. Actual results: The latest kernel doesn't show in the list. Expected results: The latest kernel should be the first in the list. Additional info: Suggested fix for the maintainer: remove the %post in the .spec file, possibly as in the attached patch. Workaround for the end-users who experience the issue: Change the locations in grub-customizer to the correct ones: File, Change Environment (CTRL+O): OUTPUT_DIR: /boot/grub2 OUTPUT_FILE: /boot/grub2/grub.cfg Check "save this configuration". Apply. Then: # dnf reinstall grub2-common # grub2-mkconfig -o /boot/grub2/grub.cfg Verify that the EFI grub.cfg is a stub that redirects to /boot/grub2/grub.cfg, e.g.: # cat /boot/efi/EFI/fedora/grub.cfg search --no-floppy --fs-uuid --set=dev 929be0e4-7adb-4cc6-850c-5211dbbe124a set prefix=($dev)/boot/grub2 export $prefix configfile $prefix/grub.cfg
Thanks. I will do that.
FEDORA-2023-e27869ad06 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e27869ad06
FEDORA-2023-0ebebf17ff has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0ebebf17ff
FEDORA-2023-e27869ad06 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e27869ad06` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e27869ad06 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-85a4357c69 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-85a4357c69 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-0ebebf17ff has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-0ebebf17ff` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0ebebf17ff See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-85a4357c69 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-e27869ad06 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-0ebebf17ff has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
Perhaps it's just me, but after updating to grub-customizer-5.2.2-3.fc37, the /etc/grub-customizer/grub.cfg wasn't updated, i.e. it remained as before, with the bogus OUTPUT_DIR and OUTPUT_FILE paths. That's presumably because it's tagged as a configuration file ('c'). Even after the upgrade, 'rpm -V grub-customizer' reported: S.5....T. c /etc/grub-customizer/grub.cfg And the mtime of that file was the time of the previous upgrade, when it was tweaked by the (now gone) postinstall scriptlet.
(In reply to Bruce Jerrick from comment #10) > the /etc/grub-customizer/grub.cfg wasn't updated, i.e. it remained as before, > with the bogus OUTPUT_DIR and OUTPUT_FILE paths. Indeed, the fixed version is _not_ supposed to repair a broken configuration created by any previous version, but only to behave correctly as a fresh installation. It's better to uninstall, then reinstall grub-customizer. Alternatively, one can manually fix the paths and the other two grub.cfg by following the suggested workaround at the end of the original report.
I think config file must not be corrected automatically by update. There can be other changes made by user.