Gestern war mein schwarzer Mittwoch. Als Manjaro-User rollte das Talos-Release an, also die Version 22.1.0 der Arch-basierten Distribution. Da ich seit 2 Jahren Manjaro/GNOME ohne Probleme verwende, sah ich auch diesem grossen Update ohne Bedenken entgegen. Ich betreibe drei Maschinen mit dieser Distribution: eine Oracle-VM im Büro sowie einen PC und einen Laptop zu Hause. Letztere sind meine Hauptrechner.
Zuerst wurde das Update zu 22.1.0 auf meiner virtuellen Maschine (Oracle Virtual Box, Host: Windows, X.org) gemeldet. Nach dem Update bootete die VM bis zum Splash-Screen und verweigerte den Start von GDM (Login). Ich konnte ins Terminal booten, mich dort anmelden und mittels startx den Desktop starten. Die Ursache des Problems habe ich gestern nicht mehr herausgefunden.
Doch es kam noch viel schlimmer.
Zu Hause angekommen, meldeten auch meine beiden Hauptrechner die Ankunft des Manjaro-April-Updates. Die Probleme in der virtuellen Maschine schob ich auf Larry Ellison und X.org. Da hatte ich wesentlich grösseres Vertrauen in Wayland auf echtem Eisen.
Ich scheue kein Risiko und bin kein Hasenfuss. Deshalb habe ich das Update auf Rechner 1 (HP-Desktop) mit geballter Faust und voller Zuversicht gestartet. Zuerst lief alles wie gewohnt ab: die 1.4 GB wurden zügig heruntergeladen. Doch dann kam das lange Warten. Normalerweise wird die Installation der Pakete kurz nach dem Download der Pakete gestartet; dann kommen die post-installation-hooks und die Flatpaks. Nachdem ich fünf Minuten auf den Beginn der Installation gewartet hatte, wurde ich ungeduldig. Es schien mir, als wäre Pamac eingefroren, da auch htop keine nennenswerten Aktivitäten zeigte.
Dann nahm die Katastrophe ihren Lauf. In Pamac konnte ich die laufenden Aktionen nicht abbrechen (keine Reaktion auf das Abbrechen oder Schliessen der Anwendung). Ein zweiter Start von Pamac bezeugte, dass bereits eine Instanz des Paketmanagers lief. An dieser Stelle hätte ich Stärke und Geduld zeigen sollen.
Stattdessen habe ich die kill -9 Keule ausgepackt und das System gebootet. Danach durfte ich in die Abgründe der Hölle schauen. Manjaro meldete, dass der Kernel (6.1) nicht geladen werden konnte. Kurze Zeit später kam im Terminal die Nachricht, dass auch der zweite Kernel (5.15) nicht laden kann. Zur Auswahl blieben mir das BIOS und das GRUB-CLI. Vielleicht hätte ich mit eurer Hilfe das System retten können; doch schon hatte ich Etcher gestartet und eine frische Manjaro-ISO auf den USB-Stick gebrannt.
Selbstverständlich habe ich drei Minuten darüber nachgedacht, ob ich meine Rolling-Manjaro-Ambitionen aufgeben und wieder in den sicheren Hafen der LTS-Distros einschiffen soll. Als dann Lioh schrieb: "Frickel Distro. Nimm halt Ubuntu wie immer", habe ich tatsächlich kurz über alternative Distributionen nachgedacht. Fedora 38, Fedora Silverblue, VanillaOS, Mint, Arch? Alles Unsinn; ich habe genug Distros ausprobiert, um zu wissen, dass Manjaro die Beste für mich ist.
Gut 5 Minuten später war die alte Installation Vergangenheit und die Version 22.1.0 "Talos" installiert. Ich freue mich immer über die schnelle Installation einer GNU/Linux-Distribution, weiss aber genau, dass es danach drei Tage dauert, bis die Anwendungen und Konfigurationen wieder den eigenen Ansprüchen genügen. Datenverlust ist bei mir kein Thema, zumal das letzte Backup vor 3 Tagen erstellt wurde.
Jetzt steht Rechner 2 (Tuxedo-Laptop) vor meiner Nase und fragt nach dem Update. Das ist der Moment, in dem die Update-Angst einsetzt. Zurzeit bin ich noch unentschlossen, was ich machen soll. Ihr werdet die Antwort in eurem GNU/Linix.ch-Osterkörbchen finden.
Nachtrag
Mittlerweile kann ich bestätigen, dass das Talos-Update (22.1.0) sauber durchläuft. Man darf natürlich nicht die Dummheit begehen, den Update-Prozess in der Mitte abzubrechen, weil man zu ungeduldig ist. Zwischen dem Download der Pakete und dem Beginn der Installation können einige Minuten vergehen.
Allerdings kann es den Effekt geben, dass man nach dem Booten im Login des Terminals (TTY1) landet. Das passiert, weil der GNOME Display Manager (GDM) während des Updates als Orphan (verwaistes Paket) markiert wird. Falls man (so wie ich) diese Waise vor dem Reboot entfernt, hat man ein Problem. Die Frage ist, warum so ein wesentliches Paket überhaupt ge-orphant wird. GDM ist für den grafischen Login-Dialog und das Handling der Display-Server zuständig. Ohne GDM stoppt der Boot-Prozess, weil kein grafisches Login und kein Start eines Display Servers (X, Wayland) möglich ist.
Falls man sich der Ursache bewusst ist, lässt sich das Problem ganz schnell aus der Welt schaffen. Dazu installiert man GDM neu und startet den Display-Manager. Das geht so:
sudo pacman -S gdm
systemctl restart gdmDanach startet die Desktop-Umgebung und auch nach einem Reboot ist alles wieder in trockenen Tüchern.
Hallo Ralf, warum hast du keine Sicherungen deiner kompletten Partion (zB per dd erstellt)? Dann hättest du die gesamte Partition restoren können. Wenn du eine LVM Installation deines Systems hast (mit einzelnen LV's) wird das Backup noch kleiner und handlicher, da du nur die System LV's sichern musst um Restore zu bewerkstelligen. Ich habe zB diese LVM Config:
LVroot / --> 20 GB
LVvar /var --> 20 GB
LVhome /home --> nach belieben LVswap Swap --> 4 GB
In einem Disasterfall bräuchte ich von einem Livesystem nur LVroot und LVvar zurückzusichern. Bei mir ist das vielfach erprobt und funktioniert ohne Probleme.
Grüße Bluelupo
Ja, das ist ein Problem bei dem die Distros einfach noch besser werden müssen. Selbst Mint ist mir beim Upgrade schon oft genug um die Ohren geflogen... wenigstens kriegen sie die .x Upgrades mittlerweile zuverlässig hin... WTF
Bei NixOS sind solche Probleme nicht zu erwarten, weil Updates nur veröffentlicht werden, nachdem sie diverse automatische Tests erfolgreich durchlaufen haben. Z.B. dass der Login und GNOME läuft.
Und selbst wenn man eine obskure Konfiguration hat und z.B. X-Server nicht mehr startet, ist ein Rollback nur einen Befehl. Dann kann man den Fehler melden und warten, bis er behoben ist oder selbst lernen das Problem zu beheben, für alle Nutzer!
In meiner über 20jährigen "Linux-Desktop-Karriere" war Manjaro immer die Problem-Distro Nr. 1. Selbst wenn ich Ambitionen zu einer RR-Distro hätte, würde ich nicht Manjaro nutzen. Tumbleweed gibt einem da mehr Rückfallnetze.
Vielleicht hann da helfen:
https://forum.manjaro.org/t/manjaro-hanging-after-latest-update/137964
Nehmt Tumbleweed, das macht keine Probleme :-)
Stimmt natürlich nicht, was ich oben geschrieben habe (verspäteter Aprilscherz). Zu oft habe ich nach einer Update-Panne versucht das System wieder zurecht zu biegen. Es vergehen Stunden und die gute Laune ist futsch. Glaubt man dann endlich Erfolg gehabt zu haben, kommt die Ernüchterung in den nächsten Stunden/Tagen, weil garantiert doch nicht alle Update-Fehler behoben wurden.
Deshalb installiere ich einfach alles neu, das geht schnell und gleichzeitig trenne ich mich bei der Neuinstallation auch von vielen Paket-Leichen. Schaffe mir also ein neues aufgeräumtes System. Meine persönlichen Daten liegen als tägliches Backup auf einer sicheren Platte. Das nervige Problem ist die darauf folgende Anpassung des Systems an die eigenen Bedürfnisse. Ein bis zwei Tage gehen dabei immer drauf.
Mit freundlichem Gruß Karl
Schon mal Gentoo probiert bzgl. Rolling Release? Wenn man das Basis System nicht als bleeding edge installiert und anschließend im Portage nur ausgewählte Applikationen auf unstable stellt, zB KDE, halten sich auch die Updates in Grenzen.
Ist für mich persönlich eine schöne Balance aus einem stabilen Grundsystem und ausgewählter bleeding edge Software.
Mit dem oddlama-gentoo-installer hat man auch eine komfortable Möglichkeit Gentoo zu installieren, inkl. root on ZFS und damit Snapshots für Backups.
Ich habe auch eine weile Manjaro getestet. Die Updates waren fehlerbehafteter als bei Arch. Warum auch immer.
Jetzt wieder Gentoo, läuft ewig bombenstabil.
yay > pamac
Unter Debian Testing, mit Gnome unter Wayland, bin ich im letzten Jahr über die gleiche Schwelle gestolpert,- nur startx half als Workaround. Erst nach einem Wechsel von GDB zu lightDM war ein Booten in die GUI wieder möglich. Ich habe danach Gnome gelöscht und XFCE eingerichtet.
Du solltest wirklich NixOS anschauen! Es funktioniert grundlegend anders als alle anderen.
Du kannst z.B. sehr einfach ein stable Release nutzen und einzelne Pakete aus dem unstable Channel. Viele benutzen aber auch direkt Unstable und sagen, es ist sehr stabil. Falls doch etwas nicht funktionieren sollte kannst du mit einem Befehl ein Rollback machen. Selbst wenn es nicht bootet im Bootloader vorherige Konfiguration auswählen. Du hast also zu jeder Zeit ein funktionierendes System und kannst nach belieben Experimentieren!
Es gibt übringens mehr Pakete für NixOS als im AUR und sie sind auch aktueller. Falls das dir wichtig ist. Im Gegensatz zum AUR werden sie von einer Community gepflegt und bei Änderungen gibt es Review und Test. Es gibt aber auch das NUR mit noch mehr Paketen.
Manche sagen NixOS ist stabiler als Debian und aktueller als Arch.
Man muss die deklarative Konfiguration lernen, aber wer Debian oder Arch benutzt sollte dazu in der Lage sein. Wer schonmal Configuration Management benutzt hat ist mit dem Konzept vertraut.
Komisch, meine Arch-Installation ist von 2010 und läuft heute noch...
Mein Debian Rechner ist im 10. Jahr und schnürt ...zumindest vom System her. Die HW wird mittlerweile träge und daher wird es über kurz oder lang etwas neues geben. Ansonsten kann ich nicht klagen. Hängt halt immer davon ab, was du mit do einem System alles machst. Die experimentellen Phasen und daraus resultierenden Lernkurven habe ich hinter mir.
"Ohne GDM stoppt der Boot-Prozess". Das man in der Console landet ist nachvollziehbar, aber wird der boot Prozess wirklich unterbrochen wenn ein display manager nicht starten kann? Ist das ein "Feature"?
Lest den Nachtrag zum Artikel. Es war alles meine Schuld und hatte eigentlich nichts mit Manjaro zu tun.
„Ich […] weiss aber genau, dass es danach drei Tage dauert, bis die Anwendungen und Konfigurationen wieder den eigenen Ansprüchen genügen.“
Ich setze derzeit Ubuntu LTS ein und mache immer eine Neuinstallation, (frühestens) wenn das erste Point Release da ist.
Da ich auch die Rechner meiner Familie betreue, mit teilweise ähnlichen, teilweise stark unterschiedlichen Bedürfnissen, habe ich mir ein Bash-Skript gebastelt, um die Neueinrichtung zu erleichtern. Es gibt eine Liste mit Paketen, die auf allen Systemen installiert werden sollen und dann mittels case und if wird diese je nach hostname erweitert.
Wenn ich ein neues Paket installiere, füge ich den Paketnamen in dem entsprechenden Abschnitt ein.
Sollte ich ein Paket außerhalb der Paketquellen installieren, wird dies ebenso mindestens dokumentiert und soweit möglich auch im Skript automatisiert.
Nach der Installation vergleiche ich ich dann den Inhalt von ausgewählten Dateien und Ordnern unterhalb /etc/ mit dem Backup.
Auf diese Art und Weise habe ich nach der Neu-Installation sehr schnell wieder ein System so wie ich es brauche.
Meine Garuda (Arch) hatte auch ein kleines Problem, was mit der Anmeldung von LightDM zu tun hatte. Nach drei Tagen ging es wieder normal. Wegen Kernel, ich nutze meist mehrere, um bei Problemen auf einen anderen beim Booten zu wechseln. Ideal finde ich auch auf GDM oder LightDM zu verzichten. Mit SDDM hatte ich noch nie Probleme. Ich muss allerdings auch sagen, dass ich kein Experte bei Linux bin und oft mehrere Distros teste, um Erfahrungen zu sammeln, mit KVM z.b.
Ich hatte kürzlich ähnliche Erfahrungen mit einem Manjaro-Upgrade.
Ich rannte wie der Nutzer hier in ein Problem mit texlive: https://forum.manjaro.org/t/failed-to-install-updates-texlive-basic/143785
Nachdem ich pacman -Syu angestoßen habe, schien das Update dann doch zu laufen. Ich entschied mich, erstmal den Raum zu verlassen und sperrte (aus Gewohnheit) den Bildschirm. Das war ein großer Fehler!
Als ich nach einigen Minuten zurückkam, konnte ich mich nicht mehr an Gnome anmelden, weil GDM komische Artefakte zeigte und auch das Passwort nicht mehr annahm. Kurzer Einschub Nr. 1: Weshalb wird das Szenario eines gesperrten Bildschirms nicht berücksichtigt bei, das ist doch jetzt nicht so weit hergeholt und eigentlich ziemlich banal? Wenn die Distribution ein unfallfreies Upgrade mit gesperrtem Bildschirm nicht garantieren kann, dann müsste das ausgeschlossen werden bzw. der Benutzer mindestens davor gewarnt werden!
Somit blieb mir nichts anderes übrig, das System neu zu starten. Danach stoppte der Boot-Prozess hartnäckig in der TTY, zumindest war kurz zuvor noch der Manjaro-Schriftzug zu erkennen.
An der TTY konnte ich mich aber nicht anmelden, weil diese keine Sonderzeichen in Passwörtern erlaubt! WTF? Kurzer Einschub Nr. 2: Weshalb ist das im 21. Jahrhundert noch nicht längst gelöst? Man dürfte bei der Installation garnicht erst die Möglichkeit bekommen, sich ein Passwort zu vergeben, das die Anforderungen der TTY nicht unterstützt. Das ist wirklich eine üble Falle.
Im Nachgang habe ich dann noch einiges Versucht, da ich das System nicht gleich aufgeben wollte. Unter anderem habe ich über ein Manjaro-Live-Image und chroot versucht mittels pacman -Syu den Upgrad-Process zu wiederholen – das Upgrade lief ohne Probleme durch, jedoch hatte es für mein Problem keinen Erfolg gebracht. Nach Auffälligkeiten im Syslog für Boot-Vorgang bei plymouth habe ich auch dieses neu installiert. Das hatte alles nichts geholfen. Ich hatte die Hoffnung bereits fast aufgegeben, als mir nach etlichen Recherchen schwante, dass entweder beim Grafiktreiber oder bei GDM während des ursprünglichen Updates etwas schiefgelaufen sein könnte. Somit habe ich beide per chroot neu installiert und – oh Wunder – mein Manjaro bootete wieder in die grafische Oberfläche.
Das alles hat mich wieder etliche Stunden wertvolle Lebenszeit gekostet, sodass ich mittlerweile an meiner Entscheidung für Manjaro zweifel. Auf einem anderen Laptop teste ich jetzt mal openSuse Tumbleweed …