https://bugzilla.redhat.com/show_bug.cgi?id=2134972 --- Comment #13 from Jeremy Linton <jeremy.linton@xxxxxxx> --- I don't think I agree with much of what you wrote. Starting with the fact that I think the people who favor copying executables to security-sensitive contexts (the ESP) outside of the distro auditing path are in error. It should be possible to rpm -qf, and more importantly, rpm -Vf absolutely everything in the boot path. This means that anaconda should _never_ be performing functions that can be provided by packages when it comes to file creation and placement because those files don't have an audible path. So, I might buy that much of this should be moved to the systemd-boot package now that one exists. And given that package can be installed independently from the rest of systemd, it should probably be responsible for assuring that the systemd-boot efi executables and config files are installed in the correct location without using bootctl (which breaks the auditing path). And from this flows the distro wide problem of fixed paths because RPM's don't generally support alternate install locations. So these paths are already hardcoded in in grubby, grub-efi, etc, etc, etc. So while its possible to hand shim the ESP into /efi or places other distro's provide it, fedora/etc, for better or worse at the moment, seems to have issues if the ESP is placed elsewhere. This plays into much of the remainder of your argument, including the fact that this package excludes grubby. One might argue that is somewhat in error, but grubby's current state breaks everything you are arguing above about fixed paths because the kernel install process and the like's path/bootloader detection logic breaks when grubby pulls in grub2-tools/etc. So, while it is possible to convert a machine to systemd-boot by hand, it usually involves moving some part of /boot elsewhere in order to make systemd-boot work properly in the face of dnf update/etc. And even bootctl won't create bootable machines in anaconda if this package is missing the /boot/efi/loader/entries.srel, nor will the kernel be placed on the ESP. And that file can't be easily created at the right time in anaconda anyway. And so, its probably a workable idea to have a utility that manipulates the BLS entries like grubby does, or just rework all the bits in grubby to so that it can also support systemd, but after looking at it, its basically another entire utility. So, I'm ok with killing this package, but the correct place to move functionality, including the creation of that simlink required to assure that kernel upgrades work and a grubby like utility for editing the systemd BLS entries is in the systemd-boot package not systemd-udev. And of course, as part of assuring it works, either grubby needs to be heavily rewritten to remove the hooking/etc its doing for grub, etc. Are you signing up to add this functionality to systemd-boot, or merge this stuff there? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2134972 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
