[gustavgans]

Hallo liebe Community,
ich kämpfe gerade erfolglos mit dem Raspi-Shutdown/Restart:
a) Jeder Boot misslingt und ich lande in der emergency shell
b) Jede Nacht kommt unweigerlich der Shutdown

Zu a)
Hier ein Auszug aus den Systemmeldungen, das ist was zuletzt vor dem Aufruf der EmergencyShell passiert:
Jun 17 20:12:05 MLD systemd[1]: dev-disk-by\x2duuid-AF29\x2d56C2.device: Job dev-disk-by\x2duuid-AF29\x2d56C2.device/start timed out.
Jun 17 20:12:05 MLD systemd[1]: Timed out waiting for device /dev/disk/by-uuid/AF29-56C2.
Jun 17 20:12:05 MLD systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/AF29-56C2.
Jun 17 20:12:05 MLD systemd[1]: Dependency failed for /mnt/AF29-56C2.
Jun 17 20:12:05 MLD systemd[1]: Dependency failed for /data.
Jun 17 20:12:05 MLD systemd[1]: Dependency failed for Local File Systems.
Jun 17 20:12:05 MLD systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
Jun 17 20:12:05 MLD systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
Jun 17 20:12:05 MLD systemd[1]: data.mount: Job data.mount/start failed with result 'dependency'.
Jun 17 20:12:05 MLD systemd[1]: mnt-AF29\x2d56C2.mount: Job mnt-AF29\x2d56C2.mount/start failed with result 'dependency'.
Jun 17 20:12:05 MLD systemd[1]: systemd-fsck@dev-disk-by\x2duuid-AF29\x2d56C2.service: Job systemd-fsck@dev-disk-by\x2duuid-AF29\x2d56C2.service/start failed with result 'dependency'.
Jun 17 20:12:05 MLD systemd[1]: dev-disk-by\x2duuid-AF29\x2d56C2.device: Job dev-disk-by\x2duuid-AF29\x2d56C2.device/start failed with result 'timeout'.
Vorher wird die Hardware korrekt erkannt: Eine Intenso SSD an USB3.
Es braucht ggfs. mehrere "<Ctrl>+D" Aktionen in der EmergencyShell, bis irgend wann der Hochlauf gelingt.
Hier kurz von Hand abgeschrieben, was mir die EmergencyShell sagt (hab das fotografiert und dann abgetippt...):
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.
Drücken Sie die Eingabetaste für Wartungsarbeiten
(oder drücken Sie Strg+D, um fortzufahren):
Es reagiert bisserl unerkennbar, aber <Strg>+D geht mitunter noch paarmal schief, bis es irgend wann dann doch geht.
Bei Misserfolgen kommt wieder die obige "You are in..." Meldung, nachdem die erneuten Abbrüche geloggt wurden:
[ TIME ] Timed out waiting for device SSD_512GB PVR
[DEPEND] Dependency failed for File System Check on /dev/disk/by-uuid/AF29-56C2.
[DEPEND] Dependency failed for /mnt/AF29-56C2.
[DEPEND] Dependency failed for /data.
[DEPEND] Dependency failed for local file systems.
Die USB-SSD ist FAT formatiert und hat den "DOS"-Namen AF29-56C2, es dreht sich also alles um dieses Dings.
Ich hab mal FSCK darauf los gelassen, das findet ein Dirty-Bit, was ich löschen lasse, aber ansonsten jedenfalls
keine Dateisystemfehler. Wenn der Hochlauf von MLD mal geklappt hat ist die SSD (/dev/sda1) als /data gemountet
und VDR kann sie auch verwenden, jedenfalls für "Direktaufnahmen". Ein Timer dagegen versagt.
Ich vermute, dass die SSD sich wegen eigener Powersave-Gedanken schlafen legt, so dass sie beim Booten des Raspi, obwohl der sie ja am USB3-Port richtig erkennt, einfach nicht aufwachen mag.
Was kann ich da machen?
Der Raspi soll ansich ohne externe Tastatur laufen, aber nur so kann ich <Strg>+D senden. Lässt sich die SSD
mit irgend welchen Tricks definiert aufwecken? Oder kann man die Emergency shell durch eine "Endlosschleife"
umgehen, d.h. die Initialisierung wird halt so lange wiederholt bis die SSD endlich aufwacht?
zu b)
Aber im leufenden Betrieb geht es ja leider weiter: Während der VDR auf seinen Aufnahmetimer wartet sollte
sich die SSD nicht schlafen legen bzw. er müsste sie beizeiten aufwecken. Wenn die SSD an einem anderen
Rechner hängt (Linux oder Windows - egal) geht eigentlich alles.
Mir ist insgesamt nicht klar, wie das Suspend- bzw. Restart Konzept eigentlich gedacht ist. Der VDR fährt
den MLD ja zeitgesteuert komplett runter. Wie wacht er dann aber wieder auf? Ich hab bei älteren MLD-
Versionen über das "suspend" Plugin gelesen, das scheint in MLD6.5 nicht mehr vorgesehen zu sein. Damit
würde nur der DVB-Receiver und VDR beendet, aber MLD bleibt am Leben und weckt VDR bei Bedarf (Timer
oder Benutzereingabe per Fernbedienung?) wieder auf. Wie läuft das denn mit MLD V6.5?
Aber vielleicht "würde" das alles ja funktonieren, wenn nur die SSD verfügbar bleibt...
Man ahnt es schon: Ich weiß nicht weiter und hoffe hier auf Hilfe.
Sollte ich mal ein SupportLog generieren?

