RevPi Connect bootet nach SW-Update nicht mehr

ostermann · Post by **ostermann** » 19 Dec 2021, 22:00

Ich habe heute das erste mal die grafische Oberfläche auf meinem RevPi Connect gestartet, um erste Gehversuche mit Python zu machen. Beim Start wurden die länderspezifischen Einstellungen abgefragt. Danach hat die GUI versucht, ein Update zu installieren, was nach einiger Wartezeit fehlgeschlagen ist. Nach dem HInweis, dass das System neu gestartet werden muss, damit die Änderungen wirksam werden, habe ich den Neustart ausgeführt. Der RevPi ist dann aber nicht mehr hochgekommen. Er ist weder per Putty noch direkt per Monitor und Tastatur bedienbar. WD unr REL leuchten grün, A3 rot. Am angeschlossenen AIO-Modul leuchtet nur die Power-LED (rot).

Installiert war auf dem System bisher nur revpimodio, auerdem hatte ich wie empfohlen als ersten Schritt nach dem erstellen eines Images per "sudo apt-get upgrade -y" ein Update ausgeführt.

Gibt es irgendwas, was ich zur Fehleranalyse tun kann, bevor ich morgen versuche, über den USB Host-Port ein lauffähiges Image einzuspielen? Kann man z.B. bei Verbindung über die Host-Schnittstelle auf Logiles zugreifen?

Mit freundlichen Grüßen
Thorsten Ostermann

nicolaiB · Post by **nicolaiB** » 20 Dec 2021, 12:45

Hallo Thorsten,

vermutlich enthielt das fehlgeschlagene Update ein neues Kernelpaket. Durch den Abbruch ist die Installation jedoch nur unvollständig abgeschlossenen, sodass es nun scheinbar Probleme beim booten gibt. Siehe hierzu auch viewtopic.php?f=3&t=3215&p=11549#p11549

Die Logfiles solltest du über USB auslesen können (rpiboot nicht vergessen), sofern dein angeschlossener PC das ext4 Dateisystem lesen kann (z.B. ein Linux).

Gruß Nicolai

ostermann · Post by **ostermann** » 20 Dec 2021, 13:09

Ein Linux-System zum Auslesen des Dateisystems habe ich so ohne weiteres leider nicht im Zugriff. Ich könnte ein Linux von einer Recovery-CD booten, aber da ich in Sachen Linux Newbie bin, möchte ich da im Moment keine Zeit investieren. Ich habe noch einen RevPi in Reserve, kann die defekte Einheit also auch erstmal beiseite stellen.

Das sich das System bei einem Updateversuch komplett selbst zerlegen kann halte ich für ein solches System für sehr problematisch. Wenn das einem unerfahrenen Servicetechniker vor Ort beim Kunden passiert kann das einen längeren Anlagenstillstand auslösen.

Da ich offenbar nicht der erste bin der auf solche Probleme läuft gibt es hier offenbar Optimierungsbedarf?! Man könnte z.B. ein abgespecktes Recovery-System integrieren, das gebootet wird, wenn das Hauptsystem nicht mehr hochkommt.

Ich würde schon gerne besser verstehen, was hier passiert ist bzw. warum das schief gegangen ist. Hat die GUI einen falschen Kernel geladen? Oder wurde versucht, ein unvollständig heruntergeladenes Paket zu installieren? Und was kann ich als Anwender tun, um solche Probleme zu vermeiden?

Mit freundlichen Grüßen
Thorsten Ostermann

nicolaiB · Post by **nicolaiB** » 20 Dec 2021, 13:31

Hallo Thorsten,

ostermann wrote: ↑20 Dec 2021, 13:09 Ein Linux-System zum Auslesen des Dateisystems habe ich so ohne weiteres leider nicht im Zugriff. Ich könnte ein Linux von einer Recovery-CD booten, aber da ich in Sachen Linux Newbie bin, möchte ich da im Moment keine Zeit investieren. Ich habe noch einen RevPi in Reserve, kann die defekte Einheit also auch erstmal beiseite stellen.

Das ganze sollte auch mit einer Recovery-CD funktionieren. Alternativ findest du im folgenden Artikel Vorschläge wie es auch unter Windows funktionieren kann: https://www.heise.de/tipps-tricks/Ext4- ... 86952.html

ostermann wrote: ↑20 Dec 2021, 13:09 Das sich das System bei einem Updateversuch komplett selbst zerlegen kann halte ich für ein solches System für sehr problematisch. Wenn das einem unerfahrenen Servicetechniker vor Ort beim Kunden passiert kann das einen längeren Anlagenstillstand auslösen. Da ich offenbar nicht der erste bin der auf solche Probleme läuft gibt es hier offenbar Optimierungsbedarf?! Man könnte z.B. ein abgespecktes Recovery-System integrieren, das gebootet wird, wenn das Hauptsystem nicht mehr hochkommt.

