1. Please describe the problem: Testing the 6.15.2-201.fc42.x86_64 kernel on one of my older legacy BIOS non-UEFI systems and during the upgrade, I got these errors >> Running pre-uninstall scriptlet: kernel-uki-virt-0:6.14.9-300.fc42.x86_64 >>> Error in pre-uninstall scriptlet: kernel-uki-virt-0:6.14.9-300.fc42.x86_64 >>> Scriptlet output: >>> Couldn't find EFI system partition. It is recommended to mount it to /boot or /efi. >>> Alternatively, use --esp-path= to specify path to mount point. >>> /usr/lib/kernel/install.d/99-uki-uefi-setup.install failed with exit status 1. >>> >>> [RPM] %preun(kernel-uki-virt-6.14.9-300.fc42.x86_64) scriptlet failed, exit status 1 >>> Running pre-uninstall scriptlet: kernel-core-0:6.14.9-300.fc42.x86_64 >>> Error in pre-uninstall scriptlet: kernel-core-0:6.14.9-300.fc42.x86_64 >>> Scriptlet output: >>> Couldn't find EFI system partition. It is recommended to mount it to /boot or /efi. >>> Alternatively, use --esp-path= to specify path to mount point. >>> /usr/lib/kernel/install.d/99-uki-uefi-setup.install failed with exit status 1. >>> >>> [RPM] kernel-uki-virt-6.14.9-300.fc42.x86_64: erase failed >>> [RPM] %preun(kernel-core-6.14.9-300.fc42.x86_64) scriptlet failed, exit status 1 100% | 275.0 B/s | 8.0 B | 00m00s >>> [RPM] kernel-core-6.14.9-300.fc42.x86_64: erase failed 100% | 7.0 B/s | 48.0 B | 00m06s Transaction failed: Rpm transaction failed. 2. What is the Version-Release number of the kernel: 6.15.2-201.fc42.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Haven't had this happen with any of the previous 6.14.x kernel upgrades on this system. Just started happening with the 6.15.2-201.fc42.x86_64 test kernel. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes. Happens reliably. Download RPM files for the 6.15.2-201.fc42.x86_64 test kernel. Use dnf to upgrade the kernel 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Reproducible: Always
Created attachment 2093975 [details] kernel messages from journalctl
Created attachment 2093976 [details] Extract from dnf5.log
Is there a particular reason why kernel-uki-virt package was installed on a non-UEFI system? I agree 99-uki-uefi-setup should not give a failure anyway so the bug is legitimate but I'm wondering how the package ends up on such systems in the first place.
The failing 99-uki-uefi-setup.install script comes from virt-firmware, reassigning accordingly.
(In reply to Vitaly Kuznetsov from comment #3) > Is there a particular reason why kernel-uki-virt package was installed on a > non-UEFI system? I agree 99-uki-uefi-setup should not give a failure anyway > so the bug is legitimate Yes, makes sense to verify we are running on uefi. --- a/systemd/99-uki-uefi-setup.install +++ b/systemd/99-uki-uefi-setup.install @@ -20,8 +20,15 @@ if test -d "$BOOT_ROOT/EFI/BOOT"; then # looks like $BOOT_ROOT points to the ESP UKI_DIR_ESP="$UKI_DIR_BOOT" else - # must find ESP mount point - UKI_DIR_ESP="`bootctl -p`/EFI/Linux" + if test -d /sys/firmware/efi; then + # uefi system: try find ESP via bootctl + UKI_DIR_ESP="`bootctl -p`/EFI/Linux" + else + # not an uefi system: nothing to do + [ "$KERNEL_INSTALL_VERBOSE" -gt 0 ] && \ + echo "Not an UEFI system, exiting" + exit 0 + fi fi LOADER_INFO="$(kernel-bootcfg --print-loader)"
(In reply to Vitaly Kuznetsov from comment #3) > Is there a particular reason why kernel-uki-virt package was installed on a > non-UEFI system? I agree 99-uki-uefi-setup should not give a failure anyway > so the bug is legitimate but I'm wondering how the package ends up on such > systems in the first place. Good question. I don't recall installing it, but it's entirely possible I managed to inadvertently install it while doing something else.
FEDORA-2025-d659c8a26e (python-virt-firmware-25.7-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d659c8a26e
FEDORA-2025-d659c8a26e has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-d659c8a26e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-d659c8a26e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-d659c8a26e (python-virt-firmware-25.7-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
I'm going to put this here, as this is the bug report I came across while looking for a solution to my problem although it seems it is *related* but not identical (mine started maybe around kernel 6.14.x but I don't yet know where the problem truly originates). I think I need to raise a new issue, which I'll do when I have a bit more diag and link it here. But it is similar in that it stems from UEFI-related checks failing on a legacy boot system and has broken kernel install and removal. This is with a fully updated F42 as of this morning (and the package mentioned above). >>> Running pre-uninstall scriptlet: kernel-core-0:6.15.3-200.fc42.x86_64 >>> Error in pre-uninstall scriptlet: kernel-core-0:6.15.3-200.fc42.x86_64 >>> Scriptlet output: >>> Traceback (most recent call last): >>> File "/bin/kernel-bootcfg", line 8, in <module> >>> sys.exit(main()) >>> ~~~~^^ >>> File "/usr/lib/python3.13/site-packages/virt/firmware/bootcfg/main.py", line 323, in main >>> remove_uki(cfg, options) >>> ~~~~~~~~~~^^^^^^^^^^^^^^ >>> File "/usr/lib/python3.13/site-packages/virt/firmware/bootcfg/main.py", line 126, in remove_uki >>> nr = cfg.find_devpath_entry(efiuki.dev_path_file()) >>> ~~~~~~~~~~~~~~~~~~~~^^ >>> File "/usr/lib/python3.13/site-packages/virt/firmware/bootcfg/linuxcfg.py", line 137, in dev_path_file >>> path.append(self.dev_path_elem_gpt()) >>> ~~~~~~~~~~~~~~~~~~~~~~^^ >>> File "/usr/lib/python3.13/site-packages/virt/firmware/bootcfg/linuxcfg.py", line 126, in dev_path_elem_gpt >>> if self.udevenv['ID_PART_ENTRY_SCHEME'] != 'gpt': >>> ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^ >>> KeyError: 'ID_PART_ENTRY_SCHEME' >>> /usr/lib/kernel/install.d/99-uki-uefi-setup.install failed with exit status 1. >>> >>> [RPM] %preun(kernel-core-6.15.3-200.fc42.x86_64) scriptlet failed, exit status 1 Transaction failed: Rpm transaction failed.
OK, I think I've fixed it, and I *think* it was a tangential knock on from the above bug. At some point (possibly the above) some parts of the system had started trying to populate a redundant /boot/EFI dir (causing aforementioned /boot size problems), and that had (to date) ended up with a /boot/EFI/BOOT dir existing in my [non EFI] /boot partition. Then uki-direct's /usr/lib/kernel/install.d/99-uki-uefi-setup.install (called indirectly from kernel scripts) was seeing that and assuming it meant there was an EFI install, which *then* caused the above failure from calling kernel-bootcfg: if test -d "$BOOT_ROOT/EFI/BOOT"; then # looks like $BOOT_ROOT points to the ESP UKI_DIR_ESP="$UKI_DIR_BOOT" else ... "exit 0" in here due to non-EFI that should be called but was not fi LOADER_INFO="$(kernel-bootcfg --print-loader)" I have renamed /boot/EFI out of the way and will monitor, but doing that now lets me cleanly remove and install old kernels, so I've just got to pick up the pieces of some broken and duplicated (on uninstall failure) kernel RPM installs.