[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!