Bug#1108204: initramfs-tools: update-initramfs trigger does not update the initramfs in some cases

[Benjamin Drung <bdrung@posteo.de>]

On Wed, 2025-06-25 at 16:58 +0200, Ben Hutchings wrote:
> On Mon, 2025-06-23 at 09:19 +0200, Tobias Graemer wrote:
> > Package: initramfs-tools
> > Version: 0.148.2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > When installing a kernel package and a package with a trigger for update-initramfs
> > in one go, the update of the initramfs is skipped in some cases.
> > 
> > In a clean chroot, populated with debootstrap for "trixie", I ran
> > 
> >   apt install linux-image-amd64 plymouth-theme-mobian
> > 
> > Result:
> > 
> >   [...]
> >   Setting up linux-image-6.12.32-amd64 (6.12.32-1) ...
> >   I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.12.32-amd64
> >   I: /initrd.img.old is now a symlink to boot/initrd.img-6.12.32-amd64
> >   I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.32-amd64
> >   I: /initrd.img is now a symlink to boot/initrd.img-6.12.32-amd64
> >   /etc/kernel/postinst.d/initramfs-tools:
> >   update-initramfs: Generating /boot/initrd.img-6.12.32-amd64
> >   Setting up linux-image-amd64 (6.12.32-1) ...
> >   Setting up plymouth-theme-mobian (1.1) ...
> >   update-alternatives: using /usr/share/plymouth/themes/mobian/mobian.plymouth to provide /usr/share/plymouth/themes/default.plymouth (default.plymouth) in auto mode
> >   Processing triggers for libc-bin (2.41-8) ...
> >   Processing triggers for initramfs-tools (0.148.2) ...
> >   update-initramfs: /boot/initrd.img-6.12.32-amd64 has already been updated since Mon Jun 23 06:07:09 2025.
> [...]
> 
> I think what happens here is:
> 
> 1. Another package is installed that calls "update-initramfs -u".  This
>    activates the trigger, and we store a timestamp for it.
> 2. linux-image-6.12.32-amd64 is installed.  This calls the
>    initramfs-tools hook which synchronously builds the initramfs.
> 3. plymouth-theme-mobian is installed.  This activates the trigger
>    through a triggers control file.
> 4. The trigger runs and passes the timestamp from (1) through to
>    update-initramfs.  update-initramfs sees the current image is newer
>    than that, and skips the update.
> 
> I think we correctly handle the case where the trigger is only activated
> through "update-initramfs -u", or only through a triggers control file
> or direct invocation of dpkg-trigger.  But when both methods are used,
> this bug is possible because a timestmap file is present and it is
> wrong.
> 
> I propose to revert the optimised trigger handling until we can address
> this.  (But I'm afraid that not be possible until dpkg itself records
> timestamps for trigger activation.)

I agree with this analysis and see no alternative to wait for the dpkg
support for trigger timestamps. So here is the merge request:
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/177

-- 
Benjamin Drung
Debian & Ubuntu Developer