Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: apt tells me that grub-efi, grub2-common are no longer needed

291 views
Skip to first unread message

Greg Wooledge

unread,
Jun 23, 2021, 10:30:05 AM6/23/21
to
On Wed, Jun 23, 2021 at 03:55:04PM +0200, Markus wrote:
> Hi, just before and also after today's "apt full-upgrade" apt tells me
> that:
> The following packages were automatically installed and are no longer required:
> efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
> libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
> libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
> libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
> linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
> linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
> shim-signed-common
> shim-unsigned

This may not be helpful for you, but this is *exactly* the kind of thing
that led me to turning off apt's autoremove feature. In my experience, it
does more harm than good.

I did it by marking every package as "never-autoremove", by creating the
following one-line text file:

unicorn:~$ cat /etc/apt/apt.conf.d/99local
APT::NeverAutoRemove ".";

There may be other ways to do it.

If you don't like that solution, which I'll admit is not for everyone,
my best advice would be to pick whichever package(s) in the above output
you care about, and mark them as manually installed, using apt-mark(8).

David Wright

unread,
Jun 23, 2021, 10:50:04 AM6/23/21
to
Please post as text, not *just* html.

On Wed 23 Jun 2021 at 15:55:04 (+0200), Markus wrote:
> <html>
> <head>
>
> <meta http-equiv="content-type" content="text/html; charset=UTF-8">
> </head>
> <body>
> Hi, just before and also after today's "apt full-upgrade" apt tells
> me that:<br>
> <br>
> <pre><code>The following packages were automatically installed and are no longer required</code>:
> efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
> libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
> libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
> libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
> linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
> linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
> shim-signed-common
> shim-unsigned
>
> </pre>
> I don't have a good feeling when I see that it allows me to remove <br>
> "efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common"
> <br>
> <br>
> <br>
> What is wrong here? I am on Buster and used kernel
> 5.10.0-0.bpo.5-amd64. With today's
> <br>
> full-upgrade 5.10.0-0.bpo.7-amd64 came in.

Has grub-efi-amd64 been accidentally removed? AIUI that's the package
which depends on having the packages to boot your machine.

Cheers,
David.

Markus

unread,
Jun 23, 2021, 11:10:04 AM6/23/21
to
No, not that I am aware of. But here is the ouput of

markus@bmtMB1:~$ sudo dpkg -l | grep grub
ii  grub-common 2.02+dfsg1-20+deb10u4                       
amd64        GRand Unified Bootloader (common files)
rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3                       
amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin 2.02+dfsg1-20+deb10u4                       
amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed 1+2.02+dfsg1+20+deb10u4                     
amd64        GRand Unified Bootloader, version 2 (amd64 UEFI signed by
Debian)
ii  grub-firmware-qemu 2.02+dfsg1-20+deb10u4                       
amd64        GRUB firmware image for QEMU
ii  grub2-common 2.02+dfsg1-20+deb10u4                       
amd64        GRand Unified Bootloader (common files for version 2)
markus@bmtMB1:~$

Cheers
Markus


Am 23.06.21 um 16:43 schrieb David Wright:

David Wright

unread,
Jun 23, 2021, 12:10:05 PM6/23/21
to
On Wed 23 Jun 2021 at 17:01:07 (+0200), Markus wrote:
> Am 23.06.21 um 16:43 schrieb David Wright:
> > Has grub-efi-amd64 been accidentally removed? AIUI that's the package
> > which depends on having the packages to boot your machine.

> No, not that I am aware of. But here is the ouput of
>
> markus@bmtMB1:~$ sudo dpkg -l | grep grub
> ii  grub-common 2.02+dfsg1-20+deb10u4                       
> amd64        GRand Unified Bootloader (common files)
> rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3                       

↑↑ There's your problem. It's been removed (but not purged).

> amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
> ii  grub-efi-amd64-bin 2.02+dfsg1-20+deb10u4                       
> amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
> ii  grub-efi-amd64-signed 1+2.02+dfsg1+20+deb10u4                     
> amd64        GRand Unified Bootloader, version 2 (amd64 UEFI signed by
> Debian)
> ii  grub-firmware-qemu 2.02+dfsg1-20+deb10u4                       
> amd64        GRUB firmware image for QEMU
> ii  grub2-common 2.02+dfsg1-20+deb10u4                       
> amd64        GRand Unified Bootloader (common files for version 2)
> markus@bmtMB1:~$

Thanks for posting text.

Cheers,
David.

Markus

unread,
Jun 24, 2021, 2:50:05 AM6/24/21
to
Ok so...hmmm...I did not remove it myself. I mean why would I want to do
that?!?! Nevertheless this is an issue now.
Interestingly when booting my computer this morning grub was there and
booted into Buster. Shouldn't it be gone if it got removed (even though
it not got purged)? Hmmm...!?!?

How to fix that? Is there actually something wrong (this morning grub
was there!!!) that needs to be fixed?
Is it save to just reinstall grub-efi-amd64?

Cheers
Markus


Am 23.06.21 um 18:08 schrieb David Wright:

Greg Wooledge

unread,
Jun 24, 2021, 7:20:04 AM6/24/21
to
On Thu, Jun 24, 2021 at 08:49:40AM +0200, Markus wrote:
> Ok so...hmmm...I did not remove it myself. I mean why would I want to do
> that?!?! Nevertheless this is an issue now.
> Interestingly when booting my computer this morning grub was there and
> booted into Buster. Shouldn't it be gone if it got removed (even though
> it not got purged)? Hmmm...!?!?

Removing the grub packages doesn't remove GRUB from your hard drive(s).
Thankfully.

> How to fix that? Is there actually something wrong (this morning grub
> was there!!!) that needs to be fixed?
> Is it save to just reinstall grub-efi-amd64?

It should be, as far as I know. I'm not sure whether this will prompt
you for where to install GRUB, or whether it will retain knowledge of
this from the config files which you say haven't been purged yet.

It'll probably regenerate the grub.cfg menu, though. If you haven't done
anything too silly, that shouldn't be an issue.

David Wright

unread,
Jun 24, 2021, 10:10:04 AM6/24/21
to
On Thu 24 Jun 2021 at 08:49:40 (+0200), Markus wrote:
> Am 23.06.21 um 18:08 schrieb David Wright:
> > On Wed 23 Jun 2021 at 17:01:07 (+0200), Markus wrote:

> > > rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3
> > ↑↑ There's your problem. It's been removed (but not purged).

> Ok so...hmmm...I did not remove it myself. I mean why would I want to do
> that?!?! Nevertheless this is an issue now.

Take a look at /var/log/apt/history.log* to see the reason
and/or the occasion (but not necessarily the intent).¹

As an example of how things can happen unintentionally, this
post from Tuesday illustrates where a broken package's bug
report seems to have led to a different package being removed:
https://lists.debian.org/debian-user/2021/06/msg00581.html

> Interestingly when booting my computer this morning grub was there and
> booted into Buster. Shouldn't it be gone if it got removed (even though
> it not got purged)? Hmmm...!?!?

Only if you'd gone ahead and removed all those other packages.
There's actually nothing substantial inside grub-efi-amd64:

$ dpkg -L grub-efi-amd64
/.
/usr
/usr/share
/usr/share/bug
/usr/share/bug/grub-efi-amd64
/usr/share/bug/grub-efi-amd64/presubj
/usr/share/bug/grub-efi-amd64/script
/usr/share/doc
/usr/share/doc/grub-efi-amd64
$

> How to fix that? Is there actually something wrong (this morning grub
> was there!!!) that needs to be fixed?
> Is it sa[f]e to just reinstall grub-efi-amd64?

Yes. The package exists for its dependencies. Just reinstall it.
You can then try autoremove again, and its list should now only
include the (presumably third) versions of the kernel packages
that you wanted to remove as a matter of routine, like mine in ¹.

¹ entries in /var/log/apt/history.log look like:

Start-Date: 2021-06-19 17:45:10
Commandline: apt-get --purge autoremove
Purge: linux-headers-4.19.0-14-amd64:amd64 (4.19.171-2), linux-headers-4.19.0-14-common:amd64 (4.19.171-2), linux-image-4.19.0-14-amd64:amd64 (4.19.171-2)
End-Date: 2021-06-19 17:45:33

