Source: dracut
Version: 105-2
Severity: normal
X-Debbugs-Cc: roman.va...@gmail.com
Dear Maintainer,
Fix of #753752 introduced a patch for the dracut executable intended
to invoke initramfs generator hooks from /etc/initramfs/post-update.d/
on each dracut invocation (guarded by an environment variable though).
Despite my respect for adhering to kernel handbook guidelines I found
the usage of dracut is now may be confusing due to:
1) Debian is now using both `dracut` and `kernel-install` tools used
also outside of Debian world. However while the tools have the same
names in both worlds, their usage semantics are reversed:
- In Debian: dracut invokes kernel-install (via a post-update hook)
- In non-Debian: kernel-install invokes dracut
I believe it could be source of confusion for users over time.
2) Invocation of post update hooks is opt-out. Personally, I have
bumped into unexpectedly updated boot images several times when
switching between distros while testing dracut workflows.
3) Setting environment variable on the command line is clunky and
shell completion does not help with it.
Hence it is proposed to introduce a wrapper intended to invoke hooks
and possibly deal with Debian workflows integration in general. The
wrapper could then be considered a subject to adhering policies. And
original dracut executable should remain "lower-level" tool. Which
usage experience does not differ from non-Debian world.
In its simplest form, it could look like:
$ cat `which dracut-wrapper`
#!/bin/sh
/usr/bin/dracut "$@"
# Invoke policy-conformant bootloader hooks
if [ -z "$NO_POST_UPDATE_HOOKS" ] && [ -d /etc/initramfs/post-update.d/ ]; then
run-parts --arg="${kernel}" --arg="${outfile}" \
/etc/initramfs/post-update.d/
fi
# ${kernel} and ${outfile} to be determined :)
Another reason to introduce a wrapper is the need to restrict dracut
invocation to sane defaults. For example:
* Dracut has a feature to generate UKIs. Currently usage of the --uefi
option on the command line or in dracut configuration files may lead
to weird situations where UKIs are saved in places where initrds are
expected. As a result, the boot may be broken.
* Dracut has its own heuristic to determine the location of the
generated initrd image files if it isn't specified by the user.
However, the determined location is not always what the end-user
expects.
There are multiple approaches for the wrapper that I could think of:
a) Wrapper preserves interface of dracut executable. This is basically
demonstrated in the example above.
b) Wrapper re-implements interface of the update-initramfs script. In
case, update-alternatives mechanism could be used to swap between
implementations.
c) For the sake of completeness, just use the kernel-install script
provided in dracut repo. Then configure systems to use kernel-install
in some setups (in particular dracut + systemd-boot) and encourage
users to use kernel-install directly.
Best,
Roman
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
