Bug 2372835

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.