Posts by PromiseYou

Perlchamp

Bitte in der Anleitung vermerken, dass /boot geändert wurde auf /boot/firmware (Betrifft: cmdline.txt)

Quote from RTFM

Deine Partitionierung von /dev/sdb und Deine (/etc/fstab)-mounts in #5 sind grauslig.

-/dev/sdb hat überhaupt keine Partition für das EXT4 Filesystem (BACKUP)
-/dev/sda2 kollidiert mit /dev/nvme0n1p2
-/dev/sda3 ist viel zu groß

Dazu gesellt sich noch ein Zeichensatzfehler.

Servus !

proc            /proc           proc    defaults          0       0

# a swapfile is not a swap partition, no line here
# use  dphys-swapfile swap[on|off]  for that

# SD-RAM 4GB on Chip
# BOOT-Partition
# ROOT-Partition
PARTUUID=ff37a851-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=ff37a851-02  /               ext4    defaults,noatime  0       1

# Partitionen auf NVME0 256GB
# User-HOME
# Nextcloud System
# SWAP 
PARTUUID=d2c3b34c-01	/home	ext4	defaults,nofail,noatime	0	2
PARTUUID=d2c3b34c-02   /mnt/NC_WEB     ext4    defaults,noatime,nofail 0       2
/mnt/NC_WEB /var/www/nc	none	bind	0	0
PARTUUID=d2c3b34c-03	none	swap	sw,nofail	0	0

# ext USB HDD 2TB (SDA) 
# SMABA
# Nextcloud Daten
# alter SWAP
PARTUUID=763a960a-8b14-4f65-bcd3-237c0fe20edf	/mnt/SAMBA	ext4	defaults,noatime,nofail	0	2
PARTUUID=2c603593-83b9-4e75-8a87-204d45a08dba  /mnt/NC_DATA        ext4    defaults,noatime,nofail 0       2
/mnt/NC_DATA /var/www/nc/data	none	bind	0	0

# PARTUUID=e1ecdc93-9a1b-4e78-ab23-f9f9efbee4f8	none	swap	sw,nofail	0	0


# ext USB HDD 2TB (SDB)
# BACKUP 
PARTUUID=3cfbe86c-f911-4b26-a38d-0f7f3924234a	/mnt/BACKUP	ext4	defaults,noatime,nofail	0	2

################################################################
# Übersicht HDD's (blkid)
#/dev/nvme0n1p3: UUID="e1894d22-5d3c-4d21-9fff-caccd7810b5e" TYPE="swap" PARTUUID="d2c3b34c-03"
#/dev/nvme0n1p1: LABEL="pi_Home" UUID="b1c5525c-1f66-4579-b876-9cc8a7f643ca" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d2c3b34c-01"
#/dev/nvme0n1p2: LABEL="nextcloud_Arbeit" UUID="51db2ae0-66ea-42ef-b89e-bde69c4c1fcc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d2c3b34c-02"
#/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="5DC7-F115" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ff37a851-01"
#/dev/mmcblk0p2: LABEL="rootfs" UUID="a36be96c-66be-4487-a7a6-0481bca99d89" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ff37a851-02"
#/dev/sdb1: UUID="d9d0be7e-7810-4d8a-9fb6-538ab5bffd14" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3cfbe86c-f911-4b26-a38d-0f7f3924234a"
#/dev/sda2: UUID="81bbbed4-65d1-4e6d-855a-d31258d9d6ac" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Nextcloud" PARTUUID="2c603593-83b9-4e75-8a87-204d45a08dba"
#/dev/sda3: LABEL="SWAP" UUID="9ca2e6bd-4140-4b85-bb5e-214e83fcaed8" TYPE="swap" PARTLABEL="SWAP" PARTUUID="e1ecdc93-9a1b-4e78-ab23-f9f9efbee4f8"
#/dev/sda1: LABEL="SAMBA" UUID="ad443d5c-a69b-416a-be20-4a158dc6809f" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="SMB" PARTUUID="763a960a-8b14-4f65-bcd3-237c0fe20edf"

