apt hängt in schleife zwischen nvidia-510 und nvidia-tesla-470

[michaa7]

Meine Graka ist eine nvidia GT 710. Diese wird noch von nvidia-470 unterstützt. Mit derzeitigem (wg.nvidia unvollständig durchgelaufnem) dist-upgrade soll nvidia-510 ins system kommen, wovor nvidia nun per hinweisfenster warnt. Empfohlen wird auf nvidia-tesla-470 umzusteigen ... was ich gerne möchte ... nur apt will nicht. Apt hängt mit:

16 aktualisiert, 2 neu installiert, 0 zu entfernen und 34 nicht aktualisiert.
20 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 75,2 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 12,1 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
Changelogs werden gelesen... Fertig
Preconfiguring packages ...
(Lese Datenbank ... 514420 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../nvidia-legacy-check_510.85.02-3_amd64.deb ...
*** The following unsupported devices are present in the machine:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 710] [10de:128b] (rev a1)
Aborting nvidia driver installation.
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/nvidia-legacy-check_510.85.02-3_amd64.deb (--unpack):
»neues pre-installation-Skript des Paketes nvidia-legacy-check«-Unterprozess gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
/var/cache/apt/archives/nvidia-legacy-check_510.85.02-3_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Code: Alles auswählen

apt --fix-broken install

führt immer wieder in diese schleife zurück, ebenso ein

Code: Alles auswählen

apt purge nvidia-driver && apt install nvidia-tesla-470-driver

# update-glx --config glx
Es gibt 3 Auswahlmöglichkeiten für die Alternative glx (welche /usr/lib/glx bereitstellen).

Auswahl Pfad Priorität Status
------------------------------------------------------------
* 0 /usr/lib/nvidia 100 automatischer Modus
1 /usr/lib/mesa-diverted 5 manueller Modus
2 /usr/lib/nvidia 100 manueller Modus
3 /usr/lib/nvidia/bumblebee 95 manueller Modus

# update-glx --config nvidia
Es gibt 1 Auswahlmöglichkeit für die Alternative nvidia (welche /usr/lib/nvidia/nvidia bereitstellt).

Auswahl Pfad Priorität Status
------------------------------------------------------------
* 0 /usr/lib/nvidia/current 470 automatischer Modus
1 /usr/lib/nvidia/current 470 manueller Modus

Jemand ne idee wie ich da rauskomme (habe nicht neu gebooted ... und will das vorläufig auch nicht)

[DeletedUserReAsG]

ebenso ein

Code: Alles auswählen

apt purge nvidia-driver && apt install nvidia-tesla-470-driver

Mit welcher Meldung?

Ansonsten würde ich nun auch versuchen, nvidia-legacy-check zu entfernen. Notfalls mit Gewalt (aka dpkg --force-…). Dann würde ich das Gleiche mit nvidia-driver machen. Falls es nicht tun sollte: die Meldungen sind von Bedeutung. Erst, wenn der alte Kram (und der kaputte neue Kram) weg sind, würde ich nvidia-tesla-470-driver zu installieren versuchen.

[michaa7]

Mit

Code: Alles auswählen

dpkg --configure -a

bin ich aus der Schleife gekommen. Noch ein

Code: Alles auswählen

 apt --fix-broken install

und ein nochmaliges

Code: Alles auswählen

# dpkg --configure -a

installierten einiges was zuvor nicht durchlief Übrig blieb diese Fehler:

# dpkg --configure -a
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von libnvidia-ml1:amd64:
libnvidia-ml1:amd64 hängt ab von nvidia-alternative (= 510.85.02-3); aber:
Version von nvidia-alternative auf dem System ist 470.141.03-2.

