[gelöst] Wie verhindert man das aktuelle grub Update?

[MSfree]

Mir wird gerade das Update für grub angeboten. Da das Update aber Probleme zu bereiten scheint, möchte ich das verhindern.

Mein System ist ein 12 Jahre alter Core2, das noch über ein echtes BIOS verfügt. Secure Boot gibt es hier nicht, das Update ist in meinem Fall also sinnlos, weil die alte Kiste mit oder ohne das Update manipulierbar ist.

apt-pinning ist wohl das Stichwort. Kann mir da bitte jemand auf die Sprünge helfen.

[DeletedUserReAsG]

https://wiki.debianforum.de/Pakete_auf_hold_setzen

[MSfree]

Das Stichwort "hold" wär mich nicht eingefallen.

Vielen Dank.

[Tintom]

Ich hatte gedacht das Problem wäre schon gefixt, weil es die letzten Tage so ruhig um das Thema war. Weit gefehlt: 966575

Der Bug wurde eigentlich für den grub aus sid gemeldet, aber weil zunehmend Anwender von Buster den Bugreport gekapert haben sah man sich dann doch zu einer Klarstellung genötigt:

From: Colin Watson <cjwatson@debian.org>
To: cacatoes@tuxfamily.org, 966575@bugs.debian.org
Subject: Re: Bug#966575: same error message here
Date: Fri, 31 Jul 2020 22:40:34 +0100

Control: severity -1 important

On Fri, Jul 31, 2020 at 10:39:22PM +0200, cacatoes@tuxfamily.org wrote:
> Don't know if it's useful but contributing infos I collected on this,
> since I ran into the same error message on a Lenovo Thinkpad T510
> running Debian Stable.

For anyone affected by this bug, the workaround is to run
"dpkg-reconfigure grub-pc" as root and follow the instructions in the
"GRUB install devices" question. If your system has already failed to
boot, you can use a rescue image of some kind to get back in: for
example, the Debian installer's rescue mode should be suitable.


This is a long-standing problem: we get a scattering of reports of the
same general kind with every GRUB upgrade that changes the binary
interface between GRUB's core image and modules in some way, although
the exact details depend on the upgrade in question. The situation
certainly needs to be improved.

However, the problem is not with the actual changes made in this version
of GRUB. Rather, it's a latent configuration problem on your system
(and on the systems of other people affected by this) that is triggered
by the act of making *any* change to GRUB that causes new modules in
/boot/grub not to be compatible with old core images in the boot sector
that your firmware jumps to when booting your machine. This problem
happens on systems that are configured to run grub-install to a target
device that is not actually the one that your firmware uses to boot your
computer.

This configuration error is normally the result of something like
changing disks around without telling the GRUB packaging about it, so it
continues to install to an old device without realising it isn't the one
that your firmware is configured to boot from any more. Sometimes it's
the result of a bug in some kind of installation or cloning process
instead. Unfortunately it is rarely possible to tell exactly what
caused it from any information that still exists on the systems in
question; sometimes the affected users have an idea what might have
happened and sometimes they don't. The packaging tries to detect some
problems along these lines - I did considerable work on this way back in
2010 to try to improve the situation - and the volume of reports of this
kind is much lower than it used to be as a result, but it still happens
sometimes.

I'm going to downgrade this to non-release-critical. It is absolutely a
problem that we need to deal with (somehow ... it may be that in some
cases we need to refuse to continue the upgrade instead, which would be
a different kind of bug that would tend to be filed as release-critical
too!), but given that it's a latent problem that would have been exposed
by any change of a similar magnitude, I don't think it makes sense for
it to block migration of this new version to testing.