unattended-upgrades braucht lange (gelöst) || Pin-Priority funktioniert nicht (nicht gelöst)

[BurnerR]

Habe jetzt schon dreimal im Internet gesucht und bin gerade wieder genervt:
unattended-upgrades ist ne coole Sache und bei Debian 9 per default aktiviert.
Aber wieso braucht er knapp 20 Minuten um festzustellen, dass es nicht zum aktualisieren gibt?

TL;DR:
Es lag daran, dass in den sources neben testing noch oldstable/jessie vorhanden war. Für die Jessie Pakete hat er die Pin-Priority nicht wie angedacht korrekt gesetzt, dadurch hatten die Jessie und testing Pakete beide eine Priorität von 500, dadurch hat unattended-upgrade jedes Paket einzeln verglichen ("adjusting candidate version"), was sehr lange gedauert hat.
Habe Jessie aus den Sources jetzt entfernt, jetzt geht es wieder schnell.
Warum er die Pin-Priority nicht richtig gesetzt hat habe ich leider nicht herausgefunden .
TL;DR


[src=bash]
# tail /var/log/unattended-upgrades/unattended-upgrades.log

2018-04-14 08:48:49,498 INFO Initial blacklisted packages:
2018-04-14 08:48:49,499 INFO Initial whitelisted packages:
2018-04-14 08:48:49,499 INFO Starting unattended upgrades script
2018-04-14 08:48:49,499 INFO Allowed origins are: origin=Debian,codename=jessie,label=Debian, origin=Debian,codename=jessie,label=Debian-Security
2018-04-14 09:05:53,974 INFO No packages found that can be upgraded unattended and no pending auto-removals
2018-04-14 09:06:00,170 INFO Initial blacklisted packages:
2018-04-14 09:06:00,171 INFO Initial whitelisted packages:
2018-04-14 09:06:00,171 INFO Starting unattended upgrades script
2018-04-14 09:06:00,171 INFO Allowed origins are: origin=Debian,codename=jessie,label=Debian, origin=Debian,codename=jessie,label=Debian-Security
[/src]

Da steht er jetzt seit 10 Minuten (es ist 09:15 Uhr jetzt gerade). Laut log macht er das ganze gerne mal doppelt wie offenbar auch hier gerade. Ist das normales/gewünschtes Verhalten?
Aber wieso 20 Minuten? CPU Auslastung ist 100% die Zeit über. Das kann doch unmöglich so viel länger dauern als ein manualles apt update && apt upgrade?
unattended-upgrades-dpkg.log enthält nichts zu heute.


Beim schreiben wird mir klar, dass 'codename=jessie' falsch ist. Ich vermute es liegt daran? Ich halte euch auf dem Laufenden .

PS.:

sources und prefs:
[src=bash]# cat /etc/apt/sources.list

deb http://ftp.de.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.de.debian.org/debian/ testing main

deb http://security.debian.org/debian-security testing/updates main
deb-src http://security.debian.org/debian-security testing/updates main

# stretch-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ testing-updates main
deb-src http://ftp.de.debian.org/debian/ testing-updates main

# was added for nvidia
# deb http://httpredir.debian.org/debian/ testing main contrib non-free

deb https://dl.winehq.org/wine-builds/debian/ testing main[/src]

[src=bash]# cat /etc/apt/sources.list.d/jessie.list
deb http://deb.debian.org/debian jessie main
deb-src http://deb.debian.org/debian jessie main[/src]

[src=bash]# cat /etc/apt/preferences.d/jessie.pref
Package: *
Pin: release n=jessie
Pin-Priority: -1

Package: libssl1.0.0
Pin: release n=jessie
Pin-Priority: 500[/src]

Ich werde die Pin-Priority von libssl1.0.0 (danke Steam ) runtersetzen und gucken ob das hilft. Dennoch seltsam, dass unattended-upgrades damit offenbar probleme hat??
Stellt sich mir grad eh die Frage, wie dumm das ist libssl1.0.0 anzupinnen... lol.


Update:

Hab jetzt Pin-Prioroty für libssl1.0.0 mal auf 1 gesetzt.
Und unattended-upgrades -d gestartet.
Keine Veränderung.
Allerdings, zufällig rausgegriffenes paket:
[src=bash]# apt-cache policy zurl
zurl:
Installed: (none)
Candidate: 1.9.1-1
Version table:
1.9.1-1 500
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
50 http://deb.debian.org/debian unstable/main amd64 Packages
1.3.1-4 500
500 http://deb.debian.org/debian jessie/main amd64 Packages[/src]
Das ist ja quatsch so, offenbar stimmt was mit dem pinning der jessie pakete nicht?

Zusatz:[src=bash]# apt-cache policy | grep jessie
500 http://deb.debian.org/debian jessie/main i386 Packages
release v=8.10,o=Debian,a=oldstable,n=jessie,l=Debian,c=main,b=i386
500 http://deb.debian.org/debian jessie/main amd64 Packages
release v=8.10,o=Debian,a=oldstable,n=jessie,l=Debian,c=main,b=amd64[/src]
n=jessie sollte also eigentlich korrekt sein. Vermutlich wird die pin/preferences datei nicht eingelesen...?

Mit unstable funktioniert es aber:
[src=bash]# apt-cache policy | grep unstable
50 http://deb.debian.org/debian unstable/non-free i386 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=i386
50 http://deb.debian.org/debian unstable/non-free amd64 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
50 http://deb.debian.org/debian unstable/contrib i386 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=i386
50 http://deb.debian.org/debian unstable/contrib amd64 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
50 http://deb.debian.org/debian unstable/main i386 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=i386
50 http://deb.debian.org/debian unstable/main amd64 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64[/src]

