[GELÖST] Einbinden von debian-security Repo führt zu Downgrade

[inne]

berücksichtigen ebenfalls was bereits in security gefixt wurde

Jedenfalls ist dann ein Version aus debin-security überholt - stimmt schon. Ist ja gleich woher die nach debian kopiert wurde.

[lod]

Gibt es eine Datei /etc/apt/preferences oder Dateien im Ordner /etc/apt/preferences.d ?

Hi

Ja, gibt es. Hier die Ausgaben:

Code: Alles auswählen

root@xy:/etc/apt# ls
insgesamt 72K
drwxr-xr-x   7 root root 4.0K Okt 23 14:08 .
drwxr-xr-x 157 root root  12K Okt 26 07:00 ..
drwxr-xr-x   2 root root 4.0K Okt 11 10:21 apt.conf.d
drwxr-xr-x   2 root root 4.0K Mai 28  2019 auth.conf.d
-rw-r--r--   1 root root  172 Okt  6  2019 listchanges.conf
-rw-r--r--   1 root root  125 Mär 26  2019 listchanges.conf.ucf-old
drwxr-xr-x   2 root root 4.0K Sep 17  2016 preferences.d
-rw-r--r--   1 root root 1.1K Okt 23 14:08 sources.list
-rw-r--r--   1 root root    0 Mär 10  2016 sources.list~
-rw-r--r--   1 root root  600 Mär 13  2016 sources.list.bak
-rw-r--r--   1 root root  902 Jun  3 20:50 sources.list.bkup
drwxr-xr-x   2 root root 4.0K Okt 23 13:11 sources.list.d
-rw-r--r--   1 root root  883 Sep 15 17:26 sources.list.save
-rw-r--r--   1 root root 4.3K Apr 30  2016 trusted.gpg
-rw-r--r--   1 root root 2.1K Mär 13  2016 trusted.gpg~
drwxr-xr-x   2 root root 4.0K Okt  6  2019 trusted.gpg.d
root@xy:/etc/apt# cd preferences.d/
root@xy:/etc/apt/preferences.d# ls
insgesamt 20K
drwxr-xr-x 2 root root 4.0K Sep 17  2016 .
drwxr-xr-x 7 root root 4.0K Okt 23 14:08 ..
-rw-r--r-- 1 root root   61 Sep 17  2016 security.pref
-rw-r--r-- 1 root root   51 Sep 17  2016 stable.pref
-rw-r--r-- 1 root root   52 Sep 17  2016 testing.pref
root@xy:/etc/apt/preferences.d# cat security.pref 
Package: *
Pin: release l=Debian-Security
Pin-Priority: 1000
root@xy:/etc/apt/preferences.d# cat stable.pref 
Package: *
Pin: release a=stable
Pin-Priority: 900
root@xy:/etc/apt/preferences.d# cat testing.pref 
Package: *
Pin: release a=testing
Pin-Priority: 750
root@xy:/etc/apt/preferences.d# 

Ähm...und wie resp. was muss man hier nun korrigieren? Und vor allem, an den Files hab ich meines Wissens sicherlich nie etwas gemacht...man sieht, die sind ja auch schon älter

Vielen Dank auch für eure Erklärungen.

[Livingston]

Das Sicherste wäre, sie so umzubenennen, dass kein .pref mehr am Ende steht, also z.B. *.pref.old. (Löschen ginge auch, aber vielleicht müssen wir sie ja noch mal ausgraben.) Dann das übliche update von apt / aptitude. Danach sollten alle Quellen wieder ein Pinning von 500 haben, und die Aktualität der Pakete wird fortan nur noch anhand ihrer Namen festgestellt ---> Standardverhalten.
Bliebe nur noch die Frage übrig, was Du mit der letzten Datei für testing machst. Wenn Du gar keine Testingpakete hast, ist alles erledigt. Wenn doch, wird sich das beim Upgradeversuch zeigen, und wir können uns dieses Detail noch mal anschauen.

[Xero777]

Warte, Warte warum genau hast du jetzt an der Sourcelist rumgeschraubt ? Warum, also was war nochmal genau dein Grund ? Hab, das nicht ganz verstanden. Weil dein System die Grafikkarte downgraded ? Was, war den vorher bevor du an der Sourcelist dran warst ? Taht, da die Grafikkarte noch oder gab es Probleme mit dieser oder mit etwas anderen ?

