Dracut has ability to create Unified kernel image. But it does not provide UEFI stub file. On my system when I run "dracut --uefi" I get an error: # dracut --uefi dracut[I]: Executing: /usr/bin/dracut --uefi dracut[F]: Can't find a uefi stub '/usr/lib/systemd/boot/efi/linuxx64.efi.stub' to create a UEFI executable Is it possible to provide UEFI stub with dracut, so it will not need the extra packages installed to create UKI? This problem can be solved by adding only one file. I.e. I got this file from systemd-boot-efi from Debian testing and I don't need to install installkernel or systemd-utils with ukify USE flag enabled.
I don't think it makes sense to ship the file with dracut.
sys-kernel/installkernel[uki] already pulls in the systemd-stub via systemd or systemd-utils, so if installkernel is used and the use flags are set correctly then the availability of the required stub is guaranteed.
(In reply to Mike Gilbert from comment #1) > I don't think it makes sense to ship the file with dracut. It has a function that can create UKI, but it does not have one extra file that is needed for this function. Is lokks strange IMO. (In reply to Andrew Nowa Ammerlaan from comment #2) > sys-kernel/installkernel[uki] already pulls in the systemd-stub via systemd > or systemd-utils, so if installkernel is used and the use flags are set > correctly then the availability of the required stub is guaranteed. But how can I understand that I need sys-kernel/installkernel[uki]? Dracut does not depend on it. And why do I need to install sys-kernel/installkernel[uki] and add extra use flag to systemd-utils instead of adding one file manually?
Gentoo is primarily a source-based distro. Whenever feasible, we build software from source code. The source code for the file in question lives in the systemd project. Therefore, the systemd package is the most logical place to build and install it. It does not make sense to ship a pre-built efi stub with dracut. dracut is not the only software that can make use of the file. It might make sense to ship a pre-built efi stub in some new package, but that is not something I am personally interested in maintaining.
> (In reply to Andrew Nowa Ammerlaan from comment #2) > > sys-kernel/installkernel[uki] already pulls in the systemd-stub via systemd > > or systemd-utils, so if installkernel is used and the use flags are set > > correctly then the availability of the required stub is guaranteed. > > But how can I understand that I need sys-kernel/installkernel[uki]? Dracut > does not depend on it. And why do I need to install > sys-kernel/installkernel[uki] and add extra use flag to systemd-utils > instead of adding one file manually? Users that don't use installkernel will have to take care of kernel installation manually, we expect that those users know what they're doing. Adding the systemd-stub to dracut makes no sense: - its not just one file, there are several things we would have to copy from systemd - it would have to be kept up to date - it creates a file conflict with systemd and systemd-utils (installing to some other path would resolve this but then dracut --uefi cannot find it anymore and it has to be specified manually, defeating the whole purpose) - it adds several dependencies If upstream would create and maintain their own stub, that would be a differennt story, but I doubt that will happen. What does make sense is to add another optfeature line to the ebuild.
(In reply to Mike Gilbert from comment #4) > Gentoo is primarily a source-based distro. Whenever feasible, we build > software from source code. I have long relationship with Gentoo and I know how it works :) > It might make sense to ship a pre-built efi stub in some new package, but > that is not something I am personally interested in maintaining. Thank you for the honest answer. As a developer I understand this reason completely. (In reply to Andrew Nowa Ammerlaan from comment #5) > Users that don't use installkernel will have to take care of kernel > installation manually, we expect that those users know what they're doing. I am one of them :) I'll try to solve this problem locally by rewriting systemd-utils ebuild and adding efistub use flag there later. Maybe if the solution will not be ugly I'll send it to upstream.
> or systemd-utils with ukify USE flag The USE flag that controls the installation of systemd-stub is "boot" not "ukify" > I'll try to solve this problem locally by rewriting systemd-utils ebuild and > adding efistub use flag there later. Maybe if the solution will not be ugly > I'll send it to upstream. Note that systemd-boot and systemd-stub are tied together in systemd's build system, separating them in the ebuild is not possible without patching the build system.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad152e2ef14a4ade33586f2defd558aea95be65d commit ad152e2ef14a4ade33586f2defd558aea95be65d Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2024-07-27 06:55:33 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2024-07-27 06:56:59 +0000 sys-kernel/dracut: mention systemd-stub as optional runtime dependency Closes: https://bugs.gentoo.org/936660 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> sys-kernel/dracut/dracut-103-r2.ebuild | 4 ++++ sys-kernel/dracut/dracut-9999.ebuild | 4 ++++ 2 files changed, 8 insertions(+)
