Titel: Ein Update "zurückrollen"
Beitrag von: Andreas am 19. Oktober 2024, 10:00:28
Endlich war es bei mir so weit: Meine Testing-Umgebung hat sich bei mir gerächt ;D...
Nach einem Update am 15.10. lief die grafische Oberfläche (KDE/Plasma) nicht mehr. Kein Einloggen mehr möglich, ich landete nach ein paar Sekunden wieder im Anmeldebildschirm.
Ein Blick in die pacman-logs zeigte, dass aus dem Repo "kde-unstable" etliche qt6-Pakete installiert wurden. Und ein Blick in das entsprechende Arch-Forum zeigte, dass ich nicht der einzige mit dem Problem war. Der Grund: das Update ist noch nicht komplett in den Repo, es fehlen Pakete, die zur Funktionalität unabdingbar sind. Die kommen in ein paar Stunden, oder morgen...
Ich wollte aber jetzt mit dem System arbeiten, und nicht in ein paar Stunden oder morgen (es ist schließlich mein Produktivsystem)...
Also sollten die beim letzten Update upgedateten Pakete aus den kde-unstable-Repos wieder eine Version zurückgerollt werden. Das kann man händisch - Paket für Paket - machen. Oder man lernt dazu. In so einem Fall entscheide ich mich immer für die letzte Variante.
Es ist mit wenigen Schritten möglich, alle Pakete gleichzeitig zurückzurollen - in meinem Fall um einen Tag...
Dazu ändere ich die pacman.conf und füge als Paketquelle für das betreffende Repo das hier ein:
Code:
[kde-unstable]
#Include = /etc/pacman.d/mirrorlist
Server=https://archive.archlinux.org/repos/2024/10/14/$repo/os/$arch
|
|
Die "normale Serverliste" kommentiere ich aus und füge einen Zeile hinzu, in der das Datum des gewünschten "Rollback-Tages" zu erkennen ist (in meinem Fall 14.10.2024). Dann speichere ich die pacman.conf ab und führe folgenden Befehl aus:
Code:
Kommt euch bekannt vor, ist nur irgendwie "alles doppelt"? Das hat gute Gründe! das doppelte "y" ersetzt die vorhandenen Paketdatenbanken durch die aktuellen. Mit nur einem "y" werden nämlich nur die Änderungen seit dem letzten Datenbankupdate heruntergeladen - in diesem Fall würde das nichts bewirken, da das Datum in der Vergangenheit liegt. Zweimal "u" bedeutet, es werden nicht nur neuere Versionen installiert, sondern, sollten in den Datenbanken ältere Versionen aktiv sein, werden auch Downgrades durchgeführt. Genau das wollte ich ja...
Nach etwa 2 Minuten war das System wieder voll nutzbar.
Am nächsten Tag habe ich meine Änderungen in der pacman.conf wieder rückgängig gemacht (die alte Serverliste aktiv gesetzt und die neue ausdokumentiert), ein
Code:
ausgeführt und nun waren alle Pakete des neuen qt6-Beta vorhanden und alles lief auch nach einem Update einwandfrei.
Wenn man willig ist, die Zusammenhänge zu verstehen und nach Problemlösungen für ein genau definiertes Problem im Internet zu suchen ist selbst ein "verhunztes Update" kein Problem. Systempflege macht Spaß! Das gilt aber nur, wenn auch Lernen Spaß macht und aus eigenem Antrieb erfolgt :D...
LG
Andreas |
Titel: Re:Ein Update "zurückrollen"
Beitrag von: Sebastian am 19. Oktober 2024, 14:45:04
Das hat mich sofort an meinen Thread Arch Linux Archive (https://www.suletuxe.de/forum/index.php?board=11;action=display;threadid=677) erinnert, von 2022 wo die gleiche Methode eingesetzt wird ;D
LG
Sebastian |
Titel: Re:Ein Update "zurückrollen"
Beitrag von: Sebastian am 29. Oktober 2024, 20:30:16
Ich habe Testweise meine Mirrorliste auf das Arch Linux Archiv auf das Wochen Verzeichnis eingstellt.
Somit wird mein EOS nur noch jeden Montag (Vielleicht auch erst Dienstag wegen verzögerung) Updates finden. Damit liege ich dann immer ca. eine Woche zurück. Änlich wie die Distribution Manjaro das macht nur mit dem Unterschied das ich es mir aussuchen kann. ;D
Ich werde das mal ein paar Wochen so laufen lassen und mal schauen in welche Probleme ich dann herein gerate. Weil das EndeavourOS Repo aktueller ist und auch AUR Pakete dann vielleicht Probleme machen können weil ich ja nicht mehr aktuell bin und hinterherhinke.
Einfach nur weil es mich interessiert und ich die Erfahrung mal machen möchte.
Hatte bei einen unserer Teffen ja schon bei jemanden mal gesehen, da wurde Manjaro verwendet. Dort konnte z.b. yay-bin nicht gebaut werden weil pacman zu alt war. |
Titel: Re:Ein Update "zurückrollen"
Beitrag von: Andreas am 30. Oktober 2024, 07:12:23
Ja, bei pacman / yay wird das Probleme geben. Und bei etlichen meiner Amateurfunkprogramme (die Du ja alle nicht hast) auch. Ebenso bei den CAD / 3D-Druck-Programmen zur Ansteuerung von 3D-Druckern, Lasercuttern und 3D-Fräsern (die Du ja auch nicht hast). Bin gespannt, welche "Standardprogramme" da auch von betroffen sein werden...
LG
Andreas |
Titel: Re:Ein Update "zurückrollen"
Beitrag von: Sebastian am 30. Oktober 2024, 11:53:40
Bin ich auch gespannt.
Wie gesagt ich kann mir nur vorstellen das vielleicht Pakete aus dem EndeavourOS Repo Probleme machen könnten und die paar AUR Pakte die ich habe, die sich aber in grenzen halten
Code:
❯ pacman -Qm
arch-log 0.4.0-1
bash-complete-alias 1.18.0-1
brave-bin 1:1.71.118-1
dvdisaster 0.79.10-4
envycontrol 3.5.1-1
fzf-tab-completion-git r408.97658f9-1
kb 0.1.7-2
pacman-log-orphans-hook 1.1-2
python-colored 2.2.4-1
rpi-imager-bin 1.9.0-3
ventoy-bin 1.0.99-1
|
|
|
Titel: Re:Ein Update "zurückrollen"
Beitrag von: Andreas am 30. Oktober 2024, 15:18:04
Um das Forum übersichtlicher zu halten, poste ich meine Ausgabe von
Code:
als Dateianhang ;D
LG
Andreas |
Titel: Re:Ein Update "zurückrollen"
Beitrag von: Andreas am 31. Oktober 2024, 16:33:28
Ich verwende Archlinux (kein EndeavourOS!) seit 5 Jahren auf meinen Servern. Diese sind 24/365 aktiv und online. Ich habe noch nie eine Downtime oder einen Ausfall oder ein Problem durch ein zu früh ausgerolltes Update gehabt. Selbstverständich verwende ich dort NICHT die Testing-Quellen!Somit ist es nach meinem Urteil absolut sinnfrei sich Gedanken zu machen, Updates zu verzögern. Die Server sind Dauerangriffen ausgesetzt - es sind hunderttausende am Tag. Etwa 100 davon sind ernstzunehmen und ich beobachte die Struktur solcher Angriffe. Die meisten suchen jahrzehntealte Lücken oder Dummuserkonfigurationen des Webservers / von ssh / von mysql. Dank der Aktualität des Systems hatte ich bisher noch nie einen Zero-Day-Exploit. Das war unter Debian anders.
LG
Andreas |
Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|