Und, wie ist dein aktueller Stand an der Sourcelist ? Und am System ? Kannst du noch updaten und upgraden ? Welche Version hast du aktuell ?

[Livingston]

@Xero777: Ist doch alles noch recht übersichtlich. Und wenn man das vorsichtig der Reihe nach anpackt, brennt auch nix an.

1. Die Policy-Einstellungen geradezubiegen, kann hier keinen Schaden verursachen, da sich alle Quellen in der sources.list an die Regeln halten. Die Debian-eigenen innerhalb des Buster-Releases sind auf alle Fälle unstrittig, die Virtualbox-Quelle hält sich auch an die Namenskonventionen (kann ich ich auch aus eigener Erfahrung bestätigen) und Webmin... nuja, zugegeben ein wenig schräg, trägt aber nicht zu einer Verschlimmerung bei, weil es eh' nicht mit den anderen Quellen konkurriert. Schlimmstenfalls kann es mangels erfüllter Abhängigkeiten nicht in Schuss gebracht werden.

2. Ich glaube auch, dass man die sources.list verbessern kann, würde das aber erst im nächsten Schritt tun. Das blöde Downgraden muss nämlich erst mal abgeschaltet werden, und danach haben wir einen sauberen Stand, von dem aus man weitermachen kann.

3. Danach würde ich in der sources.list die buster-upgrades freischalten, und den webmin-Krempel u.U. danach angehen.

EDIT: Nachtrag
4. Testing spielt auch keine Rolle. Hat zwar ein eigenes Pinning, ist aber nicht in der sources.list. Hier mal meine eigene sources.list:

Code: Alles auswählen

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

# buster-backports, previously on backports.debian.org
deb http://deb.debian.org/debian/ buster-backports main contrib non-free <--- nur reinnehmen, wenn man es wirklich braucht
#VBox
deb http://download.virtualbox.org/virtualbox/debian buster contrib

Und das läuft komplett ohne pinning in den preferences

EDIT2: Hab gerade eine falsche Liste gepostet. Das hier ist jetzt die Version, die bei mir läuft.

[lod]

Das Sicherste wäre, sie so umzubenennen, dass kein .pref mehr am Ende steht, also z.B. *.pref.old. (Löschen ginge auch, aber vielleicht müssen wir sie ja noch mal ausgraben.) Dann das übliche update von apt / aptitude. Danach sollten alle Quellen wieder ein Pinning von 500 haben, und die Aktualität der Pakete wird fortan nur noch anhand ihrer Namen festgestellt ---> Standardverhalten.
Bliebe nur noch die Frage übrig, was Du mit der letzten Datei für testing machst. Wenn Du gar keine Testingpakete hast, ist alles erledigt. Wenn doch, wird sich das beim Upgradeversuch zeigen, und wir können uns dieses Detail noch mal anschauen.

Vielen Dank für Deine Hilfe. Hat geholfen. Nachdem ich diese Dateien umbenannt und alles nötigen Repos wieder einkommentiert hab, sind die Downgrades verschwunden und alles klappt wunderbar Backports benötige ich keine.

Meine Source-List sieht nun wie folgt aus:

Code: Alles auswählen

#------------------------------------------------------------------------------#
#                   OFFICIAL DEBIAN REPOS                    
#------------------------------------------------------------------------------#

###### Debian Main Repos
deb http://deb.debian.org/debian/ buster main contrib non-free
deb-src http://deb.debian.org/debian/ buster main contrib non-free

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

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

#------------------------------------------------------------------------------#
#                      UNOFFICIAL  REPOS                       
#------------------------------------------------------------------------------#

###### 3rd Party Binary Repos
###Virtualbox
deb [arch=i386,amd64] http://download.virtualbox.org/virtualbox/debian buster contrib

###Webmin
deb http://download.webmin.com/download/repository sarge contrib

Vielen Dank für eure Hilfe! Ich hab den Eintrag als "gelöst" markiert.

[lod]

