Re: Disappearing shim-signed after failed dist-upgrade
On Tue 29 Jun 2021 at 22:41:10 (+0100), Gareth Evans wrote:
> On Tue 29 Jun 2021, at 17:11, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Tue 29 Jun 2021 at 08:29:22 (+0300), Andrei POPESCU wrote:
> > > On Lu, 28 iun 21, 09:46:17, David Wright wrote:
> > > >
> > > > But your evening run of apt-get -y dist-upgrade was unconstrained,
> > > > and so shim-signed could be removed because it was no longer being
> > > > held onto as a Depends or Recommends.
> > >
> > > Except that `apt-get dist-upgrade` doesn't do that (`autoremove` does),
> > > it only removes packages when it determines that it's needed to complete
> > > the dist-upgrade, so a Conflicts or Breaks with an upgraded package.
> >
> > So we can presume, perhaps, that it's a case of ranking:
> > shim-signed being installed as a Recommends is ranked lower
> > than upgrading shim-signed-common, and so it gets removed.
> >
> > All my systems were upgraded successfully because I ignored
> > any arm64 bug reports, so all my lists and caches have been
> > refreshed since, and I don't have access to the control data
> > for shim-signed/1.33+15+1533136590.3beb971-7.
> >
> > Perhaps others can make better informed guesses.
>
> I suspect "aptitude why shim-signed" may not remain relevant, but if so:
>
> $ aptitude why shim-signed
> i grub-efi-amd64-signed Recommends shim-signed
>
> apt history shows grub-efi-amd64-signed was last upgraded along with other grub* packages, apparently without issue, on 2021-03-03.
The only difference from my system is that my grub-efi-amd64-signed
shows as automatic as well, and only installed through a Recommends
(by grub-efi-amd64-bin). I don't think it makes any difference here.
> Even if I had made use of upgrade rather than dist-upgrade, presumably a dist-upgrade would have been indicated here (by the existence of packages kept back) and the same position would have resulted - ie. having to wait for a potentially essential package to be made available in upgraded form so it could be reinstalled so that it could be further upgraded in future... no?
I think, rather, that a manual upgrade could have upgraded shim-signed,
just as long as you say OK to any complaint coming from apt-listbugs.
> $ aptitude why shim-signed-common
> i shim-signed Depends shim-signed-common (>= 1.36~1+deb10u2+15.4-5~deb10u1)
>
> It seems the upgrade of shim-signed-common may have removed shim-signed.
>
> Shouldn't essential packages involved in dependencies only ever be available for upgrade together, unless perhaps the dependency >=version remains satisfied?
That normally happens, and did in this case. AFAICT you got hit by the
caution understandably exercised by unattended-upgrades: it's easier
to come along after the event and push an upgrade forward, rather than
roll back one that caused an error or failure.
> Before succeeding in installing the newer version of shim-signed, I did try installing the version originally installed with Buster, but apt said it wasn't available. In the end I didn't need to attempt installing from eg. DVD, but couldn't this be impossible too due to other conflicts?
I think that installing an old version would be unwise, as well as
potentially difficult. Better to read up on the bug for more
information. AIUI in this case, only arm users were affected.
> In short, should a boot-related package ever be removed and not replaced in the same upgrade operation?
When it doesn't actually affect booting itself, then it's just another
package. That appears to be the case here. AFAICT linux-image-* debs
are about the only ones that install directly into /boot.
> Is it to be expected to have to keep an eye on this sort of thing?
Well, the caution practised by unattended-upgrades should make alerts
rare, but that's all the more reason to pay close attention when it happens.
Cheers,
David.
Reply to: