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.