Raspberry bootet nicht mehr nach sudo poweroff

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Nabend!

    Ich habe ein Problem. Mein Pi bootet nicht mehr. Der Pi lief komplett auf einer SSD (ohne SD). Das ganze passierte, nachdem ich ihn sauber per sudo poweroff herunter gefahren habe und vom Strom getrennt habe. Wenn ich den Pi nun ans Stromnetz packe, bilnkt die grüne LED 4 mal kurz und 4 mal lang. Immer im Wechsel. Laut Belegung: unsupported board type. Was immer das bedeutet.

    Ich habe die SSD mal an meinen Laptop angesteckt. Dabei ist aufgefallen, dass augenscheinlich auf der boot Partition einige Dateien fehlten (siehe Bild). Weiterhin scheint sich nun die SSD nicht mehr aushängen zu lassen (Meldung 1 Vorgang steht noch aus).

    Mein System:

    Raspberry Pi 4 mit 4 GB

    Rasbi OS 64 bit light Bullseye Version von Sep. 22

    alles per sudo apt-get update und sudo apt-get upgrade aktuell gehalten, der Bootloader ebenfalls.

    Mein Vorgehen bez. SSD:

    Raspi OS direkt auf die SSD geflasht.

    Danach rootfs per Gparted verkleinert und mehrere weitere Partionen erstellt.

    Danke für Eure Hilfe!

  • Zur hilfreichsten Antwort springen
  • Im Nachhinein wirds schwierig, weil die Dateien zum aktuellen Kernel passen müssen. D.h. entweder hast Du Glück und Du kannst die noch downloaden oder nicht.

    Eine nachhaltige Lösung wäre regelmäßig Backups zu erstellen damit man bei so einem Problem die Dateien einfach zurückkopieren kann. Um nicht zu schreiben: Kein Backup, kein Mitleid! ;)

  • von einer gesunden boot Partition von meinem zweiten System (Kernel, Versionen dürften gleich sein) herüber kopiere?

    Versuch macht klug, ABER ich würde nur die fehlenden Dateien rüber kopieren!

    also du meinst ein Backup der boot Partition, richtig?

    Ich meinte nachdem man ein System aufgesetzt hat, sollte man wenigstens einmal pro Woche Backups vom kompletten System erstellen lassen. Ob das nun ein Backup des kompletten Imges ist oder ein Backup der geänderten und neuen Datein per sync ist erstmal egal und eine Frage des Speicherplatzes des Quell und Ziellaufwerks.

    Mir ist klar, dass "Kein Backup, kein Mitleid!" sehr hart klingt, aber aus Fehlern lernt man oder sollte man zumindest.


    Vergessen... Du kannst die Dateien auch per Windows kopieren. Die /boot ist ja eine Windows Partition, da spielen Dateirechte oder Eigentümer kaum eine Rolle.

    - Der Weg zur Erkenntnis: Wie frage ich nach Hilfe? | Zur Erinnerung: Forenregeln | Quatsch und Tratsch: Plauderecke -

    Einmal editiert, zuletzt von hyle (21. Januar 2023 um 22:34) aus folgendem Grund: Ein Beitrag von hyle mit diesem Beitrag zusammengefügt.

    • Hilfreichste Antwort

    Kopiere dann doch einfach die noch vorhandenen Datein auf der fehlerhaften SSD auf den Laptop, damit die nicht verloren gehen und kopiere die fehlenden Dateien von dem anderen RPi auf die SSD.

    Am Laptop kannst Du das ja alles mir den Maus schubsen. ;)

  • Moin!

    Es war von Erfolg gekrönt! Ich habe einfach von einer gesunden boot Partition alle Dateien kopiert. Diese habe ich dann auf die fehlerhafte boot Partition der SSD kopiert (vorhandene Dateien überspringen). Und er hat sofort wieder gebootet!

    Also erledigt! :)

    Allerdings stellt sich natürlich die Frage, warum denn überhaupt die Dateien gelöscht wurden. im Rahmen des möglichen Updates...

  • Allerdings stellt sich natürlich die Frage, warum denn überhaupt die Dateien gelöscht wurden. im Rahmen des möglichen Updates...

    Mir auch. Ich update regelmaessig meine Raspberries und habe sowas noch nicht erlebt.

    hyle Du hast geschrieben dass das wohl schon oefter im Forum berichtet wurde. Hast Du ein Pattern erkennen koennen warum das passiert?

  • Du hast geschrieben dass das wohl schon oefter im Forum berichtet wurde. Hast Du ein Pattern erkennen koennen warum das passiert?

    Ich würde (aus der Erinnerung heraus) behaupten, dass es alles Updates waren, bei denen der Kernel auch betroffen war. :conf:

  • Hallo zusammen,

    Ich würde (aus der Erinnerung heraus) behaupten, dass es alles Updates waren, bei denen der Kernel auch betroffen war. :conf:

    da kommen viele Ursachen zusammen.

    In der boot-Partition werden bei jedem Kernel-Update die alten Kernel gespeichert. Irgendwann ist die Partition voll. Dann funzt ein weiterer Kernel-Update nicht mehr.

    Ich habe auch das Script in Verdacht, dass ein Kernel-Update ermöglicht. Das Script läuft ungefähr so ab:

    • Herunterladen von Dateien
    • Entpacken
    • neue Module erzeugen (inaktiv)
    • aktuelle Module umbenennen (inaktiv)
    • neue Module aktiv setzen
    • Neustart (erst dann werden die neuen .elf-Dateien verwendet)

    Wenn in dem vor-vor- und vor-letzten Schritt irgendwas schief läuft, hat man ein dysfunktionales System.

    Ich habe auch den Verdacht, dass dieses "Kernel-Update-Script" möglicherweise diesen Vorgang nicht immer vollständig unterstützt. Diejenigen, die als erste solch ein Script (ungeahnt) nutzen, laufen Gefahr, dies als Beta-Nutzer zu tun.

    Stunden später erst läuft dieses Script dann richtig. Das bedeutet, dass ein frühzeitig gestarteter fehlerhafter Kernel-Update Stunden später nicht nehr reproduzierbar ist.

    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.

  • Ich kenne das Script nicht aber normalerweise macht man einen Update so, dass man parallel zum alten Stand den neuen Stand aufsetzt und dann moeglichst mit einem oder, wenn es nicht anders geht, ein paar Befehlen von alt auf neu umschaltet - also moeglichst schnell und die Zeit in dem das System inkonsistent ist moeglichst kurz haelt. Wenn dann ein OutOfDisk auftritt sollte es sehr unwahrscheinlich sein dass das in dieser kurzen Zeitspanne auftritt. Deshalb wundert mich

    aktuelle Module umbenennen (inaktiv)
    neue Module aktiv setzen

    denn ein Umbenennen dauert definitiv laenger und ich vermute auch das aktiv setzen der Module. Mir scheint da gibt es irgendwelche Randbedingungen die dazu zwingen das so zu tun denn die Raspberry Developer sollten eigentlich Profis sein.

    Man hat ja mit Buster die Bootpartition auf 200M vergroessert - vermutlich auch aus diesem Grund.

    Was mich wundert dass ich noch nie in diese Problem reingelaufen bin und bei mir laufen 4 Raspis 7/24 die regelmaessig von mir manuell updated werden :conf:

Jetzt mitmachen!

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