Selbe Platte an 2 Raspberrys booten funktioniert nicht

Invers · 14 August 2020, 22:00:09

Ich habe 2 Pi's und eine Festplatte. Die Platte bootet nur am Pi, dessen Image ich auch erstellt und auf die Platte gespielt habe.
Der 2. Pi bootet mit dieser Platte nicht.
Ich wollte einen Pi in Reserve haben, falls mal der aktive Pi kaputt geht.

Ich habe gelesen, dass da eine UUID o.Ä. eine Rolle spielen soll, habe aber nichts verstanden.
Kann mir einer sagen, wie das genau geht, dass ich mehrere Pi's von der selben Platte booten kann?

Danke im Voraus.

MadMax-FHEM · 14 August 2020, 23:24:20

Naja, dann schreib erst mal:

wie hast du die Platte erstellt!?

SD und dann die SD umgeflasht!? -> dann passen die UUIDs etc.

Und da ja ein PI damit bootet muss es ja passen...
Und wenn so erstellt, dann werden UUIDs genommen und auf die Partitionen der Platte übernommen...

Wenn selbst was gebastelt und KEINE UUID genommen, dann kann es sein, dass es in einem bootet und im anderen nicht (aber selbst bei Angabe von /dev/... ist das bei 2 PIs eher unwahrscheinlich, dass die Partitionen unterschiedlich "heißen" / außer: es stecken weitere Platten etc. dran)...

Sind beide PI auch eingerichtet von USB zu booten -> EEPROM geschrieben!?

EDIT: ansonsten hilft auch einen Monitor dran schließen und sehen wo es "hakt"...

Gruß, Joachim

MadMax-FHEM · 14 August 2020, 23:34:18

Wenn du bzgl. UUIDs sicher gehen willst:

bei dem PI der bootet folgendes ausführen

Code Auswählen


sudo blkid

Und dann eben schauen was in

Code Auswählen


cat /boot/cmdline.txt

und in

Code Auswählen


cat /etc/fstab

steht.

Die PARTUUID sollten halt passen...

Wenn in fstab bzw. cmdline.txt NICHT PARTUUID genommen, sondern /dev/sda1 oder ähnliches steht, dann könnte es eben beim 2ten PI anders "benamst" sein (aber wie geschrieben: auch das eher unwahrscheinlich)...

Gruß, Joachim

Invers · 15 August 2020, 08:49:35

Hi, danke für die schnelle Antwort.

Ich habe die SD-Karte vom Pi mit Diskimager irgendwann auf einen USB-Stick geflasht. Schon eine Weile her.
Pi bootet auch vom Stick. Nun ist mir der Stick aber zu langsam und ich wollte eine Platte einsetzen.
Somit habe ich vom Stick mit Diskpart ein Image geflasht und auf die Platte gespielt, natürlich wieder mit Diskpart.

Nun bootet der Pi auch prima von der Platte.

Ich habe dann versucht, die Platte an einen anderen Pi anzuschliessen, der auch bereits von USB booten kann.
Der 2. Pi bootet nun aber leider nicht von dieser Platte.

Der USB-Stick zeigt:

pi@fhem3:~ $ sudo blkid
/dev/sda1: LABEL="boot" UUID="6228-7918" TYPE="vfat" PARTUUID="a01bace7-01"
/dev/sda2: LABEL="rootfs" UUID="6bfc8851-cf63-4362-abf1-045dda421aad" TYPE="ext4" PARTUUID="a01bace7-02"

und

pi@fhem3:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=a01bace7-02 rootfstype=ext4 elevator=deadline fsc k.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

und

pi@fhem3:~ $ cat /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=a01bace7-01 /boot vfat defaults 0 2
PARTUUID=a01bace7-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that

Wenn ich die Platte anschliesse, kommt folgendes dabei raus:

pi@fhem3:~ $ sudo blkid
/dev/sda1: LABEL="boot" UUID="6228-7918" TYPE="vfat" PARTUUID="a01bace7-01"
/dev/sda2: LABEL="rootfs" UUID="6bfc8851-cf63-4362-abf1-045dda421aad" TYPE="ext4" PARTUUID="a01bace7-02"

und

pi@fhem3:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=a01bace7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

und

pi@fhem3:~ $ cat /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=a01bace7-01 /boot vfat defaults 0 2
PARTUUID=a01bace7-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that

Der Pi kann also von beiden Medien Booten.

Der andere Pi bootet weder vom USB-Stick, noch von der Platte. Somit kann ich da auch nichts auslesen. Eine Bildschirmanzeige kommt nicht.

Ich bekomme heute Nachmittag meine SSD geliefert und probiere mal, diese an den 2. Pi anzuschliessen und vorher ein frisches System zu installieren. Dann würde ich mich mit dem Ergebnis noch einmal melden.

MadMax-FHEM · 15 August 2020, 10:28:22

Also die UUIDs stimmen und da der eine PI bootet zeigt das auch, dass es passt.

Bist du sicher, dass der andere PI tatsächlich für USB Boot vorbereitet ist!!?

EDIT: also mind. 1x mit dem Eintrag "program_usb_boot_mode=1" in der /boot/config.txt gebootet!!? Und auch geprüft, dass ins EEPROM geschrieben wurde: "vcgencmd otp_dump | grep 17:" die Ausgabe sollte ,,17:3020000a" sein. Siehe: https://www.elektronik-kompendium.de/sites/raspberry-pi/2404241.htm

Hat der schon jemals von einer USB-Platte/Stick gebootet?

Bootet der überhaupt noch!!?

Verwendest du bei dem PI der nicht will DASSELBE Netzteil (nicht: das gleiche, sondern dasselbe)!?

EDIT: um welche Typen PI handelt es sich jeweils? Und: welches OS hast du auf USB-Stick bzw. Platte?

