Raspberry Pi 4 - Booten mit zwei SSD-SATA gleichzeitig und ohne SD-Karte

  • Hallo Raspi-Forum,


    nach einer längeren Recherche vieler Rasperry-Seiten im www und vieler Filmchen auf Youtube muss ich mich mal an euch wenden.


    Ganz kurze Vorbemerkung:

    Ich möchte meinen Raspberry 4 für eine Nextcloud nutzen und hierfür zwei SSD mit 1 TB am USB3-Port anschließen. Mit SD-Karten habe ich früher schlechte Erfahrungen (fehlende Langlebigkeit) gemacht und sie deshalb momentan aus meinem Raspi "verbannt".


    Was funktioniert?

    Die Nextcloud läuft super und mein Raspberry bootet problemlos, wenn EINE SSD angeschlossen ist. Nach dem Login stöpsle ich dann die zweite SSD an und sie wird automatisch gemountet. Die zweite Platte benötige ich nur für die Datensicherung.


    Was funktioniert nicht?

    Wenn beim Einschalten beide SSD angeschlossen sind, dann würfelt mir der Raspi meine beiden SSD durcheinander.



    Infos für Diagnose:


    - Mein System ist Ubuntu Server 20.04 mit bereits vorkonfiguriertem USB-Start.


    - Meine /etc/fstab lautet:

    (Ich habe bereits versucht, die Partitionen auch mit Hilfe von "Label", "PARTUUID" und "UUID" anzusprechen. Macht aber keinen Unterschied.)

    Code
    /dev/sda1    /boot/firmware    vfat    defaults           0    0
    /dev/sda2    /                 ext4    defaults           0    0
    /dev/sda3    /media/nextcloud  ext4    defaults           0    0
    /dev/sdb1    /mnt/sdb1         vfat    defaults,nofail    0    0
    /dev/sdb2    /mnt/sdb2         ext4    defaults,nofail    0    0
    /dev/sdb3    /mnt/sdb3         ext4    defaults,nofail    0    0


    - Wenn ich die drei Zeilen der /etc/fstab, in denen /dev/sdbX steht, auskommentiere, beide Platten anschließe und den Pi hochfahre, dann bekomme ich über lsblk folgende Ausgabe:

    (Auszug)

    sda1 /boot/firmware

    sda3 /media/nextcloud

    sdb2 /

    (Ja, wirklich, ermountet sdb2 mit / )


    Meine Fragen:

    - Kann es sein, dass der Raspberry überfordert ist, wenn zwei SSD beim Start dranhängen?

    - Kann der Grund auch USB3 sein?

    - Hat jemand eine Lösung?


    Falls Ihr noch wichtige weitere Infos braucht für die Ursachenfindung, dann reiche ich diese gerne gleich nach.


    Und danke schon mal!


    (Im schlimmsten Fall muss ich statt eines Reboot halt weiterhin das System herunterfahren, die Platte abstöpseln, das System hochfahren und die Platte wieder anstöpseln.)

  • //Edit: ... und UUID in der /etc/fstab.

    Vor allem auch in der /boot/cmdline.txt unbedingt die UUID statt /dev/sdX... benutzen. Die Bezeichnungen sda.. sdb.. können sich ändern, je nachdem welche Platte zuerst oder an welchem USB-Port angeschlossen wird.

  • Vielen Dank euch beiden,


    zum aktiven Hub: Ich hatten schon einen (atolla mit 4 Steckplätzen https://www.amazon.de/atolla-Netzteil-SuperSpeed-Datenhub-Intelligenter-Schwarz/dp/B07P6MPXJ7 (Affiliate-Link)) Er hat nicht funktioniert. Ich habe ihn dann wieder zurückgeschickt, weil der Pi überhaupt nicht mehr hochgefahren ist. Leider.


    hyle, welchen Hub benutzt du? Laut meiner Recherche ist es eher Glück, wenn man einen Hub findet, der auch funktioniert. Vielleicht probiere ich dann mal deinen...


    zur UUID: Ich hatte schon die Vermutung, dass die UUID sinnvoller ist, aber wie gesagt, es machte keinen Unterschied. Ich habe das auch ausprobiert.


    Das komische ist: Egal an welchen USB-Port ich die SSD anstecke und über welche Methode ich die fstab aufbaue, er nimmt immer von der einen Platte die erste Partition zu /boot/firmware und von der anderen Platte die zweite Partition zu /. (PARTUUID, UID, /dev..., Label,... es ist völlig egal, wie ich die Platten anspreche.)


    Jetzt beißt sich aber die Katze in den Schwanz... Meine /dev/sda1 wird nach /boot/firmware gemountet und /dev/sdb2 nach /. Wenn ich also in der /boot/cmdline.txt (also auf /dev/sdb2 !!) Angaben mache, dann ist doch das ganze Mount-Geschäft schon abgeschlossen? Oder nicht? Ich müsste also viel mehr hinterfragen als nur die Sache: /dev <-> UUID. Wird der Inhalt der Datei /boot/cmdline.txt ausgewertet, bevor /dev/sdb2 nach / gemountet wird?

    Update: Habe gerade hier im Forum einen Thread gefunden, in dem der Bootverlauf erklärt wird. Scheinbar wird die /boot/cmdline.txt doch vorher ausgewertet.


    Bisher gibt es bei mir die Datei cmdline.txt nicht. Ich habe mich auf elinux.org mal umgeschaut und habe den Eindruck, dass meine Datei eigentlich nur einen Eintrag benötigt:

    root=UUID=12345678-1234-1234-1234-123456789a02


    Ich habe meine Ubuntu-20.04-Installation nicht selbst für das Booten fit gemacht sondern ein Image aus dem Internet bezogen. Hier war die Aufteilung /dev/sda1 wird zu /boot/firmware und /dev/sda2 wird zu / schon erledigt. Sollte man daran etwas ändern oder ist das so in Ordnung?


    Von euren Tipps und Antworten abgesehen, besitzt die Lösung über /dev/sda und /dev/sdb folgenden Charme:

    Angenommen, die Partitionen der sda werden regelmäßig nach sdb geklont und die sda geht kaputt, dann muss ich die sda nur wegnehmen und die ursprüngliche sdb wird beim nächsten Bootvorgang zur sda. Da die /etc/fstab mit geklont wurde und dort die /dev/sda ja auch gemountet werden soll, müsste man überhaupt nichts ändern. Die Lösung über UUID bedeutet, dass ich auf der ursprünglichen sdb eine "eigene" fstab benötige, die nicht beim klonen überschrieben werden darf. (Habs gerade noch mal durchgelesen :conf:)


    Ich probiere jetzt ein paar Dinge aus und melde mich wieder.

  • Ich habe ihn dann wieder zurückgeschickt, weil der Pi überhaupt nicht mehr hochgefahren ist. Leider.

    Hier ein link zu meinem Hub (Affiliate-Link).

    Der funktioniert einwandfrei.

  • Hallo,


    da bin ich wieder.


    Also, es funktioniert tatsächlich nicht. Das Anlegen einer cmdline.txt in /boot bringt nichts, weil der Pi ja die /dev/sdb2 als / mountet. Und dort gibt es keine /boot/cmdline.txt, weil ich sie ja auf der sda-SSD angelegt habe. Die cmdline.txt wird also erst nach dem mounten ausgewertet.



    Danach habe ich auch auf der /dev/sdb2 die cmdline.txt angelegt und in der /etc/fstab per UUID die 2. Partition der sda als / angegeben. Bringt nix! Er nimmt IMMER die sdb2 als /.


    Der Pi nimmt die 2. Partition der sdb als sda2 an. Das ist mein Eindruck.



    Mal schauen, ob es eine elegante Lösung gibt, oder ob ich bei meinem hin- und herstecken bleiben muss...

  • Angenommen, die Partitionen der sda werden regelmäßig nach sdb geklont

    ... dann wird auch das "boot Flag" und das "root - Flag" auf das Zielgerät übertragen, was zu überraschenden Ergebnissen kommt.



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Ich habe mir den aktiven Hub von CSL bestellt und warte mal ab, ob es mit dem dann geht...


    DANKE für eure Hilfe bis dahin.

  • Hallo RTFM,


    du vermutest, dass mein ursprünglicher dd-Befehl das ganze durcheinander gebracht hat?


    Ich sollte also die zweite Platte mit fdisk und einer neuen Partitonstabelle (vielleicht gpt?) wieder platt machen? Könnte ein Versuch wert sein.


    Ich probier's mal...

  • Hallo Jürgen,


    diese Seite hat meine bisherige Google-Suche noch nicht ausgespuckt! Die Anleitung sieht super aus. Da werde ich einiges finden, das mich weiterbringt. Ich denke aber, dass die meisten Infos in den zahlreichen Kommentaren stecken. Na dann mach ich mich mal dran...

  • CuJ

    Hier einmal Zitate aus deinem Eingangspost

    Ich möchte meinen Raspberry 4 für eine Nextcloud nutzen und hierfür zwei SSD mit 1 TB am USB3-Port anschließen

    Beide Platten haben laut lsblk #7 jeweils 111,8GB


    Die zweite Platte benötige ich nur für die Datensicherung.

    Warum haben dann beide Platten die exakt gleichen Partitionen? Selbst die UUID's sind doppelt vorhanden.

    Hast du das Betriebssystem mit dd auf beide Platten geschrieben? Dann ist das kein Wunder, dass der Pi sich merkwürdig verhält.

  • Selbst die UUID's sind doppelt vorhanden.

    Hast recht, aber nur die UUIDs bei /dev/sda1 und /dev/sdb1, die PARTUUIDs sind unterschiedlich.


    MfG


    Jürgen

  • Hast du das Betriebssystem mit dd auf beide Platten geschrieben? Dann ist das kein Wunder, dass der Pi sich merkwürdig verhält.

    Hat er, und zwar ursprünglich von einer SD mit 128 MB.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Ich bin mit der Ursachenfindung meines Problems weitergekommen.


    Bisher habe ich jeweils zwei identische SSD verwendet. WD SATA SSD 120 GB im Test-System zum Probieren und WD SATA SSD 1 TB im richtigen System, das dann auch laufen soll. Vorhin habe ich mal mein Testsystem verändert: sda = WD SATA 120 GB, sdb = SAMSUNG 840EVO 120 GB.


    Ich habe dann mittels dd die sda auf sdb geklont. Die sdb3 war ein paar Sektoren zu klein und ich musste die sdb3 nochmals mit Hilfe von fdisk und mkfs.ext4 anlegen. Ein rsync hat den Inhalt der sda3 auf die sdb3 kopiert.


    Der reboot hat geklappt und alle Partitionen werden korrekt gemountet. Es lag vermutlich bisher an der Tatsache, dass die Platten identisch sind. (Alle Label, UUID, PARTUUID,... sind nach dem dd-Befehl paarweise identisch, also /dev/sda1 = /dev/sdb1, /dev/sda2 = /dev/sdb2, aber durch das Mounten über /dev/sda... ist das kein Problem.)


    In der /etc/fstab werden alle SSD mit /dev/sda... und /dev/sdb... gemountet. Ein simulierter Ausfall der /dev/sda... hat geklappt. Die geklonte vormalige /dev/sdb war nach dem Abstöpseln der /dev/sda dann die neue /dev/sda und das Hochfahren funktionierte problemlos, weil ja auch die /etc/fstab geklont wurde...


    So, für mein Testsystem hätte ich eine Lösung. ABER meine beiden "teuren" 1 TB SSD laufen noch nicht. Und vorallem: Eine vernünftige Lösung ist das ehrlicherweise nicht. Das mounten über UUID ist vermutlich schon sinnvoller. Ich werde mich also mal mit dem BLOG von James A. Chambers beschäfftigen.


    <Spaß> Tauscht jemand mit mir eine 1 TB SSD? </Spaß>

  • Ich sehe schon, ich muss mein System anders konzipieren. Mein bisheriger Ansatz ist nicht besonders elegant (um es mal vorsichtig auszudrücken.)


    Es klang zunächst simpel:

    - Vorgefertigtes Image auf die SSD

    - Klonen mit dd auf eine zweite Reserve-SSD

    - Bei Ausfall der ersten SSD einfach die Reserve-SSD weiterbetreiben

  • In dem Foto sind die UUIDs und die PARTUUIDs identisch, diese Zwillinge machen Probleme.


    MfG


    Jürgen


    P.S.: Sieh Dir mal den "SD Card Copier" näher an

  • Hallo Jürgen,


    ja, die identischen UUID und PARTUUID stellen wohl ein Problem dar auf identischen Platten. Handelt es sich aber um zwei verschiedene Platten, dann geht es wohl doch (irgendwie). Aber das irgendwie ist natürlich nicht zufriedenstellend.


    Was denkst du, wird die Anleitung von Chambers funktionieren, wenn ich nachher zwei identische Platten mit unterschiedlichen UUID, PARTUUID und Labels dranhänge?


    Ich darf dann aber nicht mit dd die Partitionen klonen...