[gustavgans]

Ich habe jetzt das "Verständnisproblem" aus dem Topic-Titel rausgenommen... es GIBT ja ein Boot-Problem.

Sowohl schwache Stromversorgung als auch Kabelfehler kann ich definitiv ausschließen. Außer natürlich wenn das nagelneue Oginool-Raspi Netzteil defekt ist. Details:
Raspi-Netzteil "45W", freilich bringt es bei 5,1V (das ist ja das einzige was der RPi5 zieht) "nur" 5A, also gut 25W.
Der RPi5 braucht unter Vollast (die er weder beim Booten noch im Betrieb auch nur annähernd erreicht - Lüfterchen langweilen sich) unter 10W. Die Sundtek zieht max. 0,5A (hängt an USB2 und hat ein externes Netzteil für die LNB-Speisung), also 2,5W. Eine NVMe SSD wird mit 8-10W angegeben. "Meine" externe SSD ist eine 1,8" Intenso "Premium" (falls es Jemanden interessiert: Produktnummer 3823450), die mit geringem Stromverbrauch beworben wird, allerdings kann ich keine Zahlen finden. Es ist nicht gerade ein Ferrari, ich kann mir nicht vorstellen, dass sie mehr als 10W zieht. Sie hängt am RPi an USB3, kriegt also mehr als 0,5A wenn sie mehr möchte.
Ich mag mich irren, aber eine SSD zieht besonders viel Strom bei Schreibvorgängen, weniger beim Lesen. Wenn die MLD mal läuft und der VDR zwei Aufnahmen parallel macht, dann laufen am RPi tatsächlich mal hörbar die Lüfter und die SSD hat maximal viel zu tun. Diese Betriebsart ist absolut stabil. Ich kann mir deshalb nicht vorstellen, dass ich ein Hardwareproblem habe.
Franky hatte bei seinen Tests auch festgestellt, dass es gar keine energiehungrige SSD braucht, um das Problem nachzustellen - ein simpler USB-Stick genügt.

Ich habe natürlich in der fstab gespielt. Weder "0 0" hat etwas geändert, noch dass ich mal testweise mit Option "nofail" auf die Bühne gegangen bin.

Vielleicht hilft uns folgende Beobachtung: Beim Booten wartet der RPi ein paar Minuten lang, wie man ja im Logging auch sehen kann. Schließlich blinkt das blaue LED Lämpchen an der SSD dreimal. Genauer gesprochen: Das Lämpchen hat die ganze Zeit Dauerlicht, auch während der Wartezeit. Die Timeouts kommen irgend wie ohne dass sich an der SSD irgend was bewegt. Bis die Zeit endlich um ist: Das Blinkmuster ist AAAAAAN, Aus, An, Aus, Aaaan... (innerhalb ca. 1/2 Sekunde) dann dauert es nochmal 1-2Sekunden und DANN ERST kommt die EmergencyShell. Mangels funktionierendem <ESC> kann ich nicht sehen, was bis dahin an Meldungen aufläuft, aber das Systemlog ist da ja im Grunde auch pusthum noch aussagefähig.

Nachdem ich die EmergencyShell mit <Strg>+D verlassen habe dauert's nur paar Sekunden, dann blinkt mich die SSD genauso nochmal an, dann gehen die Lichter am Sundtek an und danach auch das LiveTV Bild.

Schon wieder ein endloser Roman von mir...

Es handelt sich ja ganz offensichtlich um ein RPi5 spezifisches Problem. Da im Systemlog x-fach Powersaving-Einträge sind MAG ES SO SEIN, dass das Energiemanagement nicht gescheit funktioniert, bis die MLD mal läuft. Mit dem Start des VDR ist aber alles "ready" und auch die USB-Devices "spielen mit".

