Für mich ist das eigentlich eine recht elegante Lösung, aber:
Ich habe noch auf einem anderen Slot ein Image auf dem gleichen Stand, nur ohne "Würgaround " Es ist halt nur schwer, den Fehler in irgend einer Weise zuzuordnen, weil es eben mit den Bootoptionen manchmal funktioniert, meist aber nicht. Ähnlich einer kalten Lötstelle, genau so unberechenbar

Ich weiß nicht einmal, ob die blanke Installation ohne Settingsübernahme und ohne zusätzliche Plugins nicht auch zufällig in den Standby-Modus gebootet hat.

Was kann ich also tun, um dem Übel auf die Spur zu kommen?

Ich hatte, bevor ich diesen Thread eröffnet habe, übrigens das hier gefunden: hdfreaks.cc/index.php/Thread/3…u-und-bleibt-an/?pageNo=1
Da wurde das gleiche Problem auf einer Gigablue auch schon mal diskutiert, ohne daß es meiner Meinung nach zu einem zielführenden Ergebnis gekommen ist.

Wird gemacht. Aber erst morgen

So...wie besprochen das Image ohne Patch gestartet, Debug-Log aktiviert und Box runtergefahren in den Deep-Standby.
Dann Steckdose abgeschaltet und nach gut einer Minute wieder aktiviert.
Die Box fuhr wieder hoch und der Fehler trat trotz der der beiden Einstellungen in den Anpassungen (Standby) mit einer Verzögerung von 2-3 Sekunden wieder auf.

Hier das zugehörige Debug-Log:
Enigma2-debug-20250421_12-46-56.zip

Ich hoffe, das hilft weiter.
Ansonsten erstmal schöne Restostern

Das ist ja seltsam...ich habe direkt vor der Einrichtung unseres Patches ein Full-Backup erstellt und es dann nach dem Einspielen auf den Testslot nach Aktivierung des Debug-Logs heute morgen gestartet. Zudem liegt meine standby.sh des gepatchten Images noch auf /home/root/ (ich weiß, ich muß da irgendwann mal aufräumen ).

Unter diesem Script-Pfad gibt es in der openhdf-7.3-mutant51-108-20250328_multi.zip auch keine standby.sh.

Aber vielleicht ist das ja sogar Teil der Lösung. Den Skriptordner im usr-Verzeichnis scheint es noch nicht lange zu geben. Zumindest habe ich diesen in älteren Versionen des HDF-Images und auch in der 7.5er nicht gefunden.

Mhhh...seltsam.
Wenn ich die Installationsdatei der aktuellen Version entpacke, ist der Ordner usr/scripts vorhanden (im Bild oben), bei einer früheren Version jedoch nicht (darunter).


Deshalb meine Vermutung.

Mache ich nachher mal und liefere das Log nach.
Wird das eigentlich bei einem Neustart neu geschrieben oder angehängt?

Noch was zum Thema /usr/scripts:
Ich habe auch bei einer 6.5er Build 216 auf der Box diesen Ordner entdeckt. Ich weiß aber leider nicht, wie der dahin gekommen sein kann.

Letzteres.
Ich habe eine Logitech Harmony Fernbedienung am Start, die in einer Aktion alle beteiligten Geräte Box, Fernseher, AV-Receiver) einschaltet und auch ausschaltet. Wenn die Box nach dem Einschalten der Steckdose allerdings schon aktiv ist, wird sie stattdessen runtergefahren. Ist die Box allerdings nach dem Schalten via Steckdose im Standby, geht sie zusammen mit den anderen Geräten ganz normal an. Und genau da möchte ich hin

Edit:
Was mir gerade noch zum Debug-Log in Sachen Runterfahren und Neuschreiben beim Start einfällt...geht das überhaupt? Evtl. Speicherort auf Festplatte verlegen und dann über Multiboot auf einen anderen Slot wechseln?

Ach nee...Denkfehler meinerseits. Es wird ja eine neue Datei angelegt und die alte nicht überschrieben.
Hier also das Log incl. Herunterfahren:
Enigma2-debug-20250422_19-55-35.zip

Yep...mach ich morgen
Hier schon mal der Inhalt:

Wird als Cronjob beim Hochfahren der Box gestartet. Die Sleep-Anweisung verzögert die Ausführung derart, daß die Box ca 5 Sekunden nach dem Hochfahren in den Standby-Modus wechselt.

Nachdem ich meine Standby.sh in den Skriptordner des Testimages kopiert habe, war die Box nach dem Neustart völlig aus dem Tritt. Sie hat weder auf die Fernbedienung (nicht die Logitech, sondern die Originale) reagiert noch war sie über das WebIF zu erreichen. Zum Glück ging der SSH-Zugang noch, so daß ich an die Logs herankommen und die standby.sh wieder entfernen konnte.
Ein shutdown 0 über das CLI erzeugt dann einen Crash.

Das Debug-Log sowie die Crashlogs (seltsamerweise gleich zwei) befinden sich im Anhang.

Logs.zip

Was mir bei der Aktion auch wieder aufgefallen ist: Wenn ich von meinem gepatchten Image über Multiboot auf das Testimage wechsele, greifen die Einstellungen in Sachen Standby aus den Anpassungen. Nach einem Neustart des Testimages aus dem Deep-Standby ist das Problem jedoch wieder da, auch ohne daß die Schaltsteckdose im Spiel war.

Ach ja, und eine kleine Korrektur noch: Die Sleepanweisung in meinem derzeit aktiven Skript steht auf 30 Sekunden, nicht auf 40.