Hallo RTFM

hier meine aktuelle fstab ... immer noch so schlimm? (oder haben sich meine Recherchen gelohnt?)

So, ich habe da mal einiges auprobiert, was aber in mir Fragezeichen lsst, welche jedoch nicht gelöst werden müssen

Der Lieferdienst eines großen Versandhandels hat mir eben Nachschub an USB-Sticks geliefert. Einen davon habe ich sogleich mit Raspi-Imager bespielt.

Im Pi 5 klappte das Umschalten des Monitors einwandfrei.

dann führte ich ein UPDATE durch, ohne Fehler, dann noch nen DIST-Upgrade oben drauf. auch ohne Fehler.

Also wieder den Stick mit dem Testsystem rein.

Via raspi-config auf wayland zurück gestellt und Fehler reproduzierbar. Obwohl ich heute morgen bereits ein Update erfolgreich durchgeführt habe, dachte ich mir, kann nicht schaden, vor allem dachte ich, ich mache auch ein DIST-UP. Also erst ein UPDATE, und siehe da, es kommen 5 neue Pakete. Dann noch nen DIST-UP, jedoch ohne neuen Pakete.

Pi neu gestartet, und .. Fehler weg.

Hier jedoch nochmal etwas mehr aus dem Log zum Fehler

Apr 09 12:15:56 raspberrypi sh[783]: Warning: ../src/main.c: 321: Selected output HDMI-A-1 went away
Apr 09 12:15:56 raspberrypi sh[783]: Warning: ../src/main.c: 334: No fallback outputs left. Detaching...
Apr 09 12:16:22 raspberrypi sh[783]: Warning: ../src/main.c: 321: Selected output NOOP-1 went away
Apr 09 12:16:22 raspberrypi sh[783]: Warning: ../src/main.c: 334: No fallback outputs left. Detaching...
Apr 09 12:20:43 raspberrypi sh[783]: wl_display#1: error 1: invalid arguments for zwlr_virtual_pointer_manager_v1#8.create_virtual_pointer_with_output
Apr 09 12:20:43 raspberrypi sh[783]: ERROR: ../src/main.c: 507: Failed to dispatch pending

Quote from Raspi Anfaenger

Umschalten von Wayland auf X11 löst das Problem allerdings und der Raspi läuft wieder wie er soll. Damit kann man das Problem zwar umschiffen, aber eine richtige Lösung ist das nicht.

Yap, kann ich bestätigen. Habe gerade umgestellt, und kann nun zwischen Windows und Pi hin und her schalten.

Naja, wayland ist ja (wenn ich richtig bin) der neue Weg, und wir wissen, wie langsam Bannanen bei uns in Europa reifen (so in den Reifelagern)
Gut dass X11 als alternative so schnell erreichbar ist
Gutes workaround

Quote from Qvrgre

Ich schreibe gerade am Handy, wie wäre es mit den Optionen der config.txt:

1. force_hotplug
2. HDMI_boost

Alles zu finden in der offiziellen Doku der foundation!

Bei mir reicht Nr.1 da ist es egal wann der Monitor eingeschaltet wird, habe immer ein Bild am Monitor, mein Pi läuft 24/7

Hat leider nicht geklappt. .
Auch der Eintrag video=HDMI-A-1:1920x1080M@60 in der cmdline.txt verhilft nicht zum Erfolg.

Ich denke auch nicht, dass es daran liegt, denn der Output liegt ja an. Und mit STRG+ALT+F1 lässt mich ja auch auf die Konsole springen. Somit liegt kein Fehler mit HDMI vor. Vielmehr der X-Desktop verliert seinen Ausgabekanal, und kann somit nicht mehr an senden, bzw. sendet an ????

Ich kann mich jedoch nicht erinnern, dass es mich schon mal gestört hat, somit schließe ich auch ein Softwarefehler nicht aus. Werde gleich mal ein neuen Stick anfertigen und mit einer neuen Version testen. Aber interessant ist es schon