dpkg: Fehler beim Bearbeiten des Paketes libnvidia-ml1:amd64 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von nvidia-smi:
nvidia-smi hängt ab von nvidia-alternative (= 510.85.02-3); aber:
Version von nvidia-alternative auf dem System ist 470.141.03-2.
nvidia-smi hängt ab von libnvidia-ml1 (= 510.85.02-3); aber:
Paket libnvidia-ml1:amd64 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes nvidia-smi (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
libnvidia-ml1:amd64
nvidia-smi

Ein

Code: Alles auswählen

apt purge  nvidia-smi  libnvidia-ml1

und es sieht so aus als ob mein dist-upgrade nun fehlerfrei durchläuft.

Nur, ähnliches ist auch schon früher mit dem 495 treiber passiert. Wie sorge ich dafür, dass einerseits kein nvidiatreiber höher als 470 installiert wird, andererseits 470 *updates*, die es immer wieder mal gibt, dennoch durchkommen?

# apt policy nvidia-driver
nvidia-driver:
Installiert: 470.141.03-2
Installationskandidat: 510.85.02-3
Versionstabelle:
510.85.02-3 500
500 http://neutower:3142/deb.debian.org/debian unstable/non-free amd64 Packages
*** 470.141.03-2 100
100 /var/lib/dpkg/status
470.141.03-1~deb11u1 500
500 http://neutower:3142/deb.debian.org/debian stable/non-free amd64 Packages

[DeletedUserReAsG]

Wie sorge ich dafür, dass einerseits kein nvidiatreiber höher als 470 installiert wird, andererseits 470 *updates*, die es immer wieder mal gibt, dennoch durchkommen?

Sollte an dieser Stelle nicht passieren, wenn du nun nvidia-tesla-470-driver statt nvidia-tesla-driver installiert hast. Dass dein Update auf 510 anfing, hat auch eher damit zu tun gehabt, dass du 470 nicht explizit, sondern vermutlich das Metapaket nvidia-driver installiert hattest, das vom jeweils neusten Treiber abhängt. Wobei’s bei Siduction dann wohl einen anderen Fehler beim Update gegeben hätte – ist halt kein Stable – aber zumindest wärst du nicht erstmal in der Schleife gelandet.

OT: könntest du Ausgaben in Code-Tags posten? Wären dann erheblich besser lesbar.

[michaa7]

Ok, ein

Code: Alles auswählen

apt purge nvidia && apt install nvidia-tesla-470-driver

sorgte dafür dass nun der 510ner treiben nicht mehr beim dist-upgrade gezogen wird.

Danke für den Hinweis (nur wenn nvidia-driver schon so schlau ist zu bemerken dass der 510ner nicht für meine Graka paßt und das Hinweisfenster sogar weiß was installiert werden muß, dann wäre es nur *folgerichtig* mit der Frage "soll stattdessen der treiber 'nvidia-tesla-470-driver' installiert werden und das system dauerhaft entsprechend konfiguriert werden" den entsprechenden Installationspozess zu iniziieren. )

Re Code-tags: Ich bin bis jetzt davon ausgegangen, dass Ausgaben Text sind, und nicht Code im strengen Sinn. Code habe ich immer nur verwendet wenn es um commands ging die so per c&p angewendet werden könnten. Ist das hier so nicht gewünscht?

[JTH]

Re Code-tags: Ich bin bis jetzt davon ausgegangen, dass Ausgaben Text sind, und nicht Code im strengen Sinn. Code habe ich immer nur verwendet wenn es um commands ging die so per c&p angewendet werden könnten. Ist das hier so nicht gewünscht?

Das ist wie vieles bei Formatierung sicher zum Teil Geschmackssache. Aber mir und ich denke auch anderen geht es so, dass sich auch die Ausgaben von Kommandos in der Schrift, wie sie die [code]-Tags bewirken, leichter weil gewohnter lesen. Und wird so auch regelmäßig hier verwendet.

Manchmal geht ohne die code-Tags auch tatsächlich eine Listen- oder Tabellenformatierung kaputt, wie zum Beispiel oben bei der Ausgabe von update-glx --config glx.

[DeletedUserReAsG]

nur wenn nvidia-driver schon so schlau ist zu bemerken dass der 510ner nicht für meine Graka paßt und das Hinweisfenster sogar weiß was installiert werden muß, dann wäre es nur *folgerichtig* mit der Frage "soll stattdessen der treiber 'nvidia-tesla-470-driver' installiert werden und das system dauerhaft entsprechend konfiguriert werden" den entsprechenden Installationspozess zu iniziieren.

Wie gesagt, das fällt dir bei deinem Siduction spätestens dann auf die Füße, wenn 470-tesla aus Sid rausrollt, weil’s durch den Nachfolger erstetzt wird. Möglicherweise gibt’s dann einen 470-legacy – aber das kann ja nvidia-legacy-check heute noch nicht wissen. Auch kann’s nicht wissen, wie du dich entscheiden wirst, denn du könntest ja auch einen der derzeitigen Legacy-Treiber haben wollen. Und bei Stable, das nunmal über Testing aus Unstable entsteht, und für das es Unstable und Testing überhaupt erst gibt, ist das sowieso nicht von Bedeutung: dort ändert sich die Version in Normalfall ja nicht – warum sollte man also den Aufwand für Sid- und Testing treiben, wenn der Mechanismus in Stable, das ja letztlich das Ziel des Ganzen ist, gar nicht gebraucht wird? Das wäre ’ne Sache, welche die Siduction-Leute sich mal anschauen könnten – dort mag’s sinnvoll sein.

Ich bin bis jetzt davon ausgegangen, dass Ausgaben Text sind, und nicht Code im strengen Sinn.

Geht eher darum, dass Shell-Ausgaben oft formatiert sind, und ohne die Code-Tags diese Formatierung (durch Leerzeichen oder Tabs) verschwindet, bzw. durch Zeilenumbrüche kaputtgemacht wird. Auch ist eine unproportionale Schrift bei Ausgaben für Leute, die häufiger die Shell verwenden, leichter/schneller zu erfassen, weil die Ausgaben ja in der Shell auch in einer solchen Schrift vorliegen.

[michaa7]

nur wenn nvidia-driver schon so schlau ist zu bemerken dass der 510ner nicht für meine Graka paßt und das Hinweisfenster sogar weiß was installiert werden muß, dann wäre es nur *folgerichtig* mit der Frage "soll stattdessen der treiber 'nvidia-tesla-470-driver' installiert werden und das system dauerhaft entsprechend konfiguriert werden" den entsprechenden Installationspozess zu iniziieren.

Wie gesagt, das fällt dir bei deinem Siduction spätestens dann auf die Füße, wenn 470-tesla aus Sid rausrollt, weil’s durch den Nachfolger erstetzt wird. ...

Ich verstehe nicht, was das deiner Meinung nach mit siduction zu tun hat (hoffentlich stolpert towo hier drüber) und nicht auch mit sid geschehen würde?

[DeletedUserReAsG]

Ich verstehe nicht, was das deiner Meinung nach mit siduction zu tun hat (hoffentlich stolpert towo hier drüber) und nicht auch mit sid geschehen würde?

Ich weiß nicht, wo du gelesen hast, dass es bei Sid nicht geschehen würde? Natürlich würde es bei Sid, und etwas später auch bei Testing, ebenso geschehen. Ich habe an dieser Stelle „Siduction“ geschrieben, weil du ja vermutlich immer noch Siduction nutzt: 510 ist bei Debian nur in Sid, und würdest du ein reines Sid verwenden, würdest du hier vermutlich nicht mehr schreiben – entweder, weil’s schon lange nicht mehr funktioniert, oder weil solche Kleinigkeiten nebenbei und eigenständig behoben würden, weil sowas nun mal zu erwarten ist, und man damit umgehen kann.

Der Unterschied zwischen Sid und Siduction hier ist: die User von Sid (und Testing) können ausdrücklich nicht davon ausgehen, dass sich jemand um einen sauberen Updatepfad in solchen Situationen kümmert, die im späteren Stable gar nicht auftreten können; vielmehr müssen sie das selbst im Auge behalten¹.
Siduction hingegen scheint dieses Ziel zu haben – also werden sich deren Leute halt darum kümmern müssen, wenn solche Probleme wie hier bei ihren Anwendern nicht mehr auftreten sollen.

--
¹) Vielleicht erinnerst du dich ja dunkel an eine der Diskussionen, in der ich versucht habe, dir zu erklären, warum die Dinger „Unstable“ und „Testing“ heißen würden, und du mir fehlenden Praxisbezug vorgeworfen hast? Als ich geschrieben habe, dass ich dich darauf hinweisen werde, wenn dein Problem auf diesen Sachverhalt zurückzuführen ist? Nun … dies ist ein praktisches Beispiel.