Cheers,
David.

Nicolas George

unread,
Jun 24, 2021, 10:10:05 AM6/24/21
to
David Wright (12021-06-24):
> Only if you'd gone ahead and removed all those other packages.

Not even then. The GRUB packages are useful for installing the GRUB
bootloader. Once it's installed, the computer will boot, and the package
are not necessary, although they might be useful to automatically update
the configuration after upgrades.

Regards,

--
Nicolas George

Markus

unread,
Jun 24, 2021, 11:00:04 AM6/24/21
to
Thank you, David, for the very useful hint.

I found this in apt history:

Start-Date: 2021-03-06 21:08:42
Commandline: apt full-upgrade
Requested-By: markus (1000)
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u3,
2.02+dfsg1-20+deb10u4), grub2-common:amd64 (2.02+dfsg1-20+deb10u3,
2.02+dfsg1-20+deb10u4), grub-efi-amd64-bin:amd64 (2.02+dfsg1-20+deb10u3,
2.02+dfsg1-20+deb10u4), grub-efi-amd64-signed:amd64
(1+2.02+dfsg1+20+deb10u3, 1+2.02+dfsg1+20+deb10u4)
Remove: grub-efi-amd64:amd64 (2.02+dfsg1-20+deb10u3)
End-Date: 2021-03-06 21:08:45


Do you guys maybe find similar entries in apt history?

So why did apt remove it while upgrading other grub corresponding
packages? And then afterwards apt is complaining and wants to remove
grub, efibootmgr and other stuff.

The following packages were automatically installed and are no longer
required:
efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
shim-signed-common
shim-unsigned

Is it somehow linked to that shim-* packages that got also updated.
Wasn't there a bug report recently about this package when updating to
Buster 10.10?

Maybe it was like this:
1. On 2021-03-06 grub-efi-amd64 got removed because the other updated
grub packages somehow took over its tasks

2. shim got updated just recently and took over the tasks of
efibootmgr
grub-efi-amd64-bin
grub-efi-amd64-signed
grub2-common

3. only grub-common gets not removed because it is still required and in
conjunction with shim it is enough and all fine.

Because if you subtract the "no longer required" grub packages from

markus@bmtMB1:/var/log/apt$ sudo dpkg -l | grep grub
ii grub-common 2.02+dfsg1-20+deb10u4
rc grub-efi-amd64 2.02+dfsg1-20+deb10u3
ii grub-efi-amd64-bin 2.02+dfsg1-20+deb10u4
ii grub-efi-amd64-signed 1+2.02+dfsg1+20+deb10u4
ii grub-firmware-qemu 2.02+dfsg1-20+deb10u4
ii grub2-common 2.02+dfsg1-20+deb10u4

you end up with grub-common and grub-firmware-qemu.

From here you can read that shim is also some kind of bootloader:
https://packages.debian.org/en/buster/shim-signed

But obviously shim depends on grub2-common and grub-efi-amd64-bin.
Hmmm...this makes no sense...

Cheers



Am 24.06.21 um 16:00 schrieb David Wright:

Markus

unread,
Jun 24, 2021, 11:10:07 AM6/24/21
to
I wanted to reinstall grub-efi-amd64 and got this:

markus@bmtMB1:/var/log/apt$ sudo apt install grub-efi-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
grub-efi-amd64 : Depends: grub-common (= 2.02+dfsg1-20+deb10u3)
Depends: grub2-common (= 2.02+dfsg1-20+deb10u3)
Depends: grub-efi-amd64-bin (= 2.02+dfsg1-20+deb10u3)
E: Unable to correct problems, you have held broken packages.
markus@bmtMB1:/var/log/apt$


So...something is wrong here. Puhh...how to fix that?


Thanks and Cheers
Markus


Am 24.06.21 um 13:10 schrieb Greg Wooledge:

Greg Wooledge

