As of 106-1 dracut-core is shipping /usr/lib/kernel/install.d/50-dracut.install

The Debian kernel postinst invokes:
- /etc/kernel/postinst.d/dracut which generates an initrd and calls kernel-install
- /etc/kernel/postinst.d/zz-systemd-boot which calls kernel-install (and now also generates an initrd with different options)

So I end up with two initrds and two "initrd" options in my /efi/loader/entries/ file.

It seems we need one or the other. I'm not sure if Debian's initramfs-tools will also converge on using systemd's kernel-install,
but I guess some coordination is needed.

My current workaround is running `dpkg-reconfigure dracut` after kernel install, which seems to fix the double initrd in my ESP.

Related to #1091455 and #1082811

Kind regards,

You say

"/etc/kernel/postinst.d/dracut which generates an initrd and calls
kernel-install"

I wonder how the postinst.d/dracut calls kernel-install? Have you logs
or some debug output that shows this?

You say

"/etc/kernel/postinst.d/dracut which generates an initrd and calls
kernel-install"

I wonder how the postinst.d/dracut calls kernel-install? Have you logs
or some debug output that shows this?

At the end of `/usr/bin/dracut`:

```bash
…
# 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

exit 0
```


Then, in `/etc/initramfs/post-update.d/systemd-boot`:

```bash
#!/bin/sh

set -eu

test -x /usr/bin/bootctl || exit 0

bootctl is-installed --quiet || exit 0

echo "Updating kernel version $1 in systemd-boot..."

kernel-install add "$1" "/boot/vmlinuz-$1" "$2"
```

So, this happens if you have systemd-boot and dracut installed.

Kind regards,

Hi,

I use dracut (106-5) + systemd-ukify (257.3-1) to generate a UKI on trixie.

I had observed an increase in UKI size between the installation of
systemd-ukify (followed by the initial generation of a UKI) and that
generated by a recent kernel update.

I suspected it was a second initrd and, after reading this bug report,
appear to have confirmed this suspicion by executing `dpkg-reconfigure
dracut` to re-generate a UKI of the 'expected' size.

I'm away for a few days, but I suspect something similar to the logic
in /etc/kernel/postinst.d/dracut to avoid running multiple times is
needed somewhere?

Best wishes,
Phil

Hi,

I just upgraded to Trixie and ran into this bug. Unfortunately it seems
to have more unintended consequences. Here's (one of) the problem(s):

   1. dracut ships /etc/kernel/postinst.d/dracut which generates an
      initramfs into /boot/initrd.img-$VERSION and correctly
      handles the hostonly={yes|no} setting from the configuration.

   2. dracut also ships /usr/lib/kernel/install.d/50-dracut.install
      which generates an initramfs into
      $KERNEL_INSTALL_STAGING_AREA/initrd *but hardcodes*
      "--add-confdir hostonly" as a command line argument. The latter
      has been fixed by PR [0] (commits [1-2]) but AFAICT there has
      been no release yet which contains these changes.

   3. systemd-boot ships /etc/kernel/postinst.d/zz-systemd-boot which
      calls kernel-install, which calls
      /usr/lib/kernel/install.d/50-dracut.install and then
      /usr/lib/kernel/install.d/90-loaderentry.install which does this:

      for initrd in "${KERNEL_INSTALL_STAGING_AREA}"/microcode* "${@}"
      "${KERNEL_INSTALL_STAGING_AREA}"/initrd*; do [ -f "$initrd" ] ||
      continue echo "initrd $ENTRY_DIR/${initrd##*/}" have_initrd=yes
      done

      This effectively means that *both* initramfs files end up in the
      loader entry for systemd-boot and thus *both* initramfs entries
      are loaded by the kernel on boot

   4. This effectively concatenates/merges to *full* initramfs images
      (instead of only partial overlays as intended), one of which is a
      hostonly=yes initramfs even though the user may have explicitly
      configured hostonly=no. On my system this leads to some warnings
      about missing devices on boot, but fortunately the system still
      boots. However, other users may not be so lucky.

The problem can be worked around by disabling the .install file:

ln -s /dev/null /etc/kernel/install.d/50-dracut.install
dpkg-reconfigure linux-image-`uname -r`

However, I think the correct solution is for dracut to *stop shipping*
the /usr/lib/kernel/install.d/50-dracut.install file completely, at
least until a consensus has been found as to which part of the software
stack (kernel postinst vs. systemd-boot->kernel-install) *should*
generate the initramfs in Debian. This is most likely a policy decision
[3] involving the systemd and Linux maintainers.

Best regards

Alexander Kurtz

[0] https://github.com/dracut-ng/dracut-ng/pull/1238
[1] https://github.com/dracut-ng/dracut-ng/commit/663e720e76407cf10e4e5c8d834b292beba828fa
[2] https://github.com/dracut-ng/dracut-ng/commit/62fdf59c94ef7ec2261d054384ceddff39c3643b
[3] https://kernel-team.pages.debian.net/kernel-handbook/ch-update-hooks.html

For what it's worth, I have worked around this issue locally by modifying the
postinst script from systemd-boot to explicitly use the initrd generated by
the dracut script:

/etc/kernel/postinst.d/zz-systemd-boot:
-kernel-install add "$1" "$2"
+kernel-install add "$1" "$2" "${2%/*}/initrd.img-$1"

This is not very nice, but this also happens to bring it in line with the
behaviour of the systemd-boot initramfs post-update hook, which always uses
the three-argument form of kernel-instsll (but it's easier to do there because
the script gets the path of the generated initrd as one of its arguments).