[clausmuus]

Hi,
wegen der SSD: Hat es einen besonderen Grund, warum Du die mit FAT Formatiert hast? Das bei der MLD üblicherweise für die Daten verwendete XFS wäre die deutlich bessere Wahl, und würde keine Probleme machen. Beim FAT Filesystem ist mit Datenverlust zu rechnen wenn Du den RPI mal hart abschaltest.
Dein FAT Filesystem hat ganz sicher ein Problem. Möglicherweise wird das Fehler Bit bei jedem herunterfahren erneut gesetzt. Es schaut so aus, als würde das Systemd, welches das Mounten übernimmt das fsck Tool für FAT Dateisysteme nicht finden, weshalb es zu Deinen Fehlern kommt.

Beim RPI ist ein automatisches Aufwachen nicht möglich (ohne zusätzliche Hardware). Daher darf das System nicht bei Inaktivität heruntergefahren werden, wenn Timer gesetzt sind. Ich weiß grad nicht auswendig, ob das noch nicht implementiert ist, oder ob Du die Einstellung dafür geändert hast. Jedenfalls solltest Du in den VDR Einstellungen das ausschalten bei Inaktivität deaktivieren.
Bei der MLD-6 ist kein "Suspend" mehr vorgesehen, da die meisten DVB Treiber inzwischen selbständig in einen Energiesparmodus gehen, wenn diese nicht benötigt werden. Das bedeutet, dass wenn Du den RPI als Server nutzt, und kein Ausgabe Device installiert hast, der bei Inaktivität nur sehr wenig Strom braucht (ähnlich viel, wie ein abgeschalteter x86'er PC). Wenn Du den RPI zum TV Schauen nutzt, gibt es Plugins, die das Ausgabegerät bei Inaktivität deaktivieren, was auch den Stromverbrauch reduzieren würde. Oder Du schaltest z.B. manuell auf einen Sender, der nichts empfängt.

[gustavgans]

Danke @clausmuus für die Erklärungen.
a) Dateisystem
Die SSD ist nur deshalb FAT weil das ab Werk so war und ein formatierter Datenträger wird ja erstmal so eingebunden wie er ist. Werde ich in XFS ändern, danke für den Hintergrund.
b) Dateisystemfehler und fsck
Ich hab auf dem MLD System in der Konsole fsck benutzt, es ist also eigentlich da und müsste dann ja auch gefunden werden wenn der systemd es braucht. Das Dirty-Bit kommt immer beim "Runterfahren", weil die SSD noch gemountet ist, bzw. wird halt nicht gelöscht weil das Runterfahren "zu hart" passiert. SSD in anderen Rechner (Linux/Windoof) und Disk prüfen sagt "alles ok". Na ja ich stelle erstmal auf XFS um und dann sehen wir weiter. Da MLD nicht hochfährt wenn /data nicht erreichbar ist: Ich nehme erstmal in den Einstellungen die SSD wieder raus, formatiere sie danach um und stelle sie neu als /data ein - nur zur Sicherheit... oder ich kann irgend wo einstellen, dass MLD hochfährt auch ohne /data, obwohl es in den Einstellungen definiert ist?
c) Suspend etc.
Leider ist mein RPi auch Wiedergabegerät. Es würde mir sicher die Sache etwas erleichtern, wenn ich den Namen des/der Plugins kenne - nicht jeder Name ist ja für Dummies wie mich gleich verständlich...
Der VDR war ursprünglich natürlich so eingestellt, dass er die MLD nach Zeit (Inaktivität und Timer-Brückenzeit) runterfährt. ich hatte noch versucht, durch Auskommentieren der Zeile "--shutdown=..." in der /etc/vdr/conf.d/00-vdr.conf daran etwas zu ändern, aber das hatte nicht geklappt. Jetzt stehen die beiden VDR-Parameter auf "0", also fährt nix mehr runter und natürlich hab ich dabei gemerkt, dass die Sache inklusiv TV-Ausgabe nun halt Leistung zieht... Insofern wäre ein Plugin, mit dem VDR die TV-Ausgabe und vielleicht auch den DVB-Empfänger schlafen schicken kann, solange VDR sie nicht braucht, schon toll.
Andererseits: Wenn der VDR bei seiner "Runterfahr-Funktion" (irgen ein) "shutdown.sh" aufruft, dann müsste es mir doch möglich sein, dort ein paar Klimmzüge einzubauen, etwa zunächst /data ordentlich zu unmounten, paar Sekunden zugeben für WriteCaches und so, und erst dann den shutdown wirklich zu machen. Oder ich könnte in ebendieser shutdown.sh beliebige Aktionen machen, nur eben gerade NICHT das System runterfahren. Da aber das Auskommentieren der "--shutdon=..." Zeile nicht funktioniert hatte ist vielleicht die Mechanik ganz anders und ich müsste anderswo "spielen"?
Zum besseren Verständnis: Den VDRAdmin-Prozess gibt es doch noch, nur macht er keine Suspend-Sachen mehr?

