> https://fedoraproject.org/wiki/Changes/cleanup_systemd_install > == 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). In general, I think it's great to see this happening. Thank you! > 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. Nitpick: 'make install' invokes /usr/bin/installkernel which (sometimes?) invokes kernel-install which will create a UKI, if the configuration specifies that. This sentence implies that 'make install' has some issue with UKIs, but that is not true. /usr/bin/installkernel does a lot of stuff, most of it probably wrong. We could 'ln -sf --relative /usr/bin/kernel-install /usr/sbin/installkernel' and then 'make install' would work without grubby. > The vast majority of this work has > been done, leaving only two action items, removing grubby from core, > and merging a shimming package (sdubby) into the fedora repos. As I wrote before in the bug, what is really grubby and sdubby needed for? Most of what grubby does is arcane archaic stuff that we don't need. With grubby/sdubby we have an additional layer that adds complexity and is very inflexible. Why can't we have Anaconda write the Boot Loader Specification files directly or invoke kernel-install? Zbyszek _______________________________________________ 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
