-
Notifications
You must be signed in to change notification settings - Fork 174
kiwi creates /boot/efi/EFI/BOOT/grubx64.efi which is not owned by any package #2553
Description
Problem description
Hi,
We recently noticed that official Rocky Linux 9.4 images include additional files compared to 9.3:
/boot/efi/EFI/BOOT/grub.cfg
/boot/efi/EFI/BOOT/grubx64.efi
/boot/efi/EFI/BOOT/mmx64.efi
These files do not belong to any package and this is a problem because /boot/efi/EFI/BOOT/grub.cfg does not get updated (unlike /boot/efi/EFI/rocky/grub.cfg whose update is triggered by grub2-common's posttrans). This means that, if the UUID of the boot partition is changed, nothing will update its value in /boot/efi/EFI/BOOT/grub.cfg, making the system unbootable. I also believe that /boot/efi/EFI/BOOT/grubx64.efi will never be updated either, which poses a security risk.
@nazunalika explained that these files are created by kiwi and pointed me to this line which seems to handle the creation of /boot/efi/EFI/BOOT/grub.cfg:
kiwi/kiwi/bootloader/config/grub2.py
Line 561 in 1e9fdf2
| def _copy_grub_config_to_efi_path( |
I am also seeing the same thing on Fedora 40 images.
Could you please explain what the purpose of these files is? I can understand the need for a default bootloader file (/boot/efi/EFI/BOOT/BOOTX64.EFI) but /boot/efi/EFI/BOOT/grubx64.efi does not look like a special path to me.
Expected behaviour
Additional EFI files which do not belong to a package should not be created, or there should be a way to disable their creation.
Steps to reproduce the behaviour
I do not know the specifics of how the Rocky Linux or Fedora images are created.
OS and Software information
Same answer as above.
- KIWI version:
- Operating system host version:
- Operating system target version:
- Open Build Service version (N/A if not using OBS):
- Koji version (N/A if not using Koji):