UKI(package is kernel-uki-virt) is a single, bootable file that
bundles everything needed to start a Linux system. It contains its own
bootable stub and bypasses GRUB2 completely. The kernel-core and
kernel-uki-virt can coexist in one machine. And both of them call
kernel-install remove <kversion> upon package removal and this leads
to the complete removal of both the traditional kernel & its
artifacts(initramfs, BLS entry file,...). For example, if the customer
remove kernel-uki-virt, currently it also removes BLS entry which
causes the regular kernel fails to boot up. In
https://github.com/systemd/systemd/pull/37897 it added
--entry-type=type1|type2 option to kernel-install. type1 stands for
normal kernel, type2 stands for uki. When kernel-install is invoked
with --entry-type=type2 which is for UKI, we should not remove the BLS
entry.
Resolves: #RHEL-108008
Signed-off-by: Yuxin Sun <yuxisun@redhat.com>
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Resolves: #RHEL-83915
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Reviewed-by: Leo Sandoval <lsandova@redhat.com>
Reviewed-by: Marta Lewandowska <mlewando@redhat.com>
When kernel-install is called for a UKI, 20-grub.install copies it to /boot
which is totally unneeded, UKIs are now handled by the standard systemd's
90-uki-copy.install (systemd-253+) correctly which places them to the ESP.
Resolves: #RHEL-21368
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
The kernel-install script is also used to install kernels when built from
source using the `make install` target.
And if this source contains modifications, a '+' is added as suffix by the
scripts/setlocalversion if no LOCALVERSION was set in the kernel config.
This confuses the grub2 kernel-install plugin, since it currently assumes
that any kernel that contain a version with a '+' suffix is a debug kernel.
But the match is too greedy, just having '+debug' should be enough to check
whether the kernel to install is a debug kernel or not.
Related: #2184069
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>