Arch Linux User Repository

I'd like to add this feature to choose the XBOOTLDR instead of the ESP partition. I tried to make it as simple as possible so I added another variable (ukify_use_xbootldr) in the .conf and then overriding the ESP path with bootctl --print-boot-path if said variable is true. Here's the patch:

diff --git a/dracut-ukify b/dracut-ukify
index 3f5acd7..581b419 100755
--- a/dracut-ukify
+++ b/dracut-ukify
@@ -42,6 +42,9 @@ esac
}

ESP_PATH=$(bootctl --print-esp-path)
+if [[ "$ukify_use_xbootldr" = "true" ]]; then
+  ESP_PATH=$(bootctl --print-boot-path)
+fi
MACHINE_ID=$(</etc/machine-id)
# shellcheck source=/etc/os-release
source <(grep -E '^(BUILD_)?ID=' /etc/os-release)
diff --git a/dracut-ukify.conf b/dracut-ukify.conf
index 5745a79..21ef3cd 100644
--- a/dracut-ukify.conf
+++ b/dracut-ukify.conf
@@ -47,6 +47,10 @@ colorize=auto
#  [fallback]='EFI/Linux/linux-${version}-${machine_id}-${build_id}-fallback.efi'
#)

+# Choose whether the UKI image path ends up the XBOOTLDR partition (generally /boot; from "bootctl --print-boot-path") instead of the default ESP partition (generally /efi; from "bootctl --print-esp-path").
+# Can be true or false.
+#ukify_use_xbootldr=true
+
# Override kernel cmdline per variant
# It can be used to define each variant it's own cmdline, for example:
#ukify_cmdline=(

edit: Fixed missing fi in the patch

be aware that the new systemd boot do not support lz4

@ddd my bad, fixed, thanks

Wrong hash of dracut-ukify.conf after the latest change.

Thanks for the pointers. I will test it out in a VM later. This information should be documented better in the Arch Wiki. The UKI article just links to the Dracut article in the Dracut subsection. And the Dracut article tells you to use the flags/options for Dracut to use it, but then tells you to use this package to get the pacman hooks, but it is not stated that you should not use dracut UKI generation then. Since the systemd-ukify details are in the UKI article, you won't know if you only look at the Dracut article.

@dngray @jcruz you both got wrong assignment by using dracut's built-in uefi(ukify) mode. You don't need to pass any uefi-related options to the dracut, but generate plain old initrd image, which then will be included in the resulted uki image by systemd-ukify. To avoid this issue further I'll add --no-uefi flag to the internal dracut image generation process.

TL;DR: remove uefi="yes" option from dracut config, and don't ever use dracut --regenerate-all with dracut-ukify.

You should remove 'uefi=yes' from dracut.conf. This option make dracut generate UKIs on its own and it conflicts with dracut-ukify which uses ukify for that.

jcruz, you're not the only one I too was having this issue https://bbs.archlinux.org/viewtopic.php?id=292326 and have not been able to successfully build a UKI with dracut-ukify.

I made habit of making sure to do it with dracut directly after a kernel update to avoid it. Would be nice if this could be fixed, or we could know what we're doing wrong.

Hi,

I'm testing this on a VM and installed a fresh arch. My setup includes LUKS & LVM and 3 kernels: linux, linux-zen & linux-lts. I have a custom /etc/dracut.conf.d/custom.conf with the following:

compress="gzip"
install_items+=" /etc/crypttab "
hostonly="yes"
uefi="yes"

From arch-chroot, when I run dracut --regenerate-all -f it generates the efi files and it works just fine after reboot. I'm using systemd-boot.

In the etc/dracut-ukify.conf I changed the default kernel to be linux-zen and uncommented the ukify_variants. I also removed the hostonly flag from the custom.conf above.

If I then run dracut-ukify -a to regenerate the efi and reboot I get an error about a magic number and can't decompress a file and it won't boot. I have to boot from the installation ISO and regenerate with pure dracut.

I know dracut works, so I'm not sure why this script does something that breaks it.