Hab ich meinen Pi auf dem Gewissen ?


  • Ja Runlevel liefert mir die ausgabe "unknown"
    Und init5 gibt mir die ausgabe "init is the parent of all processes"

    Wenn runlevel unknown sagt, dann bist Du vermutlich in einer "Not-bash"

    dann mal sudo init 5 (mit Leerzeichen) ...

    Ich hoffe, da kommen dann ein paar Fehlermeldungen als Hinweis.

    oder filesystemcheck machen und dann rebooten.

    -ds-

    • Offizieller Beitrag

    Das mit der Not-Bash hatten wir schon auf seite 1 ;).
    Witzig ist allerdings das er sagt, das er es nicht mounten kann, es aber doch tut (oder vorher schon getan hat, aber bei mount nicht anzeigt).

    teste mal

    Code
    e2fsck /dev/mmcblk0p2
  • Wenn runlevel unknown sagt, dann bist Du vermutlich in einer "Not-bash"

    dann mal sudo init 5 (mit Leerzeichen) ...

    Ich hoffe, da kommen dann ein paar Fehlermeldungen als Hinweis.

    oder filesystemcheck machen und dann rebooten.

    -ds-

    sudo init 5 da sagt er "sudo: not found"

    Filesystemcheck sagt er auch not found

  • Was mich halt nur wundert, daß die Probleme bei zwei verschiedenen SD Karten bestehen. Ich würde mal versuchen, die Kernelmessages und mögl. Logfiles ( da war doch auf einem Foto ein Log Verzeichnis zu sehen ) auf einen USB Stick zu sichern und mal hier zu posten.


  • Das mit der Not-Bash hatten wir schon auf seite 1 ;).
    Witzig ist allerdings das er sagt, das er es nicht mounten kann, es aber doch tut (oder vorher schon getan hat, aber bei mount nicht anzeigt).

    teste mal

    Code
    e2fsck /dev/mmcblk0p2

    da sagt er auch not found


    Was mich halt nur wundert, daß die Probleme bei zwei verschiedenen SD Karten bestehen. Ich würde mal versuchen, die Kernelmessages und mögl. Logfiles ( da war doch auf einem Foto ein Log Verzeichnis zu sehen ) auf einen USB Stick zu sichern und mal hier zu posten.

    in dem logverzeichnis ist nur ein leeres txt dokument da hab ich auch schon geschaut :(

    das sieht interessant aus, hilft das weiter ?

    Einmal editiert, zuletzt von skull2505 (9. August 2013 um 22:30)

  • Hallo skull,

    also ich kann mir nur noch vorstellen, dass das Netzteil was abbekommen hat.
    Vielleicht kannst Du Dir ja mal kurz von jemandem eins ausleihen.
    Oder, wenn Du einen aktiven USB-Hub hast, kannst Du auch von einem Port (besser zwei) auf einen der beiden auf dem RPi gehen. Das funktioniert auch.

    cu,
    -ds-

  • Lenk mal die Ausgaben von dmesg in eine Datei auf die SD Karte um, dann kannst Du die in mit einem Windowsrechner hier als Anhang speichern, teste mal ob daß so geht:

    dmesg > /boot/dmesg.log
    sync
    umount /boot
    init 0

    Damit sollten die Kernelmeldungen auf der boot Partition der SD Karte als dmesg.log File liegen welche Du dann posten kannst.

    Einmal editiert, zuletzt von Fliegenhals (10. August 2013 um 10:28)

    • Offizieller Beitrag

    gut, dann mach das was fliegenhsls vorgeschlagen hat. Usb stick ran und dann

    Code
    mkdir /media
    mount /dev/sda2 /media
    mkdir /media/logresc
    mkdir /media/logdata
    cp -r /var/log /media/logresc
    cp -r /mnt/var/log /media/data

    wobei sicherzustellen ist das
    der usb stick wirklich /dev/sda2 ist (notfalls per dmesg prüfen) und der stick fat32 formatiert ist

  • Versuch doch mal bitte folgendes, an einem Windowsrechner änderst Du auf der SD Karte die Namen der Kernelimages um:

    kernel_emergency.img -> kernel_emergency.img.bck
    kernel.img -> kernel_emergency.img

    Dann startest Du den RPi neu, hab keine Ahnung ob daß klappt aber ein Versuch macht klug. Vielleicht kannst Du im Betrieb noch die Spannung an den GPIO Pins jeweils gegen Masse und die 3,3V messen, besonders interessant ist Pin 5 und Pin 6. Es könnte ja sein, daß im Chip wichtige GPIO's ( z.B. Pin 5 & 6 ) nach der Aktion einen Kurzschluß haben und deshalb permanent das Emergency Kernelimage geladen wird. Wie bist Du denn in den target_fs Editor gelangt?


  • gut, dann mach das was fliegenhsls vorgeschlagen hat. Usb stick ran und dann

    Code
    mkdir /media
    mount /dev/sda2 /media
    mkdir /media/logresc
    mkdir /media/logdata
    cp -r /var/log /media/logresc
    cp -r /mnt/var/log /media/data

    wobei sicherzustellen ist das
    der usb stick wirklich /dev/sda2 ist (notfalls per dmesg prüfen) und der stick fat32 formatiert ist

    die beiden Ordner auf dem USB Stick sind leer sowie die Ordner auf dem PI die ih koieren wollte.

    Der Vorschlag von Fliegenhals hat geholfen, ich bin jetzt wieder auf dem normalen GUI bzw im Terminal.
    Kann man jetzt irgendwie herausfinden was da los ist ? ^^

    In den target_fs editor bin ich gelangt als ich die README.md geöffnet habe ( die hatte ich schonmal offen, da war sie aber leer).

    Achso wo wir schonmal bei Editor sind, wie komme ich aus einer TXT Datei raus die ich mit "vi" geöffnet habe ? ^^

    Auf jedenfall vielen dank an alle beteiligten, jetzt kann ich den pi wenigstens als Taschenrechner nutzen :) :danke_ATDE:

    Gruß

    Martin


  • Nein, hab einen Kurzschluss verursacht als ich mit den GPIO s gespielt habe und nicht aufgepasst habe

    Hi,
    ok ... das mit dem falsch anstecken habe ich schon mitgekriegt. War nur so eine Idee, weil ein übertakteter RPi oft dazu tendiert, die SD zu schrotten.

    cu,
    -ds-

  • Der Vorschlag von Fliegenhals hat geholfen, ich bin jetzt wieder auf dem normalen GUI bzw im Terminal.
    Kann man jetzt irgendwie herausfinden was da los ist ? ^^

    Na dann ist genau daß eingetreten was ich bereits vermutet habe. Jetzt mußt Du nur noch testen, welche Hardware noch einen Schaden davon getragen hat ( Kernelmeldungen ) und für deinen behinderten RPi eine passende Aufgabe finden. Vielleicht sind ja noch ein Paar GPIO Ports zu gebrauchen.

Jetzt mitmachen!

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