EDIT: wie ist es bzgl. bootloader!? Stichwort: "rpi-update". Sind die auf gleichem/ähnlichem Stand!? Steht beim einloggen (per ssh) im "Begrüßungs-Text")...

EDIT: die Verwendung einer SSD mit genau demselben Image wird (verm.) nicht helfen... Weil da ja eigentlich auch jetzt schon alles passt. EDIT: und ein neues verm. auch nicht (bzw.: wäre eigenartig)...

EDIT: wobei ich schon wegen Strombedarf NICHT von einer HDD booten würde, außer sie ist "extern versorgt"! Daher ist SSD schon besser. Weil USB und SD vermutlich ähnlich "schlecht" sind.

EDIT: und es wäre schön, für die geposteten Ausgaben "code-Tags" zu verwenden (das '#' im "Menü"), da lesen sich die Ausgaben besser...

Gruß, Joachim

Invers · 15 August 2020, 13:54:02

ZitatAlso die UUIDs stimmen und da der eine PI bootet zeigt das auch, dass es passt.

Bist du sicher, dass der andere PI tatsächlich für USB Boot vorbereitet ist!!?

EDIT: also mind. 1x mit dem Eintrag "program_usb_boot_mode=1" in der /boot/config.txt gebootet!!? Und auch geprüft, dass ins EEPROM geschrieben wurde: "vcgencmd otp_dump | grep 17:" die Ausgabe sollte ,,17:3020000a" sein. Siehe: https://www.elektronik-kompendium.de/sites/raspberry-pi/2404241.htm

Ich bin sicher und habe auch die Ausgabe geprüft. Er bootet ja auch vom USB-Stick, den ich neu angelegt habe, also nur zum Test. Und ja, er bootet noch.

ZitatVerwendest du bei dem PI der nicht will DASSELBE Netzteil (nicht: das gleiche, sondern dasselbe)!?

Habe ich zum Test mal gegen einander vertauscht, aber ohne negative Folgen.

aktiver Pi 1, der auch von Platte bootet

Code Auswählen

pi@fhem3:~ $ cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Plus Rev 1.3pi@fhem3:~ $

2. Pi

Code Auswählen

pi@raspberrypi:~ $ cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Rev 1.2pi@raspberrypi:~ $

Begrüßungstext
Pi 1

Code Auswählen

Linux fhem3 4.19.102-v7+ #1295 SMP Thu Feb 6 15:43:59 GMT 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Aug 15 13:28:58 2020 from 2003:ea:8706:1200:54ab:d408:d704:4fb

Begrüssung Pi 2

Code Auswählen

Pi 2
Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Aug 15 11:07:25 2020 from 192.168.178.54

Codetags finde ich an der Stelle albern, ist ja nur Fliesstext.

Ich hoffe, ich habe keine Frage übersehen.

Invers · 15 August 2020, 14:21:09

Ich habe hier folgenden Lösungsweg gefunden, den ich aber nicht verstehe:

Zitat... Bin jetzt durch vergleichen und Google drauf gekommen warum.

Das Zauberwort ist : PARTUUID

Nach einen Recovery wird diese anscheinend neu vergeben, jedoch steht in der cmdline.txt und fstab noch die alte PARTUUID, somit weiß der pi nicht wo seine Dateien sind...

Heißt also neue PARTUUID auslesen und die besagten Dateien ändern und schon wird gebootet.

Hab jetzt grad nochmal auf die OSMC pi's geschaut, die Lösung ist: Nicht die PARTUUID anzugeben sondern /dev/mmcblk0p1 und /dev/mmcblk0p2 für die Partitionen verwenden.

Somit funktioniert es universell und Acronis läuft auch wie gewünscht

MadMax-FHEM · 15 August 2020, 14:22:15

Hm, eigenartig...

Die Frage zum Netzteil wurde nicht beantwortet

Also normalerweise: wenn die Platte/USB-Stick was auch immer "in sich stimmig ist" (und das scheinen beide zu sein), dann sollte der PI booten. Vors. er kann von USB booten -> hast du ja getestet...

Dann kann es eigentlich wirklich nur sein, dass die Platte (warum auch immer) bei dem einen PI nicht ausreichend Strom bekommt und (rechtzeitig) anläuft...

Ansonsten fällt mir dazu nichts ein.

Ja es mach "nur Fließtext" sein aber trotzdem lesen sich "solche Ausgaben" deutlich besser!
Grad, wenn man mal nur mit dem Handy kuckt/kucken kann...

Gruß, Joachim

MadMax-FHEM · 15 August 2020, 14:25:35

Eigenartig, denn wenn die Ausgaben oben gestimmt haben, die sehen gut aus!?

Ich würde NICHT /dev/... nehmen, weil je nachdem wo du die steckst eben auch mal anders "durchbenamt" wird...
...und: eine SD sicher anders benamt wird als ein USB-Stick (und evtl. sogar eine HDD noch mal anders etc.)...

Aber: musst du wissen...

Und was heißt: bei einem Recovery ändern sich die!? Normalerweise NICHT wenn nur alles "geklont" "umgeflsaht" wird! Ansonsten eher mal das Backup-System "prüfen" (wechseln)...

Gruß, Joachim

Invers · 15 August 2020, 14:45:01

Die Frage nach dem Netzteil hatte ich beantwortet, direkt unter dem entsprechenden Zitat.

Erst einmal vielen Dank. Die SSD ist nun gekommen und ich guck mal, was passiert.
Wenns nicht läuft, würde ich mich noch mal melden.

MadMax-FHEM · 15 August 2020, 14:48:22

Ok, dann hab ich das überlesen...

Aber denk noch mal über das Einbinden per /dev/... nach...

Viel Erfolg, Joachim