Raspi 3 startet nicht nach Config

  • IHi.

    Mein Raspi startet nicht mehr (auch kein Bild auf Monitor).
    Ich habe ihn gerade erst neu aufgesetzt, aktualisiert (apt-get upgrade & rpi-update), danach Neustart.
    Dann raspi-config ... Hier die Localization umgestellt, i2c und spi eingeschaltet und GPU RAM auf 256.
    Danach bootet er nicht mehr. In den Logs finde ich leider nichts. dmesg ist leer, die anderen Logs enden beim Herunterfahren.

    Hier nun die config.txt:

    dtparam=audio=on
    gpu_mem=256
    dtoverlay=vc4-kms-v3d
    dtparam=i2c_arm=on
    dtparam=spi=on

    Ich habe auch schon versucht die Werte anzupassen, GPU-Mem weg runter, dtoverlay (was auch immer das sein soll) auskommentiert, etc..
    Die rote LED ist an, die grüne LED blinkt unregelmäßig für 10-20 Sekunden und geht dann aus.
    Kann noch eine andere Config irgendwo umgestellt sein? Irgendwo noch Logs zu finden außer in /var/log ?

    Tausend Dank schonmal

    Einmal editiert, zuletzt von retikulum (6. März 2016 um 12:10)

  • Danke für die schnelle Antwort!
    Japp. Neuinstallieren funktioniert. Ich hab das gleiche Problem bisher zweimal gehabt. Immer mit dem Ergebnis, dass das Teil nicht bootet. Ich hab auch nichts besonderes gemacht außer den genannten Punkten oben.
    LEDs: Rot immer an, grün blinkt jetzt in mehr oder weniger gleichem Rhytmus (die ersten 20 Sekunden allerdings taktlos... wie beim Boot?). Nach ca. 90 Sekunden hört die grüne LED auf zu blinken.

    Die Logs sind noch immer leer... in dmesg müsste doch wenigstens was drin stehen oder?

    Ich teste jetzt mal noch ne andere Karte. Die aktuelle ist eine neue Transcend 32GB. Hab noch nen Sandisk, die probiere ich mal.

    Einmal editiert, zuletzt von retikulum (6. März 2016 um 12:31)

  • Hallo Retikulum,

    dann setze das Teil nochmals neu auf und aktualisiere mit

    Code
    sudo apt-get update
    sudo apt-get upgrade

    Und vergiss rpi-update! Wer hat Dir gesagt, dass Du dieses Skript starten sollst? Dies gehört nicht zum offizielen Update / Upgrade-Prozess. Und wenn Du Pech hast, dann geht es Dir wie den meisten, dass Du Dir auch ein Update hereinziehstm, an dem nǵerade noch gearbeitet wird. Dieses nennt man unstable - im Gegensatz zu dem, was Di Dir über update / upgrade hereinziehst. Dieses wird als stable bezeichnet.

    Hast Du mal einen Bildschirm angeschlossen? Meiner Erfahrung nach ist es normal, dass ein Raspberry Pi nach geraumer Zeit (ca. 30 s) keine Aktivitäten zeigt, d.h. die grüne ACT-leuchtet und blinkt nicht mehr. Denn diese LED zeigt an, wenn auf die SD-Karte geschrieben oder von ihr gelesen wird.

    Warum erwartest Du irgendwelche Lebenszeichen der ACT-LED, wenn nichts gelesen / geschrieben wird?


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (6. März 2016 um 13:21)

  • Ist das normale Umgangston hier? Dann kann ich auch gleich mit dem Hobby aufhören und mich mit meiner Frau unterhalten ;)

    Wie du im allerersten Satz siehst, habe ich einen Monitor dran. Wie du in den folgenden Sätzen siehst, sind auch die Logs leer. Raspi taucht auch nicht im Netzwerk auf.
    Auch ist das Problem nicht nach rpi-update-Reboot aufgetaucht, sondern nach der Config.
    Wie hoch kann ich die GPU-Mem stellen? Evtl. ist 256 erstmal zu viel?

    Was solls, ich setze das Ding neu auf und lasse es mit der config gui.

    Einmal editiert, zuletzt von retikulum (6. März 2016 um 13:18)

  • Hallo retikulum,


    Ist das normale Umgangston hier? Dann kann ich auch gleich mit dem Hobby aufhören und mich mit meiner Frau unterhalten ;)


    Huch... :s



    Wie hoch kann ich die GPU-Mem stellen? Evtl. ist 256 erstmal zu viel?

    Ich habe bei meinen Raspberry Pi's den Wert für GPU aufs Minumum gesetzt. Für die Performance war das nur vorteilhaft.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • Und vergiss rpi-update! Wer hat Dir gesagt, dass Du dieses Skript starten sollst? Dies gehört nicht zum offizielen Update / Upgrade-Prozess. Und wenn Du Pech hast, dann geht es Dir wie den meisten, dass Du Dir auch ein Update hereinziehstm, an dem nǵerade noch gearbeitet wird. Dieses nennt man unstable - im Gegensatz zu dem, was Di Dir über update / upgrade hereinziehst. Dieses wird als stable bezeichnet.

    Nana..:-/
    Also das stimmt ja so nicht! Über rpi-update wird der offizielle Kernel verteilt. Auf der bereits vorinstallierte stammt von dort.
    In deren Git wird viel Wert auf Stabilität gelegt. Eine kleine Änderung wird da schon mal 4 Wochen getestet.
    Unstable heißt dort next und ist nicht per default eingerichtet. Es gibt immer nur stables wenn nicht anderes angegeben wird.

    Einmal editiert, zuletzt von robingr (7. März 2016 um 12:03)


  • Eine kleine Änderung wird da schon mal 4 Wochen getestet.

    Da wird nicht richtig getestet, denn wenn das der Fall wäre, dann würde es z. B. diesen Thread nicht geben.

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

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Fehler passieren überall. Gerade bei neuer Hardware.
    rpi-update holt die aktuelle master. Es ist aich möglich nie next branch zu nutzen. Das ist im Moment die 4.4er Reihe.
    Ich habe mit meinem Pull Request die Erfahrung gemacht, dass da sehr ordentlich und gewissenhaft gearbeitet wird. Ich hatte noch NIE, nicht beim Pi1, Pi2 und jetzt beim 3er ein Problem mit dem Master Kernel.


  • Nana..:-/
    Also das stimmt ja so nicht! Über rpi-update wird der offizielle Kernel verteilt. Auf der bereits vorinstallierte stammt von dort.
    In deren Git wird viel Wert auf Stabilität gelegt. Eine kleine Änderung wird da schon mal 4 Wochen getestet.
    Unstable heißt dort next und ist nicht per default eingerichtet. Es gibt immer nur stables wenn nicht anderes angegeben wird.

    Falsch.
    Der aktuelle STABLE Kernel, wie er auch auf den offiziellen Images zum Einsatz kommt, ist regulär im apt-get Repository und somit über apt-get installierbar. Über "rpi-update" ohne Argumenten hingegen erhält man immer einen Kernel/Firmware an dem aktuell entwickelt wird und deshalb natürlich noch Fehler enthalten kann bzw als UNSTABLE gilt. Erst wenn die Entwickler durch ausgiebige Tests keine Probleme feststellen konnten wird der Kernel/Firmware ins apt-get Repository übernommen.
    Es gibt zudem verschiedene Zweige an denen entwickelt wird, mit 4.1 und 4.4 sind derzeit die meisten Entwickler beschäftigt.

    Nur weil Du bisher Glück hattest bedeutet das nicht dass das was wir schreiben nicht stimmt. Du hattest einfach nur Glück. Etliche andere hier hatten schon Probleme mit "rpi-update" bezogenen Versionen - was wie gesagt auch nicht wirklich verwunderlich ist.

    "rpi-update" ist ein Script um sich an der Entwicklung zu beteiligen, oder auf kommende Features schon vor offiziellem Release, auf eigenes Risiko, vorzeitig zugreifen zu können. Das wird aber leider fatalerweise missverstanden und von vielen Blogs falsch beschreiben.


    Back to Topic:

    Sofern die GUI auf Autostart steht, verursacht die config.txt Einstellung "dtoverlay=vc4-kms-v3d" derzeit noch Probleme. Der dadurch aktivierte OpenGL Treiber unterstützt zudem momentan nur den RPi2. Werf das also mal aus der config.txt raus.

  • Okay, überredet. Mein Fehler sorry. :(
    Ich bin immer davon ausgegangen, dass die aktuelle master stable ist und die Firmware in den Repos Pointreleases sind.
    Ich habe nämlich auch noch nie gesehen, dass es da mal ein update hätte geben können.
    Und die master wird in einem üblichen Intervall gebaut. Zeitabstände ähnlich Debian und Ubuntu..


  • Fehler passieren überall. Gerade bei neuer Hardware.

    Das Problem ist auch mit dem PI1 bzw. PI2 und dem Master-Kernel aufgetreten.


    Ich hatte noch NIE, nicht beim Pi1, Pi2 und jetzt beim 3er ein Problem mit dem Master Kernel.

    Dann hast Du bis jetzt, einfach nur Glück gehabt.

    Wenn Du es nicht glaubst, dann kannst ja mal mit der Firmware-Revision cae1bdb3f430414aa563ff0255b0efaf71bb84be (Master-Kernel; Commits on Mar 3, 2016) und deinem PI2 testen. Die vier *.dat-Datein bzw. die vier *.elf-Dateien aus dem Verzeichnis "/boot" sind fehlerhaft. Der PI bootet nicht mehr:

    https://github.com/Hexxeh/rpi-fir…5b0efaf71bb84be

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

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hi,


    Okay, überredet. Mein Fehler sorry. :(
    ...


    mach' Dir nix draus ... jeder kann sich mal irren. Es geht ja auch nicht darum recht zu haben. Solche "Tipps" sind halt brandgefährlich und sorgen evtl für Probleme, die später nur schwer bis gar nicht nachvollziehbar sind.
    Sieh' es positiv und verbuch' es unter "wieder was dazugelernt" ;)

    cu,
    -ds-

  • Das ist auch nicht so einfach zu verstehen. Der verwendete Kernel beim rpi-update ist schon der stabile (Nicht gleich losmeckern, sondern weiterlesen!). Allerdings ist das der Kernel, der für das offizielle Debian als stable gekennzeichnet ist. Im Prinzip gibt es gar keinen stabilen Kernel für den Raspberry Pi, weil es bei der Portierung und dem "Drumherum" immer mal zu Fehlern kommen kann. Deswegen wird auch recht lange getestet, bis ein als stable gekennzeichneter Kernel ins Image übernommen wird. Meist lag der Fehler auch gar nicht im portierten Kernel, sondern in einer für den aktuellen Kernel falschen Umgebung, verursacht durch das Laden der oben genannten unpassenden Dateien. Aber wie gesagt, das Ergebnis ist das gleiche, als wenn der Kernel nicht stabil wäre.


  • Das ist auch nicht so einfach zu verstehen. Der verwendete Kernel beim rpi-update ist schon der stabile (Nicht gleich losmeckern, sondern weiterlesen!). Allerdings ist das der Kernel, der für das offizielle Debian als stable gekennzeichnet ist.

    Auch das stimmt nicht so richtig :fies:

    Das Grundgerüst der Kernel's werden nicht von Debian sondern von kernel.org entwickelt bzw herausgegeben. Debian nimmt sich dieses Grundgerüst und modifiziert es entsprechend ihrer Distribution. Für Raspbian bzw den RaspberryPi wiederum wird dann dieses Grundgerüst genommen und entsprechend modifiziert - im Fall des Raspberrys mit den dafür spezifischen Merkmalen und anstehende neue Features die die Entwickler einbauen wollen, versehen.

    Es ist richtig das von Kernel.org derzeit der 4.4 Kernel (und die davor) als "stable" markiert ist.
    Aber da die RaspberryPi Entwickler (bzw Community) daran herumgespielt haben, gilt dieser so lange nicht mehr als stable bis die RaspberryPi spezifischen Features augenscheinlich zu funktionieren scheinen.... Natürlich kann auch ein als "stable" markierter Kernel noch Fehler enthalten, die dann aber meist nur unter sehr speziellen Gegebenheiten auftreten, dann hoffentlich reported werden sodass die dann im nächsten Release behoben wurden.

    Es macht aber IMHO nicht so viel Sinn darüber zu diskutieren ab wann ein Kernel als Stable gilt. Das sorgt nur für unnötig Verwirrung.
    Fakt ist auf alle Fälle das über "rpi-update" ohne Argumente, ein Kernel/Firmware geladen wird an dem noch entwickelt wird. Man kann über das vom rpi-update Script github-Repository zwar auch einen Stable laden, dazu muss man aber den speziellen commit-hash angeben.

  • So ist das wohl ...


    ...
    Das Grundgerüst der Kernel's werden nicht von Debian sondern von kernel.org entwickelt bzw herausgegeben.
    ...


    nur der Vollständigkeit halber und falls es jemandem mal unterkommt: dieser Basiskernel wird auch als Vanilla-Kernel bezeichnet ...

    cheers,
    -ds-


  • Back to Topic:

    Sofern die GUI auf Autostart steht, verursacht die config.txt Einstellung "dtoverlay=vc4-kms-v3d" derzeit noch Probleme. Der dadurch aktivierte OpenGL Treiber unterstützt zudem momentan nur den RPi2. Werf das also mal aus der config.txt raus.

    Alles klar, das ist also die Einstellung. Danke schonmal.
    Gerade ist mir auch die SD-Karte komplett abgeraucht. Scheint also doch die Karte gewesen zu sein. Hatte noch mehrmals gewisse Anomalien... mal ist der Raspberry gestartet, mal nicht. Jetzt war die Karte auch nicht mehr in meinem anderen Raspberry per Cardreader lesbar. Habe jetzt temporär ne andere drin... diese läuft bisher problemlos.

Jetzt mitmachen!

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