Raspi bootet nicht mehr von PCIe SSD

Hallo,

ich habe mein System „kaputtgemacht“, obwohl ich – soweit ich es verstehe – nichts geändert habe. Das System bootet im Moment nicht mehr.

Ich hatte einen RasPi 5 mit einem laufenden RaspPi OS Lite auf einer PCIe HatDrive SSD. Alles hat einwandfrei funktioniert, aber jetzt bootet er nicht mehr.

Info:

• Boot-Reihenfolge ist f416:
  1. PCIe
  2. SD-Karte
  3. USB
• Angeschlossene Hardware:
  • PCIe SSD (RasPi OS Lite) -> bootet nicht mehr
  • SD-Karte (RasPi OS Desktop -> wurde genutzt um OS auf externe USB-SSD zu imagen
  • Externe USB-SSD -> sollte als backup der PCIe SSD dienen, falls diese Probleme macht

Ich wollte ein vollständiges Backup des Systems mit allen Daten auf der externen USB-SSD machen. Am Ende sollte es auch möglich sein, von dieser externen SSD zu booten, weshalb der erste logische Schritt für mich war, das gleiche OS auf die externe USB-SSD zu bringen.

Folgende Schritte habe ich im Allgemeinen durchgeführt:

1. Raspi heruntergefahren (OS lief von der PCIe-SSD)
2. PCIe-SSD hardwareseitig ausgebaut
3. Raspi wieder gestartet, der jetzt von der SD-Karte mit einem RasPi OS Desktop gebootet hat
4. Mit dem Raspberry Imager das Raspberry Lite OS auf die externe USB-SSD geschrieben
5. Raspi heruntergefahren
6. SD-Karte hardwareseitig entfernt
7. Raspi neu gestartet, jetzt von der externen USB-SSD gebootet
8. Über Putty den Befehl sudo apt update && sudo apt upgrade -y ausgeführt um das OS auf den aktuellsten Stand zu bringen
9. Raspi mit der externen USB-SSD neu gestartet
10. Raspi ausgeschaltet
11. Die PCIe-SSD hardwareseitig wieder eingebaut
12. Raspi eingeschaltet

→ Jetzt bootet er nicht mehr. Er sollte von der PCIe SSD booten.

Wenn ich die Boot-Reihenfolge auf f461 ändere und die SD-Karte wieder einsetze, wird die PCIe-SSD als externes Laufwerk angezeigt – es liegt also kein Hardwareproblem mit der PCIe-SSD vor.

Soweit ich weiß, verändert der Befehl sudo apt update && sudo apt upgrade -y nur das Betriebssystem auf dem jeweiligen Medium, von dem gebootet wurde – in meinem Fall die externe USB-SSD. Er sollte nichts am EEPROM des Raspi verändern. Deshalb gehe ich davon aus, dass sich durch das Einrichten der externen SSD nichts an der PCIe-SSD oder dem EEPROM des Raspi geändert hat.

Kann mir jemand sagen, was das Problem sein könnte? Ich bin etwas gestresst, da auf der PCIe-SSD meine Nextcloud läuft.

Vielen Dank im Voraus!

Chris

Danke für die schnellen Antworten!

hyle,

Ja, das ist wohl wahr . Hintergrund war, dass ich an dem ursprünglichen System (funktionierende PCIe SSD) möglichst nichts ändern wollte weshalb ich lieber die PCIe SSD ausgebaut hab (auch um nicht ausversehen auf dieser etwas zu ändern...hab da schlechte Erfahrungen).

Aktuell ist f416 mit PCIe SSD angeschlossen und SD Karte gesteckt. Externe USB SSD ist nicht angeschlossen. Er bootet nicht (hängt wohl beim Versuch von der PCIe SSD zu booten und kommt gar nicht zum Versuch von der SD Karte zu booten). Aber auch ohne gesteckter SD Karte bootet er nicht.

RTFM ich denke das dürfte nur auftreten, wenn ich auch zwei identische Geräte gesteckt habe. Also im Fall, dass ich f416 und nur die PCIe SSD gesteckt ist dürfte das Problem nicht auftreten, oder?

Viele Grüße

Folgende Ausgaben:

Bei f416 und nicht gesteckter PCIe SSD, boot von SD Karte und wenn gebootet ist die USB-SSD gesteckt:

XXX@raspberrypi:~ $ lsblk -o name,label,uuid,partuuid
NAME LABEL UUID                                 PARTUUID
sda
├─sda1
│    bootfs
│          EC36-4DE1                            bdc370d0-01
└─sda2
     rootfs
           d4cc7d63-da78-48ad-9bdd-64ffbba449a8 bdc370d0-02
mmcblk0

├─mmcblk0p1
│    bootfs
│          5DC7-F115                            93c36ff5-01
└─mmcblk0p2
     rootfs
           a36be96c-66be-4487-a7a6-0481bca99d89 93c36ff5-02

Bei f461, gesteckter PCIe SSD, gesteckter SD Karte und gesteckter USB-SSD:

XXX@raspberrypi:~ $ lsblk -o name,label,uuid,partuuid
NAME LABEL UUID                                 PARTUUID
sda
├─sda1
│    bootfs
│          EC36-4DE1                            bdc370d0-01
└─sda2
     rootfs
           d4cc7d63-da78-48ad-9bdd-64ffbba449a8 bdc370d0-02
mmcblk0

├─mmcblk0p1
│    bootfs
│          5DC7-F115                            93c36ff5-01
└─mmcblk0p2
     rootfs
           a36be96c-66be-4487-a7a6-0481bca99d89 93c36ff5-02
nvme0n1

├─nvme0n1p1
│    bootfs
│          4EF5-6F55                            d3512064-01
└─nvme0n1p2
     rootfs
           ce208fd3-38a8-424a-87a2-cd44114eb820 d3512064-02

Folgende Ausgabe:

XXX@raspberrypi:~ $ lsblk -o name,label,uuid,partuuid,mountpoints
NAME        LABEL  UUID                                 PARTUUID                             MOUNTPOINTS
sda
├─sda1      bootfs EC36-4DE1                            bdc370d0-01                          /media/XXX/bootfs
└─sda2      rootfs d4cc7d63-da78-48ad-9bdd-64ffbba449a8 bdc370d0-02                          /media/XXX/rootfs
mmcblk0
├─mmcblk0p1 bootfs 5DC7-F115                            93c36ff5-01                          /boot/firmware
└─mmcblk0p2 rootfs a36be96c-66be-4487-a7a6-0481bca99d89 93c36ff5-02                          /
nvme0n1
├─nvme0n1p1 bootfs 4EF5-6F55                            d3512064-01
└─nvme0n1p2 rootfs ce208fd3-38a8-424a-87a2-cd44114eb820 d3512064-02

Was meint ihr denn zu der Annahme, dass das OS Update sudo apt update && sudo apt upgrade -y doch irgendwas direkt am EEPROM verändert hat und nicht nur auf der externen USB-SSD von der damals gebootet wurde?

Erneut danke für eure Rückmeldungen!

hyle Im Moment folgende Ausgabe, da ich von der SD Karte booten will.

XXX@raspberrypi:~ $ rpi-eeprom-config

[all]
BOOT_UART=1
BOOT_ORDER=0xf461
NET_INSTALL_AT_POWER_ON=1

Wenn ich von der PCIe SSD booten will (und auch die SD Karte entferne) folgende Ausgabe:

XXX@raspberrypi:~ $ rpi-eeprom-config
[all]
BOOT_UART=1
BOOT_ORDER=0xf416
NET_INSTALL_AT_POWER_ON=1

Was ich gemacht habe, bevor ich das System auf der PCIe SSD in Betrieb genommen hatte (also lange bevor das jetzige Problem aufgetreten ist und danach hat es ja erstmal alles funktioniert) war noch ein EEPROM-Update mittels sudo rpi-eeprom-update -a. Aber das muss ich ja jetzt eigentlich nicht nochmals machen, da die Konfiguration mit PCIe SSD und dem jetzigen EEPROM Stand bereits lief, oder?

Ja, ich habe immer die 230V über eine schaltbare Steckdose komplett weggenommen, bevor ich die PCIe SSD gesteckt oder rausgezogen habe.

RTFM

Ich versuche deine Ideen mal für mich zusammenzufassen und zu hinterfragen. Ich verstehe es noch nicht so richtig und bitte nicht falsch verstehen, ich bin froh um jede Hilfe:

1. Gleichlautende LABELs

Quote from RTFM

Du hast zwar verschiedene UUIDs und PARTUUIDs, aber drei je gleichlautende LABELs.

Ja, ich habe in der Ausgabe in meinem Post oben gleiche LABELs bei allen drei Speichermedien. Aber wenn ich doch nur die PCIe SSD gesteckt habe (und die SD Karte und die externe USB-SSD nicht), dann dürfte doch dieser Konflikt nicht auftreten, oder?

Quote from RTFM

D.h., dass bei einem Mount einer Partition (die im Grafiksystem im Automount über LABEL primär funktioniert) Du nur über die PARTUUID, oder die UUID durch einen Eintrag in die jeweilige /etc/fstab "automounten" kannst.

Wenn es bei dem RasPi OS Desktop auf der SD-Karte nicht funktionieren würde, verstehe ich die Aussage. Da das Problem auf der PCIe SSD mit RasPi OS Lite auftritt, verstehe ich es aber nicht ganz. Deshalb verstehe ich es so, dass es bei meinem Fall (nur PCIe gesteckt und f416) keinen Unterschied machen dürfte, was ich auf meinem OS auf der SD Karte einstelle, oder verstehe ich etwas ganz falsch?

Quote from RTFM

Das Light-OS auf Deiner NVME braucht jedenfalls die Einträge in /etc/fstab, da es ja kein Grafiksystem besitzt.

Im /mnt/pcie_/etc/fstab der PCIe SSD steht folgendes:

  GNU nano 7.2                                fstab
proc            /proc           proc    defaults          0       0
PARTUUID=d3512064-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=d3512064-02  /               ext4    defaults,noatime  0       1
UUID=0fad9c56-7f70-483d-9d2f-c9215de6b9b1 /mnt/ssd1  ext4  defaults,noatime  0  2
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

Dieses sollte meiner Meinung nach gelten, wenn ich Boot-Order f416 und nur die PCIe SSD angeschlossen habe. Hier sind die PARTUUIDs von den beiden PCIe SSD Partitionen hinterlegt. Zusätzlich die UUID der externen USB-SSD. Hier hatte ich nichts geändert und so lief es ja bereits.

Kann es evtl. zu Problemen kommen, da ich hier eben auch die USB-SSD hinterlegt habe? Aber eigentlich müsste er das doch einfach ignorieren, wenn er sie nicht findet (da sie ja nicht angeschlossen ist), oder?

2. dtoverlay

Quote from RTFM

Dazu kommt, dass Du eine PCIe-NVME nur dann betreiben kannst, wenn auch das passende Modul dazu mit einem "dtoverlay= " in die config.txt aufgenommen wird, falls die automatische Initialisierung (mangels angeschlossener NVME ) versagt.

Das klingt plausibel. Folgende config.txt auf der boot Partition der PCIe SSD.

 GNU nano 7.2                      /mnt/pcie_boot/config.txt
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Additional overlays and parameters are documented
# /boot/firmware/overlays/README

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

# Run as fast as firmware / board allows
arm_boost=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[cm5]
dtoverlay=dwc2,dr_mode=host

[all]

Das ist auch die originale config.txt an der ich nichts verändert habe und mit der es ja mal funktioniert hatte. Wenn ich dich jetzt richtig verstehe, kann es sein, dass es damals funktioniert hat, jetzt aber nicht mehr funktioniert, da eine automatische Initialisierung fehlschlägt. Laut Internetrecherche muss ich also zur config.txt ein dtparam=pciex1 und ein dtoverlay=pciex1 hinzufügen und es sollte funktionieren. Das hat allerdings leider auch nicht geklappt .

Sorry, jetzt ist es ein wenig länger geworden, aber ich wollte so viele Infos wie möglich mitgeben.

Yes, das im fstab wars! Mit einem nofail am Schluss funktioniert sie wieder! DANKE Franjo G aber auch an hyle und RTFM für die super und schnelle Unterstützung!

Jetzt kann es mit dem eigentlichen Projekt, ein bootbares Backup der PCIe SSD auf der externen USB-SSD zu erstellen weitergehen

Danke für die Tipps!

Ich hatte im ersten Schritt vor das OS über den Imager auf die externe USB-SSD aufzuspielen und den Rest dann über rsynch zu machen, war mir aber nicht sicher ob das dann alles so funktioniert hätte (auch mit der Docker Umgebung).

Ich habe mir die Dokus von den beiden Tools mal angeschaut...hören sich beide gut an.

Beim raspiBackup hätte ich das Problem, dass ich nur meine "live" PCIe SSD habe und eine weitere USB-SSD die groß genug ist um das Backup draufzuspielen. Heißt ich habe keine Möglichkeit das Backup auf ein weiteres Medium, das groß genug wäre, zurückzuspielen und zu testen.

Das rpi-clone hört sich optimal an, grad wegen der Möglichkeit direkt vom Backup Medium zu booten. Das werde ich mal ausprobieren mit einer SD Karte als Quelle und einem USB Stick als Ziel. Hoffe es ist relativ einfach zu bedienen und klappt problemlos dann auch von PCIe SSD auf USB-SSD, aber das werde ich dann sehen...