Naja, und Dein Monitor ist am PI, wenn auch aus. Ich trenne aber Pi von Monitor durch den Switch. Der gibt wohl kein Presentsignal, und somit scheint lightdm seinen Ausgang zu verlieren.

Ich habe das gleiche Problem.

Jedoch schaltet der Monitor nur ab, weil der Desktop kein Signal liefert.

Wenn du mit der Tastatur einen anderen Ausgabekanal nimmst, dann kann man auf die Konsole zugreifen (STRG+ALT+F1 = TTY1 = Konsole)

Jedoch weiß ich nicht, wie man von hier aus, den Desktop wieder einschalten kann, um mit ALT+F7 dahin zurück zu wechseln. Mit VNC kann ich zwar dann zum im Speicher stehen Desktop wechseln, aber auf dem PI selber komme ich nicht mehr auf diesen Desktop.

Ich habe irgendwann und irgendwo sowas schon mal gelesen, aber das Betraf halt das "alte" 'X' System.

Nachbauen kann man den Fehler, wenn man im Monitorauswahlmenue den aktiven Monitor deaktiviert.

Hier die passenden Meldungen im Systemlog

Apr 09 14:03:17 raspberrypi sh[779]: Warning: ../src/main.c: 321: Selected output HDMI-A-1 went away
Apr 09 14:03:17 raspberrypi sh[779]: Warning: ../src/main.c: 334: No fallback outputs left. Detaching...

Apr 09 14:05:30 raspberrypi sh[779]: Warning: ../src/main.c: 321: Selected output NOOP-1 went away
Apr 09 14:05:30 raspberrypi sh[779]: Warning: ../src/main.c: 334: No fallback outputs left. Detaching...

Warum einmal HDMI und einmal NOOP weiß ich nicht.

Mich nervt es. Denn wenn ich den PI5 einrichte, mache ich dass meißt an meiner Windows-Büchse wo ich nur den Monitor via Switch umschalte. Jetzt muss ich dauern auf VNC umschalten, wobei das manchmal auch nicht geht, da auf einmal ein Desktop mit der Größe 25866 x 40372 angefordert wird, und dieser dann 'ferngesteurt' wieder beendet wird (lt. Anzeige)

Die Einstellung hdmi_safe=1 in der config.txt reicht nicht aus. Das habe ich bereits versucht

Quote from Franjo G

Aktuell ist noch

Franjo, Du hast ein RollOut welches wohl später zum tragen kommt. Ich habe

Auf der Nextcloud - Homepage habe ich auch mal irgendwo gelesen, dass es beim RollOut bis zu 14 Tage dauern kann.

Und zum ClamAV kann ich auch nichts gutes schreiben. Auf dem Notebook in der Firma lief das super. Ich wollte es auch auf meinem CM5 machen .... URGS

8 gleichzeitige Scans und alle wollen Speicher. Bei mir lief 3 mal alles zu. Seitdem nix mehr. Also nixmehr ClamAV.
Da ich das Ding ja nur für mich nun nutze, ist das okay.

Ich überlege derzeit, das ClamAV auszulagern, und als externen Dienst der Cloud zur Verfügung zu stellen

Bei mir war es, dass der PI sich mit der lokalen IPv6 meldet, aber der DNS die IPv6 vom Router liefert.

Ich trage bei mir die IPv6 mit script in den DynDNS ein.

in Deinem ddDNS steht am Ende 1a5a
Die Portfreigabe im Router endet auf 83b8

und somit schlägt Cerbot von außen auf die 1a5a und somit auf die Fritz, und kann sich somit nicht fnden

Detail: 2a02:908:1900:8::1a5a: Fetching http://schlacht.ddnss.de/.well-known/acme-challenge/SS9hJ0BtAzjE6puHl9BmMSewr1O7DURHPFvfG76Eqq0: Error getting validation data

