(this conversation really should have been going to the flash-kernel clone in #781882 and not to the original upgrade-report bug in #781742, I've adjusted CC and moved the original to BCC)
On Thu, 2015-05-07 at 15:04 +0100, Ian Campbell wrote: > Resending with a more obvious subject. > > The workaround I describe in the final paragraph does seem to work, but > I'm not sure that's the best way to go. So I've been mulling this over for a while and I'm afraid the conclusion I've eventually reached is that if the initramfs has been regenerated then we really ought to be writing it to flash too, since otherwise we risk leaving the system in an unbootable state. I think this risk is already somewhat present in the gap between <some package>'s update and the initramfs trigger but adding another delay between the initramfs trigger and the flash-kernel trigger is certainly widening it. This may even be the logic behind initramfs clobbering $DPKG_MAINTSCRIPT_PACKAGE for all I know. I think if there is anything to be done here it would be to investigate reducing the number of times the initramfs is regenerated in the first place. Thanks for the report, it was certainly worth investigating and considering. I'm closing the cloned bug against flash-kernel with this message, I'll leave it up to the initramfs-tools maintainers (or others) if they want to reclone the original bug (where all the actual useful info is) into something. Ian. > > On Mon, 2015-05-04 at 15:31 +0100, Ian Campbell wrote: > > (CC initramfs-tools@packages, context is flash-kernel invocation not > > being deferred via triggers during upgrade and ultimately running > > several times in a dist-upgrade) > > > > On Sat, 2015-04-04 at 10:49 +0100, Ian Campbell wrote: > > > At first glance it seems like invocations via the initramfs-tools hooks > > > are not being deferred. > > > > This is because initramfs-tools.postinst contains: > > # Regenerate initramfs whenever we go to dpkg state `installed' > > if [ "x$1" != xtriggered ]; then > > # this activates the trigger, if triggers are working > > update-initramfs -u > > else > > # force it to actually happen > > DPKG_MAINTSCRIPT_PACKAGE='' update-initramfs -u > > fi > > > > and flash-kernel uses [ -n "$DPKG_MAINTSCRIPT_PACKAGE" ] when deciding > > to defer to a trigger. So the invocations of flash-kernel > > via /etc/initramfs/post-update.d/flash-kernel end up never being > > deferred. > > > > I don't think initramfs-tools is wrong to do this per-se, but it does > > mean that anything hooked off the post-update.d hooks cannot reliably > > use triggers (dpkg-trigger uses $DPKG_MAINTSCRIPT_PACKAGE itself). > > > > flash-kernel itself does something similar, but instead of manipulating > > DPKG_MAINTSCRIPT_PACKAGE it instead sets FLASH_KERNEL_NOTRIGGER=1 and > > keys off that. > > > > It seems like the best solution would a patch to switch initramfs-tools > > to a similar scheme, would such a patch be accepted? > > > > If not then I will arrange for /etc/initramfs/post-update.d/flash-kernel > > to signal to f-k somehow that triggers should be used despite the lack > > of DPKG_MAINTSCRIPT_PACKAGE. > > > > Ian. > > > > > > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