[michaa7]

Ah, ok, wie gehabt also.

[DeletedUserReAsG]

Du könntest mir aber schon zugute halten, dass ich darauf erst auf explizite Nachfrage von dir hin eingegangen bin, oder?

[michaa7]

Gut, halte ich dir zu Gute. Es ist dennoch der selbe alte Quark.

[DeletedUserReAsG]

Willkommen in der Realität – die ist halt auch da, wenn du sie nicht wahrhaben willst

Dies ist nunmal ein Problem gewesen, das bei Stable nicht aufgetreten wäre, mit dem bei Testing und Unstable aber ausdrücklich zu rechnen ist. Wenn es bei Siduction nicht auftreten soll, werden sich deren Devs also selbst drum kümmern müssen.

hoffentlich stolpert towo hier drüber

Vielleicht schaut towo ja tatsächlich noch rein und sagt was dazu. Die Chance dafür hättest du übrigens enorm vergrößert, hättest du im Threadtitel angegeben, dass es um Siduction und nicht um Debian geht.

[michaa7]

Willkommen in der Realität – die ist halt auch da, wenn du sie nicht wahrhaben willst

...

Ich verstehe überhaupt nicht worauf du hinaus willst. Es gab ein Problem innerhalb eines Paketes. Dieses ist gelöst worden. Dabei ist es egal ob das in sid, testing oder stable auftrat. Es war da und wurde gelöst.