das sagt die Fehlermeldung

ich habe es so gelöst:

rueckgabe = request.urlopen('https://checkip.spdyn.de/')
inhalt = rueckgabe.read()

# wandle in String um
wert = inhalt.decode("UTF-8")
myurl = "https://update.spdyn.de/nic/update?hostname=%s&myip=%s&user=%s&pass=%s" % (spdynurl, wert, spdynurl, spdyntoken)

Das führe ich als cron alle 4 Stunden durch

Moin, Tach, oder wie auch immer

Nach 4 Tagen fehlerfreien Betrieb mit SWAP auf sda, habe ich nun wieder den SWAP auf der NVME eingeschaltet. Bin nun mal gespannt, ob der Fehler wieder auftritt.

Ich schließe diesen Baum mit offenem Ergebnis

Quote from Raspi Anfaenger

Was für ein CM5 Modul ist denn bei Dir im Einsatz? Die Lite Version ohne Wlan und Bluetooth?. Ich frage, weil mit der gab's das ein oder andere Problem (z.B. plötzliches Abschalten). Ab der Version pieeprom-2025-02-11 sollen dieses Probleme jedoch behoben sein. Es gibt bereits eine noch neuere Version irgendwas aus dem März 2025. Versuch's mal damit....

Gruß Martin

Hallo Martin,

ich nutze einen CM5 mit 4GB Ram und 32GB SD.

Seit dem Update rennt das System ohne Fehler.Derzeit läuft der absolute Härtetest. ClamAV installiert und Nextcloud hat sich der Aufgabe angenommen, alles zu scannen, wo es hingucken kann. Ram und Swap sind bei 100% und die CPU auch. Alles ohne Fehlermeldungen. Ich vermute es war das Update, wobei ich mich frage, warum es beim 'full-upgrade' nicht eingespielt wurde. Es hat über 14 Tage gedauert bis das Update bei mir durch war (Gerade mal nachgeschaut.) WOW

Ich warte noch 2 Tage und dann schließe ich den Thread (wenn nix mehr passiert)

Schau mal hier

GitHub - pwr-Solaar/Solaar: Linux device manager for Logitech devices

Linux device manager for Logitech devices. Contribute to pwr-Solaar/Solaar development by creating an account on GitHub.

github.com

Update:
erstmalig 72 Stunden Up-Time ...

Seid meiner letzten Meldung hier, wurden die Dateien:

firmware-atheros

und 

rpi-eeprom

erneuert.

Beim rpi-eeprom habe ich die Änderungen auf git-hub gelesen. Jedoch finde (ich) nichts, was den Fehler behoben haben könnte.

Beim firmware update habe ich jedoch keine Seite gefunden, wo (ICH) mit zurecht komme, welche Änderungen hier vorliegen, und ob die vielleicht den Fehler beseitigt haben.

