On 2017-05-08, Sylvain L. Sauvage wrote: > I just updated my server (only a few packages) and the initramfs > and kernel were flashed THREE times! > First for the new version of udev (I guess). The trigger is > deferred but immediately executed. Thus flashing outdated data > (kernel being updated afterward). > Next for the new version of initramfs-tools. > Then for the new version of the kernel. Both triggers are > deferred and executed one after the other, uselessly because > they flash the exact same files. > > I fail to see the advantage of a trigger when it’s activated > right away or twice for the same job. > > You can see aptitude’s output (in French, but you should get the > gist of it) in the attached file. > update-initramfs: Generating /boot/initrd.img-3.16.0-4-kirkwood > flash-kernel: installing version 3.16.0-4-kirkwood > Generating kernel u-boot image... done. > Flashing kernel (2074936/2097152 bytes)... done. > Flashing initramfs (5140458/9437184 bytes)... done. ... > Traitement des actions différées (« triggers ») pour flash-kernel (3.35+deb8u3) ... > flash-kernel: installing version 3.16.0-4-kirkwood > Generating kernel u-boot image... done. > Flashing kernel (2074936/2097152 bytes)... done. > Flashing initramfs (5140458/9437184 bytes)... done. This is almost certainly because flash-kernel has hooks in both the kernel and initramfs: /etc/kernel/postinst.d/zz-flash-kernel /etc/kernel/postrm.d/zz-flash-kernel /etc/initramfs/post-update.d/flash-kernel I don't see a great way around this, as flash-kernel needs to be updated when either gets updated, and they may often happen at the same time. The triggers do at least prevent it from getting updated every time a relevent package gets updated, even it if still happens multiple times in any given run... That said, someone with a better understanding of dpkg triggers might be able to come up with something better... live well, vagrant
Attachment:
signature.asc
Description: PGP signature