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).
--
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
Attachment:
signature.asc
Description: OpenPGP digital signature