Und deine Ausführungen zu meiner Frage warum nvidia, wenn es schon eine inkompatible Graka feststellt, die Installation nicht auf den Treiber umbiegt, sondern sich aufs warne beschränkt habe ich nicht nachvollziehen könne, bzw. die Kausalität nicht verstanden (Aber das führt jetzt langsam auch zu weit).

Deine zeitschleifenhafte Wiederholung meiner angeblichen Realitätsverweigerung jedoch wirkt auf mich wie das einstmalige "dann-geh-doch-nach-drüben"-"Argument". Ich nutze sid(uction). Punkt. Na und?

Und soweit es den Gebrauch von sid(uction + Vorgängern) betrifft habe ich nun eine 16-jährige Realitätserfahrung und kann die Brauchbarkeit recht gut beurteilen. Und wenn es da Probleme gibt frage ich hier nach wie andere dies tun bei Problemen im Testing oder Stable Zweig.

[DeletedUserReAsG]

Und deine Ausführungen zu meiner Frage warum nvidia, wenn es schon eine inkompatible Graka feststellt, die Installation nicht auf den Treiber umbiegt, sondern sich aufs warne beschränkt habe ich nicht nachvollziehen könne, bzw. die Kausalität nicht verstanden

Genau das ist ja das Problem. Die Paket-Maintainer müssten diese Funktionalität einbauen, aber das wäre halt sinnfreie Bindung von Ressourcen: Das Problem kann in Stable, zu dem Unstable und Testing ja nun einmal führen sollen, so gar nicht auftreten – warum sollte man da also Zeit und Ressourcen versenken? Wer Unstable und Testing benutzt, der erwartet solche kleinen Unebenheiten sowieso, und kümmert sich bei deren Auftreten selbst drum.