Kann mir vllt. jmd. einen Link posten, wo man die Änderungen der Version 20240709-2~bpo12+1+rpt2 gut ersichtlicht sind? (ich finde da immer nur die Katalogseiten von Debian

[EDIT]

mir ist soeben noch etwas aufgefallen. Das Firmware-Atheros war vor Update die Version 20230625-2+rpt3. Sehe ich das richtig, dass dies eine Version von 2023 war?

[/EDIT]

Ich scheine doch nicht alleine davon betroffen zu sein.

habe da soeben einen Beitrag im RasPi Forum gefunden, wo dieses Thema wohl auch besprochen wird. https://forums.raspberrypi.com/viewtopic.php?t=383253
Hier berichten User, dass sie erst seit der Einführung von Bookworm probleme hatten, mit Konfigurationen welche vorher stabil liefen.

Ich gehe dann wohl mal Tee kochen

Klaro

Das Board ist von Waveshare: https://www.waveshare.com/cm5-poe-base-a.htm jedoch ohne dem Netzteil. Hier wird das original 27 Watt Steckernetzteil verwendet.

USB

Bus 004 Device 002: ID 2109:0813 VIA Labs, Inc. VL813 Hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 
  bDeviceProtocol         3 
  bMaxPacketSize0         9
  idVendor           0x2109 VIA Labs, Inc.
  idProduct          0x0813 VL813 Hub
  bcdDevice           90.11
  iManufacturer           1 VIA Labs, Inc.
  iProduct                2 USB3.0 Hub
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001f
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes           19
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval               8
        bMaxBurst               0
Hub Descriptor:
  bLength              12
  bDescriptorType      42
  nNbrPorts             4
  wHubCharacteristic 0x0009
    Per-port power switching
    Per-port overcurrent protection
  bPwrOn2PwrGood      100 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  bHubDecLat          0.4 micro seconds
  wHubDelay          4004 nano seconds
  DeviceRemovable    0x00
 Hub Port Status:
   Port 1: 0000.0203 5Gbps power U0 enable connect
   Port 2: 0000.0203 5Gbps power U0 enable connect
   Port 3: 0000.02a0 5Gbps power Rx.Detect
   Port 4: 0000.02a0 5Gbps power Rx.Detect
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x002a
  bNumDeviceCaps          3
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      HIRD Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat           4 micro seconds
    bU2DevExitLat         231 micro seconds
  Container ID Device Capability:
    bLength                20
    bDescriptorType        16
    bDevCapabilityType      4
    bReserved               0
    ContainerID             {00000000-0000-0000-0000-000000000000}
Device Status:     0x000d
  Self Powered
  U1 Enabled
  U2 Enabled

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 
  bDeviceProtocol         3 
  bMaxPacketSize0         9
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0003 3.0 root hub
  bcdDevice            6.06
  iManufacturer           3 Linux 6.6.74+rpt-rpi-2712 xhci-hcd
  iProduct                2 xHCI Host Controller
  iSerial                 1 xhci-hcd.1
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001f
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
        bMaxBurst               0
Hub Descriptor:
  bLength              12
  bDescriptorType      42
  nNbrPorts             1
  wHubCharacteristic 0x0009
    Per-port power switching
    Per-port overcurrent protection
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  bHubDecLat          0.0 micro seconds
  wHubDelay             0 nano seconds
  DeviceRemovable    0x00
 Hub Port Status:
   Port 1: 0000.0203 5Gbps power U0 enable connect
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x000f
  bNumDeviceCaps          1
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x02
      Latency Tolerance Messages (LTM) Supported
    wSpeedsSupported   0x0008
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
Device Status:     0x0001
  Self Powered 

Das müssten die benötigten Infos beinhalten. Nachfolgend 'lsusb', wo der BUS 4 wohl den HUB repräsentiert. Device 2 und 4 sind die Platten, als müsste 1 und 2 zum Controller des HUB gehören (so geraten nicht gewußt)

Angeschlossene Peripherie: USB-Hub aktiv von 'orico', daran 2* USB HDD M3 Portable von Seagate / Maxtor
der Hub wird seit ca. 8 Jahren an PI's (3B und 4) betrieben, und wurde angeschafft, weil 2 andere HUB's probleme machten, und dieser hier noch nie. Somit gehe ich hier von einer vollen Kompatibilität aus.

Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 0bc2:61b5 Seagate RSS LLC Maxtor HX-M201TCB [M3 Portable 2TB]
Bus 004 Device 003: ID 0bc2:61b5 Seagate RSS LLC Maxtor HX-M201TCB [M3 Portable 2TB]
Bus 004 Device 002: ID 2109:0813 VIA Labs, Inc. VL813 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 2109:2813 VIA Labs, Inc. VL813 Hub
Bus 003 Device 002: ID 1a86:8091 QinHeng Electronics USB HUB
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ja, ich habe alles mit PARTUUID gemacht

blkid
/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="5DC7-F115" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ff37a851-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="a36be96c-66be-4487-a7a6-0481bca99d89" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ff37a851-02"
/dev/nvme0n1p1: LABEL="pi_Home" UUID="b1c5525c-1f66-4579-b876-9cc8a7f643ca" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d2c3b34c-01"
/dev/nvme0n1p2: LABEL="nextcloud_Arbeit" UUID="51db2ae0-66ea-42ef-b89e-bde69c4c1fcc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d2c3b34c-02"
/dev/nvme0n1p3: UUID="e1894d22-5d3c-4d21-9fff-caccd7810b5e" TYPE="swap" PARTUUID="d2c3b34c-03"
/dev/sda1: UUID="ad443d5c-a69b-416a-be20-4a158dc6809f" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="SMB" PARTUUID="763a960a-8b14-4f65-bcd3-237c0fe20edf"
/dev/sda2: UUID="81bbbed4-65d1-4e6d-855a-d31258d9d6ac" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Nextcloud" PARTUUID="2c603593-83b9-4e75-8a87-204d45a08dba"
/dev/sda3: LABEL="SWAP" UUID="9ca2e6bd-4140-4b85-bb5e-214e83fcaed8" TYPE="swap" PARTLABEL="SWAP" PARTUUID="e1ecdc93-9a1b-4e78-ab23-f9f9efbee4f8"
/dev/sdb1: UUID="d9d0be7e-7810-4d8a-9fb6-538ab5bffd14" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3cfbe86c-f911-4b26-a38d-0f7f3924234a"

Und ja, die PARTUUID auf der SDA sehen wirklich blöde aus.

Was ich auf jeden fall nicht hatte, waren die Einträge in der config.txt. (dtparam=pciex1 sowie dtparam=pciex1_gen=3)

Da der Fehler ja nur alle paar Tage mal auftaucht, warte ich nun mal ab, ob der Fehler wieder auftaucht. Vielleicht habe ich mich bis dahin auch in das Einbinden von Verzeichnissen eingearbeitet.

yap, stimme ich zu!

ABER

dieses Chaos hat NICHTS mit dem Fehler zu tun. Also schon sehr OT

Um aber diesem "Chaos" etwas Deutlichkeit zu schaffen habe ich die Fehlerhaft eingerichtete SDB mit einer neuen Partion-Table versehen, und dort auch eine 'ordnungsgemäße' Partition eingerichtet. Diese befindet sich nun mit PARTUIID eingebunden als BACKUP

Dann bleibt nur der 'unschöne Fehler', dass das Verzeichnis 'data' als MOUNTPOINT und nicht als BIND ingebunden ist.

Ja, daran arbeitet ich, aber ich habe noch nie mit -bind gearbeitet, so dass mein nächster Schritt ist.

Aber wie bereits gesagt, dieses alles hat nix mit dem Aussetzen des NVME zu tun

Hier nun meine neue fstab:

proc            /proc           proc    defaults          0       0
PARTUUID=ff37a851-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=ff37a851-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

# Partitionen auf NVME0
PARTUUID=d2c3b34c-01    /home   ext4    defaults,nofail,noatime 0       2
PARTUUID=d2c3b34c-02    /var/www/nc     ext4    defaults,noatime,nofail 0       2
# PARTUUID=d2c3b34c-03  none    swap    sw,nofail       0       0

# ext USB HDD 2 TB (SDA) 
PARTUUID=763a960a-8b14-4f65-bcd3-237c0fe20edf   /mnt/SAMBA      ext4    defaults,noatime,nofail 0       2
PARTUUID=2c603593-83b9-4e75-8a87-204d45a08dba   /var/www/nc/data        ext4    defaults,noatime,nofail 0       2
PARTUUID=e1ecdc93-9a1b-4e78-ab23-f9f9efbee4f8   none    swap    sw,nofail       0       0

# ext USB HDD 2 TB (SDB) 
PARTUUID=3cfbe86c-f911-4b26-a38d-0f7f3924234a   /mnt/BACKUP     ext4    defaults,noatime,nofail 0       2

Ja, die SWAP ist noch bei 40GB und damit zu groß ... i know ....

Quote from PromiseYou

Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug

was verfolgt eigentlich dieser Lösungsansatz, welcher im Syslog genannt wird? Muss das in die config oder boot ?

Quote from framp

Die Fehlermeldungen zeigen ziemlich sicher entweder auf Powerprobleme oder NVMe Probleme hin. Vielleicht ist der NVMe nicht offiziell supported von CM5? Wenn ich mich nicht irre gibt es hier im Forum eine Liste von funktionierendem NVMe Speicher auf der RPi5. Die sollten wohl auch bei dem CM5 funktionieren.

da habe ich das gefunden:

Thread

Raspberry Pi 5 HAT+ und SSD NVMe-Kompatiblitätsliste

Hallo an Alle,
Version 54 vom 06.06.2026 (v53 war vom 20.04.26)

schon seit einiger Zeit wünsch ich mir ne Übersicht, welche NVMe -SSDs mit welchen HAT + (oder BAT für Bottom Attached - HAT und BAT wird in dieser Anleitung nicht namentlich unterschieden!) auf dem 5er booten, laufen, rennen und welche es nicht tun.
Klar kann man das Forum durchforsten, aber schon allein der wunderbare Artikel über die "magischen" SSD -Adapter zeigt, wie hilfreich es ist, wenn man eine einheitliche Anlaufstelle…

McDotter

November 27, 2024 at 4:00 PM

danach haben die 'besseren' module (wie auch die EVO) bei den controllern 01, 02 und 03 Probleme. Da mein I/O Board das von Waveshare ist, denke ich, die haben überall die gleichen Chips verbaut, und somit werde ich mal schauen, ob ein gelistetet Modul abhilfe verschafft.

Was jedoch interessant ist, der Status 'Unsafe Shutdowns' hat sich bei den letzten 3 Ausfällen nicht erhöht.
Die 76 stammt von der Einrichtung, bis ich das System das erste Mal stabil hatte (siehe Forum-Beitrag 'CM5 mit 32GB eMMC bootet nicht nach systemcrash')

Die Spannungen überwache ich mit netdata, und dort ist kein Spannungsabfall zu beobachten.

In der Anleitung der Foundation steht etwas wegen Gen3 sei noch nicht 100%. Dann finde ich aber wieder Einstellempfehlungen mit eingeschaltetem Gen3

Kann auch hier der Fehler her kommen? Ist das für die Hardware im Timing ein großes Problem? (Ich kenne nur die damaligen Timing-Probleme bei SD-RAM mit entsprechenden Schreib und Lesezyklen, und wie die im Einklang mit dem Systemclock zusammen zu bringen sind).
Stelle mir auch hier so etwas vor. Wait-State oder so.

Quote from framp

Ok. Dann liegt es wohl nicht an der Power (Ich nehme an Du nutzt einen aktiven USB Hub )

Hat wohl jetzt nichts mit dem eigentlichen Problem zu tun - aber es verwundert mich dass Du den Swap auf die sda mit 40GB gelegt hast. Warum nicht auf die NVMe? Die ist definitiv schneller. Auch sind 40GB wohl etwas überdimensioniert

yup .. ist nen aktiver hub

Hatte zuvor den swap auf der NVME (steht auch noch in der fstab, und die PART ist auch noch da. (8GB)
Als dann der Kernl PANIK bekam, weil er nicht mehr swappen konnte, und es bei mir frostig wurde

Deshalb habe ich mir von den vorhanden partitionen vorne und hinten etwas abgeknabbert, um in der Mitte dann die swap zu haben.

naja, ich scheine mich um eine 10er potenz verschätzt zu haben .. es sollten 4 GB werden nicht 40 war mir dann aber erstmal egal. Dachte ja, dass das swappen den RP1 heiß werden lässt, und das wollte ich ausschalten. Jedoch weiß ich nun, es hat nix mit dem swap zu tun.