Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - clausmuus

1
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.

2
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.

3
Meine bisherige Recherche hat ergeben, dass ein Grund für Dein Problem die Spannungsversorgung sein könnte. Beim Booten braucht der RPI alleine bereits sehr viel Strom. Wenn dann zu diesem Zeitpunkt auch noch die SSD aufwacht bricht die Spannungsversorgung zusammen, und die SSD startet nicht sauber. Ursache kann ein zu schwaches Netzteil oder ein schlechtes USB Kabel zwischen Netzteil und RPI sein.

Eventuell würde es bereits ausreichen in der /etc/fstab am ende der ersten genannten Zeile das "1 2" gegen ein "0 0" zu tauschen, da dann der fsck weg fällt (der dei SSD anspricht, beim xfs ansonsten aber nichts weiter macht).

4
Du kannst mal folgendes versuchen:
Ersetze in der /etc/fstab diese beiden Zeilen
Code: [Select]
UUID=b124a098-f5f6-4c16-aab4-9b619a1a5d44 /mnt/b124a098-f5f6-4c16-aab4-9b619a1a5d44 auto noatime 1 2
/mnt/b124a098-f5f6-4c16-aab4-9b619a1a5d44 /data none bind 0 0
durch diese
Code: [Select]
UUID=b124a098-f5f6-4c16-aab4-9b619a1a5d44  /data  auto  defaults,nofail,x-systemd.automount,x-systemd.idle-timeout=10min  0  0
Dies bewirkt, dass die SSD erst dann gemountet wird (das "x-systemd.automount") wenn sie benötigt wird, und verhindert den fsck beim Booten (das "0 0" am Ende)

5
Hi,
an der ld.so.cache liegt es nicht. Da stehen alle verfügbaren libs drin, und die wird auch immer wieder automatisch aktualisiert.

6
Hast Du mal einen Blick in die /etc/ld.so.preload geworfen, ob da noch die Soundtek Lib (libmediaclient.so) drin steht? Falls ja, muss die raus.

7
@franky,
möglicherweise wird beim Update des sundtek Paketes der Eintrag in der /etc/ld.so.preload nicht gelöscht. Überprüfe das mal und entferne den gegebenenfalls.
Ich hatte bei meinem test ob das neue sundtek Paket funktioniert kein Update gemacht, sondern frisch installiert.

Die libc-Korrekturen sind nicht in der MLD enthalten. Ich bin aber auch nicht sicher, ob die relevant sind. Man könnte den Post auch so verstehen, dass Sundtek genau die Funktion überläd, die in der libc fehlerhaft sein soll. In jedem Fall sollte die Sundtek lib beim Booten nicht mehr geladen werden, sondern erst beim VDR Start. Sollte allerdings der VDR für die boot Verzögerungen verantwortlich sein, würde meine Änderung gar nicht helfen. In dem Fall müsste das Boot Problem allerdings verschwinden, wenn das VDR Paket entfernt wird ;)
Ich werde morgen noch mal testen, ob ich das Problem mit meinem RPI-4 nachstellen kann und überprüfe dann die Details.

Übrigens sollte ein Drücken der ESC Taste beim Booten zwischen MLD Logo und Boot Meldungen umschalten. Da kann man dann auch sehen, wobei das Booten hängen bleibt.

8
Ich habe jetzt die Sundtek Fernbedienung (Typ 3) an meinem einfachem Sat Receiver getestet. Die funktioniert auch mit dem aktuellen Treiber.

Ich habe dann auch gleich geprüft welches Protokoll diese sendet. Es ist wie von Sundtek beschrieben das Nec Protokoll.
Es ist aber zu beachten, dass jeder Hersteller eigene Codes sendet. Mit dem Sundtek Receiver werden also nur Sundtek Fernbedienungen funktionieren. Auch wenn Deine ebenfalls im Nec Protokoll sendet, wird der Empfänger also nichts empfangen, wenn es keine Sundtek Fernbedienung ist.

9
Mir war ein Fehler beim sundtek Paket unterlaufen. Den habe ich korrigiert.
Bei meinem Test mit dem RPI-4 funktioniert die Änderung jetzt.

10
Es gibt ein Update für den RPI5. Ihr könnt mal testen, ob es hilft (und weiterhin funktioniert), wenn ihr das VDR und sundtek Paket aktualisiert.
Das sundtek Paket enthält auch ein Versions Update.
Ich habe das so geändert, dass das Preload der Lib nur noch bei ausgesuchten Prozessen erfolgt (z.B. beim VDR), und nicht mehr global für alles.

11
Ich habe die Posts gefunden, die vermutlich diesen Fehler betreffen. Ab hier gibt's die Antwort von Sundtek: https://www.vdr-portal.de/forum/thread/137119-fehler-in-libmediaclient-so/?postID=1386928#post1386928
Demnach gab es Probleme mit dem Lesen von Dateien, wenn dies in Mehreren Thrads parallel erfolgt. Im aktuellen Sundtek Treiber sollte das behoben sein.

12
Hi Franky,

Du kannst mal folgendes versuchen:
- Lösche die .../libmediaclient.so Zeile aus der Datei /etc/ld.so.preload
- Erstelle die Datei /etc/vdr/environment.d/sundtek und füge dort den Pfad aus der /etc/ld.so.preload Datei in der Form "LD_PRELOAD=.../libmediaclient.so" ein.
Dann sollte das Booten wieder klappen und der Sundteck Receiver trotzdem funktionieren.

13
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.

14
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.

15
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.