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 ?
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.
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)
Zitat von: RappaSan am 15 August 2022, 11:29:09
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
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
Zitat von: Bartimaus am 15 August 2022, 13:06:55
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...
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.
Naja ich dachte es geht erstmal ums Prinzip, weil Deine Vorgehensweise klingt nach beliebigen Fehlermöglichkeiten. ;)
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 ::)
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 ;)
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)
console=serial0,115200 console=tty1 root=PARTUUID=a82f0a82-02 rootfstype=ext4 fsck.repair=yes rootwait
fstab Original (SD-Karte)
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)
console=serial0,115200 console=tty1 root=PARTUUID=00021594-03 rootfstype=ext4 fsck.repair=yes rootwait
fstab (USB-Stick)
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
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"
Zitat/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 ...
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)....
Zitat von: Bartimaus am 15 August 2022, 15:28:12
Was meinst Du mit "versucht der wirklich....?"
Du hast als /dev/sda einen Stick dran der definitiv nicht bootet / booten sollte!?
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
zuerst wird entschieden welches Gerät gelesen wird, dann wird gelesen was da zu tun ist.
Was Du jetzt meinst: Du startest fest von x und dort steht was zu tun ist. Das geht schon immer auch beim ersten Raspberry. Also die Startinfo steht auf der SD Card und das RootFS liegt auf sda oder wo auch immer.
Ist aber nicht das was Du mit dem Pi 4 machen kannst. Ob der jetzt aber wirklich alle USB Geräte versucht oder bloß eines weiß ich jetzt nicht.
Hm, ich interpretiere USB-Boot so, das ALLES auf dem USB-Stick ist, Boot+Rootfs. SD-Karte müsste man dann entfernen können.
Wenn der aber bei USB-Boot IMMER zuerst auf SDA sucht, und mein USB-Stick als Nr.2 dann als SDB definiert ist.... funktioniert es nicht. Wobei ich mich dann frage, wozu man PARTUUID verwendet und nicht SD/A/B.
Versuch macht kluch.... wir werden sehen...
Ja USB Boot ist so, aber bevor er auf dem USB Gerät liest was zu tun ist muss es erstmal starten.
Aber ev. sind meine Befürchtung nicht richtig:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#multiple-bootable-drives
ZitatWhen searching for a bootable partition, the bootloader scans all USB mass storage devices in parallel and will select the first to respond. If the boot partition does not contain a suitable start.elf file, the next available device is selected.
Trotzdem würde ich, wenn ich Probleme habe, diese nicht dadurch verschärfen, dass noch eine Unmenge anderer Sticks am Gerät stecken. :P
Ist auch ein Argument ::)
Verdächtig fand ich jedoch auch, das ich nach dem Absturz vor ein paar Wochen es wirklich nicht mehr hinbekommen habe, den usb-Stick nur als rootfs zu nutzen....
Zitat von: Otto123 am 15 August 2022, 12:50:16
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
Da hat der Otto recht, eigentlich sollte die Einstellung keinen Effekt mehr haben.
Hatte sie bei mir aber trotzdem (Bullseye).
Hi,
habe jetzt mal Bullseye64Lite auf einem anderen Stick installiert.
Ab in den Raspi, SD-Karte raus.... er bootet von USB.
Soweit so gut.
Dann habe ich den SicherungsUSBStick in der fstab eingebunden, reboot.... keine Reaktion. Zwar anpingbar, aber kein ssh-Zugriff.
RPi stromlos gemacht, und ohne weitere Konfigänderung bootete er, incl. eingebundenem SicherungsUSBStick.
Ok.
Runtergefahren, SD-Karte und anderen (nicht funktionierenden BOOT-USB eingesteckt, diesmal aber an anderem USB-Steckplatz... System bootet, allerdings von der SD-Karte. Durch den Tausch der USB-Ports hat mein SSD-USB-Stick jetzt SDA und der andere Stick SDB.... hat aber trotzdem nicht davon gebootet.
Interessant ist aber die etwas andere cmdconfig.txt den mir der RPIManager auf den Stick geschrieben hat.
Ok, weitersuchen. Jetzt ist mir noch zu warm.
Ich muß nochmal genauer kucken, was ich damals in die config.txt reingeschrieben habe.
Ich meine, ich hab da auch noch ein boot_delay=3 drin...
Wie gesagt, danach funktionierte der spezielle USB-Stick (war glaub ich ein Transcend 4 GB)
Nachgesehen und ausprobiert: boot_delay=3 hat geholfen, max_usb_current ist nicht nötig->wieder rausgeworfen.
Der Vollständigkeit halber verlinke ich mal die offizielle Doku mit Einstieg beim Pi4 (https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-4-boot-flow)
Ich habe es noch nicht komplett verstanden, aber vor dem Pi4 ist eine Datei /boot/bootcode.bin relevant um den Stick als bootfähig zu erkennen. Beim Pi4 wird dieser Code aus dem eeprom geladen und dann für USB diese Logik abgearbeitet:
ZitatWhile USB discover has not timed out
Check for USB mass storage devices
If a new mass storage device is found then
For each drive (LUN)
Attempt to load firmware
...
Ich vermute hier ist die Datei start4.elf gemeint. Wann die Datei config.txt wirklich dran ist weiß ich nicht.
Wahrscheinlich ist für den Erfolg primär wirklich das time out bei der USB Erkennung relevant. Aber das ist nur Halbwissen ...