Vorschlag zur Güte bzw. Bitte: Wenn ich die SSD aus der fstab raus nehme (die MLD braucht sie ja selber ansich gar nicht), würde dann der Bootvorgang erstmal durchlaufen, vermute ich. Aber wenn das so wäre, was müsste ich tun, damit beim Start des VDR die SSD als /data gemountet wird? Also wie "Mounten" geht wüsste ich, aber wo ich das dann einbauen müsste weiß ich nicht. Es gibt bestimmt irgend welche Skripte, die ablaufen, wenn VDR startet/stoppt/einen Timer startet u.ä. Könnte mir dazu bitte Jemand unter die Arme greifen?

Es gab mal ein deutsches VDR Wiki, das gibt's seit Jahren nicht mehr. Bei yaVDR bin ich vermutlich nicht richtig, und im englischen VDR-Wiki hab ich Probleme, etwas zu finden. Wir sind hier bei MLD, nicht bei VDR, aber ich hoffe, dass mir hier Jemand die kleinen Geheinisse lüften mag.

[gustavgans]

Oh, die fstab-Variante mit den x-systemd Optionen hatte ich überlesen. Probiere ich morgen und melde mich danach wieder.

[clausmuus]

Ich habe bei mir schon des öfteren beobachtet, dass vor allem die USB Kabel für Spannungsversorgungs-Probleme verantwortlich sind. Selbst bei einem RPI-Zero, der mit Abstand am wenigsten Strom braucht, führen einige Kabel zu starken Spannungseinbrüchen. Sofern Du nicht nur das offizielle Netzteil verwendest, sondern auch ein offizielles Kabel (sofern es eines gibt), ist dies immer eine möglicher Schwachstelle.
Du musst halt bedenken, dass kurzfristig viel höhere Ströme fließen können, als im Durchschnitt, was für einige Millisekunden zu einem Spannungseinbruch führen kann, was dann den Mount verhindern kann, und ein restart der SSD auslöst.
Frankiys Test mit USB Stick wurde noch vor meinen Änderungen mit dem Lib Preload gemacht.

Wenn die geänderten Mount Optionen nicht helfen sollten, gebe ich Dir Beispiele wie Du den Mount verschieben kannst, bis der Bootvorgang komplett abgeschlossen ist.

[gustavgans]

Sorry hat was gedauert - bin im Job zZt. ziemlich eingespannt...

Die Änderung der fstab laut @clausmuus funktioniert. Der Hochlauf der MLD bis zum Start des Live-TV Bildes dauert nun weniger als 15sec, das MLD-Logo hat gar keine Gelegenheit mehr, sich beim Hochlauf zu zeigen.

Ich habe allerdings etwas weitergespielt und kann jetzt folgendes mitteilen:

- Die "x-systemd.*" Parameter als Optionen in der fstab sind am Ende nicht notwendig, ebensowenig die Abwahl des Dateisystemtests.
- Nicht einmal die Entfernung des Sundtek Preload aus der /etc/ld.so.preload ist notwendig.

In Wirklichkeit hat der RPi5 mit folgenden zwei Dingen ein existenzielles Problem:

- Das Mounten von /data über ein bind auf /mnt/{UUID-der-SSD} bekomme ich überhupt nicht hin.
- Die Verwendung von noatime ist problematisch (lässt sich mit nofail entschärfen).

Meine /etc/ld.so.preload enthält jetzt wieder den Eintrag "/usr/lib/libmediaclient.so".
Der Eintrag für die USB-SSD in der /etc/fstab lautet jetzt "UUID=b124a098-f5f6-4c16-aab4-9b619a1a5d44 /data auto defaults,nofail,noatime 1 2"

Ich hab zwar keine große Ahnung von den Interna in Linux bzw. dem systemd, und auch nicht vom RPi5, aber ich erlaube mir hier mal die erneute Vermutung, dass es bloß ein Initialisierungsproblem mit dem RPi5-spezifischen USB Subsystem gibt. OHNE noatime erfolgt bereits beim initialen Öffnen der USB-SSD ein Schreibvorgang, der wohl den USB zwangsweise auch "aufweckt". MIT noatime geht's schief, lässt sich aber mit nofail einfangen. Mit dem zweistufigen Einbinden per bind scheint es grundsätzlich ein Problem zu geben - der bind wartet wohl nicht lange genug oder überholt den vorigen mount-Prozess.