Warte, Warte warum genau hast du jetzt an der Sourcelist rumgeschraubt ? Warum, also was war nochmal genau dein Grund ? Hab, das nicht ganz verstanden. Weil dein System die Grafikkarte downgraded ? Was, war den vorher bevor du an der Sourcelist dran warst ? Taht, da die Grafikkarte noch oder gab es Probleme mit dieser oder mit etwas anderen ?

Und, wie ist dein aktueller Stand an der Sourcelist ? Und am System ? Kannst du noch updaten und upgraden ? Welche Version hast du aktuell ?

Hi Xero777

Ich hatte das Problem, dass wenn ich die Security-Updates eingebunden hatte, es einen Downgrade vom Packet "intel-microcode" gab. Dies wiederum wird sehr wahrscheinlich für die Grafikkarte verwendet und war dann nicht mehr mit dem NVIDIA Treiber "kompatibel" und somit kam der Standard VESA Treiber zum Einsatz.

Vorher war noch, dass ich mal ein Problem mit den Debian FTP-Spiegel Sources für die Schweiz hatte (die von der ETH Zürich). Siehe diesen Thread hier: viewtopic.php?f=34&t=176391 Das hat dann dazu geführt, dass ich auf die "normalen" Sources ausgewichen bin. Ich sehe nun auch, was seinerzeit das Problem war, nur konnte ich es da noch nicht so genau nachvollziehen resp. kannte ich diese apt policy nicht. Darauf hin hab ich einfach die Security-Updates mal deaktiviert, da diese ja irgendwann mal in die normalen Updates fliessen. Da aber in letzter Zeit immer wieder Meldungen von Schwachstellen aufkam, dachte ich, ich gehe dem Problem mal genauer nach

Lange Rede kurzer Sinn: Es lag an diesem Pinning resp. an den Files unter /etc/apt/preferences.d welche die Standard-Prioritäten verändert haben und wohl für all das Übel verantwortlich waren

[lod]

Vielen Dank an inne, JTH, rhHeini, willy4711, Livingston und Xero777 für eure Hilfe!

[Blackbox]

Es lag an diesem Pinning resp. an den Files unter /etc/apt/preferences.d welche die Standard-Prioritäten verändert haben und wohl für all das Übel verantwortlich waren

Das ist zwar eine Lösung, aber die ist auf Dauer nicht nachhaltig.
Besser wäre es aus meiner Sicht gewesen, du hättest dich mit APT Pinning beschäftigt, so a) das Problem verstanden und b) mit einem ordentlichem Pinning zukünftige Probleme aus dieser Richtung vorgebeugt.
Aber ich erwarte nicht, dass dich mein gut gemeinter Rat tangieren wird.

[willy4711]

Das ist zwar eine Lösung, aber die ist auf Dauer nicht nachhaltig.