Da deine Erwartung offensichtlich ist, dass die entsprechende Funktionalität in dem von dir genutzten, von Debian Sid abgeleiteten, System vorhanden sein sollte, wirst du dich dafür also an dessen Entwickler wenden müssen. Was ist daran nicht zu verstehen?
Und da du Siduction und nicht Sid benutzt, wird es dir eben in Siduction und nicht Sid auf die Füße fallen, dass du nun explizit -470 installiert hast, sobald diese Version aus Sid und damit Siduction rausrollt.

Ich erwarte dann deinen Thread, und werde dich dort ein weiteres Mal auf die Bedeutung von „Unstable“ und den möglichen Zusammenhang mit dem vorliegenden Problem aufmerksam machen

[fischig]

Mal so als Zwischenruf, der mir beim Mitlesen durch den Kopf geht:
Irgendwo in der GMS kritisiert Kant jemanden, der „weich gegen sich, aber hart gegen andere“ ist.¹⁾

¹⁾ Die genaue Textstelle zu finden ist mir mittels internetgestützter Such„maschinen“ nicht gelungen. falls es jemand gelingt, wäre ich dankbar für Nennung der „Maschine“ und der verwendeten Suchbegriffe.

[michaa7]

... Das Problem kann in Stable, zu dem Unstable und Testing ja nun einmal führen sollen, so gar nicht auftreten – ...

Wenn du das so erklären würdest dass auch ich verstehe warum das so ist könnte dieser Faden eine produktive Wendung nehmen statt dieses

ein weiteres Mal auf die Bedeutung von „Unstable“...

nach 16 Jahren sid(+) Nutzung. Das doch albern.

[DeletedUserReAsG]

Warum sollte das albern sein? Deine 16 Jahre, mit denen du dich immer wieder brüstest, haben ja nun nicht dazu geführt, dass du dir den Entwicklungsprozess von Debian mal angeschaut hättest und daher wüsstest, was es mit Unstable eigentlich auf sich hat.

Ich könnte nun versuchen, die Sache näher zu erläutern – allerdings weiß ich recht genau, dass ich das schon mindestens einmal sehr ausführlich versucht habe, woraufhin du sinngemäß meintest, dass ich blöde wär’, und das ja alles gar nicht so sein würde. Nochmal versuche ich das daher nicht, denn: „Die Definition von Wahnsinn ist, immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten.” (zugeschrieben: Einstein). Allerdings hatte ich in dem betreffenden Thread auch geschrieben, dass ich dich drauf aufmerksam machen würde, wenn du mal wieder ein daraus resultierendes Problem hättest – und das war hier der Fall.

Wenn du’s tatsächlich verstehen wolltest, dann könntest du dir einfach den entsprechenden Thread raussuchen und ihn nochmal in Ruhe lesen. Dann könntest du auf debian.org nachschauen, ob das Dargestellte sich dort wiederfinden lässt (Hint: es lässt sich dort wiederfinden), und dann die hoffentlich richtigen Schlüsse draus ziehen.

Du kannst natürlich auch weiterhin davon ausgehen, dass „Unstable“ die Bedeutung „getestet und für den Endanwender freigegeben, Fehler sind nicht zu erwarten“ hätte (und dass „Sid“ in der Referenz der gute Junge gewesen wäre ) – und halt dann und wann vor Problemen stehen und nicht verstehen, warum das so ist (in diesem konkreten Fall also beispielsweise: warum es einerseits bei Unstable überhaupt erst zu dem Problem mit dem Paket gekommen ist, und warum sich andererseits bei Debian auch keiner drum kümmern wird, das zu beheben). Deine Wahl.