[src=bash]# cat /etc/apt/preferences.d/unstable.pref
Package: *
Pin: release a=unstable
Pin-Priority: 50
[/src]

[src=bash]# ls /etc/apt/preferences.d/ -alh
total 20K
drwxr-xr-x 2 root root 4.0K Apr 14 09:47 .
drwxr-xr-x 6 root root 4.0K Feb 4 00:05 ..
-rw-r--r-- 1 root root 61 Nov 19 11:29 firefox.pref
-rw-r--r-- 1 root root 115 Apr 14 09:47 jessie.pref
-rw-r--r-- 1 root root 52 Nov 19 11:34 unstable.pref[/src]


PPS.:
Weitere Vermutung war, dass apt.conf was falsch eingestellt ist, habe aber nichts gefunden:
[src=bash]/etc/apt/apt.conf.d# cat * | grep Default
DefaultEnabled "false";
DefaultEnabled "false";
DefaultEnabled "false";
DefaultEnabled "false";
DefaultEnabled "false";
// Set this value to "true" to get emails only on errors. Default
// Default: "now"
// Enable logging to syslog. Default is False
// Specify syslog facility. Default is daemon
DefaultEnabled "true";

/etc/apt/apt.conf.d# cat * | grep jessie
// n,codename (eg, "jessie", "jessie-updates")

[/src]

Ich glaube, mir sind jetzt die Ideen ausgegangen .
Fazit
Wenn ich jessie rausnehme aus den sources, dann läuft unattended-upgrades innerhalb weniger sekunden durch.
libssl1.0.0 bleibt erhalten, da manuell zur installation ausgwählt. Na gut. Workaround.

 

[theSplit]

@BurnerR: Danke für diesen Problembericht und die Lösung!

Nur als Tipp dazu: Wenn du unbedingt eine bestimme Paketversion brauchst, kannst du diese mit "apt-mark hold paketname" halten so fern bereits installiert.
Das hält APT gänzlich davon an das Paket zu upgraden. "Manuell installiert" ist ja kein direkter Schutz gegen Upgrades.

Mit "apt-mark unhold paketName" kannst du das halten wieder ausschalten für Paketname.

Und mit "apt-mark showhold" ansehen was gehalten wird.

Das ist echt praktisch, weil dir ein Update das Paket nicht hochrüsten wird.
Einziges Manko: Das Settings sollte man allerdings nicht permanent drin haben, um auf der sicheren Seite zu sein wenn Sicherheitsupdates kommen.
Aber es kann nützlich sein in so einem Fall.

 

[BurnerR]

War bisher nicht nötig daher kannte ich apt-mark hold nicht - danke dir für den Tipp.
Steam hat ne dependency zu libssl1.0.0,, neuere Versionen wurden in einem neuen paket libssl1.1 ausgeliefert. Ansonsten hättest du recht gehabt mit hold... wobei ich das jetzt nicht gemacht hätte mit ner libssl .

--- [2018-04-16 09:06 CEST] Automatisch zusammengeführter Beitrag ---

Grad nochmal den Thread gelesen.. neue Theorie...
Es liegt an den Leerzeichen in /etc/apt/preferences.d/jessie.pref
Sonst fällt mir aber wirklich nichts mehr ein .

 

[sia]

n=jessie sollte also eigentlich korrekt sein. Vermutlich wird die pin/preferences datei nicht eingelesen...?

Sicher? Sollte es nicht a=jessie sein? a steht ja für den Namen des Archivs.

Hab jetzt Pin-Prioroty für libssl1.0.0 mal auf 1 gesetzt.

Pin-Priority: -1 bedeutet, dass das Paket auf keinen Fall installiert wird (<0).

Pin-Priority: 500 bedeutet, dass das Paket installiert wird, wenn die Version neuer als die aktuell installierte ist.

Siehe man 5 apt_preferences:

Never downgrade unless the priority of an available version exceeds 1000.

[…]

How Apt Interprets Priorities

Priorities (P) assigned in the APT preferences file must be positive or negative integers. They are interpreted as follows (roughly speaking):

P > 1000

causes a version to be installed even if this constitutes a downgrade of the package.​

990 < P <=1000

causes a version to be installed even if it does not come from the target release, unless the installed version is more recent.​

500 < P <=990

causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent.​

100 < P <=500

causes a version to be installed unless there is a version available belonging to some other distribution or the installed version is more recent.​

0 < P <=100

causes a version to be installed only if there is no installed version of the package.​

P < 0

prevents the version from being installed.​

Du möchtest libssl1.0.0 also eigentlich auf Pin-Priority: 1001 oder höher stellen, wenn ich das richtig verstanden habe?

Es liegt an den Leerzeichen in /etc/apt/preferences.d/jessie.pref
Sonst fällt mir aber wirklich nichts mehr ein .

Wie meinst du das? Die Einrückung? Kann ich mir nicht vorstellen. Aber probier' es doch einfach mal aus

Ist halt auch nicht die coolste Sache, wenn du Debian 10 (testing/Buster) mit den Quellen von Debian 8 (Jessie) benutzt. Da ist ja noch Debian 9 (Stretch) dazwischen. Hast du kürzlich mal ein apt dist-upgrade durchgeführt? (btw: apt ist das neue apt-get)

Sicher, dass libssl1.0.2 nicht funktioniert? Du kannst auch mit folgendem Script selektiv die Runtimes von Steam löschen:

[src=bash]#!/bin/sh
find ~/.local/share/Steam/ \( -name "libgcc_s.so*" -o -name "libstdc++.so*" -o -name "libxcb.so*" -o -name "libgpg-error.so*" -o -name "libX11.so*" \) -print -delete[/src]