Vielen Dank bis hier!

[clausmuus]

Du kannst in der /etc/fstab in der Zeile mit der SSD am ende das 2 durch eine 0 ersetzten. Dann wird die nicht mehr geprüft. Aber wie gesagt, bei einem FAT Filesystem wirst Du irgendwann Datenverlust haben.

Du kannst im Ordner /usr/share/vdr/shutdown.d eigene Skripte ablegen, die beim Ausschaltversuch ausgeführt werden. Wenn ein Script ein Exitcode zurück gibt (also z.B. ein "exit 1" aufruft), wird das System nicht runterfahren.

[gustavgans]

Inzwischen habe ich die USB3-SSD eingehenden Tests unterzogen (FAT32-Dateisystem ist ok) und dennoch umformatiert. Nach Einholen einiger weiterer Meinungen jedoch nicht XFS, sondern ext4 verwendet. Ist ja nun auch natives Linux Dateisystem, inklusive Journal, angeblich bei Havarien wie Stromausfall letztlich stabiler als XFS und nicht soooo viel langsamer. Einen Flaschenhals erwarte ich damit definitv nicht.
Frisch neu partitionierte (GPT) SSD in den Raspi bei laufendem MLD, In den Einstellungen als Speicher für /data eingerichtet und los probiert.
Ergebnis: Es passiert GENAU DAS SELBE wie zuvor: Timeput des Datenträgers, Emergency-Shell.
Ich glaube nun nicht mehr an ein Dateisystem-Problem, eher schon an einen Powersave-Effekt, denn beim Systemstart-Log steht immer mal wieder was von "Powersave aktiviert". Das hielte ich dann für einen "Fehler im System".
Damit sich das Jemand ansehen kann habe ich ein Support-Log erstellt (jNKwsZ), bitte schau sich das Jemand mal an.
Leider hat der Wechsel der logischen SSD eine weitere Folge, die wirklich unangenehm ist: Das OSD des VDR geht nicht mehr: Wenn ich es aufrufe (<Pos1>) kommt nicht das Vollbild-OSD als Overlay zum Fernsehbild, sondern das Fernsehbild geht weg (schwarze Katze um Mitternacht...), zwei Sekunden später kommt es wieder, zusammen mit dem "kleinen" OSD (wie nach jedem Kanalwechsel), das kleine OSD geht dann auch wie üblich nach paar Sekunden weg. Ich kann somit jetzt nur noch Live-TV und Kanalwechsel machen.
Ich VERMUTE, dass der VDR beim Öffnen des OSD auf /data zugreifen will, etwa um schonmal die Aufnahmenliste zu holen, damit jedoch scheitert. In der Konsole kann ich aber problemlos auf /data zugreifen. Also entweder steht irgend wo in einer VDR-Einstellung noch die alte Platte, oder ich habe ein Rechteproblem? Tatsächlich hat die SSD den Eigentümer root, der im Terminal ja "da" ist, in VDR aber nicht? Solche Probleme gibt es mit FAT32 ja nicht...
Vielleicht hätte ich die SSD unter MLD löschen sollen (Einstellungen/Speichermedien/Den Datenträger löschen), aber nun ist die SSD ja ansich "fertig" bzw. ich könnte ja "irgend eine fremde" SSD mal anstecken wollen. Welchen der 25 vorhandenen Benutzer muss ich denn als "Owner" setzen, damit MLD und alle Apps damit arbeiten können? Einfach "user:users" hat jedenfalls nicht geklappt. Oder sollte ich mit chmod -R 777 /data "alles für alle" freigeben (ungern...)?
Statt einem gelösten Problem (EmergencyShell beim Boot) habe ich jetzt leider eins mehr - Hiiiilfe...

