Andreas
Administrator
 Offline
Einträge: 1140
Linux von Innen
|
 |
Alles über Updates bei Arch/Antergos/Endeavour
« am: 05. April 2019, 17:21:41 »
|
|
Wie oft sollte man ein Update machen?
Wer einmal pro Woche ein Update macht, liegt in einem komfortablen Bereich. Selbst wenn mal aufwändige (aus den AURs zu bauende) Pakete erneuert werden ist die Dauer des Updates in akzeptablem Rahmen. Wer zu lange wartet bzw. auftretende Probleme nicht löst sondern aufschiebt, macht sich und eventuellen Helfern das Leben unnötig schwer! Updates dauern dann immer länger, und es kann auch sein dass immer mehr kleinere Probleme (siehe nächsten Absatz) auftauchen, die im Verbund dann schon mal zu größeren anwachsen können. Deswegen empfehle ich generell, Problemchen sofort anzugehen anstatt sie aufzuschieben und zu hoffen, dass sich das alles mal von selbst auflöst.
Wenn ein Update mal hakt...
############################################
(1)...weil folgende Meldung beim Update aus den Standard-Repos erscheint:
:Fehler: <Name_des_Paketes>: signature from "irgendeine_Email_Adresse" is marginal trust
Fehler: Der Vorgang konnte nicht durchgeführt werden (Ungültiges oder beschädigtes Paket)
Hier sind Schlüssel aus dem Archlinux-Keyring abgelaufen (zu lange mit den Updates gewartet??). Das kann man mit einer Neuinstallation des Keyring-Paketes lösen:
sudo pacman -Syy
sudo pacman -S archlinux-keyring
... und wenn man Endeavouros nutzt noch ein sudo pacman -S endeavouros-keyrin
Danach stoppt ein Update aus den Standard-Repos nicht mehr wegen eines abgelaufenen Schlüssels. Wenn das nicht hilft, kann man auch dem "Schlüssel mit dem fehlenden Vertrauen" manuell vertrauen mit
sudo pacman-key --lsign-key emailadresse_des_Schlüssels_an_dem_es_hakt
############################################
(2)...weil irgendwelche Abhängigkeiten nicht aufzulösen sind, gibt es drei Möglichkeiten:
1) Bei Verwendung des grafischen Updatetools kann man einfach die betreffenden hakenden Pakete manuell abwählen und dann auf "Übernehmen" gehen. Dann laufen alle anderen Pakete durch. Und irgendwann (hoffentlich bald) löst sich die Abhängigkeit von selbst auf, weil die Maintainer dran gearbeitet haben
oder
2) Man öffnet als root (z.B. mit dem mc) die Datei /etc/pacman.conf Dort findet man die eine Zeile mit dem Inhalt
#IgnorePkg =
Man entfernt nun einfach die Raute am Anfang und setzt die auszuschließen Pakete hinter das Gleichheitszeichen, also z.B.
IgnorePkg = mate-calc x264
Datei abspeichern - fertig. Von nun an werden die aufgelisteten Pakete NIEMALS aktualisiert (aufpassen!!)
oder
3) Man aktualisiert auf der Kommandozeile mit
pacman -Syu --ignore=mate-calc
Das wirkt nur einmalig und man kann ab und zu probieren, ob sich die Abhängigkeit schon gelöst hat. Man kann auch Wildcards * und ? einsetzen, um ganze Paketgruppen auszuschließen.
############################################
(3)...weil bei Updates aus dem AUR "der Schlüssel xxxxxxxx fehlt":
Wenn ihr sicher seid, dass das neue Paket auch wirklich von dem Maintainer stammt (gerade dafür gibt es ja die Schlüssel!!!) dann hat der Maintainer einfach den neuen Schlüssel noch nicht korrekt mitgeteilt. Dann müsst ihr ihn selbst holen (aber, wie geschrieben, nur, wenn ihr euch sicher seid dass das keine Malware ist). Gebt als User auf der Konsole ein:
gpg --recv-keys xxxxxxxxxxx
wobei xxxxxxxxxxx jeweils der fehlende Schlüssel ist.
Sollte der Schlüssel nicht bei den AURs fehlen sondern bei Updates aus den normalen Repos importiert ihr ihn mittels
sudo pacman-key -r xxxxxxxxxxx
sudo pacman-key --lsign-key xxxxxxxxxxx
############################################
(4)...weil bei Updates aus dem AUR das Bauen eines Paketes fehlschlägt:
Schlägt der Bau eines einzigen Paketes aus den AUR fehl, wird GAR KEINS upgedatet. Das ist natürlich nicht so schön. Also müssen wir zunächst die Ausgaben des Updatescriptes komplett verfolgen und feststellen welches Paket den Fehler verursacht. Hat man das herausgefunden, startet man einfach ein neues Update.
Zunächst versuchen wir das betroffene Paket in einer chroot-Umgebung zu bauen wie im nächsten Beitrag in diesem Thread beschrieben ist. Oft ist das schon die Lösung. Hilft das nicht, müssen wir dieses Paket wie folgt behandeln:
Nachdem yay die upzudatenden Pakete dann angezeigt hat kann man Pakete vom Update ausnehmen. Die Pakete werden durchnummeriert angezeigt. Man kann durch Angabe der Nummer (durch Leerzeichen getrennt auch mehrere, Bereiche können durch z.B. 3-7 angegeben werden, auch zusätzlich zu weiteren Paketen) Pakete angeben, die nicht upgedatet werden.
############################################
(5)...weil die Fehlermeldung "Konnte Datei xyz.db nicht von abcde übertragen: Failed to connect to repo abcde Port gf: Verbindungsaufbau abgelehnt" kommt:
Einer der Server auf dem die Updatedateien liegen ist entweder temporär oder dauerhaft nicht zu erreichen. In dem Fall bricht Arch ALLE Updates ab. Man sollte diesen Server aus den Updates ausschliessen. Die Server stehen in der Konfigurationsdatei /etc/pacman.conf, die man nur als root bearbeiten kann. Man öffnet diese Datei also als root zum Bearbeiten (am Einfachsten geht das mit dem mc, den wir ja schon oft besprochen haben). Dann suchen wir die Zeile mit dem Inhalt:
[xyz] (in diesem Fall also [trinity]). An den Anfang dieser Zeile setzen wir ein Kommentarzeichen (das ist die Raute #). Die nächste Zeile mit Inhalt unter dieser beginnt mit "Server=" - vor die setzen wir auch ein Kommentarzeichen. Jetzt noch das Ergebnis mit F2 abspeichern - fertig! Jetzt wird dieser Server nicht mehr abgefragt.
Man sollte aber ab und zu ausprobieren, ob er wieder erreichbar ist (einfach die beiden Kommentarzeichen wieder entfernen). Geht es immer noch nicht: Zeichen wieder rein.
############################################
(6)...weil die Fehlermeldung "Fehler: Konnte Datei 'xyz.db' nicht von blablabla.blu übertragen : SSL certificate problem: certificate has expired" oder
Fehler: Konnte Datei 'xyz.db' nicht von blablabla.blu übertragen : OpenSSL SSL_connect: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt in connection to blablabla.blu:443 kommt:
...dann ist das SSL-Zertifikat des Servers, von dem bestimmte Pakete abgeholt werden sollen, ungültig (abgelaufen oder schlimmstenfalls gefälscht) - oder der Server ist aktuell einfach nicht erreichbar. Hier kann man zwei Dige tun:
1) Einfach Geduld haben. Nach ein paar Stunden, oder Tagen, einfach nochmal probieren. Tritt das Problem nach 4 Tagen aber immer noch auf sollte man das betreffende Repository in der /etc/pacman.conf ausdokumentieren. Dann gehen in der Zwischenzeit wenigstens alle Updates durch, die nicht von diesem Server kommen. Ab und zu testen, ob es mit wieder aktiviertem Repo vielleicht auch wieder läuft.
############################################
(7)...weil "Eine oder mehrere Dateien überstanden nicht die Gültigkeits-Prüfung!" kommt:
...dann ist manchmal einfach die Prüfsumme falsch, die mit angegeben wurde. Wenn der Fehler auch nach mehreren Tagen noch da ist wird es das vermutlich sein. In dem Fall kann man die Prüfsummen neu berechnen lassen.
Dafür wechseln wir mit
cd ~/.cache/yay/name-des-Paketes
in das Verzeichnis in dem die Dateien liegen. Kontrolliert: Es sollte hier auch eine Datei namens "PKGBUILD" vorhanden sein. Wenn ja, seid ihr richtig und es geht weiter. Mit dem Befehl
updpkgsums PKGBUILD
berechnen wir jetzt neue Prüfsummen. Danach können wir einen Installationsversuch "per Hand" mit folgendem Befehl starten:
makepkg -i PKGBUILD --noconfirm
Läuft jetzt alles durch? Dann war es das!
############################################
(8)...weil "Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
<Paketname>: /Pfad/zu/irgendeiner/Datei existiert im Dateisystem" kommt:
Hier ist etwas Fingerspitzengefühl angesagt. Handelt es sich um Fonts, Lizenz-Dateien,Manuals etc. kann man einfach dieses Paket gezielt installieren und zum Überschreiben zwingen mit:
yay --force -S <Paketname>
...danach das Update nochmal aufrufen, es wird dann durchlaufen. Sollten Bibliotheken (.o, .lib etc.) überschrieben werden fragt lieber im Forum nochmal nach mit genauer Angabe der Fehlermeldung.
############################################
(9)...weil yay beim "sich-selbst-updaten" nicht genügend Berechtigungen hat und das Update daher steckenbleibt:
In dem Fall muss man einfach den Ordner, in dem yay die Dateien für "sich selbst" aufhebt (und NUR diesen!!) komplett löschen, und zwar mit sudo rm -rf ~/.cache/yay/yay
############################################
Ab und zu (bei den tausenden Updates die man im Laufe eines Jahres erhält ist das ab und zu) gibt es auch Fälle bei denen man "per Hand" eingreifen muss. Das veröffentlichen dann die Entwickler selbst auf den Arch News Seiten. Schaut doch einfach mal rein und beurteilt selbst ob sowas wirklich oft nötig ist...
LG
Andreas
|
| « Letzte Änderung: 28. Mai 2023, 11:31:45 von Andreas » |
 Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Autor
