Zum Thema "bootet nicht (mehr)" & Co.

  • Hallo zusammen,

    wir hatten hier schon ein paar Threads zum Thema, dass der Pi nicht oder nicht mehr bootet.
    Bisher ist, soweit ich es verstanden habe, im einen oder anderen Fall war ein workaround gefunden worden, aber die Ursache ist bisher immer noch unklar.
    So was beschäftigt mich einfach, und ich habe jetzt noch eine mögliche Ursache herausgefunden.
    Der Grund könnte die Firmware sein.

    Hilfreich in dieser Hinsicht ist dieser Beitrag auf elinux.org.
    Aus Mangel an ausreichend PIs habe ich mal meine beiden geprüft.


    Code
    pi@raspberrypi ~ $ /opt/vc/bin/vcgencmd version
    May 24 2013 16:54:51 
    Copyright (c) 2012 Broadcom
    version 6676ab07e56aeec897f23d09b8fb87b55cbec981 (clean) (release)

    der zweite meldet:


    Code
    pi@pinasprint ~ $ /opt/vc/bin/vcgencmd version
    May 24 2013 16:54:51 
    Copyright (c) 2012 Broadcom
    version 6676ab07e56aeec897f23d09b8fb87b55cbec981 (clean) (release)

    Beide laufen anstandslos mit wheezy:


    Code
    pi@raspberrypi ~ $ uname -a
    Linux raspberrypi 3.6.11+ #456 PREEMPT Mon May 20 17:42:15 BST 2013 armv6l GNU/Linux
    bzw.
    pi@pinasprint ~ $ uname -a
    Linux pinasprint 3.6.11+ #456 PREEMPT Mon May 20 17:42:15 BST 2013 armv6l GNU/Linux

    In diesem Zusammenhang könnte vielleicht noch der Inhalt von /proc/cpuinfo interessant sein:


    Vielleicht kann man ja durch Vergleiche mal rausbekommen, was die Problem-PIs hier so von sich geben (nachdem sie gebootet haben).
    Die Idee hinter diesem Posting ist, evtl. mal von meinen Daten abweichende, aber funktionierende Versionen hier zu sammeln, um dann später mal ein paar Informationen zum Vergleich zur Verfügung zu haben.
    Daher wären solche Fälle wie "bootet nur wheezy", "bootet kein wheezy mehr aber ..." von besonderem Interesse.

    Desweiteren ist in o.g. Link eine kurze Anleitung, Firmware und Kernel von einem Linux- oder Windows-PC aus auf der SD-Karte zu ändern.

    cu,
    -ds-

  • Hi,

    bootet Wheezy und läuft stabil (ist einer von vier Pi!)

    May 24 2013 16:54:51
    Copyright (c) 2012 Broadcom
    version 6676ab07e56aeec897f23d09b8fb87b55cbec981 (clean) (release)


    Processor : ARMv6-compatible processor rev 7 (v6l)
    BogoMIPS : 697.95
    Features : swp half thumb fastmult vfp edsp java tls
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant : 0x0
    CPU part : 0xb76
    CPU revision : 7

    Hardware : BCM2708
    Revision : 000d
    Serial : 0000000020bf2b5e

    Linux raspberrypi 3.6.11+ #456 PREEMPT Mon May 20 17:42:15 BST 2013 armv6l GNU/Linux


    Auf diesem läuft RaspBMX und das macht mucken. Ohne zutun, bootet er es seit ein paar Tagen nicht mehr.

    Mar 7 2013 19:34:17
    Copyright (c) 2012 Broadcom
    version 375458 (release)

    Processor : ARMv6-compatible processor rev 7 (v6l)
    BogoMIPS : 795.44
    Features : swp half thumb fastmult vfp edsp java tls
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant : 0x0
    CPU part : 0xb76
    CPU revision : 7

    Hardware : BCM2708
    Revision : 000e
    Serial : 0000000065743de3

    Linux raspbmc 3.6.11 #2 PREEMPT Wed Mar 13 17:12:47 UTC 2013 armv6l GNU/Linux

    Die anderen beiden werde ich noch testen.

    Gruß Jürgen

    Einmal editiert, zuletzt von Wataba (15. Juni 2013 um 14:01)

  • Hi wataba,

    interessant ist ja schon mal, dass die beiden sich sowohl in der Firmware- als auch in der Kernel-Version unterscheiden.

    Bin ja mal gespannt, ob hier noch mehr Daten eintrudeln, dann kann man vielleicht tatsächlich Rückschlüsse auf das Fehlverhalten eines Pi ziehen.
    Und nebenbei rettet man noch den einen oder anderen Pi vor dem Schredder oder dem Wurf aus dem Fenster ;) ...

    cu,
    -ds-

  • hier mal meine Daten zum Vergleich:

    Code
    pi@raspberrypi ~ $ /opt/vc/bin/vcgencmd version
    May 24 2013 16:54:51 
    Copyright (c) 2012 Broadcom
    version 6676ab07e56aeec897f23d09b8fb87b55cbec981 (clean) (release)
    Code
    pi@raspberrypi ~ $ cat /proc/version 
    Linux version 3.6.11+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #456 PREEMPT Mon May 20 17:42:15 BST 2013


    bis jetzt läuft alle ohne Probleme, habe meinen Pi aber auch noch nicht lange.

  • Hallo zusammen,

    mittlerweile sind hier 5 RPi's im Einsatz: 2x Model B und 3x Model A. Davon 4x made in GB (Farnell) und 1x made in CN (RS). Ein Model B und ein Model A läuft auf Dauer, also 24/7.

    Anfangs ging ich, wie vermutlich viele, recht sorglos mit dem Overclocking um. Wenn der RPi ein paar Tage zuverlässig gelaufen ist, glaubt man, es ist alles soweit ok. Ein Trugschluss!

    Wenn intensiv auf die SD geschrieben wurde, z.B. bei umfangreicheren updates, zeigte "dmesg" (sinngemäß) folgende Warnung: "mmcblk0 timeout - waiting for interrupt ...". Beunruhigend, aber die RPi's liefen zunächst zuverlässig weiter und liessen sich auch immer wieder booten. Irgendwann (nach 2-3 Wochen) war nach einem weiteren, größeren Update aber Schluß. Entweder kein Bootvorgang mehr (aufgrund einem offenbar scheibchenweise kaputt gegangenen und irreparablem filesystem bzw. einzelnen Dateien) oder der Crash kam gleich im laufenden Betrieb.

    Ich bin nach meinen Erfahrungen absolut davon überzeugt, daß die immer wieder auftauchenden threads "bootet (plötzlich) nicht mehr" weit überwiegend zumindest eine der folgenden Ursachen haben:

    - qualitativ mangelhafte SDcard (z.B. "class10" ist ein Speed- aber kein Qualitätskriterium, die teuerste muss nicht unbedingt die beste sein)

    - mangelhafte Stromversorgungl (Ausgangsspannung unter Last prüfen, ausreichende Leistung setze ich voraus) oder auch durch diverse, nicht ganz normgerechte, aktive Hubs (siehe andere threads)

    - Overclocking und/oder zu hohe Taktfrequenzen (schätzungsweise überwiegend die Ursache)

    - kein sauberes Herunterfahren des Systems

    Ich habe "class 4" und "class 10" SDcards von Samsung und Sony im Einsatz. Auf overclocking verzichte ich, den Prozessortakt habe ich aber auf 850 Mhz erhöht, sonst keine Änderungen an den Busfrequenzen. Seit ca. 2 Wochen gibt es keine "timeouts" mehr im Log, "stressige" Schreib-/Lesevorgänge auf den SDcards funktionieren bisher problemlos.

    Eine saubere Stromversorgung vorausgesetzt, kann ich insbesondere den "Overclockern" nur empfehlen, mit "dmesg" öfter mal auf Warnungen des Kernels zu achten. Ob sich der Kernel in der noch weit verbeiteten 3.6er Version aber so verhält, weiß ich leider nicht.

    dreamshader: ich glaube, dies sind in erster Linie die Ursachen - aber glauben heißt ja bekanntlich nicht wissen. ;)

    Gruß, mmi

  • Hi mmi ...

    freut mich, mal wieder was von Dir zu lesen.

    Ich gebe Dir in vollem Umfang recht ...

    Ich denke mal so um die 95% aller Probleme sind in der Tat in der Stromversorgung zu suchen. Die meisten wissen scheinbar gar nicht, dass sie über die Micro Buchse nur 1000mA in den Pi pumpen können. Und ich nehme es den Leuten gar nicht mal übel, denn ich bin anfangs in dieselbe Falle getappt.

    Was die SD-Karten betrifft, so teile ich deine Meinung, dass sie einen Schwachpunkt darstellen können. Allerdings hatte ich in diesem Thread den Eindruck, dass dieses Thema gerne heruntergespielt oder ignoriert wird.

    Und dann bleibt so ein kleiner Beigeschmack, wenn ich lese, dass ein Pi z.B. zwar noch XBian aber nicht mehr wheezy bootet.
    Und das hier Unterschiede bezüglich Prozessor und Firmware existieren, ist ersichtlich.
    Bevor ich so ein Teil dann auf den Müll schmeiße, kann ich als ultima ratio auch mal die Firmware überschreiben.

    Alles in allem ist zwar alles auch auf elinux.org nachzulesen, aber vielleicht schadet es nicht hier mal eine Art troubleshooting for beginners als Read-Only Thread aufzumachen.

    Nun, harren wir der Dinge die da kommen ...

    Viele Grüße aus dem sonnengebadeten Rosenheim,
    -ds-


  • Was die SD-Karten betrifft, so teile ich deine Meinung, dass sie einen Schwachpunkt darstellen können. Allerdings hatte ich in diesem Thread den Eindruck, dass dieses Thema gerne heruntergespielt oder ignoriert wird.


    Absolut meine Meinung. ;)

    Nachdem es ein paar Tage prima funktioniert hat, will man vermutlich gar nicht mehr daran denken, daß es an überhöhtem Takt und/oder OC liegen könnte.

    Unabhängig davon sehe ich aber unverändert als Hauptursache die teils unzulängliche Qualität bei den sdcards. Die Industrie zielt vielfach nur auf Geräte wie z.B. Digitalkameras, dementsprechend sind vermutlich die Qualitätskontrollen ausgerichtet. Eine Digitalkamera schreibt oder liest aber immer sequentiell nur eine einzige Datei, das verwendete Dateisystem (FAT) ist simpel.

    Die Anforderungen an die Qualität (Elektronik) einer sdcard sind bei einem journaled filesystem wie "ext4" viel höher.. Häufige multiple Schreibvorgänge, teilweise entstehen stressige Situationen (ich nenne es mal so).

    Ärgerlich ist, daß evtl. Fehler sich oft erst später bemerkbar machen (bei kaputten Dateien hilft natürlich auch keine Reparatur mit "fsck" mehr).
    Neben "ext4" habe ich auch mit dem für sdcards gedachten "f2fs" filesystem getestet, es gibt aber bzgl. den auftretenden Kernelmeldungen keinen Unterschied. Ein weiterer Beweis, daß es am Verhalten der sdcard an sich liegt. Meine "schlechten" sdcards sind deshalb wieder in die Digikam-Abteilung gewandert, wo sie einwandfrei funktionieren.

    Vergiss bei Deinem Vergleich nicht, daß z.B. raspbian in der Grundkonfiguration vermutlich mehr traffic auf der sdcard als andere Distris erzeugt. Soweit ich weiß, sind z.B. "atime", "diratime" etc. aktiviert, "log" und "tmp" Verzeichnisse sind (zumindest teilweise) auf der sdcard eingerichtet. Zusätzlich das Journal, so wird schon von Haus aus recht viel geschrieben.

    Ich sehe darin unverändert eine der hauptsächlichen Ursachen.

    Nach Regen endlich Sonnenschein - hoffentlich nach dem Hochwasser nun nicht zu viele Schnaken am, im und um den Chiemsee! ;)

    Gruß, mmi

  • Nun darf man aber nicht außer Acht lassen, das der Pi in erster Linie nie für 'Produktivlösungen' konzipiert wurde. Als Experimentierlösung bot sich aus Kostengründen wohl die SD-Card förmlichst an. Ich muß gestehen, das bei mir noch nie eine Karte verabschiedet hat(te) und ich somit eigentlich diverse Probleme nicht nachvolziehen kann.

    waren das Zeiten, als Ordner noch Verzeichnisse waren

    Einmal editiert, zuletzt von I.R.Gendwer (18. September 2013 um 10:55)

  • Habe hier aktuell 3 PIs im problemlosen Einsatz:



  • Hallo,

    sollte ich hier mit meiner Frage falsch liegen, bitte ich um Entschuldigung und Nachsicht.

    Mich würde Folgendes interessieren:
    Wird die Firmware in einen Flash-Speicher o.ä. auf der Platine vom Pi geschrieben oder nur auf die SD-Karte?

    Ich habe nämlich das Phänomen, dass ein Pi anstandslos funktioniert. D.h. ich habe 3 SD-Karten. Setze ich den Pi jeweils unter Strom, bootet das Gerät problemlos bei jeder Karte.

    Bei einem zweiten Pi ist dies allerdings nicht der Fall. Nur bei einer der 3 Karten bootet der Pi, bei den anderen beiden aber nicht.

    Nun frage ich mich, ob ich bei dem ersten Pi irgendwann ein FW-Update durchgeführt habe (ich bin totaler Laie, was den Pi angeht) und müsste das Update auch bei dem 2. Pi durchführen.

    Wenn allerdings die FW auf die SD-Karte geschrieben wird, dann erübrigt sich das FW-Update.

    Danke für die Antwort und Gruss

    Mike

  • Hi,

    die Firmware steht auf der SD-Karte. Der RPi hat kein Flash für ein "BIOS" ;) ...

    Und wenn Du ein Komplett-Image (also wheezy oder was auch immer) verwendest und nicht über diese exotischen Boot-Dinger dann denke ich, sollte die Firmware auch immer aktuell sein.

    cu,
    -ds-

  • Ja, benutze gleiches Netzteil und gleiches HDMI-Kabel am identischen Monitor.

    Ich habe schon vor einer Woche ein Pi reklamiert, heute das neue bekommen und es funktioniert genauso wenig.

    Aufgefallen ist mir Folgendes:
    Sobald ich das 'alte' Pi mit dem Netzteil verbinde, geht der Monitor an und die Kommandozeilen vom Booten laufen über den Bildschirm. Bei allen 3 Karten.

    Verbinde ich hingegen das 'neue' Pi mit dem Netzteil, dann passiert überhaupt nichts. Ausser bei der einen SD-Karte. Da geht es.

    Gruss
    Mike

  • Sind das SD Karten vom selben Hersteller und Typ? Wenn Deine Pi schon mal ausgetauscht wurde und immer noch derselbe Effekt vorliegt kann es auch sein, dass Deine erste Pi gerade optimale Toleranzen für Deine SD Karten hat - aber alle anderen in die Röhre mit dem Kartentyp schauen.

  • Ja, es sind absolut die gleichen Karten.

    Zum besseren Verständnis:
    In unserem kleinen Theater wird über einen Beamer eine Vorschau auf kommende Veranstaltungen gezeigt und dazu verwende ich den einen Pi.

    Die Vorschau selbst erstelle ich zuhause und dazu wollte ich den 2. Raspberry verwenden um nur noch die Karten austauschen zu müssen. Sonst muss ich den Pi vom Theater mitnehmen, der aber dort benötigt wird.

    So wie das jetzt läuft, geht das aber nicht.

    Gruss

    Mike


  • Sind das SD Karten vom selben Hersteller und Typ? Wenn Deine Pi schon mal ausgetauscht wurde und immer noch derselbe Effekt vorliegt kann es auch sein, dass Deine erste Pi gerade optimale Toleranzen für Deine SD Karten hat - aber alle anderen in die Röhre mit dem Kartentyp schauen.

    Da mogst scho recht ham ...
    aber dass von drei Karten gleich zwei nicht funktionieren ist schon erstaunlich.

    Es sei denn, die Karten stehen auf dem Index ... also sind als nicht supported deklariert.

    cu,
    -ds-

Jetzt mitmachen!

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