Warum ist das nicht Nachhaltig ?
Eine "normale" sources.list braucht kein Pinning (alle 500)
Ich fahre seit über zwei Jahren alle Repos (auch die Fremdrepos auf 500, hatte damit
noch nie Probleme.
Selbst wenn man die Backports ergänzt werden die automatisch auf eine Priorität von 100 gesetzt
Das ist die einzige Ausnahme.

Kümmern muss man sich nur, wenn man der Meinung ist irgendwelche "Extravaganzen" , sich leisten zu müssen.

[Blackbox]

Warum ist das nicht Nachhaltig ?

Weil das Beschäftigen und damit das Verstehen des APT Pinning Mechanismus besser gewesen wäre.
Denn sobald die Fremdquellen (wieder) aktiviert werden, kann jeder Zeit dieses Problem erneut auftreten, dem hätte APT Pinning vorgebeugt.

Ich fahre seit über zwei Jahren alle Repos (auch die Fremdrepos auf 500, hatte damit noch nie Probleme.

Hallo Willy, hier unterliegst du leider einem Trugschluss.
Nur weil du bisher noch keine Probleme hattest, gilt dies aber nicht automatisch für alle anderen Debian Anwender.

Gerade Fremdrepositories sollten immer (niediger) gepinnt sein, als die offiziellen Hauptrepositories, so man unbedidingt der Meinung ist, Fremdrepositories einsetzten zu müssen.

Selbst wenn man die Backports ergänzt werden die automatisch auf eine Priorität von 100 gesetzt

Das ist auch gut so, aber kein Automatismus.
Will heißen, dass du nicht damit rechnen solltest, dass jedes Paket in/aus einem Fremdrepository auch den richtigen Pinnig-Wert mitbringt.
Deswegen ist APT Pinning bei Misch und/oder Fremdrepositories wichtig und wurden geschaffen, um genau diesem Problem (Pakete aus Fremd- bzw. Mischquelle ersetzt Paket aus Debianquelle) entgegenwirken zu können.

Kümmern muss man sich nur, wenn man der Meinung ist irgendwelche "Extravaganzen" , sich leisten zu müssen.

Fremd- und Mischquellen zählen bereits zu den "Extravaganzen".

[Livingston]

Ich seh' das genau umgekehrt wie blackbox. Ich stimme zwar zu, dass eine Beschäftigung mit Pinning wichtig ist, aber bevor man sich da ranwagt, sollte das System erst mal rund laufen. Da dies mit dem, was in der sources.list steckt, funktioniert, hielt ich dieses Vorgehen für richtig.

Pinning ist nicht gerade schön dokumentiert. Die man page ist zwar inhaltlich korrekt, aber verständlich ist was anderes. Ich glaube, wenn man damit rumspielen will, sollte man erst mal in einer virtuellen Maschine ein paar Trockenübungen machen - hat mir jedenfalls nicht geschadet

[Blackbox]

aber bevor man sich da ranwagt, sollte das System erst mal rund laufen.

Damit machst du aber eine Henne-Ei-Diskussion auf bzw. nimmst du einen Blickwinkel nach dem Problem ein.
Ich wiederum agumentiere proaktiv.
Will sagen, hätte $MAN sich sich von Anfang an, konsequent mit APT Pinning beschäftigt, hätte es diesen Thread (wahrscheinlich) nicht gegeben.
Aber da der Fehler nun einmal eingetreten ist, ap­pel­lie­re ich, daraus zu lernen und nun endlich auf APT Pinning zu setzen, was das Erlernen von APT Pinning voraussetzt.

Pinning ist nicht gerade schön dokumentiert.

1.) Ist eine »schöne« Dokumentation immer eine Geschmackssache/eine Verständnisfrage.
2.) https://wiki.debianforum.de/AptPinning ← Diese Dokumentation reicht dir nicht?

[lod]

Es lag an diesem Pinning resp. an den Files unter /etc/apt/preferences.d welche die Standard-Prioritäten verändert haben und wohl für all das Übel verantwortlich waren

Das ist zwar eine Lösung, aber die ist auf Dauer nicht nachhaltig.
Besser wäre es aus meiner Sicht gewesen, du hättest dich mit APT Pinning beschäftigt, so a) das Problem verstanden und b) mit einem ordentlichem Pinning zukünftige Probleme aus dieser Richtung vorgebeugt.
Aber ich erwarte nicht, dass dich mein gut gemeinter Rat tangieren wird.

Hi

Vielen Dank für Deine Anmerkung. Du hast zwar recht, dass ich mich nicht sehr tief mit dem Thema auseinandergesetzt habe. Jedoch bin ich mir auch sicher, dass ich nie etwas an diesen Files geändert habe und das Pinning somit mind. seit 2016 besteht.

Code: Alles auswählen

root@xy:/etc/apt/preferences.d# ls
insgesamt 20K
drwxr-xr-x 2 root root 4.0K Sep 17  2016 .
drwxr-xr-x 7 root root 4.0K Okt 23 14:08 ..
-rw-r--r-- 1 root root   61 Sep 17  2016 security.pref
-rw-r--r-- 1 root root   51 Sep 17  2016 stable.pref
-rw-r--r-- 1 root root   52 Sep 17  2016 testing.pref

Das Problem ist aber deutlich später aufgekommen. Auf meinem System, welches ich nun sicherlich schon seit 8 Jahren mit Debian betreibe, gab es VBox und Webmin schon immer von diesen Fremd-Repos und ich habe mich vor noch längerer Zeit (dazwischen mal die HW gewechselt und eine Neuinstallation vorgenommen - Lenny war meine erste Debian-Installation) bewusst dazu entschieden, diese zwei Komponenten aus Fremdrepos zu verwenden und bin damit bis jetzt immer gut gefahren.