Ich setze diesen Topic jetzt noch nicht auf "gelöst", denn ich hab zwar bisserl herum experimentiert, glaube aber nicht dass ich kompetent genug bin, um das nun verallgemeinert beurteilen zu können. Vielleicht kann @franky das auch nochmal genauer anschauen. Wenn sich meine Analyse bestätigt, wäre ja eine relativ simple Lösung, für den RPi5 eine etwas andere Einbindung von /data zu implementieren als sonst in der MLD üblich (will sagen: ohne bind - warum machen wir das standardmäßig überhaupt?). Eine ungleich komplexere Aktion wäre der Versuch herauszufinden, weshalb das USB-Subsystem beim RPi5 anders reagiert als andere Architekturen und dies im Kernel abzubilden...

Was aus meiner Sicht definitiv vom Tisch ist: Dass ich ein Problem mit der Stromversorgung habe. Nur am Rande: Natürlich wird das Original-Käbelchen verwendet (20cm lang) und natürlich funzt die SSD an jeder anderen Hardware, die hier herumlungert, auch und gerade mit diesem Käbelchen tadellos.

[clausmuus]

Die Option "noatime" ist nicht das Problem. Diese sorgt dafür dass beim Lesenden Zugriff nicht immer auch geschrieben wird, und ist in diesem Punkt etwas rigider als die Voreinstellung.
Entscheidend ist aber wohl die Option "nofail", die das Abbrechen des Bootens verhindert, wenn Dein USB Laufwerk ein Problem hat.
Und auch Deine Beobachtung, dass der Bind Mount zusammen mit nofail nicht funktioniert ist richtig. Diese Kombination klappt nicht ohne zusätzliche Boot Parameter.
Das etwas umständliche Mounten mit dem Bind, ist dem geschuldet, dass wir sehr viele unterschiedliche Möglichkeiten anbieten, wie Datenlaufwerke eingebunden werden. Damit sich das ganze halbwegs überschaubar und vorhersehbar gestalten lässt, verwenden wir den Umweg über den Bind Mount, der in Deinem speziellen Fall nicht nötig wäre.

Den /usr/lib/libmediaclient.so Eintrag in der /etc/ld.so.preload solltest Du weiterhin entfernen, denn dieser könnte auch irgendwann in der Zukunft Probleme machen, und war vermutlich auch bisher ein Teil Deiner Probleme.

Ich werde mal schauen, wie ich das Mounten des Daten Laufwerkes umbaue, damit die von Dir beobachteten Probleme nicht mehr auftreten. In diesem Bereich habe ich sowieso noch Änderungen vor, in die dann auch Deine Erkenntnisse einfließen werden.

[gustavgans]

Bin gespannt auf neue Erkenntnisse... Wir könnten dieses Topic auf "gelöst" setzen, denn jetzt geht's ja bei mir. Aber ein reproduzierbares Verhalten auch anderswo gäbe der Sache vielleicht mehr Glaubhaftigkeit.

Ganz kurz zu noatime:
Wenn ich das nutze, brauche ich nofail, damit's weiter geht. Wenn ich OHNE noatime arbeite, brauche ich auch kein nofail!
Ich kann mich noch nimmer nicht völlig von der Idee verabschieden, dass die USB-Architektur des RPi5 nicht gänzlich sauber im "System" behandelt wird. Ohne noatime wird ja bereits beim Mounten der initiale Lesezugriff, mit dem bloß geschaut wird "wer das ist", auch ein Schreibzugriff passieren. MIT noatime aber halt nicht. Könnte nun ja sein, dass der USB-HDD Init (von mir aus das "richtige Aufwachen") beim Mount nicht richtig abläuft, durch einen Schreibvorgang jedoch dann implizit mitkommt. Also würden nachfolgende Aktionen wegen unvollständigem Init scheitern, wenn noatime aktiv ist, somit braucht man nofail, jedoch braucht man KEIN nofail wenn man kein noatime verwendet, also beim Mount direkt einen Schreibvorgang bekommt.
Das mag nun ein Geheimnis des Rpi5 sein - und bleiben. Was aber jedenfalls beim RPi5 gar nicht geht, egal wie wir mit nofail und/oder noatime spielen, ist, dass wir /data über einen bind mounten.

