Bootet nicht mehr von ssd

  • Wenn schon die System-Grundkonfiguration "plötzlich" scheitert, deutet das auf einen Ladefehler der von der Bootpartition (SD - P1 FAT32 ) geladenen Dateien hin.


    Funktioniert das Booten ohne SSD mit einer SD, auf der sich auch die Root Partition noch auf der SD befindet ?



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Das Problem (oder ein ziemlich ähnliches) hatte ich auch.:conf:

    Bei mir lag trat es nach einem Update auf :@ - hab dann ein neues Image gezogen und alles neu installiert.

    In einem anderen Post ist ein Beitrag verlinkt, der aufführt, dass es bei den Raspi 4 "unterschiedliche Qualitäten" gab, und einzelne Geräte mit speziellen Einstellungen in den Firmwares nicht (mehr) klarkommen.

    Wenn das bei dir die Ursache sein könnte: Sofern möglich, ein aktuelles Update des Kernels ziehen und einspielen (wenn du noch ein funktionierendes Raspbian auf der SD hast).

    ---

    we all live in a yellow subroutine...

  • Quote

    dass es bei den Raspi 4 "unterschiedliche Qualitäten" gab,

    ( im Internet steht leider viel Ungeprüftes)

    das glaube ich erst, wenn die gleiche SD-Karte bei 2 RPi 4B mit dem einen einen Fehler hervorruft und mit dem anderen nicht.

  • Der Grund steht doch in Bild 1 ganz unten:


    Code
    ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2) ]--- 

    Das heißt doch nichts anderes, als dass Deine SSD (samt root Filesystem) nicht gemountet werden kann. Und das wiederum kann simple Gründe wie einen falschen Eintrag in der /boot/cmdline.txt oder auch Probleme mit dem Filesystem auf der SSD selbst haben. Beides musst Du kontrollieren. Ich tippe eher auf ersteres.



    Beitrag verlinkt, der aufführt, dass es bei den Raspi 4 "unterschiedliche Qualitäten" gab, und einzelne Geräte mit speziellen Einstellungen in den Firmwares nicht (mehr) klarkommen.

    Quelle? Das halte ich für ein Gerücht.

  • Muss man sich aber durchwühlen...

    Hmmm. Solche „Vermutungen“ solltest Du belegen können. Ich hab’s nur kurz überflogen, finde jedoch nur das genaue Gegenteil (hier/hier) .

  • Erstens:

    Malz1902 kannst du mal deine cmdline.txr posten? Vielleicht hat sich die geändert? (ein vergessesen "2" hinter /dev/sda kann echt nerven...)


    Zweitens:
    Hi STF

    schön, dass du dir den Link reingezogen hast. Aber, und ich hab bewußt geschrieben: "durchwühlen" - ich meinte das auch nicht ohne Grund so. :angel: (ich glaub, ich hab gestern über zwei Stunden wegen meinem Bootproblem gegoogelt, und die meisten Infos aus der Ecke gezogen (zu RPi gibt es ja leider nur wenige wirklich kompetente Quellen).

    Im Großen und Ganzen geht es in dem Thread und seinen Links auf andere Posts um Probleme, die besonders beim Übertakten einzelner RP4 auftraten und den Fixes an diverses Teilen der Firmware, um das wieder in den Griff zu kriegen.

    Und irgendwo in den vielen Beträgen erklärt einer von den Jungs ("jamesh", Raspberry Pi Engineer & Forum Moderator)

    in:

    (https://www.raspberrypi.org/fo…65a2c17708a7a389#p1599805)

    Quote

    This will be independant of revision or age. All chips come out of the fab with slightly different properties. There's a bell curve of those properties, a few are very close to the edges of the curve, and looks like the power management strategy is slightly too aggressive for those devices right at the limits. This applies to all the chips on the board, not just the SoC, and it could be a combination. Unfortunate we didn't see anything in testing, but this likely means it's very rare. Note, these are my personal thoughts on the matter, not an official Pi statement, and I may well be wrong!


    ich nehm das mal als eine sehr seriöse Quelle.


    Und aus den ganzen Threads heraus kann man ableiten, dass die Jungs in der Firmwareentwicklung nach bestem Wissen und Gewissen auch mal eine raushauen, bei der ein (im Sinne von im ppm-Bereich oder so) RP4 nicht mehr mitmacht - ob übertaktet oder nicht...

    Dann zieht man eben ein neues Image und setzt neu auf oder investiert ein vielfaches an Zeit für eine exakte Fehleranalyse (je nach Aufwand der bereits durchgeführten Anpassungen der eigenen Raspi-Installation).

    Ich persönlich setz meine Systeme gerne mal neu auf und hab dann Ruhe.

    In meinem Fall war das die Lösung (nicht die cmdline.txt, bei mir ging nix mehr, weder SD noch SD/USB).

    ---

    we all live in a yellow subroutine...

  • sehr seriöse Quelle.

    Du hast genau das nochmal zitiert, was hinter meinem ersten "hier" steckte. Das ist zwar die Meinung eines Ingenieurs der Foundation, jedoch explizit NICHT die offizielle Auskunft der Foundation selbst, schreibt er ja auch selbst.


    Und dann steht da nur altbekanntes von Fertigungstoleranzen - und das wiederum hat nichts, aber auch gar nichts mit irgendwelchen Revisionen etc. zu tun. Das ist einfach so. OK, btt bitte. Warten wir mal als erstes auf die cmdline.txt.

  • Bei mir exakt dasselbe Problem, habe mehrmals das Image neu installiert. Beim ersten Start hat es funktioniert, ist aber nach ein paar Minuten unter Belastung abgeschmiert und dannach war es wie beim Kollegen hier beschrieben. Ich poste einfach mal mein Config und mdline File ;)


    Als auf der sd karte war hatte ich folgendes getan:

    1. Frisches Raspbian installiert

    2. sudo apt-get -y update && sudo apt-get -y upgrade && sudo apt autoremove

    3. https://www.verdrahtet.info/20…ooten-ganz-ohne-sd-karte/




    Config File meiner SSD

    Cmdline meiner SSD

    Code
    pi@raspberrypi:~ $ cat /mnt/ssd/cmdline.txt
    console=serial0,115200 console=tty1 root=PARTUUID=7039decb-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

    Config meiner SD

    Cmdline meine SD

    Code
    cat /boot/cmdline.txt
    console=serial0,115200 console=tty1 root=PARTUUID=06bb2613-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait


    Abschließend noch ein fdisk -l

    vllt kann mir hier jemand helfen.

    UAS mode weiß ich nicht wie ich ihn aktiviere bzw was es ist und overvolt 1 hat nichts bewirkt.


    Vielen dank für euere Hilfe. Top forum

  • Dankesehr :)


    lsusb

    Bus 002 Device 002: ID 152d:578e JMicron Technology Corp. / JMicron USA Technology Corp.

    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub

    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

  • Versuche es mal damit:

    usb-storage.quirks=152d:578e:u console=serial0,115200 console=tty1 root=PARTUUID=7039decb-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait


    MfG


    Jürgen

  • Als CMD file ? Moment ......


    Leider keine Veränderung. Er bringt auch ewig viele Block Fehler als wäre die Platte defekt. Aber ohne SD könnte er ja nicht booten wenn die SSD defekt wäre. .....

    Edited once, last by hyle: Ein Beitrag von DrBenji mit diesem Beitrag zusammengefügt. ().

  • aus dem Tutorial ? Doch das hab ich gemacht als der Pi noch über die SD Karte lief. Meinst du das war der Fehler ?


    Ich probiere es gerne nochmal bei einem Junfreulichen Raspberry OS

  • So langsam nervt JMicron.

    Achja, ich schließe mich hyle an, könnte ein Fehler sein.


    Mach die Änderung mal rückgängig,

    danach versuch mal zusätzlich zur Änderung in der /boot/cmdline.txt folgendes:

    sudo nano /etc/default/rpi-eeprom-update

    Hier in der Datei ersetze das „Critical“ durch „Stable“


    Anschließend ein sudo rpi-eeprom-update -a

    Wenn Du jetzt ein sudo rpi-eeprom-update

    eingibst sollte so etwas herauskommen:

    Code
    BCM2711 detected
    Dedicated VL805 EEPROM detected
    BOOTLOADER: up-to-date
    CURRENT: Mo 15. Jun 13:36:19 UTC 2020 (1592228179)
    LATEST: Mo 15. Jun 13:36:19 UTC 2020 (1592228179)
    FW DIR: /lib/firmware/raspberrypi/bootloader/stable
    VL805: up-to-date
    CURRENT: 000137ad
    LATEST: 000137ad

    Mit dieser Konfiguration starten meine (ASMedia) Adapter.

    MfG


    Jürgen