Bug 2372835 - 'Couldn't find EFI system partition' scriptlet errors during 6.15.x test kernel upgrade
Summary: 'Couldn't find EFI system partition' scriptlet errors during 6.15.x test kern...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python-virt-firmware
Version: 42
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Gerd Hoffmann
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-06-14 10:54 UTC by Eugene Mah
Modified: 2025-07-15 10:23 UTC (History)
16 users (show)

Fixed In Version: python-virt-firmware-25.7-1.fc42
Clone Of:
Environment:
Last Closed: 2025-07-12 01:44:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
kernel messages from journalctl (124.69 KB, text/plain)
2025-06-14 10:54 UTC, Eugene Mah
no flags Details
Extract from dnf5.log (36.83 KB, text/plain)
2025-06-14 10:55 UTC, Eugene Mah
no flags Details

Description Eugene Mah 2025-06-14 10:54:06 UTC
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

Comment 1 Eugene Mah 2025-06-14 10:54:54 UTC
Created attachment 2093975 [details]
kernel messages from journalctl

Comment 2 Eugene Mah 2025-06-14 10:55:20 UTC
Created attachment 2093976 [details]
Extract from dnf5.log

Comment 3 Vitaly Kuznetsov 2025-06-19 09:18:05 UTC
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.

Comment 4 Vitaly Kuznetsov 2025-06-19 09:32:17 UTC
The failing 99-uki-uefi-setup.install script comes from virt-firmware, reassigning accordingly.

Comment 5 Gerd Hoffmann 2025-06-19 13:02:16 UTC
(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)"

Comment 6 Eugene Mah 2025-06-19 13:39:18 UTC
(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.

Comment 7 Fedora Update System 2025-07-03 16:26:57 UTC
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

Comment 8 Fedora Update System 2025-07-04 01:34:06 UTC
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.

Comment 9 Fedora Update System 2025-07-12 01:44:49 UTC
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.

Comment 10 Neil Bird 2025-07-15 10:07:01 UTC
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.

Comment 11 Neil Bird 2025-07-15 10:23:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.