Kann man an einem RPi5 festlegen von welchem USB Geräte zu booten ist wenn mehrere USB Geräte angeschlossen sind?

in der "cmdline.txt" steht doch die PARTUUID des /-Verzeichnisses, wenn man also hier den richtigen Eintrag einpflanzt, sollt das System zwar vom /boot des ersten auffindbaren FAT32-Datenträgers starten, doch die Einbindung von /boot könnte man nach dem Starten doch an das entsprechende Verzeichnis des /-Datenträgers anpassen.

Denn /boot ist dann doch nicht mehr im Zugriff, oder?

wenn, dann würde ich von ner SD booten und per PARTUUID oder UUID auf das gewünschte USB-Speichermedium verweisen (wie schon Rasp-Berlin vorgeschlagen hat).
Mit dem Vorteil, man kann per SD-Wechsel den entsprechenden Datenträger aussuchen.
Aber: nach einem Update des Kernels muss /boot auf der SD auch aktualisiert werden. Im Falle mehrere SDs eben alle involvierten Datenträger.
Ich hab damit nur schlechte Erfahrungen gemacht.

Ich fürchte ihr habt beide das Problem nicht verstanden! (oder ich euch nicht)

Folgendes Szenario: Ein aktiver USB-Hub hängt am RPi. In diesem Hub stecken zwei USB-Sticks, auf denen jeweils ein komplettes OS installiert ist. Eine SD oder einen NVMe-Hat gibt es nicht.

Frage: Welcher der beiden USB-Sticks wird gewinnen und als System starten?

Antwort: Es ist nicht der, bei dem Du vorher die config.txt umbenannt hast.

Quote from framp

Diese Methode gefällt mir auch besser da ich dann nicht jedesmal im RPI5 das EEPROM ändern muss

Warum das denn? Du bootest ja bald von einer NVMe. Dann stell die Bootreihenfolge dauerhaft so ein, dass zuerst von SD, dann von USB und dann von NVMe gebootet wird.

Wenn Du nun mit dem Vorhandensein einer config.txt arbeiten kannst, dann ist es doch eine einfache Sache zu bestimmen, was booten soll.

Der Vorteil davon ist, dass auf allen Datenträgern verschiedene OS in verschiedenen Versionen liegen können. Die PARTUUIDs dürfen natürlich nicht gleich sein.

Falls Du versehentlich bei allen die config.txt umbenannt haben solltest, kannst Du einfach eine andere SD mit einem Lite OS in den Slot des RPi stecken, die NVMe mounten und dessen config.txt wieder gerade biegen.

Ich empfehle einen USB-Hub mit Schalter
USB-Port 1 Raspi-OS , Port2 -- Ubuntu , Port3 BSD, Port 4 Stick mit Daten (/home). Dann nur mehr den Schalter umlegen und alles ist gut.
Das funktioniert von Raspi 3 aufwärts gut und problemlos.

Übrigens die Port werden anhand ihrer anschluss-nummer durchlaufen. der erste gefundene gewinnt.

In Deinem Anwendungsfall ist es sogar noch einfacher und ohne config.txt umbenennen machbar, auch wenn ich diese Möglichkeit richtig gut finde.

Du stellst die Bootreihenfolge wie oben geschrieben ein und bootest von USB das OS, wovon ein Backup getestet werden soll und in den SD-Slot des RPi steckst Du (ggf. mit Verlängerung) eine SD, auf die restored werden soll. Dann schubst Du nach dem Backup (evtl. auch von ein am USB angestecktem Laufwerk oder NAS) das Restore an und wenn das fertig ist, bootest Du den RPi einfach neu. Jetzt wird automatisch von der SD gebootet und Du das Restore testen. Ist alles schick, dann RPi runter fahren, SD raus und RPi starten....

Färtsch!

So ähnlich mache ich das bei meinen Backups auf dem RPi 5, allerdings mit NVMe und rpi-clone direkt auf SD-Cardreader am USB.

Ah ok! Ja dann ist das Umbenennen der config.txt in diesem Fall wohl doch der einfachste Weg.

Oder wie wäre es einen Schaltbaren HUB mit zB. 4xUSB-Ports zu verwenden, meine Idee ist es auf einer nVME 2-3 root Partitionen zu erstellen, dann auf 3 verschiedenen Stick's nur die boot mit 3 verschiedenen PARTUUID einzurichten, danach können alle 3 boot-Sticks im HUB verbleiben und bei bedarf Stick 1-3 einschalten und booten, so bräuchte man nicht jedes mal die config.txt zu renamen!

IMHO

EDIT:

Da kann auch ein kernel update kommen da immer die richtige boot zur entsprechenden root verwendet wird, so wie ich mir das gedacht habe.

Lg Qvrgre

Ich hatte auf Intel einmal so ein Multi-Boot-System.......
Da konnte man unterschiedlich Plattendevices damit steuern. Das setzt die jeweilige Partition auf bootable.
Man müsste nachlesen, wie die Firmware vom Raspi den USB-Bus händelt.