[clausmuus]

Bei der MLD läuft der VDR mit root Rechten. Ein Rechte Problem gibt es also nicht.

Um Probleme zu vermeiden, solltest Du am besten die MLD Standards verwenden. Im Fall es Datenlaufwerkes bedeutet das, für die Daten ein xfs Filesystem. Nur dieses wird von unseren Testern durch getestet. Die anderen Dateisysteme werden zwar auch unterstützt (können also gemountet werden), aber gründlich getestet hat das niemand.
Du solltest also die gesamte SSD wählen und über das Setup löschen.
xfs hat nicht nur Geschwindigkeits-Vorteile. Z.B. werden bei dem auch möglicherweise auftretende Fehler im laufenden Betrieb korrigiert, und nicht beim booten, was den Startvorgang erheblich ausbremsen würde.

Eines Deiner Probleme könnte da dran liegen, dass möglicherweise durch Dein löschen des Datenlaufwerkes auf diesem die Ordner tv, music und photo/vdr fehlen. Prüfe also mal ob die Ordnet /data/tv , /data/music und /data/photo/vdr existieren, und erstelle die mit mkdir ... falls die fehlen.

Außerdem ist mir aufgefallen, dass bei Dir die Datei /etc/vdr/menu.xml leer ist. Dadurch kann der VDR kein OSD Menü anzeigen. Vermutlich kannst Du das durch ein "apt reinstall vdr-plugin-menu" reparieren.

