Habe ich eine "Killer"-Konfiguration?

  • Liebe alle, ich habe mittlerweile drei(!) defekte(?) Rpi4 zu Hause liegen, bin bald am Verzweifeln und erhoffe mir einen Geistesblitz.


    Folgender Hintergrund: ich habe das offizielle Homebridge-Image auf eine Samsung EVO 64Gb SD-Karte gebrannt und mit einem Rpi4b - 8Gb betrieben.

    Stromversorgung über das offizielle 3A-Netzteil, passive Kühlung über ein "Metallgehäuse mit Kühlrippen" (mit CPU-Temperaturen um 54°C).

    Ein zusätzlicher Deconz-Server wurde über hb-config installiert; an einem USB2-Port hing ein ConBee-II Stick mit 1m USB-Verlängerung.


    Dieses Setup lief über mehrere Wochen anstandslos 24/7 .. bis es plötzlich nicht mehr lief: Eines Morgens war der Server nicht mehr erreichbar, auch nicht per SSH. Neustart brachte nichts, am Rpi4 leuchtete dauerhaft die rote und grüne LED (die Grüne flackerte nur 1x kurz, wenn man das Netzteil anschloss). Auch Boot-Versuche mit komplett neuen SD-Karten, bzw USB-Sticks und jungfräulichen Images schlugen fehl. Ich habe versucht, ein neues EEprom zu brennen, Ergebnis: ein Blinkcode der grünen LED 8x kurz... aber sonst kein Lebenszeichen. ;(


    Also habe ich die Homebridge-SD-Karte in einen neuen Rpi4b-4Gb gesteckt.. und das System bootete sofort ohne Probleme! Schön und gut... also alles "umgemodelt". Da ich eine mögliche Überhitzung ausschließen wollte, habe ich den Raspi in ein ein aktiv gekühltes Gehäuse eingebaut (Temp. ~45°C). Dieses Mal funktionierte der Server knapp eine Woche, dann war er über Nacht erneut abgestürzt... Ein Hardreset brachte ihn aber zunächst wieder zum Laufen... bis zum nächsten Tag, dann war der zweite RPi4 ebenfalls "klinisch tot".

    Da ich einen Großteil meiner Heimautomation über den Homebridge-Server laufen hatte, blieb mir nichts anderes übrig, als erneut einen fabrikneuen Raspi einzubauen, der mit der alten SD-Karte erneut sofort bootete... aber nur vier Tage durchhielt, bis er die gleichen Symptome, wie oben beschrieben bot. <X


    Zwischenzeitlich hatte ich in meiner Verzweiflung folgendes komplett neues Setup zusammengestellt und betreibe dieses seit 48 Stunden: nagelneue Homebridge-Installation auf mSATA mit USB3-Adapter. Rpi4b-4GB. Stromversorgung über 4A-Netzteil->Geekworm X735-Platine->GPIO. Ich habe Angst, dass mir der vierte Raspi ebenfalls abraucht.


    Was mache ich falsch?!?!?!?!

    Kann ich die drei anderen Raspis eventuell wiederbeleben?


    Danke im Voraus!

  • Hallo docNeptun

    Erst mal Willkommen hier im Forum!

    Um die drei "toten" Pi zu testen, installiere eine normales Raspberry auf einer SD und schau, was passiert.

  • Warum hast Du vor Deiner Verzweiflung nicht einfach in die Logfiles geschaut ?


    Der 8 Mb Pi4 braucht, um die 8 Mb richtig auszunützen, 64 Bit Software. Da der 64 Bit ARM-Kernel mit der Hardwarebeschleunigung noch nicht zurecht kommt, gibt es keine offizielle "stable" Version. Und ein 64 Bit Kernel braucht auch 64 Bit Programme, sonst ist der 64 Bit Kernelvorteil wirkungslos. In der 32-Bit Version werden nur 4 MB direkt vom Kernel adressiert. Die weiteren 4 Mb werden für Files verwendet.


    Wenn ein Pi 24/7 durchgehennd betrieben wird, muss der Admin periodisch (zumindest 1x/Woche) den Gesundheitszustand des Systems überprüfen. Geschieht das nicht, kann das Filesystem korrupt werden, oder der Hauptspeicher durch Zombies überlaufen. Deine Schilderung deutet auf letzteres hin.


    Jeder Pi4 hat ein anderes EEPROM Datum/Version im Auslieferungszustand. Wenn Du dieselbe SD Karte in verschiedene Pi4 steckst, solltest Du alle Pis (EEPROMs) auf denselben Versionsstand bringen und das automatische EEPROM Update deaktivieren.

    https://www.raspberrypi.org/do…are/raspberrypi/README.md

    --> SPI Boot

    --> Boot Diagnostics Display

    --> Boot modes (P4 Bootflow

    Eine neuere Version im Pi4-EEPOM kann von einer älteren Version auf der SD nicht "geupdatet" werden.



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Aber weder das nicht verwenden einer 64Bit Version, noch die Tatsache das man nicht jede Tag reinschaut sollten den Pi killen, oder? Auch das EEPRom update sollte den Pi nicht schrotten solange es fehlerfrei durchläuft.


    Ist vielleicht das Netzteil defekt? Überspannung?

  • Hallo allerseits, erstmal danke für die Begrüßung und das Feedback, das mich schon fast überfordert.

    Ich muss dazu sagen, dass ich zwar technisch versiert und sehr gut schrittweise Anleitungen befolgen kann, sonst aber ein Linux/Raspberry-Noob bin...


    zu den Fragen:

    Warum hast Du vor Deiner Verzweiflung nicht einfach in die Logfiles geschaut ?


    Wenn ein Pi 24/7 durchgehennd betrieben wird, muss der Admin periodisch (zumindest 1x/Woche) den Gesundheitszustand des Systems überprüfen. Geschieht das nicht, kann das Filesystem korrupt werden, oder der Hauptspeicher durch Zombies überlaufen. Deine Schilderung deutet auf letzteres hin.


    Jeder Pi4 hat ein anderes EEPROM Datum/Version im Auslieferungszustand. Wenn Du dieselbe SD Karte in verschiedene Pi4 steckst, solltest Du alle Pis (EEPROMs) auf denselben Versionsstand bringen und das automatische EEPROM Update deaktivieren.

    - hast Du einen kleinen Tipp: zum Auslesen der SD-Karte habe ich nur ein Windows-System.. da kriege ich, glaube ich, nur einen Teil der Partition(en) zu Gesicht... wo finde ich die Logfiles?!

    - Ich habe die Speicherauslastung regelmäßig über die Homebridge-UI und Apps wie PiHelper beobachtet.. reicht das? Darüber hinaus habe ich alleine zwecks Update der Plugins und der Server-Software (un)regelmäßige Neustarts des Servers vorgenommen.


    - Das mit dem EEPROM verstehe ich nicht. Ich dachte, es handelt sich nur um ein "minimal"-System, das den Bootvorgang regelt... und dass man für ein EEPROM Update ein spezielles "Service-Image" über den Pi-Imager vorbereiten muss. Ich war naiver Weise davon ausgegangen, dass "immer die aktuellste Version" schon funktionieren wird.. zumal ich nicht weiß, wie ich im Nachhinein die EEPROM-Version ermitteln kann...
    Inwiefern wird denn ein EEPROM Update vorgenommen, wenn ich eine bestehende Installation einfach nur hochfahre?


    Um die drei "toten" Pi zu testen, installiere eine normales Raspberry auf einer SD und schau, was passiert.

    Es passiert leider gar nichts. Ich habe das offizielle Raspberry PI OS über den Pi-Imager auf eine nagelneue SD-Karte und einen USB-Stick gebrannt... nichts.

    Oder fast nichts: nach Anschluss des Netzteils flackert die grüne LED 1x auf, danach brennen rot+grün dauerhaft. Keine Monitor-Anzeige, kein Zugang per SSH... nichts.

  • Ist vielleicht das Netzteil defekt? Überspannung?

    Das ist meine aktuelle Vermutung. Daher habe ich für meinen Neuversuch ein neues Netzteil und eine Zusatzplatine zur Spannungsversorgung über GPIO installiert. Ich glaube allerdings, dass ich zwischen Versuch 1 und Versuch 2 auch das Netzteil sicherheitshalber bereits getauscht hatte...


    Eine weitere Sorge betrifft die USB-Verlängerung.. kann der erhöhte Widerstand die USB-Stromversorgung überfordern und dadurch den Raspi "grillen"?

    Es wird ja empfohlen, stromhungrige USB-Geräte über einen aktiven Hub mit Strom zu versorgen.. aber ich dachte, schlimmstenfalls funktioniert einfach das USB-Gerät nicht richtig.

  • - Das mit dem EEPROM verstehe ich nicht. Ich dachte, es handelt sich nur um ein "minimal"-System, das den Bootvorgang regelt... und dass man für ein EEPROM Update ein spezielles "Service-Image" über den Pi-Imager vorbereiten muss. Ich war naiver Weise davon ausgegangen, dass "immer die aktuellste Version" schon funktionieren wird.. zumal ich nicht weiß, wie ich im Nachhinein die EEPROM-Version ermitteln kann...
    Inwiefern wird denn ein EEPROM Update vorgenommen, wenn ich eine bestehende Installation einfach nur hochfahre?

    Kannst Du mit dem "Homebridge-Image" das PI4-EEPROM updaten?

    ich frage deshalb, weil ich es auf meinem PI4/8GB mit OpenBSD, das nicht kann. Ich muss dafür, den PI4/8GB mit dem RasPI-OS booten und kann dann updaten.


    EDIT:


    BTW: Zum booten des OpenBSD mit dem PI4/8GB, wird das PI4-EEPROM (größer/gleich einer bestimmten Version) aber benötigt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Edited once, last by rpi444 ().

  • Im Homebridge Image steckt ein Raspbian/Pi-OS light drinnen.

    OK, dann könnte der TE die Ausgaben von:

    Code
    sudo rpi-eeprom-update
    sudo vcgencmd bootloader_config
    cat /etc/default/rpi-eeprom-update*

    anschauen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • OK, dann könnte der TE die Ausgaben von:

    Code
    sudo rpi-eeprom-update
    sudo vcgencmd bootloader_config
    cat /etc/default/rpi-eeprom-update*

    anschauen.

    Könnte ich, wenn die infrage stehenden Raspis noch einen Mucks von sich geben würden :(

  • Könnte ich, wenn die infrage stehenden Raspis ...

    ja, aber da Du Angst hast, dass der 4. Raspi auch abraucht, könntest Du auch dort schon mal nachschauen. ;)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • ja, aber da Du Angst hast, dass der 4. Raspi auch abraucht, könntest Du auch dort schon mal nachschauen. ;)

    Haha. Touché...
    Ich habe nur leider immer noch nicht so recht verstanden, warum genau mich die EEPROM-Version interessieren sollte, bzw. wie ich damit einen eventuell kaputt gegangen sein werdenden Raspi wiederbeleben kann.

  • Dann folge den Links von #4


    Servus !

    Schon gelesen und trotzdem leider nicht verstanden.

    Der Raspberry-Dokumentation entnehme ich, dass das EEPROM die bootcode.bin enthält, welche zum Hochfahren benötigt wird. Soweit so gut. Wenn das EEPROM von einer älteren OS-Version nicht automatisch aktualisiert werden kann, aber erfolgreich gebootet hat, kann ich doch per sudo apt-get update / upgrade auch auf die aktuelle stable EEPROM-Version wechseln, oder nicht? Da alle verwendeten Images ohnehin aktuell sind, stellt sich m.E. die Frage gar nicht... Es könnte natürlich sein, dass mein EEPROM "zerschossen" ist. Für diese Eventualität habe ich versucht, eine neues EEPROM aufzuspielen (heruntergeladen und auf SD geschrieben mit dem offiziellen Imager), was aber nicht funktioniert hat - Error-Blinkcode 8x kurz.


    Zu den Boot-Diagnostics: der Bildschirm bleibt bei mir schwarz - es wird bei den defekten Raspis gar nichts angezeigt.


    Übrigens, das hatte ich vergessen, zu erwähnen: auch ohne eingelegte SD-Karte leuchten beide LEDs kontinuierlich.

  • Da alle verwendeten Images ohnehin aktuell sind, stellt sich m.E. die Frage gar nicht...

    Du meinst das Homebridge-Image? Welche rpi-eeprom-Version ist in dessen Repo?

    Code
    apt-cache policy rpi-eeprom
    cat /etc/default/rpi-eeprom-update*

    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Du meinst das Homebridge-Image? Welche rpi-eeprom-Version ist in dessen Repo?

    Code
    apt-cache policy rpi-eeprom
    cat /etc/default/rpi-eeprom-update*

    ?

    Kann ich gucken, wenn ich zu Hause bin... ich hatte aber nach dem ersten Boot ein vollständiges Update gemacht...

  • ... ich hatte aber nach dem ersten Boot ein vollständiges Update gemacht...

    Mit welchem Image hast Du bei deinem 4. Raspi, den ersten Boot bzw. das Update gemacht?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Hast Du auch vergessen zu erwähnen, dass Du mit der Clock-Frequenz herumgespielt hast ?

    Das würde das 8x kurz Blinken (grün) erklären.

    Das grüne Flackern deutet darauf hin, dass Datentransfer zur SD, oder von der SD stattfindet. Flackert die grüne LED nur einmal kurz, hat nur der Pi versucht eine Anfrage zu erstellen, ohne eine Antwort von der SD zu erhalten. Das kann durch einen Kontaktfehler im Kartenslot, oder eine kalte Lötstelle am Cardreader verursacht werden.


    Eine EEPROM Version vor dem 16.4.2020 zeigt kein Diagnosedisplay an. Danach auch nur, wenn DISABLE_HDMI nicht aktiviert ist.


    Welche EEPROM Version Du versucht hast zu ibstallieren, weiss ich nicht. Auch ob Dein Installationsversuch gelungen ist, bleibt offen.


    Vielleicht gibst Du die drei vermeintlich defekten Pi-4 jemanden, der die Links von #4 versteht.



    Servus !

    RTFM = Read The Factory Manual, oder so