Pi startet nicht mehr - ACT (grün) blinkt 4x kurz

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,
    mein Pi startet nicht mehr.

    Installiert ist über noobs Raspbian auf dem pi model b.
    Es lief alles seit 4 Monaten perfekt, der Pi ist hauptsächlich für DLNA und als Webserver (Nginx) eingesetzt.
    Aufgrund der heartbleed Geschichte fuhr ich Updates und Upgrades durch und machte anschließend einen Neustart. Seit dem ist der Pi tot und ich konnte ihn nicht mehr per ssh erreichen.
    Das ganze wurde per Fernwartung durchgeführt, heute war ich wieder am Pi vor Ort und sah, dass beim Booten die grüne Act Leuchte 4 mal hintereinander blinkt.
    Dies bedeutet wohl, dass die start.elf Datei nicht geladen wird.

    Hat jemand eine Idee was ich machen kann? ist solch ein Fehler bekannt?
    Ist der Pi gebrickt oder nur die Karte? oder bekommt man alles einfach wieder zum laufen?
    Der Pi war nicht übertaktet.

    Grüße lichtbricht

  • Pi startet nicht mehr - ACT (grün) blinkt 4x kurz? Schau mal ob du hier fündig wirst!

  • Guckst du hier -> Green LED blinks in a specific pattern


    Meine Vermutung wäre das die SD oder das Dateisystem kaputt ist. SD's vertragen nämlich keine unendlich vielen Schreib-/Lese- Zugriffe und wenn auf der SD Medien-Dateien immer wieder geschrieben/gelesen wurden wird das vermutlich zum ToT geführt haben.

    BTW: Never change a running System.
    Wenn dein PI nicht übers Internet zugänglich ist brauchst du auch den Heartbleed Bug nicht beachten. Davon abgesehen das man dafür nur das openssl Paket hätte updaten müssen ;)

  • Hey,
    danke für die schnelle antwort.
    Die Karte ist lesbar, zumindest an nem anderen Computer.
    das Update ist wichtig, da mein Pi dauert am INternet als Webserver hing.
    Ich hab auch lediglich ein openssl update durchgeführt.
    Das Blinkmuster habe ich mir shcon angesehen. Deswegen vermute ich auch ein Fehler an der start.elf, allerdings hat ein Tausch bisher noch nichts gebracht....


  • Meine Vermutung wäre das die SD oder das Dateisystem kaputt ist. SD's vertragen nämlich keine unendlich vielen Schreib-/Lese- Zugriffe und wenn auf der SD Medien-Dateien immer wieder geschrieben/gelesen wurden wird das vermutlich zum ToT geführt haben.

    "Urban Legend"... :lol:
    Mir und anderen (siehe diverse Links, kann derzeit nicht finden, bin auf Arbeit) ist noch nie eine Karte untergekommen, die deswegen "kaputtgeschrieben " wurde..., meist sterben die Karten aus profaneren Gründen (Flüssigkeiten, Grobmotoriker, Tierkontakt, elektrische Fehlspannungen) :)

    Die c't hat ja nun auch schon diverse Tests mit SSD-LW und anderen Halbleiterspeichern gemacht - das Fazit war: Bei normaler Nutzung schafft es ein Anwender nicht, das Limit zu erreichen, das die Karten/Laufwerke haben, zumal dann nicht plötzlich nix mehr geht sondern erstmal "nur" die nutzbare Kapazität abnimmt...

    Wer von uns schreibt auf dem RPi das FS der SD-Karte mehrmals am Tag komplett voll?
    Pls. melden :D

    lichtbricht:
    Prüfe mal den Kontakt der Karte im Schacht des RP, ggf. lege ein auf die Kartengröße zugeschnittenes Blatt Papier (oder auch 2..5) unter die SD-Karte beim einschieben, um die Kontakte der Karte besser auf die Schleifer der Fassung zu pressen... *alter Indianertrick*

  • Hallo,
    danke für deinen Tipp.
    Habe ich ausprobiert - hat aber nichts gebracht.
    Der Pi wurde per ssh neu gestartet und dort trat der Fehler schon auf - ohne jede mechanische Berührung. Daher denke ich, dass es mir entweder ein paar Dateien zerschossen hat oder der Pi (warum auch immer) hinüber ist.
    Könnt ihr mir eine Auflistung aller Dateien schicken, die ihr in euerm Boot-Verzeichnis habt?

    Eine Frage die mich ansonsten brennend interessiert:
    Könnt ihr mal die SD KArte des Pis in ein Windows 7 Notebook Card-Reader stecken und mir sagen, was Windows erkennt?
    Mir ist ja bewusst, dass das Root Verzeichnis nicht anzeigbar ist, da es unter Linux formatiert ist. Aber seht ihr das Boot-Verzeichnis in Windows? Laut vielen Berichten im Internet ist das möglich. Ich bekomme hier aber nur ein "Recovery" Laufwerk des Pis (ca. 1,19 GB) groß auf dem die Dateien von nooobs sind, allerdings keine Boot-Dateien!

    Danke.


  • Könnt ihr mal die SD KArte des Pis in ein Windows 7 Notebook Card-Reader stecken und mir sagen, was Windows erkennt?
    Mir ist ja bewusst, dass das Root Verzeichnis nicht anzeigbar ist, da es unter Linux formatiert ist. Aber seht ihr das Boot-Verzeichnis in Windows?

    immer ! raspbmc und wheezy, habe aber nie noobs drauf !

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo,
    wie gesagt habe ich als letztes ein update durchgeführt.
    Das ist ein Auszug aus der Log Datei.
    Kann damit jemand was anfangen?

    Errors were encountered while processing:
    /var/cache/apt/archives/raspberrypi-bootloader_1.20140107-1_armhf.deb

    bzw. hier sind noch mehr Information.
    Ich glaub das Update hat den Boot loader zerschossen.
    Was kann ich nun tun?

    Preparing to replace raspberrypi-bootloader 1.20131219-1 (using .../raspberrypi-bootloader_1.20140107-1_armhf.deb) ...
    Adding 'diversion of /boot/bootcode.bin to /usr/share/rpikernelhack/bootcode.bin by rpikernelhack'
    Adding 'diversion of /boot/fixup.dat to /usr/share/rpikernelhack/fixup.dat by rpikernelhack'
    Adding 'diversion of /boot/fixup_cd.dat to /usr/share/rpikernelhack/fixup_cd.dat by rpikernelhack'
    Adding 'diversion of /boot/fixup_x.dat to /usr/share/rpikernelhack/fixup_x.dat by rpikernelhack'
    Adding 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack'
    Adding 'diversion of /boot/kernel_cutdown.img to /usr/share/rpikernelhack/kernel_cutdown.img by rpikernelhack'
    Adding 'diversion of /boot/kernel_emergency.img to /usr/share/rpikernelhack/kernel_emergency.img by rpikernelhack'
    Adding 'diversion of /boot/start.elf to /usr/share/rpikernelhack/start.elf by rpikernelhack'
    Adding 'diversion of /boot/start_cd.elf to /usr/share/rpikernelhack/start_cd.elf by rpikernelhack'
    Adding 'diversion of /boot/start_x.elf to /usr/share/rpikernelhack/start_x.elf by rpikernelhack'
    Unpacking replacement raspberrypi-bootloader ...
    dpkg: error processing /var/cache/apt/archives/raspberrypi-bootloader_1.20140107-1_armhf.deb (--unpack):
    corrupted filesystem tarfile - corrupted package archive
    dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
    Memory split is now set in /boot/config.txt.
    You may want to use raspi-config to set it
    Removing 'diversion of /boot/bootcode.bin to /usr/share/rpikernelhack/bootcode.bin by rpikernelhack'
    Removing 'diversion of /boot/fixup.dat to /usr/share/rpikernelhack/fixup.dat by rpikernelhack'
    Removing 'diversion of /boot/fixup_cd.dat to /usr/share/rpikernelhack/fixup_cd.dat by rpikernelhack'
    Removing 'diversion of /boot/fixup_x.dat to /usr/share/rpikernelhack/fixup_x.dat by rpikernelhack'
    Removing 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack'
    Removing 'diversion of /boot/kernel_cutdown.img to /usr/share/rpikernelhack/kernel_cutdown.img by rpikernelhack'
    Removing 'diversion of /boot/kernel_emergency.img to /usr/share/rpikernelhack/kernel_emergency.img by rpikernelhack'
    Removing 'diversion of /boot/start.elf to /usr/share/rpikernelhack/start.elf by rpikernelhack'
    Removing 'diversion of /boot/start_cd.elf to /usr/share/rpikernelhack/start_cd.elf by rpikernelhack'
    Removing 'diversion of /boot/start_x.elf to /usr/share/rpikernelhack/start_x.elf by rpikernelhack'
    Preparing to replace rpi-update 20130510 (using .../rpi-update_20140321_all.deb) ...
    Unpacking replacement rpi-update ...
    Preparing to replace ssh 1:6.0p1-4 (using .../ssh_1%3a6.0p1-4+deb7u1_all.deb) ...
    Unpacking replacement ssh ...
    Processing triggers for man-db ...
    Processing triggers for install-info ...
    Processing triggers for desktop-file-utils ...
    Processing triggers for menu ...
    Errors were encountered while processing:
    /var/cache/apt/archives/raspberrypi-bootloader_1.20140107-1_armhf.deb

    Einmal editiert, zuletzt von lichtbricht (22. April 2014 um 19:34)


  • Ich glaub das Update hat den Boot loader zerschossen.
    Was kann ich nun tun?

    am Besten installiere neu, das vollständige IMG ohne noobs .....

    musste ich auch machen, ein zerschossenes zu reparieren ist zwar möglich aber nur für vollständige Insider, ich wüsste nicht wo die Abhängigkeiten und Fehler lauern.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Habs nun hinbekommen.
    Wie im Log ersichtlich hat der Update Prozess die Boot Dateien geschrieben, dann aber aufgrund eines Fehlers wieder gelöscht.
    Ich hab sie bei github aktuelle Dateien gefunden und manuell auf die Boot Partition kopiert. Seither läuft der Pi wieder.
    Längerfristig komme ich jedoch wohl nicht um eine neue SD Karte umher, und vermutlich wäre eine Neuinstallation dann auch das Beste. Wobei es gerade so schön lief....

  • Unpacking replacement raspberrypi-bootloader ...
    dpkg: error processing /var/cache/apt/archives/raspberrypi-bootloader_1.20140107-1_armhf.deb (--unpack):
    corrupted filesystem tarfile - corrupted package archive
    dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

    Das wird er nicht ohne Grund geschrieben haben..

    Es gibt etliche Möglichkeiten die SD vor unnötiger Belastung zu schützen und somit eine längere Lebensdauer zu gewährleisten. Bemüh mal die Forumsuche nach ' varlog ', erster Treffer


    "Urban Legend"... :lol:
    Mir und anderen (siehe diverse Links, kann derzeit nicht finden, bin auf Arbeit) ist noch nie eine Karte untergekommen, die deswegen "kaputtgeschrieben " wurde..., meist sterben die Karten aus profaneren Gründen (Flüssigkeiten, Grobmotoriker, Tierkontakt, elektrische Fehlspannungen) :)

    Die c't hat ja nun auch schon diverse Tests mit SSD-LW und anderen Halbleiterspeichern gemacht - das Fazit war: Bei normaler Nutzung schafft es ein Anwender nicht, das Limit zu erreichen, das die Karten/Laufwerke haben, zumal dann nicht plötzlich nix mehr geht sondern erstmal "nur" die nutzbare Kapazität abnimmt...


    Die Technik von SSDs sind aber eine nicht vergleichbare mit SD's, da bei den SSDs ein Controller mit einem entsprechenden Algorithmus dafür sorgt dass die NAND-Flash Chips nicht zu sehr belastet werden und auch Softwareseitig am Rechner zum Beispiel TRIM für weitere Entlastung sorgt. Das läßt sich also eigentlich nicht wirklich miteinander vergleichen :D

    Ich hab auch schon etliche Tests gelesen, aber 95% der SD-Testberichte beziehen sich auf die ursprüngliche Anwendung: Kameras. Da ist die Belastung aber eine völlig andere als mit einem Betriebssystem


    Ich möchte das aber Hier nicht wirklich weiter vertiefen da offtopic - es kam jedenfalls schon öfters vor das sich RPI User ihre SD zerschossen haben, auch ohne äußere Einwirkungen ;)


  • Ich möchte das aber Hier nicht wirklich weiter vertiefen da offtopic

    stimmt :thumbs1: und mein folgender Kommentar richtet sich keinesfalls gegen dich.....
    ich möchte nur ergänzen


    es kam jedenfalls schon öfters vor das sich RPI User ihre SD zerschossen haben, auch ohne äußere Einwirkungen ;)

    soweit wir wissen, aber es gibt eine Vielzahl von Möglichkeiten SD zu zerschiessen, von falscher Spannung, miese Netzteile bis über das OS (falls zerschiessen meint "läuft nicht mehr") bis hin zu mangelhaften Karten (es gibt leider zu viele Fälschungen oder Schrottkarten)

    alle Flashspeicher basieren auf Nand Technologie, SLC sind besser, meist wird heute nur noch MLC eingesetzt und alle brauchen den Controller zum Beschreiben, da sind SD nicht anders als USB


    wikipedia ist aber nicht mehr auf den neusten Stand
    http://de.wikipedia.org/wiki/Flash-Speicher
    besonders hier SLC zu MLC
    http://de.wikipedia.org/wiki/NAND-Flash
    unter Nachteile, ich wüsste heute nicht mehr wo ich SLC ordern kann......
    (ganz selten bei teuren Teilen findet man da noch Angaben, die meisten verschweigen aber ob sie SLC oder MLC einsetzen)

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Klar gibts etliche Möglichkeiten ne SD oder irgendein anderes Device zu zerschießen - was hier aber offensichtlich nicht der Fall war und ich somit auch nicht derart arg offtopic das ausweiden wollte..........

    Dass SLC teurer ist sollte klar sein - nicht nur weils "besser" und schneller ist sondern auch weil die Herstellung teurer ist als bei MLC oder TLC.
    Da SLC aber auch teurer ist folgt darauf dass SLC nicht mit soviel Speicher verbaut wird als man es mit MLC realisieren kann. Wer also "viel Platz" haben will greift eher zur MLC bzw TLC Technik als zu SLC...

    "Normale" SD's nutzen üblicherweise MLC
    "Industrial" SD's nutzen SLC

    Man darf aber wie gesagt nicht SSD's mit SD's verwechseln.
    Bei SSD's ist auf dem Laufwerk ein eigener Controller verbaut der entsprechend vom Hersteller gewisse Algorithmen usw nutzt.
    Bei SD's ist aber kein solch ein Controller vorhanden sondern jegendlich in dem Gerät wo die Karte reingesteckt wird.

    SLC vs. MLC/TLC zeichnet sich aber auch nur in der Schreib-/Lösch- Geschwindigkeit und somit der Langlebigkeit aus, beim Lesen gibts keine Unterschiede (oder sagen wir lieber "keine bemerkbaren", sonst kommt hierzu gleich wieder nen post dass es 10-50 NanoSekunden unterschieden gäbe *hust*)

    Der Controller kümmert sich darum ob beschädigte Speicherzellen nicht mehr genutzt werden und die Daten darin woanders hin kopiert werden.. So ist es zumindest bei USB und SSD der Fall, nicht aber bei SD's!

    Nichts desto trotz kann man aber auch SLC unnötig belasten was dann zum frühzeitigen sterben führt

    Wie bereits erwähnt ist es ein gewaltiger Unterschied ob man eine SD in einer Kamera verwendet oder als Betriebssystem. Bei letzterem wird regelmässig (üblicherweise alle 8 Sekunden) auf das Laufwerk zugegriffen auch wenn ihr nichts herunterladet o.ä.. Lasst doch nur mal den I/O Monitor iostat (im Paket sysstat enthalten) oder dstat oder sar usw laufen dann seht ihr vielleicht was ich meine ;)

    Alleine in /var/log/ sind ständig Zugriffe - lässt man das System also lange im Standardzustand laufen ist es nicht wirklich verwunderlich das die ein oder andere SD nach einem Reboot nicht mehr will - mir egal was ihr jetzt wieder hierauf postet, ich bleib bei meiner eigenen Praxisgeprägten Meinung :)

    • Offizieller Beitrag

    Es ist schon irre wie solch ein Thread sich plötzlich und unerwartet in ne ganz andre Richtung entwickelt :). Der eigentlich Problem scheint ja behoben worden zu sein. Zum Thema SD Karten könnt ihr euch auch gerne in einen Thread weitermachen. Da ich selbst schon 2-8 Ausfälle hatte bin ich geneigt meigrafd seiner Argumentation zu folgen ;)

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!