Ich glaube zwar nicht dass wir eine reale Chance haben, das wirklich zu entschlüsseln, aber gespannt bleibe ich jedenfalls...

[franky]

Ich glaube auch, dass ein Teil des Problems an der speziellen USB-Architektur des RPI5 liegt, habe aber keine Idee woran es liegen könnte.

Es liegt aber sicher nicht nur an der USB-Architektur des RPI5 oder des RPI4.
Denn auch beim RPI4 wird ja bei installiertem Sundtek-Treiber und einem als /data genuztem USB-Datenträger der Startvorgang extrem verzögert.

Einen sehr großen Anteil hat daher sicher der nicht im Kernel enthaltene Sundtek UserSpace-Treiber.
Denn ohne Sundtek-Treiber mit einem USB-Tuner eines anderen Herstellers, dessen Treiber im Kernel enthalten sind, gibt keine Probleme bei einem RPI4/5 einen USB-Datenträger über bind-mount in der fstab als /data einzubinden.
Das Problem tritt eben nur auf, wenn bei einem RPI der Sundtek-Treiber installiert ist und außerdem ein USB-Datenträger als /data verwendet werden soll.

[clausmuus]

@franky,
Tritt der die Bootverzögerung beim RPI4 auch dann och auf, wenn Du die aktuellen Updates installiert hast und die /etc/ld.so.preload löschst?

[franky]

Ja, es ist beim RPI4 ein ähnliches Verhalten wie beim RPI5.
Die vergeblichen Mount-Versuche der USB-SSD nach /data (ca. 4 Minuten) enden jedoch nicht im Emergency Shell.
Auch beim RPI4 muss nicht unbedingt ein Sundtek-Tuner angeschlossen sein, sondern es reicht alleine die Installation des sundtek Pakets.
Da scheint der sundtek Treiber die USB-Ports des RPI so zu beeinflussen, dass ein Mounten eines USB-Datenträgers nach /data per bind gestört wird.

Aktuell habe ich den Sundtek-Dual an einem NUC7P mit einer USB-SSD als /data im Einsatz, wo das Problem nicht auftritt.
Das Problem tritt eben nur in Kombination RPI-USB, Sundtek-Treiber und USB-Datenträger als /data auf.

[gustavgans]

<quote>Das Problem tritt eben nur in Kombination RPI-USB, Sundtek-Treiber und USB-Datenträger als /data auf.</quote>

Ah ja natürlich! Wir haben also ein eindeutiges Szenario, mit dem es ein definiertes Problem gibt, und wir können die Ursache jedenfalls erstmal außerhalb der MLD verorten. Wenn ich wüsste wie das geht würde ich jetzt:
- Den Topic-Titel ändern in "MLD6.5 auf RPi4&5: (Re)boot Probleme - nur mit USB als /data und Sundtek Treiber", um anderen Lesern einen klareren Bezug zu geben, und
- Den Topic doch nochmal zum Sundtek Support weiterleiten, die wollen ja vielleicht dran forschen, und schließlich
- Einen Kernel-Entwickler anpingen (z.B. bei der RPi Foundation), der kann ja vielleicht mehr zum RPi-USB Design sagen und die richtigen Module für einen sauberen Init benennen.

Eine Kleinigkeit hab ich aber noch: Auch nachdem ich den preload entfernt hatte, landete der Rpi5 beim Mounten über bind in der EmergencyShell. Irgend etwas ist beim 5er PI also noch bisserl kritischer als beim 4er.

Besten Dank nochmal an alle für die tolle Hilfe.