Hi,
On 6/23/23 05:27, Gerd Hoffmann wrote:
== Detailed Description ==
As a first pass, the 'inst.sdboot' option already in anaconda should
work. As it stands, that replaces grub+shim with the systemd-boot
loader, and moves the kernel + initrd to the EFI system partition
(ESP). It doesn't attempt to create unified kernel images, so the
existing `dnf update`, `kdumpctl`, and `make install` in a kernel
source directory should all work.
What is the plan for existing UKIs, for example kernel-uki-virt.rpm?
I'd expect they should work fine without extra work (i.e. try a
kickstart file with '-kernel' + '-kernel-core' + 'kernel-uki-virt' in
the file list).
Since no one else said anything, I will comment that I've not tested the
uki package on top of systemd-boot + normal kernel flow. But the
knowledge of where to put the kernels (/boot or ESP) is autodetected by
the kernel-install script sorta automatically, and when grub isn't in
the picture its happy to put them on the ESP alongside the BLS entries.
Presumably as you note below kernel-install should be able to do this
for UKI kernels as well, removing the need to move them. Although the
BLS type is set to "type1" and puts the kernel + initrd in
/boot/efi/`cat /etc/machine-id`/`uname -r`/. So, setting the
KERNEL_INSTALL_LAYOUT=uki should override the entries.srel and get them
in the right place.
So, in theory it should work, but probably needs tweaking here/there.
Something else to test is what happens if both UKIs and traditional
kernel + initrd exist on the ESP as the docs seem to want one or the
other tied to "type1"/"type2"
[ Side node: Right now the kernel-uki-virt %postinstall just does a copy
to /boot/efi/EFI/Linux where systemd-boot should find them just fine.
After systemd v254 release we which brings some kernel-install
improvements for UKIs we should be able to switch over to use
kernel-install instead ].
take care,
Gerd
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
