Raspberry Pi4 4GB SSD Boot

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hi

    Hier mal ein kleiner Tipp was das Bootloader Upgrade an geht.

    Das Bootloader upgrade per Befehl funktioniert zum Bsp bei Libreelec wegen fehlender Komponenten im BS nicht und man müsste den Umweg über eine vollwertige Linux installation wie Raspian erst machen. (vor dem Problem stande ich nämlich)

    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…ses/tag/v2020.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

  • Hallo,

    Was hälst Du davon erstmal nur einen Schritt zu machen?

    Ziehe erstmal ein aktuelles Buster auf die SSD und versuche zu booten.

    Denn ich weiß nicht woher Deine Probleme kommen, vom RPi oder vom Backup.

    Ich hatte heute mal wieder Zeit, mich um die USB-SSD Verbatim Vx500 zu kümmern.

    Ich bin dem Rat von Jürgen Böhm gefolgt.

    Ich habe mit Win32DiskImager ein "Raspberry Pi OS (32-bit) Lite" Release date: 2020-08-20 auf die SSD geflasht.

    Und was soll ich sagen, damit bootet der RPi4B von der USB-SSD.

    Danach habe ich noch mal das Image der SD-Karte auf die USB-SSD geflasht.

    Damit bootet der RPi4B leider nicht.

    Kann man herausfinden, wo das Problem liegt?

    Ich würde extrem ungern den RPi4B für die SSD neu konfigurieren wollen.

    Gruß

    meute

  • Tja das wurde aber schon des öfteren geschrieben, daß du ein komplett neues Image ziehen sollst und direkt auf eine SSD flashen. Die August Releases haben alles was zum USB Boot gebraucht wird gleich dabei. Aber wenn's jetzt funzt, ist es ja gut.

  • Danach habe ich noch mal das Image der SD-Karte auf die USB-SSD geflasht.

    Damit bootet der RPi4B leider nicht.

    1. Boote von der SD-Karte

    2. Stecke nach dem booten von der SD-Karte die SSD an den Raspberry

    3. Lese die PARTUUIDs mit sudo blkid aus. Es geht um die PARTUUIDs von /dev/sda*

    4 Kontrolliere ob die Partitionen bereits unter /media/pi gemountet sind mit df -h,

    5. Falls bereits gemountet:

    5a. Kontrolliere ob die PARTUUID (/dev/sda2) in /media/pi/boot/cmdline.txt identisch ist

    5b. Kontrolliere ob die PARTUUIDs (/dev/sda1(/boot) und /dev/sda2(/)) in der /media/pi/rootfs/etc/fstab identisch sind

    6. Falls nicht gemountet

    6a. sudo mount /dev/sda1 /mnt, dann kontrolliere ob die PARTUUID (/dev/sda2) in /mnt/cmdline.txt identisch ist.

    6b. Danach sudo umount /mnt

    6c. sudo mount /dev/sda2 /mnt, dann kontrolliere ob die PARTUUIDs (/dev/sda1(/boot) und /dev/sda2(/)) in der /mnt/etc/fstab identisch sind.

    6d. Danach sudo umount /mnt

    Dann teile uns das Ergebnis mit

    MfG

    Jürgen

    Edit: Fehler korrigiert, jetzt zum dritten Mal:wallbash:

  • Hallo,

    Habe ich gemacht.

    Was ich aber nicht verstehe, ist, was Du mit dem Ordner /dev/sda1(/boot) meinst:

    Zitat:

    5b. Kontrolliere ob die PARTUUIDs (/dev/sda1(/boot) und /dev/sda2(/)) in der /media/pi/rootfs/etc/fstab identisch sind

    Ich habe die USB-SSD an einem RPi3B+ angesteckt, weil der neben mir steht.

    Hier das Ergebnis:

    Code
    # Laufwerks-ID ermitteln:
    blkid
    /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" PARTUUID="738a4d67-01"
    /dev/mmcblk0p2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" TYPE="ext4" PARTUUID="738a4d67-02"
    /dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="70A2-8001" TYPE="vfat" PARTUUID="2b7ad3b1-01"
    /dev/sda2: LABEL="rootfs" UUID="a1fafd2b-1ef0-4fe8-8ac1-ad33bbb48642" TYPE="ext4" PARTUUID="2b7ad3b1-02"
    /dev/mmcblk0: PTUUID="738a4d67" PTTYPE="dos"
    Code
    # USB-SSD mounten:
    sudo mount /dev/sda1 /media/usb1
    sudo mount /dev/sda2 /media/usb2
    Code
    # cmdline.txt der USB-SSD direkt nach Image raspi4711 von SD-Karte
    sudo nano /media/usb1/cmdline.txt
    console=serial0,115200 console=tty1 root=PARTUUID=2b7ad3b1-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
    Code
    # Inhalt fstab der USB-SSD:
    sudo nano /media/usb2/etc/fstab
    proc            /proc           proc    defaults          0       0
    PARTUUID=2b7ad3b1-01  /boot           vfat    defaults          0       2
    PARTUUID=2b7ad3b1-02  /               ext4    defaults,noatime  0       1

    Gruß

    meute

  • Hier das Ergebnis:

    Sieht okay aus, ich kann auf den ersten und zweiten Blick keine Fehler erkennen.

    Auf diese Weise booten bei mir mittlerweile 5 RPi4B.

    5b war nur für den Fall, das die SSD automatisch gemountet wurden.

    Versuchen wir es mal den Kombi-Boot.

    Dazu trägst Du auf der SD-Karte in der cmdline.txt die PARTUUID (2b7ad3b1-02) der SSD ein.

    Das kannst Du unter Windows rückgängig machen.

    Dann boote mit eingelegter SD-Karte und der SSD nochmal.

    MfG

    Jürgen

  • Hallo,

    Sieht okay aus, ich kann auf den ersten und zweiten Blick keine Fehler erkennen.

    Auf diese Weise booten bei mir mittlerweile 5 RPi4B.

    Ich habe die Ursache meiner Bootprobleme von USB-SSD gefunden. :wallbash:

    Standardmäßig steckt am RPi4B eine andere Datensicherungs-USB-SSD.

    Die Datensicherungs-USB-SSD habe ich immer abgesteckt, wenn ich mit der USB-SSD Verbatim Vx500 booten wollte.

    Für die Datensicherungs-USB-SSD exisitieren zwei Einträge in der /etc/fstab.

    Zuerst wird sie automatisch gemountet.

    Dieser Eintrag ist aber unkritsch (Parameter nofail) und verursacht NICHT den Bootfehler.

    Damit bootet der RPI4B von USB-SSD.

    Code
    $ sudo nano /etc/fstab
    # USB-Laufwerk fuer Backup mounten bei jedem Start
    PARTUUID=9fb1957f-01  /media/usb_ssd_backup  ext4  defaults,users,noatime,nofail,discard  0  2

    Danach wird sie nochmal als NFSshare automatisch gemountet.

    Über das NFSshare sichert der zweite RPi3B+ auch seine Daten auf die Datensicherungs-USB-SSD am RPi4B.

    Dieser Eintrag verursacht den Bootfehler.

    Da gibt es keinen Parameter nofail.

    Code
    $ sudo nano /etc/fstab
    # Mountpoint-Ordner vom USB-Laufwerk fuer Backup zum NFSshare mounten bei jedem Start
    /media/usb_ssd_backup   /media/nfs_usb_ssd_backup   none   bind   0   0

    Jetzt die spannende Frage.

    Wie muss der Eintrag für das NFSshare in der /etc/fstab, lauten, damit der RPi4B auch bootet, wenn die Datensicherungs-USB-SSD NICHT angeschlossen ist?


    Gruß

    meute

    Einmal editiert, zuletzt von meute (7. September 2020 um 18:47)

  • Hallo,

    USBID 18a5:025a

    https://linux-hardware.org/index.php?view…iceid=025a#list

    Um es kurz zu machen: No data =(

    Ob das Teil noch zu neu ist?

    https://www.verbatim.de/de/prod/vx500-…ve-480gb-47443/

    Falls sie funktioniert gib mal Bescheid, dann kann ich sie in dieser Tabelle aufnehmen.

    Du kannst USBID 18a5:025a in die Liste aufnehmen.

    Damit bootet der RPi.

    Gruß

    meute

  • Danach wird sie nochmal als NFSshare automatisch gemountet.

    Hat welchen Sinn?

    Wenn Du nur einen 2.Ordnernamen mit selben Inhalt brauchst,

    wäre ein ln -s /media/usb_ssd_backup /media/nfs_usb_ssd_backup

    vielleicht besser. Aber ich weiß nicht, welcher Zweck dahintersteht.

    MfG

    Jürgen

    P.S.: SSD ist aufgenommen

  • Ist es denn notwendig zwei verschiedene Ordnernamen zu haben?

    Den Sinn verstehe ich auch nicht so ganz???

    PARTUUID=9fb1957f-01 /media/usb_ssd_backup ext4 defaults,users,noatime,nofail,discard 0 2

    Du mountest die SSD nach media/usb_ssd_backup.

    Soweit alles ok.

    Über das NFSshare sichert der zweite RPi3B+ auch seine Daten auf die Datensicherungs-USB-SSD am RPi4B.

    Aber warum brauchst du für den NFSshare einen weiteren Ordnernamen?

    Erstelle doch unter /media/usb_ssd_backup ein Unterverzeichnis und sichere deine Daten om NFSshare dorthin.

    Z.B. /media/usb_ssd_backup/NFS

    Dann kannst du den zweiten Mountbefehl ganz weglassen.

    Oder habe ich da jetzt einen Gedankenfehler?

  • Hallo,

    Wenn Du nur einen 2.Ordnernamen mit selben Inhalt brauchst,

    wäre ein ln -s /media/usb_ssd_backup /media/nfs_usb_ssd_backup

    vielleicht besser.

    Wie / wo muss ich ln -s /media/usb_ssd_backup /media/nfs_usb_ssd_backup einbauen, damit das automatisch passiert und keinen Bootfehler verursacht, wenn die Datensicherungs-USB-SSD mal nicht angeschlossen ist?

    Hat welchen Sinn?

    Ist es denn notwendig zwei verschiedene Ordnernamen zu haben?

    Keine Ahnung, ob das notwendig ist.

    Ich habe mich bei der Konfiguration des NFSshare u.a. an diese Anleitung gehalten.

    Und da steht im Bereich "Set up a basic NFS server" folgendes:

    Zitat

    Note that /export and /export/users will need 777 permissions, as we will be accessing the NFS share from the client without LDAP/NIS authentication. This will not apply if using authentication (see below). Now mount the real users directory with:

    sudo mount --bind /home/users /export/users

    Zitat

    To save us from retyping this after every reboot, we add the following line to /etc/fstab:

    /home/users /export/users none bind 0 0

    Gruß

    meute

  • Wie / wo muss ich ln -s /media/usb_ssd_backup /media/nfs_usb_ssd_backup einbauen, damit das automatisch passiert und keinen Bootfehler verursacht, wenn die Datensicherungs-USB-SSD mal nicht angeschlossen ist?

    Mit ln wird ein Link angelegt. Der ist so lange vorhanden, bis er gelöscht wird. Einfach in der Shell ausführen und prüfen ob es wie gewünscht funktioniert. Ob Bootfehler erscheinen kannst du ja einfach testen, indem du die USB SSD nicht anschliesst und neu startest.

  • Hallo,

    Der Vorschlag mit dem Symbolischen Link

    ln -s /media/usb_ssd_backup /media/nfs_usb_ssd_backup

    wird wohl nicht funktionieren, weil man IMHO Symbolische Links nicht berechtigen kann.

    Da greift immer die Berechtigung vom Quell-Ordner.


    Ich habe das Mounten vom Quell-Ordner zum NFSshare-Ordner jetzt so gelöst.:

    bash-Skript erstellt:

    bash-Skript nach /usr/local/bin kopiert.

    bash-Skript ausführbar gemacht:

    chmod +x /usr/local/bin/meinskript.sh

    Benutzer Cron-Tabelle bearbeitet, damit das bash-Skript bei jedme Reboot ausgeführt wird:

    crontab -e

    Eintrag in Benutzer Cron-Tabelle:

    Code
    # NFSshare bei jedem Neustart mounten.
    # Vorher 30 Sek. warten.
    # In einem Cronjob Programme nur mit dem KOMPLETTEN Pfad aufrufen!
    # Min  Std  Tag  Mon  Wochtag  Befehl
    @reboot   /usr/local/bin/NFS-Server_NFSshare_mounten_nach_reboot.sh
    # Die Cron-Tabelle muss mit einem Kommentar oder einer Leerzeile enden!


    Gruß

    meute

  • Du kannst USBID 18a5:025a in die Liste aufnehmen.

    Damit bootet der RPi.

    Jürgen Böhm

    Ich sehe, Du hast tlw. mitgelesen.

    Ich wollte Dir grad mitteilen, dass Du in Deiner Liste

    Magische USB-SATA Adapter und wo sie zu finden sind

    unbedingt was zur USB-SSD Verbatim Vx500 vermerken musst.

    Sie wird sehr heiß (das hast Du schon verlinkt).

    Sie zwingt den RPi in die Knie.

    Sie hat mir meinen Prolific PL2303 USB-to-Seriell-Adapter geschossen.

    Hier die Links dazu:

    RE: SD-Karte durch SSD ersetzt - Jetzt stellt der RPi4B jede Nacht den Betrieb ein (oder hängt sich auf?)

    RE: Bei SSD Trim aktivieren und prüfen?

    Einmal editiert, zuletzt von meute (25. September 2020 um 18:22)

  • Sie wird sehr heiß

    Das wird meine Sandisk Extreme Portabel SSD auch wenn ich die direkt am Pi anklemme. Da ich aber ein stabilisiertes USB 3.0 Hub verwende, bleibt die SSD dort normal kühl bis handwarm.

Jetzt mitmachen!

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