In all dieser Zeit hatte ich weder etwas mit Pinning gemacht (bin ich mir relativ sicher) und ich kann mir auch nicht erklären, woher diese Prios kommen. Sollten diese aus einer Standard-Installation von Debian stammen, dann hätten wohl viele die selben Phänomene wie ich. Eventuell war es mal bei einem Wechsel der Debian-Version? Oder evtl. hab ich diese Dateien in einem schwachen Moment anhand irgendeiner Anleitung erstellt.

Was mich aber interessiert ist, was ist denn die Standard-Einstellung? Existieren diese Files standardmässig mit diesen Prios? Auf einem Stretch-System, dass ich noch betreibe, sind keine solche Files vorhanden und die Man Pages lassen sich (sofern ich es verstehe) auch darüber aus. Deshalb kam ich zum Schluss, ich brauche keine Prio und im Vertrauen, dass Livingston und Xer0777 wissen, wovon sie schreiben, hab ich die Files umbenannt resp. nun definitiv gelöscht und alles hat geklappt.

Schlussendlich, ja, ich hab mich nicht gross damit beschäftigt, weil ich für mein System keinen Grund sehe, die Prio vom Standard abweichend zu definieren. Aber definitiv für die Zukunft etwas dazugelernt. Sollte es nötig sein, würde ich mich dann bei Bedarf tiefer in die Materie einlesen.

Danke für Deinen gut gemeinten Rat.

Gruss

EDIT:
Der Proaktive Ansatz ist zwar löblich, aber manchmal fehlt halt einfach die Zeit...ist ja meine private Maschine und da geht der Trade-Off zwischen Zeit, Aufwand und Qualität halt meistens zu lasten der Zeit worunter dann die Qualität leidet...diese Zeit hab ich nun nachgeholt und entsprechend stimmt nun die Qualität wieder

[Livingston]

Standard ist automatisches Pinning mit Priorität 500 und keine Einträge unter preferences.

[mcb]

aber bevor man sich da ranwagt, sollte das System erst mal rund laufen.

Damit machst du aber eine Henne-Ei-Diskussion auf bzw. nimmst du einen Blickwinkel nach dem Problem ein.
Ich wiederum agumentiere proaktiv.
Will sagen, hätte $MAN sich sich von Anfang an, konsequent mit APT Pinning beschäftigt, hätte es diesen Thread (wahrscheinlich) nicht gegeben.
Aber da der Fehler nun einmal eingetreten ist, ap­pel­lie­re ich, daraus zu lernen und nun endlich auf APT Pinning zu setzen, was das Erlernen von APT Pinning voraussetzt.

Pinning ist nicht gerade schön dokumentiert.

1.) Ist eine »schöne« Dokumentation immer eine Geschmackssache/eine Verständnisfrage.
2.) https://wiki.debianforum.de/AptPinning ← Diese Dokumentation reicht dir nicht?

Na ja ich habe mich zwangsläufig als Newbie mit Extrawünschen mit Pinning beschäftigt.
https://wiki.debianforum.de/AptPinning habe ich al Anfänger nicht 100%ig verstanden. Werde nochmal einen Extrathread erstellen mit zwei drei dummen Fragen, aber pinning hat einige Falstricke, bzw. steht in den Anleitungen immer nur ein Teil.

https://wiki.debian.org/AptConfiguration

Es ist auch völlig unverständlich wie apt das ganze hinterher auflöst, scheint Ausnahmen von den Regeln zu geben.

[Tintom]

Es ist auch völlig unverständlich wie apt das ganze hinterher auflöst, scheint Ausnahmen von den Regeln zu geben.

Mach das dann besser in einem separaten Thread und dann bestenfalls in einer VM zum gefahrlosen testen. Die Logik von apt & co erscheint auf den ersten Blick manchmal komisch, lässt sich dann aber in der Folge gut aufklären.

[mcb]

Es ist auch völlig unverständlich wie apt das ganze hinterher auflöst, scheint Ausnahmen von den Regeln zu geben.

Mach das dann besser in einem separaten Thread und dann bestenfalls in einer VM zum gefahrlosen testen. Die Logik von apt & co erscheint auf den ersten Blick manchmal komisch, lässt sich dann aber in der Folge gut aufklären.

Ja - hatte ich ja vor Sorry für Offtopic.