[gustavgans]

Ich habe jetzt alles mit Standardwerten gemacht, EmergencyShell kommt beim Boot zuverlässig weiterhin. SupportLog: McjQ5B (oder yBrfiS).

Kurze Geschichte:
Keine Ahnung wo die menu.xml hin ist... ich konnte auch nirgends eine Standard-Vorlage finden. Aber klar: Das ist der Grund dafür, dass das OSD nicht mehr geht. Hätte ich selber drauf kommen müssen...
Geschaut, ob Neuformatieren (aus den MLD-Einstellungen, also XFS) gegen die Bootprobleme hilft, tut es NICHT.
Nach dem Neu-Formatieren sind natürlich die VDR-Ordner weg, neu angelegt.
Mir fiel auf (WebIF/Information), dass die BTRFS Partition seit einigen Tagen randvoll ist, es lagen nur 4 Snapshots drauf, die ich mal bis auf den letzten gelöscht hatte. Freier Speicher 1,7MB von 14,xGB??
Hab dann den letzten Snapshot zurückgespielt, hätte ja sein können dass das die menu.xml wiederherstellt. Nach der Reboot-Anforderung ging nichts mehr (gar nichts!).
RPi bzw. MLD konnte nur noch durch "Stromausfall" zum Neustart bewegt werden und landete dann in der EmergencyShell, aus der er nicht wieder zu retten ist.
Systemdisk (eine nagelneue 16GB SDCard) in anderem Rechner geprüft: Das BTRFS ist beschädigt und kann nicht repariert werden. Also:
NEUINSTALLATION, diesmal alles auf Standard:
- LAN verwendet, denn WLAN geht mit dem RPi5-Image ja nicht.
- Installation per WebIF über LAN (schön performant).
- SSD gleich verbunden und nochmal komplette Disk gelöscht.
- Nur VDR angewählt, keine anderen Funktionen, auch keinen Server, das Dings läuft ja direkt am TV.

Klar, ich musste alle Einstellungen nochmal machen. Kein Backup, kein Mitleid. Aus einem Backup, das ich JETZT habe, hätte ich mir auch menu.xml, Kanalliste etc. holen können, na ja - verbucht unter dummy-user cleverness.

WLAN wieder eingerichtet.

Aktueller Status:

Bootproblem ist unverändert da: Wenn ich mal einen Neustart brauche, dann lande ich garantiert nach laaangem Timeout in der EmergencyShell und mit <Strg>+D geht's dann weiter = Live-TV nach wenigen Sekunden. Ich glaube an ein grundsätzliches Problem beim MLD Boot, das ich nicht selber lösen kann. Bitte um Hilfe...
Vielleicht sollte doch die aktuelle Hardwareunterstützung ins Install-Image integriert werden? Vielleicht sollte ich das selber machen, habe aber noch nicht verstanden wie das Pimpen des Image geht.

NEUES Problem: Ich erreiche das WebIF NUR DANN über WLAN, wenn auch das LAN-Kabel steckt! Wenn ich statt WebIF übers Netz das lokale WebIF nutze (kann ich aus dem VDR-Systemmenü aufrufen), sagt es mir, dass es sehr wohl mit dem WLAN verbunden sei (Einstellungen/Netzwerk/... sowie Information), Trotzdem geht nicht mal ein PING zum Gateway (network unreachable). Sobald das LAN-Kabel steckt erreiche ich das WebIF über LAN und auch über WLAN. (IPs sind natürlich so konfiguriert, dass sie sich nicht beißen...) Das war bei meiner ersten Installation nicht so. Vermute dass es da eine Priorität gibt, die ich umdrehen müsste. Wo kann ich das tun?

[clausmuus]

Hi,
Dein Problem mit dem Datenlaufwerk werden wir versuchen nachzustellen. Da ich selber keinen RPI-5 habe, werde ich's mit 'nem RPI-4 prüfen. Ansonsten muss einer unser Tester ran