unread,
Jun 24, 2021, 11:20:04 AM6/24/21
to
On Thu, Jun 24, 2021 at 05:06:50PM +0200, Markus wrote:
> I wanted to reinstall grub-efi-amd64 and got this:
>
> markus@bmtMB1:/var/log/apt$ sudo apt install grub-efi-amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> grub-efi-amd64 : Depends: grub-common (= 2.02+dfsg1-20+deb10u3)
> Depends: grub2-common (= 2.02+dfsg1-20+deb10u3)
> Depends: grub-efi-amd64-bin (= 2.02+dfsg1-20+deb10u3)
> E: Unable to correct problems, you have held broken packages.
> markus@bmtMB1:/var/log/apt$

Start by getting more information:

apt policy grub-efi-amd64 grub-common grub2-common grub-efi-amd64-bin

It wouldn't hurt to double-check your sources.list as well.

Markus

unread,
Jun 24, 2021, 12:50:04 PM6/24/21
to
More information:

markus@bmtMB1:/var/log/apt$ sudo apt policy grub-efi-amd64 grub-common
grub2-common grub-efi-amd64-bin
grub-efi-amd64:
Installed: (none)
Candidate: 2.02+dfsg1-20+deb10u3
Version table:
2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
2.02+dfsg1-20+deb10u3 30000
100 /var/lib/dpkg/status
grub-common:
Installed: 2.02+dfsg1-20+deb10u4
Candidate: 2.02+dfsg1-20+deb10u4
Version table:
*** 2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
grub2-common:
Installed: 2.02+dfsg1-20+deb10u4
Candidate: 2.02+dfsg1-20+deb10u4
Version table:
*** 2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
grub-efi-amd64-bin:
Installed: 2.02+dfsg1-20+deb10u4
Candidate: 2.02+dfsg1-20+deb10u4
Version table:
*** 2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
markus@bmtMB1:/var/log/apt$


Sources list:

markus@bmtMB1:/etc/apt$ cat sources.list
deb http://ftp.de.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.de.debian.org/debian/ buster main contrib non-free

deb http://security.debian.org/ buster/updates main contrib non-free
deb-src http://security.debian.org/ buster/updates main contrib non-free

# buster-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ buster-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ buster-updates main contrib
non-free

# buster-backports
deb http://ftp.de.debian.org/debian/ buster-backports main contrib non-free

# unofficial vbox
deb http://download.virtualbox.org/virtualbox/debian buster contrib
markus@bmtMB1:/etc/apt$


Am 24.06.21 um 17:14 schrieb Greg Wooledge:

Greg Wooledge

unread,
Jun 24, 2021, 1:00:05 PM6/24/21
to
On Thu, Jun 24, 2021 at 06:43:15PM +0200, Markus wrote:
> grub-efi-amd64:
> Installed: (none)
> Candidate: 2.02+dfsg1-20+deb10u3
> Version table:
> 2.02+dfsg1-20+deb10u4 500
> 500 http://ftp.de.debian.org/debian buster/main amd64 Packages
> 500 http://security.debian.org buster/updates/main amd64 Packages
> 2.02+dfsg1-20+deb10u3 30000
> 100 /var/lib/dpkg/status

Everything else looks good, except for this "30000" section. You've got
a pin somewhere, for an older version of grub-efi-amd64, and it's
throwing everything out of whack.

Markus

unread,
Jul 7, 2021, 2:30:04 AM7/7/21
to
Am 24.06.21 um 18:51 schrieb Greg Wooledge:
Could you please help me fixing this? What are the next steps to go? How
can I unpin this or find out why it was pinned?

Thanks in advance

Andrei POPESCU

unread,
Jul 7, 2021, 3:30:05 AM7/7/21
to
Please show the output of `apt policy` (without any package) as well as
the contents of /etc/apt/preferences and any file under
/etc/apt/preferences.d/

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc

Markus

unread,
Jul 7, 2021, 6:30:05 AM7/7/21
to
Am 07.07.21 um 09:24 schrieb Andrei POPESCU:
apt policy:

Package files:
100 /var/lib/dpkg/status
release a=now
100 http://ftp.de.debian.org/debian buster-backports/non-free i386
Packages
release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=non-free,b=i386
origin ftp.de.debian.org
100 http://ftp.de.debian.org/debian buster-backports/non-free amd64
Packages
release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=non-free,b=amd64
origin ftp.de.debian.org
100 http://ftp.de.debian.org/debian buster-backports/contrib i386 Packages
release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=contrib,b=i386
origin ftp.de.debian.org
100 http://ftp.de.debian.org/debian buster-backports/contrib amd64
Packages
release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=contrib,b=amd64
origin ftp.de.debian.org
100 http://ftp.de.debian.org/debian buster-backports/main i386 Packages
release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=main,b=i386
origin ftp.de.debian.org
100 http://ftp.de.debian.org/debian buster-backports/main amd64 Packages
release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=main,b=amd64
origin ftp.de.debian.org
500 http://ftp.de.debian.org/debian buster-updates/main i386 Packages
release
o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=i386
origin ftp.de.debian.org
500 http://ftp.de.debian.org/debian buster-updates/main amd64 Packages
release
o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=amd64
origin ftp.de.debian.org
500 http://security.debian.org buster/updates/non-free i386 Packages
release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=non-free,b=i386
origin security.debian.org
500 http://security.debian.org buster/updates/non-free amd64 Packages
release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=non-free,b=amd64
origin security.debian.org
500 http://security.debian.org buster/updates/main i386 Packages
release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=i386
origin security.debian.org
500 http://security.debian.org buster/updates/main amd64 Packages
release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=amd64
origin security.debian.org
500 http://ftp.de.debian.org/debian buster/non-free i386 Packages
release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=i386
origin ftp.de.debian.org
500 http://ftp.de.debian.org/debian buster/non-free amd64 Packages
release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=amd64
origin ftp.de.debian.org
500 http://ftp.de.debian.org/debian buster/contrib i386 Packages
release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=i386
origin ftp.de.debian.org
500 http://ftp.de.debian.org/debian buster/contrib amd64 Packages
release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=amd64
origin ftp.de.debian.org
500 http://ftp.de.debian.org/debian buster/main i386 Packages
release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=main,b=i386
origin ftp.de.debian.org
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=main,b=amd64
origin ftp.de.debian.org
Pinned packages:
grub-efi-amd64 -> 2.02+dfsg1-20+deb10u3 with priority 30000




markus@bmtMB1:/etc/apt$ cat preferences
cat: preferences: No such file or directory



markus@bmtMB1:/etc/apt/preferences.d$ ls
apt-listbugs
markus@bmtMB1:/etc/apt/preferences.d$ cat apt-listbugs

Explanation: Pinned by apt-listbugs at 2021-03-06 12:05:35 +0100
Explanation: #984520: 'error: symbol "grub_register_command_lockdown"
not found' and then lightdm fails to start
Package: grub-efi-amd64
Pin: version 2.02+dfsg1-20+deb10u3
Pin-Priority: 30000

Explanation: Pinned by apt-listbugs at 2021-06-20 11:19:38 +0200
Explanation: #990082: High chance of boot problems with buster's
version of arm64 shim
Package: shim-signed
Pin: version 1.33+15+1533136590.3beb971-7
Pin-Priority: 30000
markus@bmtMB1:/etc/apt/preferences.d$


So it seems that apt-listbugs has done the pinning. Right?

Greg Wooledge

unread,
Jul 7, 2021, 7:30:05 AM7/7/21
to
I would have started with "grep -r 30000 /etc/apt" but it seems you
found another path to the answer.

Anssi Saari

unread,
Jul 7, 2021, 8:30:04 AM7/7/21
to
Markus <debi...@gmx.de> writes:

> So it seems that apt-listbugs has done the pinning. Right?

Right and while I've never used apt-listbugs, it should've asked you
what to do when you updated your system? Since the issue concerns ARM
based systems only, binning was not the correct choice.

As the bug is fixed now it seems to me apt-listbugs should clean this up
by itself, it's supposed to run periodically. I guess you could run it
manually too.

The Wanderer

unread,
Jul 7, 2021, 8:40:04 AM7/7/21
to
On 2021-07-07 at 08:19, Anssi Saari wrote:

> Markus <debi...@gmx.de> writes:
>
>> So it seems that apt-listbugs has done the pinning. Right?
>
> Right and while I've never used apt-listbugs, it should've asked you
> what to do when you updated your system? Since the issue concerns
> ARM based systems only, binning was not the correct choice.
>
> As the bug is fixed now

Is it?

I saw two bugs listed under the 30000 apt-listbugs pins: #984520 and
#990082.

#990082 is for shim-signed, and it does seem to be closed now, but if
I'm reading the discussion correctly that's not the package we're
concerned with.

$984520 is for grub-efi-amd64, which I think is the package we're
concerned with, and as far as I can tell it's still open.

> it seems to me apt-listbugs should clean this up by itself, it's
> supposed to run periodically. I guess you could run it manually too.

If I'm not mistaken, the cleanup will only happen when the appropriate
package version is available in the repositories configured as visible
in /etc/apt/sources.list*.

As far as I can see at a quick glance, the package versions with the fix
are not in testing; they're only in unstable and in buster-security. If
Markus is not tracking either of those repos, then the fixed version
won't show as available yet, so the pin won't be automatically removed.


(I learned something today; I thought the check for removing the pin was
done at apt-listbugs invocation time, not on a daily cron job. In
hindsight it makes sense, since apt-listbugs can be invoked manually and
the invoking user probably wouldn't have write access to modify
/etc/apt/preferences/ contents, but I wasn't expecting it.)

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

signature.asc

Anssi Saari

unread,
Jul 7, 2021, 3:30:03 PM7/7/21
to
The Wanderer <wand...@fastmail.fm> writes:

> #990082 is for shim-signed, and it does seem to be closed now, but if
> I'm reading the discussion correctly that's not the package we're
> concerned with.

True, especially as #990082 is specific to ARM.

> $984520 is for grub-efi-amd64, which I think is the package we're
> concerned with, and as far as I can tell it's still open.

I missed this. The report seems a little dubious though.

Markus

unread,
Jul 8, 2021, 4:30:04 AM7/8/21
to
Am 07.07.21 um 12:27 schrieb Markus:
Hi guys, it is nice that from all of this a little discussion took of.
But what can I actually do to fix my problem here? Any suggestions?

Thanks and cheers
Markus

Anssi Saari

unread,
Jul 8, 2021, 6:00:03 AM7/8/21
to
Markus <debi...@gmx.de> writes:

> Hi guys, it is nice that from all of this a little discussion took of.
> But what can I actually do to fix my problem here? Any suggestions?

What was the problem again? Just the suggestion to run apt autoremove
which probably isn't a good idea now?

Easiest is probably waiting until the bugs get fixed and fixes
distributed, the pinning should disappear and no more suggestions from
apt.

The Wanderer

unread,
Jul 8, 2021, 6:20:03 AM7/8/21
to
On 2021-07-08 at 04:21, Markus wrote:

> Am 07.07.21 um 12:27 schrieb Markus:

>> markus@bmtMB1:/etc/apt/preferences.d$ ls
>> apt-listbugs
>> markus@bmtMB1:/etc/apt/preferences.d$ cat apt-listbugs
>>
>> Explanation: Pinned by apt-listbugs at 2021-03-06 12:05:35 +0100
>> Explanation: #984520: 'error: symbol "grub_register_command_lockdown"
>> not found' and then lightdm fails to start
>> Package: grub-efi-amd64
>> Pin: version 2.02+dfsg1-20+deb10u3
>> Pin-Priority: 30000
>>
>> Explanation: Pinned by apt-listbugs at 2021-06-20 11:19:38 +0200
>> Explanation: #990082: High chance of boot problems with buster's
>> version of arm64 shim
>> Package: shim-signed
>> Pin: version 1.33+15+1533136590.3beb971-7
>> Pin-Priority: 30000
>> markus@bmtMB1:/etc/apt/preferences.d$
>>
>>
>> So it seems that apt-listbugs has done the pinning. Right?
>
> Hi guys, it is nice that from all of this a little discussion took of.
> But what can I actually do to fix my problem here? Any suggestions?

As Anssi said, that would depend what you define the problem to be.

The *symptom* is what you describe in the Subject line, and have
discussed previously.

The *cause* is the fact that someone (or some automatic mechanism, and I
don't know of any such that might exist) has seen these bug reports, and
has decided to create pins to prevent the reported-as-buggy versions
from being upgraded to.

What to do about the latter would boil down to a question of what to
decide about those bug reports. For that, you need to examine and
analyze them directly, and come to your own decisions.

You might also want to try to figure out how those pins came to be
created. If you created them (or told apt-listbugs to do so), then
presumably seeing them will have jogged your memory about why you
decided to create them, and you'll be able to make decisions about the
listed bugs based on that memory; if something else created them, then
you'll want to identify what that something else was.


The general process for dealing with pins like these, once created and
observed to be getting in the way, is:

Look at the bug reports listed in the pin(s) for the package(s) you care
about.

Decide whether or not that bug might apply to your system, and whether
or not that bug is something you expect to care about, and whether or
not you're willing to risk the consequences of having the bug on your
system if you're wrong.

Based on that decision, either A: remove the pin and install the updated
package version anyway (i.e., accept the risk), or B: keep waiting, for
the bug to be fixed and the fixed package version to be made available
in a repository you're tracking.


When I decide to do A, I simply edit
/etc/apt/preferences.d/apt-listbugs, and delete (or comment out) the
section matching that pin. There may or may not be a better way of doing
it; if there is, I can't personally advise you on it.

If you decide to do B, but want to avoid the "no longer needed" reports
from apt, then you have the option to C: pick one or more of the
packages named as being "no longer needed", and mark that package as
being manually installed ('apt-mark manual packagename' should do it).
That should paper over the symptom, while still leaving the underlying
cause in place. Personally, I don't usually do this, because I prefer to
keep the set of marked-manual packages to a reasonable minimum - but
that's a case-by-case decision, which depends largely on the
sensibilities of the individual sysadmin.


As you may be able to tell from the small discussion which has ensued
from this, the bug for shim-signed is probably not relevant to you
(unless the system you've pinned it on is arm64), so it should probably
be safe to override that one; then again, that one's also fixed (albeit
not necessarily in a version yet available in a repo you're tracking),
so it might be worth waiting.

As you may also be able to tell from that same discussion, the bug for
grub-efi-amd64 is still open. Examining the bug report for that bug
shows that it seems likely to turn out to be a problem with the specific
firmware used on the specific motherboard of the specific person
reporting the problem, and not a problem with the named package itself;
unless you expect to have a similar firmware with similar problems, this
may not be relevant to you. Then again, that bug report *is* still open,
so you might want to wait until either it gets closed or at least it
gets downgraded to a lower, non-release-critical severity (which would
indicate that it's not considered likely to be a problem for enough
users to warrant delaying the upcoming Debian release).
signature.asc

David Wright

unread,
Jul 8, 2021, 10:50:04 AM7/8/21
to
On Thu 24 Jun 2021 at 17:06:50 (+0200), Markus wrote:
> I wanted to reinstall grub-efi-amd64 and got this:
>
> markus@bmtMB1:/var/log/apt$ sudo apt install grub-efi-amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> grub-efi-amd64 : Depends: grub-common (= 2.02+dfsg1-20+deb10u3)
> Depends: grub2-common (= 2.02+dfsg1-20+deb10u3)
> Depends: grub-efi-amd64-bin (= 2.02+dfsg1-20+deb10u3)
> E: Unable to correct problems, you have held broken packages.
> markus@bmtMB1:/var/log/apt$
>
>
> So...something is wrong here. Puhh...how to fix that?

Aftr reading the bug report (seems to be about macbooks, dual disks,
misconfigured grubs, etc), and https://wiki.debian.org/AptConfiguration
which gives an idea of pinning, you might consider just:

$ sudo apt install grub-efi-amd64=2.02+dfsg1-20+deb10u4

I think you only have the one package pinned, so its dependencies
should just get dragged in as normal.

(Where there are several interrelated packages that are problematical,
people sometimes forget that installing them all in the same command
line can succeed, while installing one by one fails.)

Safety first: always have an alternative method of booting available
(usually a USB stick).

Cheers,
David.
0 new messages