USB-Boot RPi4 klappt nicht

[Bartimaus]

Moin,

bislang habe ich einen relativ neuen SanDisk Ultra-USB-Stick am Rpi4 als rootfs (SDA1) und Datenpartition (SDA2) genutzt.
Nach einem unerklärlichen Absturz hat es mit RootFS@USB nicht mehr funktioniert. Das System lief in der Konfig über ein Jahr stabil.
Deswegen läuft das System aktuell komplett von SD-Karte.

Bei meinem 2. Raspi habe ich aber das booten/Betrieb von USB komplett hinbekommen. Deswegen neuer Versuch, mit dem FHEM-Raspi.

Was wurde gemacht:
SDA1 gelöscht, und aufgeteilt bzw. neu partitioniert (boot-sda1/rootfs-sda3) Datenpartition-SDA2 ist geblieben.
Alles mit Fdisk bwz.cfdisk eingerichtet.
RPI-EEPROM-UPDATE auf aktuellen Stand (stable) gebracht

1. Bootpartion der SD-Karte nach SDA1 geklont (rsync)
2. Rootfs der SD-Karte nach SDA3 geklont (rsync)
3. cmdline.txt@SDA1 editiert, = rootfs=PARTUUID der SDA3
4. /etc/fstab@sda3 editiert, boot+rootfs jeweils die PARTUUID der SDA1/3 hinterlegt. SDA2 (datenpartition) unverändert.

USB-Boot in Raspi-Config mit Rootrechten eingetragen.

Reboot, und Raspi bootet nachwievor von der SD-Karte (gecheckt mit df -h)

Mit diesen Schritten hat es auch bei meinem anderen RPI4 geklappt.

Habt Ihr noch Ideen woran es liegen kann ?

[RappaSan]

Ich hatte vor kurzer Zeit ein ähnliches Problem mit einem Pi 3+ und einem speziellen USB stick.
Kurzes Blinken des sticks kurz nach dem power-on, danach Sendepause.

Geholfen hat dann bei mir

max_usb_current=1

in der config.txt.

Danach bootete das Ding auch wieder.

[Bartimaus]

Danke Dir, schaue ich mir an.
Wieviele USB-Sticks hast Du am Rpi ? Ich habe 2 Stück, was aber bislang tadellos funktionierte (sda/sdb)

[Otto123]

Geholfen hat dann bei mir

max_usb_current=1

in der config.txt.

Eigentlich ist diese Einstellung überholt: https://www.raspberrypi.com/documentation/computers/config_txt.html#max_usb_current

@Bartimaus Ich würde zum Test einfach mal mit RPI-Imager ein neues System auf einen USB Stick bringen, die Bootreihenfolge festlegen https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#editing-the-configuration
Und dann schauen ob er wie gewollt bootet.

Gruß Otto

[Bartimaus]

Danke Otto,

das wäre meine nächste Option gewesen. Ich wollte dafür aber meinen verwendeten USB-Stick verwenden, bin nur nicht sicher, was er dann mit der vorhandenen /sda2 DatenPartition gemacht hätte, da sind einige Daten drauf. Die würde ich dann vorher mal sichern.

Bootreihenfolge ist bei meinem Pi wie folgt konfiguriert: "0xf14 Try USB first, followed by SD then repeat"

Alternativ wollte ich die Datenpartition mittels GParted mal von sda2 nach sda3 verschieben. Hab hier nen alten Debian-Laptop

[Otto123]

bin nur nicht sicher, was er dann mit der vorhandenen /sda2 DatenPartition gemacht hätte, da sind einige Daten drauf. Die würde ich dann vorher mal sichern.

Der Imager löscht den Stick komplett, bzw. überschreibt brutal alles. Mach Dir doch keinen Stress und nimm irgendeinen anderen, USB Stick, SD-Card Reader mit einer SD Card, SSD mit USB Adapter...

[Bartimaus]

Ok, zum testen nehme ich mal einen X-beliebigen. Produktiv soll aber wieder mein flotter Stick mit SSD-Speichercontroller zum Einsatz kommen. Aber irgendwas ist bei dem ja.... , weil damit auch davon das reine /rootfs nicht lief.

[Otto123]

Naja ich dachte es geht erstmal ums Prinzip, weil Deine Vorgehensweise klingt nach beliebigen Fehlermöglichkeiten.

[Bartimaus]

Naja, soll schon final von USB laufen.... die Fehlermöglichkeiten sind in der Tat vielfältig, aber da die Vorgehensweise beim 2. Raspi funktioniert hat, muss ja der Wurm nicht in der Vorgehensweise, sondern eher an der verwendeten Hardware liegen 

[Otto123]

