Ich weiß ja nicht, ob die Versorgung mit 5 V unbedingt erforderlich ist. Was steht in der Beschreibung (Anleitung) ??
Posts by Franjo G
-
-
-
sonst funktioniert die Umschaltung auf 5 A nicht.
Das Pi 5 hatte ich in #1 übersehen.
Wo soll das offizielle Netzteil denn sonst angesteckt werden, wenn nicht am USB-C Anschluss??? -
-
Was ist da los.
Mangelnde Stromversorgung? (Mysterium)
Bei mangelhafter Stromversorgung ist Wlan eins der ersten Dinge die "abgeschaltet" werden.
-
-
Ich habe jetzt aber nicht nochmals in der offiziellen Doku nachgelesen.
Raspberry Pi hardware - Raspberry Pi DocumentationThe official documentation for Raspberry Pi computers and microcontrollerswww.raspberrypi.com -
-
Daann wird der HAT zumindest erkannt. Aber die NVME nicht.
Bei mir sieht das so aus
Code0000:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21) 0000:01:00.0 Non-Volatile memory controller: Transcend Information, Inc. NVMe PCIe SSD 110S/112S/120S/MTE300S/MTE400S/MTE652T2 (DRAM-less) (rev 03) 0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21) 0001:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge
-
-
-
PS: Jetzt steckt da noch ein weiteres Netzteil fuer ein RPi5 drin
Wird Zeit, dass mal jemand W-Strom erfindet.
-
Das siehst du an folgendem Post.
Der TE hat als Bootreihenfolge "0xf46" eingegeben. #4
Also booten von nvme und dann von USB. (SD ist gar nicht vorgesehen)[all] BOOT_UART=1 POWER_OFF_ON_HALT=0 BOOT_ORDER=0xf46
Trotzdem gibt lsblk folgendes aus
Das System bootet, liest die cmdline.txt, wählt über die PARTUUID zufällig das richtige Medium.
Dann ist die fstab an der Reihe. Hier wird dann über die PARTUUID das falsche Bootverzeichnis erwischt und gemountet.Im normalen Betrieb fällt das gar nicht auf, weil das Bootverzeichnis nicht mehr benutzt wird.
Ein Problem wird das nur, bei einem upgrade, wo auch die Bootdateien upgegradet werden. Dann wird es ekelig.//EDIT
Das ist wie Lottospielen
-
Als SW Tester würde ich sowas abgefangen sehen wollen
Das kann man nicht abfangen. Wenn man einen Datenträger mit dd auf einen anderen Datenträger Klont, dann hat das Original nichts mehr im Rechner verloren. Oder man ändert die IDs.
Das System bootet die entsprechenden Datenträger aufgrund der PARTUUID, die in der cmdline.txt bzw. in der fstab eingetragen sind. Und wenn da durch dd 2 identische PARTUUIDs vorhanden sind, dann gibt es Probleme, weil das nicht mehr eindeutig ist.Das heißt bei dd kannst du nicht beide Datenträger gleichzeitig weiternutzen ohne mit anderen Mitteln einzugreifen.
Das soll es aber jetzt auch gewesen sein.
-
Also irgendwie scheint die Umsetzung der Bootreihenfolge nicht ganz so glücklich gelöst worden zu sein.
Das hat mit der Bootreihenfolge nicht das geringste zu tun.
Das liegt einfach daran, dass dd den kompletten Datenträger incl. IDs klont.
Der Zieldatenträger hat dann die gleichen IDs wie der Quelldatenträger.Wenn du einen Schrank hast mit mehreren Schubladen bei dem 2 ioder drei Schubladen die Nummer 1 haben, und du sagst deinem Kumpel er soll dir den Inhalt von Schublade 1 holen.
Welche Schublade nimmt er dann??? -
muss ich das Skript wieder durchlaufen lassen?
Wenn du das weiterhin wie bisher mit dd machen willst ja.
An deiner Stelle würde ich das Script jetzt noch einmal auf /dev/sda loslassen, da dort noch gleiche UUIDs vorhanden sind. Ist zwar nicht unbedingt nötig aber dann ist alles sauber.
Dann kannst du dich ja mal mit raspiBackup befassen. Ist ein super Bakupscript.
ArticleraspiBackup Installation, Grundeinstellungen, Erstes Backup und Restore
Dieses ist eine Anleitung zur Installation von raspiBackup, nebst Tipps für ein erstes Backup und einen Restore.Franjo GMay 23, 2024 at 8:56 PM -
-
Uff ... da ist ja noch /dev/sda mit denselben UUIDs ...
Das gabe ich gesehen. Ist aber nicht ganz so schlimm, da ja die PARTUUID genutzt wird.
-
Das sieht gut aus. Die Bootreihenfolge hast du aber auf SD als erstes stehen?
-