Das Paketmanagement ist Teil der zugrundeliegenden Basis-Distribution Debian bzw. Raspberry Pi OS. Ich empfehle Updates nach Möglichkeit per SSH oder grafischem Terminal mit apt-get upgrade einzuspielen, da dort direkt ersichtlich ist, was schiefgelaufen ist und ggf. Fehler vor dem Neustart behoben werden können. Das abgespeckte Recovery-System ist etwas, was wir auf unserer Roadmap haben.

ostermann wrote: ↑20 Dec 2021, 13:09 Ich würde schon gerne besser verstehen, was hier passiert ist bzw. warum das schief gegangen ist. Hat die GUI einen falschen Kernel geladen? Oder wurde versucht, ein unvollständig heruntergeladenes Paket zu installieren? Und was kann ich als Anwender tun, um solche Probleme zu vermeiden?

Welches Paket ursächlich für das fehlgeschlagene Update ist, lässt sich ohne Logfiles leider nicht sagen. Ein Problem scheint in seltenen Fällen im Zusammenhang mit dem logirts Paket aufzutreten, sofern der grafische Ersteinrichtungsassistent verwendet wird. Wir analysieren das derzeit. Dem Anwender kann ich wie gesagt empfehlen die Updates wie oben beschrieben einzuspielen. Sollte es zu Fehlern im Rahmen der grafischen Ersteinrichtung kommen bitte nicht direkt neu starten, sondern versuchen das Update nochmal per Kommandozeile anzustoßen und ggf. so nachzubessern.

Gruß Nicolai

ostermann · Post by **ostermann** » 20 Dec 2021, 15:42

Ich hatte vor wenigen Tagen erste Updates per apt-get via SSH eingespielt. Ich habe das Update gestern nicht proaktiv in der GUI angestoßen, sondern das System hat mir suggeriert, es müsste upgedated werden. Mir war nicht klar, dass diese Update nicht nur die GUI betrifft. Ich werde Meldungen zu nötigen Updates in der GUI also zukünftig abbrechen/verneinen.

Mit freundlichen Grüßen
Thorsten Ostermann

ostermann · Post by **ostermann** » 24 Dec 2021, 12:03

Hallo Nicolai,

ich habe jetzt die Logs aus /dev/sdb2//var/logs gesichert. Wichtig zu wissen ist, dass man auch für den Zugriff auf das Dateisystem des RevPi erst rpiboot.exe starten muss. Sonst kann Windows das Gerät nicht sehen. Unter Linux (Knoppix Boot-CD) habe ich es nicht hinbekommen, auf den RevPi zuzugreifen.

Welche der Dateien sind für eine Analyse wichtig? Gibt es noch in anderen Verzeichnissen Logs oder andere wichtige Infos? Ich würde sonst versuchen, das erstellte Image wieder einzuspielen, damit ich den RevPi wieder nutzen kann.

Mit freundlichen Grüßen
Thorsten Ostermann

nicolaiB · Post by **nicolaiB** » 24 Dec 2021, 13:55

Hallo Thorsten,

Ja für den Zugriff auf den internen eMMC Speicher muss man den RevPi mit rpiboot in den entsprechenden Modus versetzen. Andernfalls versucht die GPU zu booten.

Die Dateien unter /var/log sollten ausreichen. Insbesondere interessant sind die Dateien des Paket Managers unter /var/log/apt.

Ich wünsche dir entspannte Feiertage!

Gruß Nicolai

ostermann · Post by **ostermann** » 28 Dec 2021, 17:42

Danke für die Rückmeldung, selbst über die Feiertage. Ich habe die APT-Logs mal angehängt. Vielleicht kann von euren Entwicklern jemand etwas damit anfangen. Ich kenne mich mit Linux leider nicht gut genug aus.

Mit freundlichen Grüßen
Thorsten Ostermann

nicolaiB · Post by **nicolaiB** » 30 Dec 2021, 10:15

Hallo Thorsten,

danke für die Logs. Ich schau mir das mal an.

Gruß Nicolai

ostermann · Post by **ostermann** » 02 Jan 2022, 22:22

Ich konnte inzwischen das zuvor erstellte Image wieder einspielen und den RevPi damit wieder zum Leben erwecken. Ich habe dann nochmal via Shell Updates nachinstalliert. Das hat ohne Probleme geklappt.

Mit freundlichen Grüßen
Thorsten Ostermann