[Tutorial] Eine unendliche Geschichte: Raspberry 4B und USB-Boot

  • Letzte Änderung: 12.02.2022 Letztes Update in Fett und Rot

    Dieses Tutorial ist noch nicht ganz fertig, ich muss noch ein paar Kapitel nachtragen.

    Ein weiterer Anlaufpunkt sind die Seiten von James A. Chambers:

    https://jamesachambers.com/raspberry-pi-4…d-flash-drives/

    https://jamesachambers.com/new-raspberry-…ork-boot-guide/

    Noch ein Hinweis: Bitte kein sudo rpi-update ausführen.

    Damit wird ein Entwicklerkernel installiert, der ziemlich merkwürdige Effekte haben kann,

    man sucht sich manchmal einen Wolf bei der Fehlersuche.

    Es fehlt noch das Resize auf volle Plattengröße, das Recovery und warscheinlich noch einiges mehr.

    Also ein erster Entwurf.

    1. Kapitel Vorbereitung

    2. Kapitel Updaten übers Betriebssystem

    3. Kapitel Updaten über die SD-Karte

    4. Kapitel Von der SD-Karte auf die SSD

    5. Kapitel Bootloader Konfiguration ändern

    6. Kapitel Fehlerhinweise und Recoveryguide

    7. Das Geheimnis der leeren MicroSD-Karte

    8. Wenn die Partition /boot leer ist

    9. Die Installation eines OS mit leerer SD-Karte

    Nachdem es sehr viele Schwierigkeiten mit dem USB-Boot des RaspberryPi 4B gibt

    habe ich mal zusammengefasst was man tun kann, um den Start von SSD hinzubekommen.

    1. Vorbereitung

    Zuerst benötigt man Buster auf eine SD-Karte.

    Auf der Seite: https://downloads.raspberrypi.org/ findet man die Ordner

    für 32Bit:

    raspios_lite_armhf/images/

    raspios_armhf/images/

    raspios_lite_armhf/images/

    und für 64Bit (beta):

    raspios_lite_arm64/images/

    raspios_arm64/images/

    Ein Image davon auf die SD-Karte flashen und ohne SSD erstmal booten.

    Ein kleines bißchen einrichten (Sprache und Tastatur) und dann erstmal ein:

    sudo apt update && sudo apt full-upgrade

    Warscheinlich ist dann erstmal ein reboot fällig.

    2. Updaten übers Betriebssystem

    Dann überprüft ihr ob der Bootloader aktuell ist:

    Code
    $ sudo rpi-eeprom-update
    BCM2711 detected
    Dedicated VL805 EEPROM detected
    BOOTLOADER: up-to-date
    CURRENT: Do 16. Apr 17:11:26 UTC 2020 (1587057086)
    LATEST: Do 16. Apr 17:11:26 UTC 2020 (1587057086)
    FW DIR: /lib/firmware/raspberrypi/bootloader/critical
    VL805: up-to-date
    CURRENT: 000137ad
    LATEST: 000137ad

    Dieser ist es nicht, er sollte auf "stable" (hier "critical") stehen, also müsst ihr ihn aktualisieren.

    Dazu muss der Eintrag in einer Datei geändert werden:

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

    Dort ändert ihr die Zeile von:

    FIRMWARE_RELEASE_STATUS="critical"

    in

    FIRMWARE_RELEASE_STATUS="stable"

    und abspeichern.

    Der Bootloader wird aktualisiert, wenn ihr folgenden Befehl ausführt:

    sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-07-31.bin

    oder

    sudo rpi-eeprom-update -a

    Anmerkung: Der Name des Bootloaders "pieeprom-2020-07-31.bin" könnte sich nach diversen Upgrades geändert haben.

    Jetzt wäre ein weiteres reboot angebracht und danach solltet ihr das Ergebnis überprüfen:

    Code
    $ sudo rpi-eeprom-update
    BCM2711 detected
    Dedicated VL805 EEPROM detected
    BOOTLOADER: up-to-date
    CURRENT: Fr 31. Jul 13:43:39 UTC 2020 (1596203019)
    LATEST: Fr 31. Jul 13:43:39 UTC 2020 (1596203019)
    FW DIR: /lib/firmware/raspberrypi/bootloader/stable
    VL805: up-to-date
    CURRENT: 000138a1
    LATEST: 000138a1

    Wie man sieht, ist jetzt der Bootloader "up-to-date" und steht auf "stable".

    Jetzt kommt noch ein Check ob die Bootkonfiguration richtig ist:

    Die Boot-Order findet man hier: https://www.raspberrypi.org/documentation/…oader_config.md

    Ab jetzt ist der Raspberry für den USB-Boot vorbereitet.

    Nun kommt der nächste Schritt:

    Flasht dasselbe Image auf die SSD, entfernt die SD-Karte und versucht von SSD zu booten.

    Sollte das klappen, müßt ihr Buster neu einrichten und ganz wichtig:

    Wichtig: Den Eintrag: /etc/default/rpi-eeprom-update auf "stable" auf der SSD überprüfen.

    3. Updaten über die SD-Karte

    Es geht auch einfacher wie von PcDoc78 in diesem Beitrag vorgeschlagen.

    Alle Releases findet man hier: https://github.com/raspberrypi/rpi-eeprom/releases

    Dazu muss man lediglich den Inhalt der Zip-Datei auf eine VFAT-formatierte SD-Karte schreiben.

    Den Raspberry herunterfahren, ausschalten und die SD-Karte mit dem Betriebssystem (BS) entnehmen.

    Dann die VFAT SD-Karte einsetzen und den Raspberry wieder einschalten.

    Die grüne LED fängt kurz darauf an zu leuchten und wenn alles geklappt hat schnell zu blinken.

    Jetzt kann man den Raspberry wieder ausschalten und die BS SD-Karte wieder einsetzen.

    Wenn man dann den Eintrag /etc/default/rpi-eeprom-update auf "stable" ändert,

    kann man sich dann über die Meldung: BOOTLOADER: up-to-date freuen.

    4. Von der SD-Karte auf die SSD

    Ich habe gerade einen weiteren Weg probiert um das Betriebssystem von der SD-Karte auf die SSD zu bekommen.

    Zuerst das Updaten des Bootloaders (Kapitel 2)

    Dann nehme man einfach den SD Card Copier des Betriebssystems.

    Von Gerät kopieren: Hier die SD-Karte auswählen

    Auf Gerät kopieren: Hier die SSD oder USB-Stick auswählen

    New Partition UUID ankreuzen

    Und dann auf Start klicken.

    Das wars, das Programm kopiert die SD-Karte auf die SSD, passt nebenbei die /boot/cmdline und die /etc/fstab

    auf die neue PARTUUID an und resized die root-Partition.

    Wesentlich schneller und einfacher als meine bisherige "Krücke".

    Das klappte sogar aus dem laufenden Betriebssystem (Buster64, light mit Mate-Desktop) heraus.

    Und bootete sofort von SSD. Ich würde sagen, DAU-Geeignet, einfacher geht es kaum.
    Eine weitere Beschreibung findet sich hier: RE: Raspberry Pi4 4GB SSD Boot

    5. Bootloader Konfiguration ändern

    In einigen Fällen ist es nötig die Konfiguration zu ändern.

    Wie sie aussieht bekommt man mit vcgencmd bootloader_config heraus:

    Dieser Raspberry wird beharrlich auf seiner SD-Karte bestehen, warum steht in der Zeile BOOT_ORDER=0x1

    Wenn man die Dokumentation von Raspberry.org genauer durchliest, findet man eine Beschreibung der BOOT_ORDER:

    Code
    Wert Mode    Beschreibung
    0x1  SD CARD Booten von der SD-Karte (oder eMMC des Compute Modul 4)
    0x2  Network Booten übers Netzwerk
    0x3  USB DEV USB device boot - Doku dazu auf Github (https://github.com/raspberrypi/usbboot)
    0x4  USB MSD USB mass Storage - Booten von einer USB-SSD/HDD
    0xe  STOP    Stop und Fehleranzeige
    0xf  RESTART Starte mit dem ersten Eintrag im BOOT_ORDER

    (bei Fehlern möge man mich korrigieren)

    Für das Booten von SSD/HDD ist für die BOOT_ORDER=0x4 wichtig,

    und dafür gibt es inzwischen einen einfacheren Weg das zu ändern:

    sudo -E rpi-eeprom-config -e

    Bei dem Aufruf wird der Editor nano mit etwa folgenden Inhalt aufgerufen:

    Nun kann den Eintrag auf 0x4 (Booten von USB) oder 0xf41 (erst von SSD, dann von SD) ändern.

    Nano mit Strg + X und j beenden, den Adapter mit SSD/HDD in die USB3-Buchse einstecken und neu booten.

    Das kann man mit sudo rpi-eeprom-update -r wieder rückgängig machen.

    Mittlerweile läßt sich der Bootloader auch über den Raspberry Pi Imager wiederherstellen,

    Unter Misc utility images befindet sich ein Eintrag: Raspberry Pi 4 EEPROM boot recovery

    Getestet habe ich ihn aber nicht.

    Auf der Seite von James A. Chambers findet sich noch mehr zu dem Thema, allerdings in Englisch.

    6. Fehlerhinweise und Recoveryguide

    Erstmal nur in Englisch:

    https://jamesachambers.com/raspberry-pi-4…recovery-guide/

    7. Das Geheimnis der leeren SD-Karte

    kann ich zwar auch nicht lösen, aber der Effekt ist deutlich sichtbar:

    Legende:

    Code
                  Maximal  Mittel Aktuell
    CPU Load 1min  93.0 %  16.0 %   8.0 % 
    CPU Load 5min  81.0 %  15.0 %   6.0 %

    (100% = Load 1.0)

    Einfach die kleinste MicroSD-Karte mit (Gparted) fat32 formatieren und in den Kartenslot stecken.

    Wirkt sogar beim RPi3B(+)

    8. Wenn die Partition /boot leer ist

    Man kann erstmal unter Windows nachsehen, ob die Dateien noch vorhanden sind.

    Das /boot-Laufwerk ist auch unter Windows sichtbar.

    Wenn die Partition leer ist (Bis auf 5-6 Dateien), kann man die Dateien einfach wieder draufkopieren,

    von einem gleichartig installierten Raspberry. Das funktioniert sowohl auf SD als auch auf SSD.

    Das sind die Dateien von /boot, und die sind auch unter Windows sicht- und kopierbar.

    - Hole Dir das aktuelle Image,

    - kopiere das auf eine SD-Karte (Windiskimager/ Raspberry Pi Imager/...)

    - Leg diese SD-Karte ein, boote davon und schließe dann die "defekte" SSD an Deinen PC an

    - kopiere den Inhalt von /boot (SD) nach /media/pi/boot (SSD) (defekt)

    - Wenn die /boot/cmdline.txt und die /boot/config.txt noch drauf sind, möglichst nicht überschreiben.

    Den Teil kannst Du überspringen, wenn die /boot/cmdline.txt noch vorhanden ist

    - boote den Raspberry von SD, schließe die SSD an den Raspberry an (Die SSD sollte dann unter /media/pi/ zu finden sein)

    - ermittel die PARTUUID der SSD mit sudo blkid (warscheinlich /dev/sda*)

    - passe die SSD in der /boot/cmdline.txt an (Die PARTUUID von /dev/sda2)

    Unter Windows sieht man nur die Boot-Partitionen. Man kann alle Dateien von einer funktionierenden SD

    auf die leere Boot-Partition von SD/SSD kopieren. Möglichst nicht die Dateien cmdline.txt und config.txt

    überschreiben.

    Und dann geht es hier weiter

    - RPI herunterfahren, stromlos machen, SD-Karte raus und dann probieren

    Hier mal eine komplette Zeile als Beispiel (Eine Zeile) und nicht übernehmen:

    console=serial0,115200 console=tty1 root=PARTUUID=ea7d04d7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles logo.nologo

    9. Installation eines OS mit leerer SD-Karte

    Diese Ehre gebührt Franjo G

    Franjo G
    11. Februar 2022 um 13:23

    MfG

    Jürgen

    P.S.: Kritik ist erwünscht

  • [Tutorial] Eine unendliche Geschichte: Raspberry 4B und USB-Boot? Schau mal ob du hier fündig wirst!

  • Wenn man es am Ende wieder auf stable ändern muss, ist es dann in der Anleitung nicht falsch herum beschrieben?

    Wenn man Original Buster auf die SSD flasht steht der Eintrag auf "critical".

    Das sollte man nicht vergessen. Ich habe das Wort "wieder" gelöscht, ist warscheinlich jetzt verständlicher.

    MfG

    Jürgen

  • Hi

    Das funktioniert mittlerweile wesentlich einfacher, zumal dieses Tutorial zum Bsp bei Libreelec wegen fehlender Komponenten im BS nicht funktioniert und man den Umweg über eine vollwertige Linux installation wie Raspian erst machen müsste.

    Ab Juni gab es ein Beta-USB-rpi-boot-eeprom-recovery und mittlerweile seit Ende Juli ein stable rpi-boot-eeprom-recovery für USB Boot.

    https://github.com/raspberrypi/rp…020.07.31-138a1

    Dieses wird auf eine Fat32 formatierte mSD entpackt, in den Raspi 4 damit und Spannungsversorgung einschalten.

    Blinkt die grüne LED dann gleichmäßig schnell hintereinander ist das recovery beendet und man kann ganz ohne Umweg über eine mSD Karte gleich auf die Festplatte/ SSD / USB oder was auch immer sein BS Flashen, anstecken und es bootet.:bravo2::bravo2:

    MfG Frank

  • Jürgen Böhm

    Ich glaube, du hast den Befehl "sudo rpi-eeprom-update -a" vergessen, um von der Version "000137ad" auf die "000138a1" zu kommen.

    Ansonsten allet knorke ;)

  • Ich glaube, du hast den Befehl "sudo rpi-eeprom-update -a" vergessen

    Jein, das kann man mit sudo rpi-eeprom-update-a machen, oder wie Jürgen das beschrieben hat mit

    sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-07-31.bin,

    da das pieeprom sich ja schon auf dem Pi befindet unter /lib/firmware/raspberrypi/bootloader//tt]

    Dort sind alle updates vorhanden.

    "beta", critical, stable)

    Das letzte (beta) pieeprom-2020-07-31.bin ist identisch mit dem letzten (stable) pieeprom-2020-07-31.bin

    Das letzte (critical) ist ca. 3 Monate älter pieeprom-2020-04-16.bin

    Update the bootloader

    • From a standard Raspberry Pi OS SD card boot:
      Code
      sudo apt update
      sudo apt full-upgrade
    • As root, edit /etc/default/rpi-eeprom-update and select stable releases.
    • Install the stable version of the bootloader and replace the current configuration settings to enable USB boot. See BOOT_ORDER property if you wish to migrate the configuration by hand.
      Code
      sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin

      Alternatively, use the Raspberry Pi Imager to create a custom SD card from the lastest MSD STABLE image on the releases page.

    • Reboot and check the bootloader version and config:
      Code
      vcgencmd bootloader_version vcgencmd bootloader_config

    Das kommt aufs gleiche raus.

    Oder wie PcDoc78 geschrieben hat mit dem "boot-eeprom-recovery Tool"

    Das wäre in der Tat das einfachste.

    Viele Wege führen nach Rom

  • Da offensichtlich einige User den Unterschied zwischen Pi3a/b(+) und Pi4b nicht verinnerlicht haben, sollte eine kurze Einführung in die Unterschiede vorangestellt werden:

    Auch mit dem "boot-eeprom-recovery Tool" muss zur Zeit die unten genannte Änderung noch durchgeführt werden, um im frisch installierten OS auf "Stable" zu kommen.

    Spoiler anzeigen

    Pi4 V1.1, 4 GB, USB3-Hub, 250 GB SSD, Bullseye 64, Mate-Desktop, SD-Card Extender (ruht)
    Pi3b Pihole (Buster)
    Pi3b, 128-GB-SSD, Buster, mit 10,1" Monitor als MM (ohne Spiegel ;) )
    orangepi zero, ohne Beschäftigung
    Pi 5 4 GB im GeekPi-Gehäuse mit externer SSD (Bookworm)


    Warnung: Raspi und Co. machen süchtig! :)

  • Erstmal herzlich willkommen im Forum.

    Das funktioniert mittlerweile wesentlich einfacher

    Das recovery kannte ich schon, aber das war mir neu, Danke für den Tip.

    Ich werde das Tut vielleicht heute Abend überarbeiten.

    Ich hatte mal versucht eine frühere Version von pieeprom* in recovery.bin umzubenennen

    und dann mit der SD-Karte abzudaten, aber das hatte nicht geklappt.

    Ich glaube, du hast den Befehl "sudo rpi-eeprom-update -a" vergessen

    Es geht wohl beides.

    Ich tüftel noch an einer einfachen Anleitung für das Resize des BS auf der SSD/Festplatte.

    Viele Leute lesen sich Anleitungen nicht mehr durch wenn zuviel Beispielcode und Anweisungen vorhanden sind.

    Obwohl manche Anleitungen relativ einfach sind, man muß sich nur etwas damit beschäftigen.

    Aber das ist schon für manche Leute zuviel der Mühe.

    MfG

    Jürgen

  • Aber das ist schon für manche Leute zuviel der Mühe.

    <Sarkasmus ON> Hat ja bisher einer der Helikoptereltern für sie erledigt </Sarkasmus OFF>

    Spoiler anzeigen

    Pi4 V1.1, 4 GB, USB3-Hub, 250 GB SSD, Bullseye 64, Mate-Desktop, SD-Card Extender (ruht)
    Pi3b Pihole (Buster)
    Pi3b, 128-GB-SSD, Buster, mit 10,1" Monitor als MM (ohne Spiegel ;) )
    orangepi zero, ohne Beschäftigung
    Pi 5 4 GB im GeekPi-Gehäuse mit externer SSD (Bookworm)


    Warnung: Raspi und Co. machen süchtig! :)

    • Offizieller Beitrag

    [Ironie]

    Ich tüftel noch an einer einfachen Anleitung für das Resize des BS auf der SSD/Festplatte.

    Mach ein Video! :baeh2:

    Duck und weg!

    [/Ironie]


    //Edit: Jetzt hatte ich doch glatt noch die ironie-Tags für Klaus vergessen.

  • Mach ein Video!

    Versuch mal eine Kommandozeile aus einem Video zu kopieren.

    Versuch mal die interessanten Stellen wiederzufinden.

    Das nervt mich an Videos, daher ist es nicht wirklich eine Option.

    Duck und weg!

    Das ist eine wirklich gute Idee ;)

    MfG

    Jürgen

    Edit: Ich gebe manchmal Hilfestellung mit Verweisen auf Tutorials und Threads die erfolgreich waren.

    Wenn dann keiner darauf eingeht lösche ich das Abo-Flag wieder und lasse die Leute dann alleine

    weiterwursteln.

  • Zitat

    Flasht dasselbe Image auf die SSD, entfernt die SD-Karte und versucht von SSD zu booten.

    Ich habe es mit einer laufenden SSD ausprobiert, die an einem 3B+ lief, dochd as hatte nicht funktioniert.

    Nachdem ich das mit der aktuellen Version neu geflascht hatte, lief es dann, so wie

    Ich tüftel noch an einer einfachen Anleitung für das Resize des BS auf der SSD/Festplatte.

    Wenn man (unter Windows) das Image-Programm der Foundation nimmt, wird die Partition vom originalen Image automatisch ausgedehnt.

    Nutzt man eins, das mit Wind23diskImager erstellt wird, wohl nicht.


    In einer der ganz frühen "raspi-config"-Versionen stand die Resize-Funktion im Script.

    Ob die Resize-Funktion ausgeführt werden darf, erfolgte ihr durch eine Einfach Abfrage des Ergebnis des Root-Dateisystems.

    Hier der alte Code:

    Computer ..... grrrrrr

  • Wenn man (unter Windows) das Image-Programm der Foundation nimmt, wird die Partition vom originalen Image automatisch ausgedehnt.

    Auch auf der SSD? Funktioniert das auch mit der Linux-Version?

    Meine Vorgehensweise ist normalerweise, das ich das Original-Buster auf eine (16G)-SD karte ziehe

    und dann erstmal nach meinen Wünschen konfiguriere (Desktop-Einrichtung und diverse Programme).

    Danach erstelle ich ein Image und shrinke dann das Image mit Pishrink. Und dieses Image kopiere ich dann

    auf die entsprechenden Datenträger. Bei den SD-Karten kann ich das resize von raspi-config nehmen

    und bei den SSDs arbeite ich nach meiner eigenen Anleitung, die noch immer funktioniert.

    Den Raspberry4-Teil lasse ich mittlerweile weg, das ist das Kombiboot.

    Die Anleitung entstand, nachdem ich bei einer 500GB-SSD und USB2.0 feststellen musste, das die Zeit

    nicht ausreichte um die SSD zu resizen und ein Timeout einen Reset beim RPi auslöste -> Bootschleife.

    Hier war der Resize-Teil von pishrink beteiligt, seitdem shrinke ich die Images mit der Option -s (ohne automatischen Resize)

    und erweitere die Partition dann von Hand. Hat bisher immer gut funktioniert.

    Perlchamp hat auch eine Anleitung verfasst die einen Desktop voraussetzt, meine Anleitung funktioniert auf der Kommandozeile.

    Hier der alte Code:

    Ist mal einen Blick wert, Danke

    MfG

    • Offizieller Beitrag

    Auch auf der SSD?

    Ohne das getestet zu haben bezweifle ich den Unterschied zwischen RPi-Imager und Win32DiskImager. Die Partition wurde bisher beim ersten Booten vergrößert, warum und vor allem wie sollte das der RPi-Imager anders handhaben?

  • Ich brauchte bei der Neuinstallation direkt auf SSD auch nichts nachzuarbeiten Geschrieben habe ich das Image auf die SSD mit dem Raspberry Pi Imager. Ob der erste Start wegen des Vergrößern wesentlich länger dauerte, weis ich gar nicht. Die Images der Pi4-SSD, die ich mit Win32Diskmanager erzeuge, sind 232,9 GiB (250.059.350.016 Bytes) groß. Ich habe die nicht vergrößert :)

    Da freut sich pishrink ;)

    Nachtrag:

    pishrink hat aus dem 232,9-GB-Full-Image der oben erwähnten SSD ein 11-GB-File gemacht......

    Spoiler anzeigen

    Pi4 V1.1, 4 GB, USB3-Hub, 250 GB SSD, Bullseye 64, Mate-Desktop, SD-Card Extender (ruht)
    Pi3b Pihole (Buster)
    Pi3b, 128-GB-SSD, Buster, mit 10,1" Monitor als MM (ohne Spiegel ;) )
    orangepi zero, ohne Beschäftigung
    Pi 5 4 GB im GeekPi-Gehäuse mit externer SSD (Bookworm)


    Warnung: Raspi und Co. machen süchtig! :)

    Einmal editiert, zuletzt von Urs-1956 (31. August 2020 um 22:17)

  • Also ich kann bestätigen, daß die "rootfs" Partition auf einer SSD beim flashen mit dem rpi-imager unter Windows nicht automatisch vergrößert wird.

    Habe ich schon des öfteren zum flashen auf SSD benutzt weil der win32imager keine SSDs akzeptiert.

  • Wenn ich das richtig verstehe wird ja auf alle Fälle etwas auf dem EEPROM verändert richtig?

    Deshalb meine Frage lässt sich das ganze auch wieder Rückgängig machen, so dass man doch wieder von SD Karte booten kann?

    Wenn ja, so könnte man das noch gleich im Tutorial erwähnen wie.

    Wenn nein, auch da wär dann ein Hinweis wünschenswert.

Jetzt mitmachen!

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