Bug#781742: initramfs-tools use of triggers and DPKG_MAINTSCRIPT_PACKAGE
(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.
> >
> >
>
>
>
Reply to: