On Tue 29 Jun 2021, at 22:41, Gareth Evans <donots...@fastmail.fm> wrote: > On Tue 29 Jun 2021, at 17:11, David Wright <deb...@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. > > > > Cheers, > > David. > > > > > > 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. > > 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? > > $ 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? > > 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? > > In short, should a boot-related package ever be removed and not > replaced in the same upgrade operation? > > Is it to be expected to have to keep an eye on this sort of thing? > > Thanks all. > Gareth > >
> having to wait for a potentially essential package to be made available > in upgraded form That and related comments might not make sense. I didn't explain there was a period when I couldn't (re)install shim-signed as apt install reported not found or something like that. Thinking about it further after sending the above, I'm not entirely sure at what point I unpinned shim-signed, so will check logs and snapshots and rack brains and get back to you. Thanks, Gareth