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