Was Dein WLAN Problem betrifft, dürfte die Erklärung recht einfach sein: Das WLAN hat eine andere IP als das LAN. Sofern Du versuchst den RPI über die LAN IP anzusprechen, wirst Du den natürlich nicht erreichen können, ohne angestecktes LAN Kabel. Und wenn Du's über den Namen versuchst, verweist der sicher auf die LAN IP, da diese zuerst da war, und sofern in der Fritzbox (oder ähnliches) bereits geändert, trotzdem noch 'ne weile in den Caches steht. Versuch's am besten mal über die WLAN IP, das sollte funktionieren.

Wieso Diene System SSD der ersten Installation voll war, kann ich nicht sagen. die vier Snapshots dürften nicht der Grund sein, da die MLD ja nur einige hundert MB belegt, und die Snapshots kleiner sind. Eventuell hattest Du auf der System SSD Aufnahmen gespeichert, bevor Du das Datenlaufwerk hinzugefügt hast. Die alten Aufnahmen werden dabei nicht gelöscht, sondern nur verdeckt.

[franky]

Ich habe heute wieder meinen Test RPI5 reaktiviert und versucht das Problem mit der USB3-SSD und dem WLan zu reproduzieren.
Konfiguriert hatte ich die neu installierte MLD 6.5 (auf 32GB SD-Karte) erst mal für den SatIP Empfang per VTuner.
Dann nacheinander 2 unterschiedliche USB3-SSDs (256GB Intenso und 512GB PNY) als /data eingebunden.
Auf der Intenso war eine alte MLD 5.5 Installation vorhanden deren Data-Partition (XFS) ich als /data eingebunden habe.
Die 512 GB PNY habe ich beim Einbinden über die CheckBox "Datenträger löschen" neu Partitionieren und Formatieren lassen.
Mit beiden SSDs gab es dann erst mal keine Probleme.
Ich habe dann noch von Lan auf WLan um gestellt.
Da war dann zwar der Empfang per VTuner über die WLan Verbinung nicht mehr optimal (manchmal Ruckler), beim Booten gab es aber noch keine Probleme mit der USB-SSD.

Da GustavGans ja einen Sundtek Tuner an seinem RPI5 betreibt, habe ich auch mal das Sundtek Paket installiert und einen SundtekTuner reaktiviert.
Sobald die Sundtek Treiber aktiv sind, gibt es Probleme mit der USB-SSD und dem WLan beim booten.
Ich lande dann auch auf der EmergenyShell.
Mit Enter und exit wird dann zwar der Bootvorgang abgeschlossen und ich habe ein TV-Bild über den Sundtek-Tuner es funktioniert dann aber kein WLan mehr.
Das WebIF erreiche ich dann auch nur noch über die IP-Adresse des Lan-Ports.

Es muss nicht mal ein Sundtek Tuner an einem der USB-Ports angeschlossen sein.
Sobald die Sundtek-Treiber aktiv sind gibt es Probleme mit dem WLan-Chip des RPI5 und der als /data gemounteten USB3-SSD.

Sobald der Sundtek-Treiber wieder deinstalliert ist, bootet der RPI5 wieder ohne Probleme aber der Sundtek-Tuner funktioniert dann natürlich nicht mehr.
Wenn ich alternativ als /data wieder die System-SD einbinde bootet das System ohne Probleme auch bei installiertem Sundtek Treiber.

[clausmuus]

Hi Franky,

Danke mal wieder für Deine super Analyse!

Ich hatte vor einiger Zeit gelesen, dass Sundtek Ihre Treiber geändert hat, damit diese ohne ein LD_CONFIG auskommen, bzw. ohne Preload ihrer Libs. Dies habe ich bisher jedoch nicht übernommen (wenn ich mich richtig erinnere), da wir bisher keine Probleme mit dem Preload hatten.
Da es nicht gerade unwahrscheinlich ist, dass die beschriebenen Probleme damit zusammen hängen, werde ich mir das die nächsten Tage mal anschauen und umbauen.