Deswegen ja:
definierter USB Stick - bootet der PI wie gewollt?
Wie sieht cmdline und fstab im Original aus?
Den Versuch mit copy rootfs wiederholen und damit das eigene Verfahren verifizieren.

Wenn dann final Dein  "flotter Stick mit SSD-Speichercontroller" wirklich einen Wurm hat - nutzt Dir Gefummel ringsherum auch bloß nicht

[Bartimaus]

Ja, so bin ich auch nach dem letzten erwähnten Absturz vorgegangen, da half auch das aufspielen eines Backups nicht (was sonst funktionierte).

cmdline Original (SD-Karte)

Code Auswählen Erweitern

console=serial0,115200 console=tty1 root=PARTUUID=a82f0a82-02 rootfstype=ext4 fsck.repair=yes rootwait

fstab Original (SD-Karte)

Code Auswählen Erweitern


proc            /proc           proc    defaults          0       0
PARTUUID=a82f0a82-01  /boot           vfat    defaults,flush    0       2
PARTUUID=a82f0a82-02  /               ext4    defaults,noatime  0       1
PARTUUID=00021594-02 /media/ssd ext4 defaults,noatime 0 2
UUID=5C940EF3940ED006 /media/USBStick64/ ntfs-3g utf8,uid=pi,gid=pi,noatime 0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

cmdline (USB-Stick)

Code Auswählen Erweitern


console=serial0,115200 console=tty1 root=PARTUUID=00021594-03 rootfstype=ext4 fsck.repair=yes rootwait

fstab (USB-Stick)

Code Auswählen Erweitern


proc            /proc           proc    defaults          0       0
PARTUUID=00021594-01  /boot           vfat    defaults,flush    0       2
PARTUUID=00021594-03  /               ext4    defaults,noatime  0       1
PARTUUID=00021594-02 /media/ssd ext4 defaults,noatime 0 2
UUID=5C940EF3940ED006 /media/USBStick64/ ntfs-3g utf8,uid=pi,gid=pi,noatime 0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

hier noch die Ausgabe von BLKID

Code Auswählen Erweitern


sudo blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="37E2-62C3" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a82f0a82-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="6a932c1f-7335-42d9-9351-1b1b2ca538d4" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a82f0a82-02"
/dev/sda1: LABEL="FritzUSB64" BLOCK_SIZE="512" UUID="5C940EF3940ED006" TYPE="ntfs"
/dev/sdb1: SEC_TYPE="msdos" UUID="D32C-D66A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="00021594-01"
/dev/sdb2: UUID="339473c6-e9f2-469e-92be-cb182dfcbf00" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="00021594-02"
/dev/sdb3: UUID="a21c2c10-b8ba-4112-bc50-1a91505b895e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="00021594-03"

[Otto123]

/dev/sda1: LABEL="FritzUSB64" BLOCK_SIZE="512" UUID="5C940EF3940ED006" TYPE="ntfs"
/dev/sdb1: SEC_TYPE="msdos" UUID="D32C-D66A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="00021594-01"

Versucht der wirklich alle USB - oder wenn der erste Mist ist gibt er auf?
SEC_TYPE="msdos" liest sich auch komisch. Ich weiß nicht wie die Partition wirklich aussehen muss damit er sie als boot akzeptiert. Die Boot Partition der SD Card sieht anders aus ...

[Bartimaus]

Ja, das mit dem SEC_TYPE ist mir auch aufgefallen. e2fsck hatte auch etwas gemoppert, was ich nicht hinbekommen hatte. aber nach einem neupartitionieren/formatieren ging es... augenscheinlich doch nicht. Ich glaube wirklich, ich hänge den Stick mal an Gparted

Was meinst Du mit "versucht der wirklich....?"
Welcher Parameter sollte gesetzt werden, falls der ein USB-Device nicht findet ? (Damit er dann weiter bootet... ohne ein nicht gefundenes aber definiertes Device)....

[Otto123]

Was meinst Du mit "versucht der wirklich....?"

Du hast als /dev/sda einen Stick dran der definitiv nicht bootet / booten sollte!?

[Bartimaus]

Ob der zu bootende  USB-Stick sda oder sdb ist, spielt doch bei Verwendung der PARTUUID@fstab/cmdline keine Rolle denke ich.... oder ?

Aber ja, er bootet davon nicht, sondern wählt Option B boot@SD-karte

Zuletzt war es sogar so, das das OS gebootet hat, konnte den Pi anpingen, abbber kein Zugriff via SSH oder Webinterface von FHEM. Erst nach dem stromlos schalten mit anschliessendem reboot war der pi@sd-karte wieder erreichbar. Ganz komisch. Ist jetzt aber stochern im Nebel, hoffe ich komme jetzt bald dazu, das mit nem alternativen Stick zu probieren