• Bug#1108204: initramfs-tools: update-initramfs trigger does not update

    From Ben Hutchings@1:229/2 to Tobias Graemer on Wed Jun 25 17:10:01 2025
    XPost: linux.debian.bugs.dist
    From: ben@decadent.org.uk

    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.)

    Ben.

    --
    Ben Hutchings
    The most exhausting thing in life is being insincere.
    - Anne Morrow Lindberg

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmhcDngACgkQ57/I7JWG EQm6mhAArkJKKunIXOBxJ7vKMATMoQmMJxXZPdvrg287kUc4UkSXRnRURmwjjCk6 FwrIMdIU4HzucN/ZfHC/eZpuHyly27zDbZJz7ytHj99y7pN52UPl0yWExk+9weh5 yisCqFWVMg2zccBZQJSTytr68kAIokjL/RmF5ACDVg1TbfSbRf7sneUtURyPFtH7 C3FZNsal4yuE5QiBLSaPrEbhNITQybLNAhRFHWX4OFEVPWvSulMefsjjIsUck7JM 5ZU6rzsNuHLwOMxE8Ru4h6GDbtt6b+JwSqaWeZTGtRvf4axLiV//CjGhuwhbFEJU QVUoDjywPUVAfVHRv0HHpWAW6cVPKPm7kZUGW6XOO+mJ2kX+q+4oYQgdhb9e4cay wGR0pGE8dg+/t/ErHYd99M+sAbrXo6N1v9h3aH52DnozndgPIoOGZe+n1/k8NamZ KoLa7NO3Q79oPDWq3D6L7JxyuEkfKlplhXGhP54INJHwBVySxWy0gwVmJ6fF0n6S ru8nmxsP6iYMHvmDRxnQ69gnkvK/ZBBixZu+UXDvmFLxXsXYOwx20TVNrku31GpH PYq4299+shBbpkGZib8u8PyZTAiL9Uv7j7yH2I/zixO1Vrg4cY/GvauVRfbeFM9Z tvlWEviPEaQJADc4GtdLTUq3QIGeE5CGKzkMqzxDaxLHoRWHQnA=
    =UI/5
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.0
  • From Benjamin Drung@1:229/2 to Ben Hutchings on Thu Jun 26 18:40:02 2025
    XPost: linux.debian.bugs.dist
    From: 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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)