[gustavgans]

@clausmuus: Wir geraten etwas off-topic mit der WebIF-Geschichte, aber dies kann abgehakt werden, denn ich hab meinen Dummy-Fehler gefunden:
Ich fahre das WLAN mit einer festen IP-Adresse. Bei der ersten Installation hatte ich die auch richtig angegeben, aber beim zweiten Install war ich irgend wie "gereizt!!!" und hab die Subnetmaske verschlafen, d.h. nur "192.168.1.42" eingegeben und nicht "192.168.1.42/24". Maaaaan!!
Ich bitte hiermit untertänigst um Entschuldigung.
Dieser Fehler hatte dann zur Folge, dass erst mit Verbindung des LAN überhaupt ein Subnet bekannt gewesen ist und dann ging halt "alles" und ohne LAN ging "nichts".
Btw ich spreche das WebIF immer über eine IP an, nie über den Namen, deshalb weiß ich immer über welches IF ich die MLD gerade erreiche...

[gustavgans]

@Franky und @cllausmuus
Super toll dass ihr euch um mein Problem kümmert, herzlichen Dank. Wie im vorigen post zu lesen war das WLAN-Problem lediglich mein eigener Dummy-Idiotenfehler. Bei der ersten Installation hat das WLAN ja problemlos funktioniert, nachdem die MLD mal installiert war und die Hardware-Descriptors aktualisiert hatte.
Die Sache mit der EmergencyShell passiert aber unabhängig davon ob ich das WLAN korrekt eingerichtet habe.
@Franky: Ich hatte natürlich zu allererst ein RaspiOS aufgesetzt und die aktuellsten Firmware-Images geholt. Ich nehme an dass die MLD das nicht kann. Original war was vom November 2025 im EEPROM, es gab was von 2026 (ich glaube es war 23.Januar 2026, kann aber auch noch was neuer sein - wenn gewünscht sehe ich nochmal genau nach). Vielleicht hattest du zusätzlich zum Bootproblem auch mit dem WLAN Probleme weil deine Firmware noch etwas älter ist?
@clausmuus: Während meiner Kontakte zu Sundtek haben die mir gesagt, dass es mit dem "neuesten" Treiberpaket irgend ein Problem gegeben hätte und ihr in der MLD deswegen bewusst nicht den neuesten Treiber verwendet. Welche Versionen bzw. Build-Datumswerte da genau gemeint waren habe ich allerdings nicht erfragt. Deshalb bitte Vorsicht mit der Aktualisierung der Sundtek-Software - nicht dass du wegen mir einen neuen Build baust der dann bei zig Anderen nicht mehr geht.
Abgesehen davon: Ich möchte hier gaaanz herzlich danke sagen, dafür dass ihr so engagiert für mich arbeitet. Bin beeindruckt!

[clausmuus]

Auch die MLD hat ein Paket, das nen Tool enthält um die RPI eprom Firmware zu aktualisieren. Das geht aber nur auf der Konsole. Wie das Paket heißt weiß ich allerdings nicht auswendig.

[franky]

Unabhängig vom WLan des RPI5 gibt es beim RPI5 offensichtlich mit USB-Datenträgern ein Problem, die beim Bootvorgang gemountet werden sollen (z.B. nach /data), wenn der Sundtek-Treiber aktiv ist.
Ich habe vorhin den gleichen Test auch bei einem RPI4 gemacht und auch da dauert der Bootvorgang deutlich länger, wenn der Sundtek-Treiber aktiv ist und ein USB-Datenträger gemountet werden soll.
Beim RPI4 landet man zwar nicht im Emergency-Shell, aber die Verzögerung des Bootvorgangs ist doch sehr nervig.

Evtl. macht es ja doch Sinn, dass sich Claus mal den Sundtek Treiber näher anschaut und ggf. umbaut.