RPi 3 bootet nicht mehr komplett.

  • Guten Abend -öh Schitt- ... *hust* Guten MORGEN! :wallbash: :wallbash: :wallbash:

    Also ersteinmal weiß ich nicht, ob ich in die Richtige Sektion gepostet habe. Es geht wahrscheinlich um die Software, die die Hardware zu sehr anschpricht und da ich eh auf OS und VM später eingehen möchte poste ich es ersteinmal unter Software.

    Ich habe seit längeren ein kleines Problem mit dem Raspberry Pi 3 B (Raspian-jesse). Dieser friert einfach ein und die Rote LED (Statusled) leuchtet nur und es kommt mir so vor, dass die LED nur den Standby anzeigt - wie bei alten Fernsehern, die eine Rote Status-Standby-LED haben.
    SSH: aborted

    Also habe ich erst einmal gar keinen Zugrifft gehabt. Ich hatte ihn letzte Woche einmal vom Dauerbetrieb entfernt und ihn abkühlen lassen (immer wenn ich ihn finde, ist er leicht aufgewärmt, aber denke, dass ist im passablen Bereich. Jedenfalls wird er durch den passiven Kühler nicht mehr so heiß, wie ich ihn das erste mal aufgefunden habe. Danach ging/bootete er auch erfolgreich und lief wieder für eine Zeit lang. An dem System fanden keine gravierenden Software Änderungen statt, sondern nur Dateispeicherung (Eigentlich nur Nextcloud, bisschen Piwik und super wenig Wordpress). Also im Großteil, Apache, PHP und MYSQL. Ich kann leider momentan nicht die Versionen nennen, ich hoffe ihr habt Verständnis. ;)


    Als ich ihn gestern erneut zum laufen bringen wollte nach einem erneuten einfrieren, bootete ich ihn mehrmals neu. Fehler gab es auch einige. Wegen dem ext4 nahm ich also zunächst an, dass einfach nur die Speicherkarte zu voll wurde (habe zuletzt etwas größere Videos in Nextcloud hochgeladen). Diese Fehler zeigte er nicht immer an. Meist nach dem start des authentification des monitoring services. Also das ist das kuriose. Manchmal bootet er, lädt die Service Module hoch und friert dann irgendwann ein, oder er zeigt mir das mit dem ext4 Fehler. Ich werde gerne später ein Foto dazu posten, aber dazu bitte später ( :sleepy: :sleepy: :sleepy: ).


    Nunja meine erste Idee war die Logs, die sich mittlerweile angesammelt hatten zu leeren. (Benutze Win 10).
    Ich habe Diskinternals Linux Reader ausprobiert, aber dort ist ja nur das Extrahieren der Dateien aus dem Dateisystem möglich und nicht das löschen.
    Also musste mal eben ein ganzes Linux Betriebssystem her über Nacht. Ich habe Virtualbox nun installiert mit den USB3.0 Extensions.
    Das 2016-12-13-pixel-x86-jessie.iso, sowie
    Debian 8.8.0-amd64 und
    Ubuntu laufen jetzt.


    Die SD-Karte kann ich auch erfolgreich in die Virtuellen Maschinen einbinden:

    Leider kann ich selbst in der VM unter Debian nichts löschen. :helpnew:

    Ich nehme an, ich muss die SD-Karte erst rein ins Debian System formantieren oder was? Das ist nur eine Vermutung, aber müsste dann es dann nicht sogar theoretisch den Pi komplett zu emulieren? Das eine VM auf dem Pi Probleme machen soll wegen der x86 Kernel Architektur ist klar, aber andersrum müsste es doch klappen oder nicht? Also kann ich nicht direkt sogar von der SD-Karte booten, damit ich das System, welches vorher auf dem Pi läuft, jetzt komplett auf der VM auf dem OS Pixel-x86-jessie, oder sogar Debian laufen kann?

    Bin da momentan echt überfragt und mittlerweile auch übermüdet (also Forensuche und Google habe ich genug genutzt, kam auch erst jetzt mich hier anzumelden, da vorher Google völlig ausreichend war/ist) und ich hoffe echt ihr könnt mir weiterhelfen. Ich bin gestern komplett neu in VM eingestiegen, habe eigentlich alles hingekriegt, aber mit Linux bin ich noch irgendwie auf den Kriegspfad, besonders bei den Dateisystemen - es wurd schon besser, keine Sorge :bravo2: :D :D :D :bravo2: :thumbs1: -


    LG STrike

  • Nur ganz kurz, weil ich gleich weg muss:

    1) Versuch mal in einem Terminalfenster den Dateimanager mit sudo pcmanfm zu öffnen. Damit müsste es gehen. Ich habe das schon lange nicht mehr gemacht und bin mir nicht sicher, ob der Dateimanager noch so heisst und ob das immer geht.

    2) Falls Du weisst wie, dann versuch doch mal aus einem Terminal-Fenster mit cd in das Verzeichnis mit den logs auf der SD Karte zu navigieren und lösche die gewünschten Dateien mit sudo rm.

    Ich hoffe, das bringt dich weiter.

    P.S. Unter Oracle VM VirtualBox kannst du keine ARM Architektur emulieren. Es gibt andere Hypervisor, wie. z.B. QEMU, die das können. Aber den Aufwand würde ich mir in deinem Fall ersparen.

  • Willkommen im Forum!

    Als aller erstes. Die rote LED zeigt nur an das der Pi mit Strom versorgt wird. Die grüne LED direkt daneben ist diejenige die in unregelmäßigen Abständen aufleuchten sollte. Flackert die rote LED ist deine Stromversorgung nicht stark/stabil genug. Zumindest wäre das meine erste Vermutung und könnte auch sämtliche Probleme die Du hast beschreiben.
    Denn mit den 1.1 GB die auf der SD noch frei sind, hast du genügend Platz um den Pi zu betreiben.

    Also erst einmal zwei Fragen:

    1) Was für ein Netzteil verwendest Du um den Pi zu betreiben? Zufällig ein Handyladegerät?
    2) Du erwähntest Fehler beim Boot. Es wäre sehr nützlich zu wissen was das für Fehler sind. Alles andere ist für uns dann nur Rätselraten.

    Einmal editiert, zuletzt von BallerNacken (7. Juni 2017 um 10:58)


  • Nur ganz kurz, weil ich gleich weg muss:

    1) Versuch mal in einem Terminalfenster den Dateimanager mit sudo pcmanfm zu öffnen. Damit müsste es gehen. Ich habe das schon lange nicht mehr gemacht und bin mir nicht sicher, ob der Dateimanager noch so heisst und ob das immer geht.

    2) Falls Du weisst wie, dann versuch doch mal aus einem Terminal-Fenster mit cd in das Verzeichnis mit den logs auf der SD Karte zu navigieren und lösche die gewünschten Dateien mit sudo rm.

    Ich hoffe, das bringt dich weiter.

    P.S. Unter Oracle VM VirtualBox kannst du keine ARM Architektur emulieren. Es gibt andere Hypervisor, wie. z.B. QEMU, die das können. Aber den Aufwand würde ich mir in deinem Fall ersparen.

    Zu 1.: WO? Am Pi? Bootet nicht komplett, wie gesagt, habe dabei auch kein Zugriff auf die SD(kein HDMI Output - vorerst ja (lädt die Graka, ebenso den Recovery Modus, aber nach den laden der Services geht nichts mehr; SSH abortet oder Connection lost) nur unter der VB unter Debian. Unter Debian ist der besagte Dateibrowser nicht installiert.

    Zu 2. find /var/log -type f -name "*.gz" -delete
    (dabei musste ich in der VB noch auf media/timo/root0/var.... verlinken)


    Ich nehme an, ich muss die SD-Karte erst rein ins Debian System formantieren oder was? Das ist nur eine Vermutung, aber müsste dann es dann nicht sogar theoretisch den Pi komplett zu emulieren? Das eine VM auf dem Pi Probleme machen soll wegen der x86 Kernel Architektur ist klar, aber andersrum müsste es doch klappen oder nicht? Also kann ich nicht direkt sogar von der SD-Karte booten, damit ich das System, welches vorher auf dem Pi läuft, jetzt komplett auf der VM auf dem OS Pixel-x86-jessie, oder sogar Debian laufen kann?

    Also mit dem Terminal ging es, nachdem ich mir die root Rechte geholt habe. Aber wenn ich sowas in Linux in der GUI machen möchte, dann muss ich wahrscheinlich, dem VB Debian System erst die Rechte setzen, wie der Raspberrypi, damit ich aus Debian (GUI) die SD-Karte bearbeiten kann? Ist diese Vermutung richtig? Wenn ja, habe ich mir die mühe durch den Terminal gesparrt. Möchte nur wissen, ob ich auf den richtigen Linux-Pfad/Weg angelangt bin.


    _________________________

    Hardware:

    Das Netzteil: VHBW AC Adapter (Model: XTD-502000/3013) (Input: 100V-240V ~50/60Hz) (Output: DC5v 2A) Habe den Pi damals in ein Komplettset geschenkt bekommen. Vermute dass das Netzteil zum Original Made in China bestand gehört.

    SD Karte: Intenso mirco SD HC Class 10 (16 GB)

    Somit sind wir schon mit der Hardware durch und mit dem löschen alter Logs ebenso. Ich werde gleich probieren ihn neuzustarten.
    ___________________________
    Hier kommt noch der Bootfehler:

    LG und vielen Dank schon für die schnellen Antworten.

    Einmal editiert, zuletzt von xXSTrikeXx (7. Juni 2017 um 15:52)

  • Hallo xXSTrikeXx,

    nimm bitte mal die SD-Karte und lege sie in einen PC ein, auf dem Ubuntu, Debian oder sonst ein Linux läuft.

    Dann machst Du mit jeder Partition der SD-Karte

    Code
    fsck


    [file system check]

    Das Dateisystem Deiner SD-Karte scheint korrupt - aber reparabel - zu sein.

    Und Du hast echt 15 Minuten vor dem Bildschirm gesessen, um das Bild aufzunehmen?

    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 (7. Juni 2017 um 16:14)

  • Das Netzteil ist afaik zu schwach für den 3B. Der sollte eines haben das gute 2.5A ausgibt. Bei 2A kann genau soetwas wie bei Dir gerne mal passieren. Auch die Spannugnsversorgung sollte leicht über 5V liegen. Wenn möglich miss das mit einem Voltmeter mal durch.

    Allerdings will ich auch eine defekte SD Karte nicht ausschließen. Hast du den Pi öfters mal außer Betrieb genommen als er noch lief?

  • In den Boot-Meldungen steht es ja: "Detected aborted journal (ext4)" und remounting read-only. Das mit read-only führt bei der root-partition zum aufhaengen sobald was geschrieben werden muss. Also geht es nicht weiter. Erst muss das defekte ext4-journal repariert werden. (mit fsck wie oben schon erwänht)

  • Hallo xXSTrikeXx !

    Wenn sich das Ext4 Filesystem auf der Partition 7 der SD-Karte mit fsck nicht mehr automatisch reparieren lässt (das wurde beim Hochfahren eigentlich schon versucht), dann kannst Du noch etwas tiefer mit e2fsck über den alternativen Superblock am Linux PC eine Wiederherstellung versuchen. Siehe < man e2fsck >

    Mit badblocks -v könntest Du auch einen Hardwaredefekt der SD direkt aufspüren (nur nie -w verwenden).

    -v ist bei vielen systemnahen Programmen der Verbosemode, das heisst, alle Ausgaben erfolgen am Terminal und nicht auf der Fehlerkonsole.


    Servus !

    RTFM = Read The Factory Manual, oder so


  • Das Netzteil ist afaik zu schwach für den 3B. Der sollte eines haben das gute 2.5A ausgibt. Bei 2A kann genau soetwas wie bei Dir gerne mal passieren. Auch die Spannugnsversorgung sollte leicht über 5V liegen. Wenn möglich miss das mit einem Voltmeter mal durch.

    Allerdings will ich auch eine defekte SD Karte nicht ausschließen. Hast du den Pi öfters mal außer Betrieb genommen als er noch lief?

    Das Netzteil sollte eigentlich reichen. Ich weiß nicht wie ich es durch einen "Voltmeter" messen kann. Einen Multimeter besitze ich jedenfalls, aber wo und wie soll ich da messen? Habe gelesen, dass 2 A völlig ausreichend sind, es sei denn der Pi läuft unter Volllast (Alle USB Plätze belegt). Ich habe jedenfalls nur ein CAT6 Kabel, was zum Pi führt und die USB Stecker sind frei. Am Bildschirm ist der Pi nur über HDMI verbunden. Ich werde in Zukunft dennoch nach einem neuem Netzteil ausschau halten.

    Den Pi habe ich eigentlich nicht öfters außer Betrieb genommen, nur als er nicht booten wollte oder sich aufgehangen hat (ich vermute das eine mal, lag es an der Hitze. Ich hatte da noch keine passiven Kühlkörper drauf und vor 2 Wochen als der Vorfall geschehen ist, war es ja schon sehr warm und im Dachgeschoss ist es auch irgendwie kein Wunder.



    Ich habe also beides ausgeführt in der Virtualbox mit Pixels raspian Version.

    Danach habe ich die Karte wieder eingsteckt und es kam das:


    Dort sieht man wahrscheinlich, wie der Pi beim Boot den FSCK ausführt.

    Dennoch erschien später ein schwarzes Bild aber dafür blinkte die grüne Lampe dauerhaft alle 2 Sekunden.

    Als ich den Stecker zog und erneut zum booten aufforderte, startete er normal bis zum blackscreen und dann ging wieder nur noch die rote Lampe.

    Zitat

    Wenn sich das Ext4 Filesystem auf der Partition 7 der SD-Karte mit fsck nicht mehr automatisch reparieren lässt (das wurde beim Hochfahren eigentlich schon versucht), dann kannst Du noch etwas tiefer mit e2fsck über den alternativen Superblock am Linux PC eine Wiederherstellung versuchen. Siehe < man e2fsck >

    Eh was? Ich brauchte eine halbe Stunde um herauszufinden, wie ich die Sdkarte umounted bekomme :D
    Also ich traue mich da noch nicht recht was zu machen, bevor mir das Image hinüber ist :angel:

    Kann da jemand helfen? :helpnew::D

    Zitat

    Und Du hast echt 15 Minuten vor dem Bildschirm gesessen, um das Bild aufzunehmen?

    Nicht direkt :D

    Bin aber jetzt seit gestern die ganze Zeit dabei - und andere kriegen dafür die Nachtschicht bezahlt :D :bravo2: :D :D :D -,
    weil ich damals nur auf den Pi Nextcloud und alles eingerichtet habe und ihn dann erstmal laufen lassen wollte, bis die Cloud dann mal voll sein wird; hätte ich mich nur noch mit dem mounten eines USB Sticks in Linux beschäftigen müssen, damit ich mehr Platz in der Cloud habe.

    Da das noch nicht der Fall war, war letzte Nacht Linux ein schnelldurch(lese)lauf. Aber hey schon wieder eine ganze Menge gelernt.

    Zum Thema SD Defekt: Ich habe da eine Musikbibliothek mit ein paar Mixes, diese habe ich dann über den Audio Player von Nextcloud (Weboberfläche) gestreamt. Können dadurch die großen Leseraten erfolgt sein, wordurch ein Defekt geschehen ist? Letzten Endes habe ich vor dem ersten Ausfall noch 2 Videos gemacht, die dann hochgeladen worden sind. Diese sind jeweils 144,4 MiB groß.

    Dabei darf man nicht vergessen, dass Nextcloud noch mit redis und solr zusammenarbeitet. Das sind jetzt aber nur alles Spekulationen meinerseits. Ich denke, dass man das schon irgendwie noch hinbekommen kann. Beim ersten mal hat der Pi es schließlich auch selbst von alleine gelöst :)

    LG & :danke_ATDE:


    PS: Jetzt nochmal zurück zur VM (Virtualbox). Ich kann dort jedes x beliebige System installieren und dem jeweiligen System, dem Hauptsystem zugrundeliegenden Rescourcen zur Verfügung stellen. Das habe ich soweit auch mit dem Raspian Image hinbekommen. Ich habe sogar den Zugriff auf die SD Karte hinbekommen, ja sogar den root0 Ordner. Dennoch lag der Hauptgrund mich hier anzumelden, um in Erfahrung zu bringen, wie ich den Pi nicht vom Pi starte (kann ja jeder :P :D), sondern den Pi auf den Computer starte. Also wie schaffe, ich es, dass die Virtualbox mir hier Nextcloud, Apache, Mysql und was da alles dazugehört mit bootet? So könnte ich gerade in der Virtuellen Box die grenzen des Systems austesten, ohne es wirklich zu overheaten oder gar einen großen Zeitverlust zu erleiden (ist halt arm). Das man umgekehrt einen Computer im Raspian (in einer VM) nicht starten kann ist mir klar (evtl. vlt pfense, aber ist ja auch egal, hatte ich nur mal irgendwo hier im Forum gelesen), weil dem Pi ja eindeutig die Rescourcen fehlen, um überhaupt eine Intel oder AMD Awendung zu starten. pgloor sagt, dass es nur mit Qemu (emulierung der ARM Architektur) klappen könnte, dennoch frage ich mich mittlerweile wo überhaupt der Unterschied zwischen emulieren und virtualisieren liegt. OT: Es gibt ja auch Android Emulatoren, habe ich dabei nicht irgendwie das gleiche mit Debian gemacht in der Virtuellen Box? (Musste ich ja auch installieren). Ich bin diesbezüglich mittlerweile mehr als confused und durcheinander. Ich hoffe zumindest, dass das zumindest einer hier nachvollziehen kann. :D

    Einmal editiert, zuletzt von xXSTrikeXx (7. Juni 2017 um 21:56)

  • Hallo xXSTrikeXx,


    Als ich den Stecker zog und erneut zum booten aufforderte, startete er normal bis zum blackscreen und dann ging wieder nur noch die rote Lampe.


    Schaltest Du den Raspberry Pi immer auf diese Weise aus? Wenn ja, dann wundern mich Deine Probleme jetzt nicht mehr. In dem Moment, in dem die grüne LED leuchtet, werden Daten von der SD-Karte gelesen bzw. auf die SD-Karte geschrieben. Wenn Du den Stecker ziehst, während gerade geschrieben wird, dann wird dadurch das Dateisystem beschädigt.
    Manchmal kann man den Schaden mit fsck beheben - oftmals hilft das aber nicht mehr.

    Wenn Du der Ansicht bist, dass der RPi "hängt", dann investiere in einen Taster, der an die GPIOs gehängt wird und ein sicheres Herunterfahren ermöglicht. Eines der vielen Beispiele findest Du z.B. hier.

    Höchstwahrscheinlich hilft hier nur noch eine Neuinstallation, da Du Dir offensichtlich durch zu häufiges Steckerziehen irreparable Schäden am Dateisystem zugezogen hast.

    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.

    2 Mal editiert, zuletzt von Andreas (18. Oktober 2017 um 00:13)

  • Nein eigentlich nicht, aber da blieb mir in dem Moment nichts anderes übrig. Und vorhin, nunja ich war verwundert, warum der Bildschirm schwarz ist und er genau im gleichen Intervall blinkt. Schließlich sah es nicht so aus, als ob er Schreib und Lesezugriffe gemacht hat, sonders es ein Statuscode war. Ich habe das ganze eine halbe Stunde lang beobachtet, bevor mir der Geduldsfaden erneut gerissen ist. Ich werde das Empfohlene dennoch erneut in der VM ausprobieren. Wünscht mir Glück :)


    Edit:

    Ich habe nun sdb5-7 umountet und alle 3 Partitionen mit fsck gecheckt. Es liegt anscheinend wirklich nur an der BootPartition. Als ich mit fsck -V /dev/sdb6 probierte, sagte er mir, dass Bits beschädigt seien und ich habe die 1 für repair geklickt. Letzen Endes hat er "leaving filesystem unchanged". Warum auch immer. Der Flag -fy brachte wieder Abhilfe und das gleiche Szenario von vorhin beginnt. Pi "Starting NTP server". Erst leuchtete die Lampe nur Rot, mittlerweile blinkt sie auch alle 2 Sekunden hört aber zwischendurch wieder auf, was vorhin nicht war. Jetzt blinkt sie wieder und nunja der Bildschirm ist ja noch an, ich denke ich werde es einfach mal abwarten :)

    Badblocks brachte nichts neues.

    Einmal editiert, zuletzt von xXSTrikeXx (7. Juni 2017 um 22:38)

  • Hallo xXSTrikeXx,


    Erst leuchtete die Lampe nur Rot, mittlerweile blinkt sie auch alle 2 Sekunden hört aber zwischendurch wieder auf, was vorhin nicht war. Jetzt blinkt sie wieder und nunja der Bildschirm ist ja noch an, ich denke ich werde es einfach mal abwarten :)


    Von welcher "Lampe" redest Du?

    Solltest Du die rote PWR-LED meinen: Diese leuchtet durchgehend, wenn die passende Spannung anliegt. Wenn sie blinkt oder gar mal für ein paar Sekunden erlischt, dann liefert das Netzteil (zeitweise) eine zu geringe Spannung.

    Meinst Du die grüne ACT-LED? Diese leuchtet nur bei I/O-Vorgängen bzgl. SD-Karte.

    Bildschirm ist an bedeutet was? Steht was auf dem Bildschirm? Text z.B. oder so?

    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 (7. Juni 2017 um 23:07)

  • Hallo Andreas,

    du machst mich auf einen schwerwiegenden Fehler aufmerksam meinerseitz: Die Nichtbeachtung des Bildschirmschoners!
    Also habe ich vorhin wirklich den Fehler gemacht ihn auszumachen, währen die grüne Lampe blinkt.

    Jedenfalls ist wie vorhin (Rot immer am dauerbrennen, war noch nie aus) und die grüne Lampe blinkt alle 2 Sekunden. Ja ich meine die ACT-LED - mit was anderem habe ich mich noch nicht beschäftigt, außer Linux mit ssh halt :D -, sodass USB Ports (aktuell nicht, muss von Zeit zu Zeit den Bildschirmschoner ausmachen) und alle GPIO Pin´s quasi unbenutzt sind.

    System-fsck besagt, dass der Ordner root0 Ok ist und somit sind meine Daten nicht beschädigt. Ich kann ja auch ganz normal zugreifen mit der VM. Alles kein Problem.

    Ich warte noch etwas und poste später ein neues Foto. Er sagt mir jedenfalls was von einem IO Fehler und dass er jetzt erstmal die tmpfiles ließt und die direktionsblöcke durchgeht -soweit ich es verstehe- :D

  • Hi xX...

    In Zeile 1 (39.666648) noch immer :56 Detectet aborted Journal
    Und jetzt werden ganz andere iNodes als korrupt angezeigt, als weiter oben.
    fsck gibt den Fehlercode als Exitcode dem aufrufenden Programm zurück
    Nur fsck -V zeigt den gesamten Vorgang auf der Konsole an.
    fsck ist aber auch nur ein Front-End für alle verschiedenen File System Checker. Triff es auf ein Ext4-Filesystem, wird das Programm für Ext4 aufgerufen.
    Mach noch 2 mal ein fsck -aV auf die Ext4 Partition. (-a repariert, soweit ohne Intervention möglich, -V zeigt alles an, siehe man fsck)
    Und wenn das nichts hilft, musst Du eine Stufe tiefer gehen.
    Mit < apropos ext4 > werden Dir einige Werkzeuge dazu angezeigt.

    Was mit der Partition 6 (boot-FAT32) jetzt los ist, weiss ich nicht

    [Wird bei Bedarf fortgesetzt]


    Servus !

    RTFM = Read The Factory Manual, oder so


  • Mach noch 2 mal ein fsck -aV auf die Ext4 Partition. (-a repariert, soweit ohne Intervention möglich, -V zeigt alles an, siehe man fsck)
    Und wenn das nichts hilft, musst Du eine Stufe tiefer gehen.
    Mit < apropos ext4 > werden Dir einige Werkzeuge dazu angezeigt.

    Was mit der Partition 6 (boot-FAT32) jetzt los ist, weiss ich nicht

    [Wird bei Bedarf fortgesetzt]
    Servus !

    Brachte auf der VM (diesmal Debian) nicht wirklich was- Sogar mit dem Flag -faV nichts.

    Ich habe folgendes Werkzeug einfach mal ausprobiert:

    resize2fs: Ungültige magische Zahl im Supervblock, bei dem Versuch, /dev/sdb6 (boot) zu öffnen
    = Kein Gültiger Superblock.

    Bei den anderen war wieder alles ohne Probleme.
    fsck.ext4dev sagt mir das gleiche (auch nur bei sdb6 [boot]).


    Da der die Partition nichtmal in Debian (VM) lesen kann (aufrufen kann ich sie im Dateiexplorer und sehe dort auch die einzelnen Dateien, aber fsck kann damit nicht anfangen) denke ich mal nur, dass ich mir die Bootsequenz zerschossen habe. Wie stelle ich die her?
    Backup machen, OS neuinstallieren und dann altes root0 mit neuem root0 überschreiben und weitermachen oder was wäre das Klügste für mich? :)

    LG und :danke_ATDE: 4 :helpnew:

    Einmal editiert, zuletzt von xXSTrikeXx (8. Juni 2017 um 13:33)

  • Hoppala.
    Du kannst ein FAT (DOS) Dateisystem nicht mit EXT2/3/4 Mitteln bearbeiten.

    < apropos fat > zeigt Dir die Werkeuge dazu

    fsck.fat -av für Partitipm 6 (boot-Partition FAT32) oder fsck.fat -pv

    fsck.ext4 = e2fsck -av für Partition 7 (root P. ext4) oder e2fsck -pv


    Servus !
    Automatisch zusammengefügt:
    @ dass ich mir die Bootsequenz zerschossen habe.
    Nein, hast Du nicht, sonst würde beim Booten nicht auf P7< / > zugegriffen.

    RTFM = Read The Factory Manual, oder so

    Einmal editiert, zuletzt von RTFM (8. Juni 2017 um 14:19)

  • Code
    root@debian:/home/timo# fsck.ext4 -av /dev/sdb7
    root0: sauber, 255108/866656 Dateien, 3020113/3464192 Blöcke
    root@debian:/home/timo# fsck.ext4 -pv /dev/sdb7
    root0: sauber, 255108/866656 Dateien, 3020113/3464192 Blöcke
    root@debian:/home/timo#

    LG

  • /dev/sdb6 und /dev/sdb7 waren aber schon unmounted (ausgehängt) ?

    FAT32-P6
    -2793472 hidden sectors
    -135168 sectors total
    -Reclaiming unconnected clusters.
    finde ich etwas merkwürdig, siehst Du auf der P6-FAT durchnummerierte Files (...0001, ...0002, ...0003 usw.)
    umount /dev/sdb6
    badblocks -sv /dev/sdb6 fehlerfrei ?

    EXT4:
    sync
    umount /dev/sdb7
    dumpe2fs -h /dev/sd7
    aus der Ausgabe brauchst Du für später: First Block und Blocksize. Bitte notieren.


    Servus !

    RTFM = Read The Factory Manual, oder so

    Einmal editiert, zuletzt von RTFM (8. Juni 2017 um 17:48)


  • /dev/sdb6 und /dev/sdb7 waren aber schon unmounted (ausgehängt) ?


    Ja waren.


    FAT32-P6
    finde ich etwas merkwürdig, siehst Du auf der P6-FAT durchnummerierte Files (...0001, ...0002, ...0003 usw.)
    umount /dev/sdb6
    badblocks -sv /dev/sdb6 fehlerfrei ?


    Soweit ich sehe nur bcm2708 bis 2710-rpi-x...
    Davon halt 4 Dateien.

    Code
    /dev/sdb5        30M    3,6M   25M   13% /media/timo/SETTINGS
    /dev/sdb7        13G     12G  1,1G   92% /media/timo/root0
    /dev/sdb6        66M     21M   46M   31% /media/timo/boot
    root@debian:/home/timo# umount /dev/sdb6
    root@debian:/home/timo# badblocks -sv /dev/sdb6 
    Von Block 0 bis 67583 wird geprüft
    Nach defekten Blöcken suchen (Nur-Lesen-Modus):  0.00% erledigt, 0:00 verstrichenerledigt                                             
    Durchgang beendet, 0 defekte Blöcke gefunden. (0/0/0 Fehler)
    root@debian:/home/timo#


    EXT4:
    sync
    umount /dev/sdb7
    dumpe2fs -h /dev/sd7
    aus der Ausgabe brauchst Du für später: First Block und Blocksize. Bitte notieren.


    Servus !


    Servus!

    Fettes Edit!
    Ich glaube mir ist dort noch ein Fehler unterlaufen:

    drwx------ 3 timo timo 16384 Jan 1 1970 boot
    drwxr-xr-x 22 root root 4096 Feb 22 23:01 root0
    drwxr-xr-x 5 root root 1024 Mai 24 13:33 SETTINGS

    ls -l von media/timo/

    Also ich habe damals ein boot_delay=1 hinzugefügt, damit ich probieren konnte ein Problem zu lösen und ich den Text auch lesen konnte :D
    Kann das jemand mit seinem Pi vergleichen? :)

    Einmal editiert, zuletzt von xXSTrikeXx (8. Juni 2017 um 20:10)

Jetzt mitmachen!

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