Ah, jetzt verstehe ich. Das Paket nvidia-tesla-470-driver aus Bookworm stellt für alte Karten einen Treiber bereit, die vom aktuellen nvidia-driver nicht mehr unterstützt werden. Damit entfällt dann die Notwendigkeit, ein eigenes 470er-Paket zu bauen.
Beiträge von maf
-
-
With Nouveau there may be problems with the hardware video decoder, but then the softhddevice will most likely work with software decoding.
Dann sollte ich es wohl mit nvidia-tesla-470-driver oder einem (selbstgebauten) nvidia-driver versuchen.
Mir ist allerdings nicht klar, was die Unterschiede zwischen bzw. die wechselseiten Vor- und Nachteile von nvidia-tesla-470-driver und nvidia-driver sind. Und deshalb auch nicht, ob sich ein eigenes Paket überhaupt lohnt. Kann jemand mir auf die Sprünge helfen?
# update-glx --config nvidia There are 2 choices for the alternative nvidia (providing /usr/lib/nvidia/nvidia).
Noch habe ich leider keine Wahl :
-
See /usr/share/doc/nvidia-tesla-470-driver/README.txt.gzfor a complete list of supported GPUs and PCI IDs.
Ist deine Karte denn überhaupt dabei?
Ja, da ist sie zum Glück dabei.
-
Danke für den Vorschlag! Als der Fehler auftrat, waren ja die Quellen bereits von Bullseye auf Bookworm umgestellt. Das wieder zurückzudrehen, um den Tesla-Treiber aus Bullseye zu installieren, habe ich mich nicht getraut. Ich habe auch überlegt, den Tesla-Treiber aus Bookworm zu installieren, war mich aber nicht sicher, ob ich dann den Treiberwechsel hinbekommen würde. Deshalb habe ich mich schließlich dazu entschlossen, mit apt autoremove nvidia* --purge den NVIDIA-Treiber zu entfernen. Nach einem Neustart wurde für die Karte automatisch der Nouveau-Treiber benutzt und ich konnte den Upgrade fortsetzen (und letztlich erfolgreich abschließen). Während des gesamten Upgrade war das System zum Glück im Multiuser-Mode.
Eigentlich war ich überrascht, im Netz keine Berichte über diesen Stolperstein gefunden zu haben. Eigentlich sollte doch jeder, der unter Bullseye das Paket nvidia-driver installiert hatte, auf ihn stoßen.
Hat jemand schon Erfahrungen damit gesammelt, wie nvidia-tesla-470-driver und vdr-plugin-softhddevice zusammenspielen? Oder tut es auch die aktuelle, angeblich deutlich verbesserte Version von Nouveau? Oder sollte ich mit Branch 470 von nvidia-graphics-driver ein eigenes Paket für Bookworm bauen?
-
Hallo,
ich habe ein Problem beim Upgrade meines VDR-Testsystems von Bullseye auf Bookworm.
Unter Bullseye habe ich das Paket nvidia-driver für meine NVIDIA GT 710 installiert. Dieses Paket gibt es unter Bookworm nicht mehr. Der richtige Ersatz - wenn ich nicht zum Nouveau-Treiber wechseln will - ist vermutlich das Paket nvidia-tesla-470-driver. Aber wie kann ich den Wechsel zum neuen Paket im Zuge des Upgrades vollziehen?
Der (in der Upgrade-Anleitung empfohlene) erste Schritt des Upgrades erkennt, dass der alte Treiber nicht mehr verfügbar sein wird und meldet den Fehler:
Code
Alles anzeigen# apt upgrade --without-new-pkgs ... Vorbereitung zum Entpacken von .../017-nvidia-legacy-check_525.125.06-1~deb12u1_amd64.deb ... ┌───────────────────┤ Konfiguriere nvidia-legacy-check ├────────────────────┐ │ │ │ Ihr System hat eine Grafikkarte, die nicht mehr vom NVIDIA-Treiber (aus │ │ dem Paket nvidia-driver) bedient wird. Sie möchten das Paket vielleicht │ │ installiert lassen - um beispielsweise eine andere Karte zu betreiben, │ │ aber der folgende Chipsatz wird damit nicht nutzbar sein: │ │ │ │ 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B │ │ [GeForce GT 710] [10de:128b] (rev a1) │ │ │ │ Die oben angegebene Karte benötigt entweder den nicht-freien │ │ Legacy-NVIDIA-Treiber (aus dem Paket nvidia-tesla-470-driver) oder den │ │ freien Nouveau-Treiber (aus dem Paket xserver-xorg-video-nouveau). │ │ │ │ Verwenden Sie den Befehl update-glx, um zwischen mehreren verschiedenen │ │ installierten Treibern hin- und herzuschalten. │ │ │ │ Bevor der Nouveau-Treiber genutzt werden kann, müssen Sie die │ │ NVIDIA-Konfiguration aus xorg.conf (und xorg.conf.d/) entfernen. │ │ │ │ NVIDIA-Treiber installieren trotz nicht unterstützter Grafikkarte? │ │ │ │ <Ja> <Nein> │ │ │ └───────────────────────────────────────────────────────────────────────────┘ *** The following unsupported devices are present in the machine: 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 710] [10de:128b] (rev a1) Aborting nvidia driver installation. dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-eYvkOP/017-nvidia-legacy-check_525.125.06-1~deb12u1_amd64.deb (--unpack): »neues nvidia-legacy-check-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück ... Fehler traten auf beim Bearbeiten von: /tmp/apt-dpkg-install-eYvkOP/017-nvidia-legacy-check_525.125.06-1~deb12u1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
Wie sollte ich jetzt vorgehen?
-
Hallo!
Statt viele eigene Anpassungen in yavdr-ansible vorzunehmen, würde ich gerne ein separates Projekt aufsetzen, in dem meine Playbooks, Roles, ... versammelt sind, und das existierende yavdr-ansible als Ansible Collection nutzen. Ganz naiv habe ich dazu yavdr-ansible um eine Datei galaxy.yml und eine Datei CHANGELOG.yml ergänzt. Es gelingt mir aber noch nicht, dieses Verzeichnis als Collection zu installieren:
Code
Alles anzeigenmalte@Harvey:~$ ansible-galaxy collection install git+file:///home/malte/dev/yavdr-ansible/yavdr-ansible Klone nach '/home/malte/.ansible/tmp/ansible-local-4596y4jtxljs/tmptmul1tq2/yavdr-ansibleok9iqklp'... remote: Objekte aufzählen: 426, fertig. remote: Zähle Objekte: 100% (426/426), fertig. remote: Komprimiere Objekte: 100% (282/282), fertig. remote: Gesamt 426 (Delta 13), Wiederverwendet 287 (Delta 7), Pack wiederverwendet 0 Empfange Objekte: 100% (426/426), 317.97 KiB | 4.75 MiB/s, fertig. Löse Unterschiede auf: 100% (13/13), fertig. Ihr Branch ist auf demselben Stand wie 'origin/maf'. Starting galaxy collection install process Process install dependency map ERROR! Neither the collection requirement entry key 'name', nor 'source' point to a concrete resolvable collection artifact. Also 'name' is not an FQCN. A valid collection name must be in the format <namespace>.<collection>. Please make sure that the namespace and the collection name contain characters from [a-zA-Z0-9_] only. Tip: Make sure you are pointing to the right subdirectory — `/home/malte/.ansible/tmp/ansible-local-4596y4jtxljs/tmptmul1tq2/yavdr-ansibleok9iqklp` looks like a directory but it is neither a collection, nor a namespace dir
Als Werte für namespace und name habe ich in galaxy.yml jeweils yavdr angegeben. Das scheint mir nicht die Ursache für den Fehler. Aber was Ansible betrifft, bin ich noch Anfänger. Vielleicht kann mir jemand weiterhelfen, der sich schon besser auskennt.
-
Ich habe vdrffs um eine zusätzliche Mount-Option nofile (in Anlehung an prlimit(1) bzw. prlimit(2)) ergänzt. Seit ich die auf 4096 (statt des Standwerts 1024) gesetzt habe, tritt der Fehler nicht mehr auf.
/sbin/mount.vdrffs ist ist ein Verweis auf das eigentliche Programm /bin/vdrffs. Diesen Eintrag benutzt mount, wenn /etc/fstab einen Eintrag enthält, der als Typ des Dateisystems vdrffs angibt.
-
Wie wäre es normal mit dem ZDF?
Danke für den Hinweis. Wer hätte gedacht, dass die ÖR noch aus dem Mustopf kommen
-
Deshalb bleiben jetzt noch knapp Tage, um eine Lösung für das Finale zu finden
-
Soweit ich den Aufbau der Seite verstanden habe, enthält sie einen eingebetteten Player. Irgendwo muss da natürlich auch die URL des Streams versteckt sein, aber ...
-
Im Browser kann man sich auf https://www.magentasport.de/basketball die Live-Übertragung anschauen. Aber fürs IPTV-Plugin hilft das m.E. nicht weiter.
-
Ich kenne keine technischen Details. In meiner Zeitung stand lediglich, dass die Spiele der deutschen Mannschaft bei MagentaSport frei empfangbar seien.
-
Eine Frage aus aktuellem Anlass: Ist es möglich, eine unverschlüsselte Sendung bei MagentaSport wie das heutige Halbfinalspiel bei der Basketball-WM mit VDR aufzuzeichnen?
-
Es könnte durch das Setup sein, dass einfach zu viele Dateien auf einmal geöffnet sind.
Sehr gute Idee! In der Tat meldet nfsd auf dem Server den Fehler 24 ('Too many open files'), wenn auf dem Testsystem die Eingabe-/Ausgabefehler anfangen. Dass ich da nicht schon viel früher hingeschaut habe ...
Ich habe daraufhin testweise das Soft-Limit für den vdrffs-Prozess von 1024 auf 4096 erhöht:
Coderoot@spiro:~# prlimit --nofile --pid $(pidof /sbin/mount.vdrffs) RESOURCE DESCRIPTION SOFT HARD UNITS NOFILE max number of open files 1024 4096 files root@spiro:~# prlimit --nofile=4096 --pid $(pidof /sbin/mount.vdrffs) root@spiro:~# prlimit --nofile --pid $(pidof /sbin/mount.vdrffs) RESOURCE DESCRIPTION SOFT HARD UNITS NOFILE max number of open files 4096 4096 files
Und beim nächsten Start des Testsystem gab es keine Fehler mehr, hurra!
Leider weiß ich noch nicht, wie ich die Änderung am besten über den Neustart rette. Die von SHF verlinkte Anleitung und andere, die ich gefunden habe, beschreiben - soweit ich sie richtig verstanden habe -, wie man Begrenzungen für einen Benutzer oder einen Dienst dauerhaft ändern kann. Ich würde sie ja gerne für ein Programm ändern. Sicherlich könnte ich ein Skript schreiben, das nach mount läuft und letztlich obigen Befehl ausführt. Besser wäre wohl eine zusätzliche mount-Option, die das Limit mittels setrlimit(2) ändert. Aber vielleicht gibt es noch einen eleganteren Weg?
-
Du kennst das distributedvideodir Plugin?
Ja, das Plugin ist auf dem Server auch im Einsatz.
Im Unterschied zum distributesvideodir-Plugin ist vdrffs ein virtuelles Dateisystem. Damit kann ich ein in sich geschlosses Dateisytem exportieren, das die Partitionen des alten VDR-Dateisystems zusammenfasst. Es ist mir nämlich nie so recht gelungen, die einzelnen Partitionen so per NFS zu exportieren, dass die Links zwischen den Partitionen auf Client-Seite wieder funktioniert hätten. Außerdem erspart vdrffs die Rekonfiguration auf Server und Client, wenn eine Partition hinzukommt oder wegfällt. Und das distributedvideodir-Plugin gab es - zumindest damals - unter MLD nicht.
Wenn ich wüsste, wie ich die einzelnen Video-Partitionen des Servers exportieren und auf dem Testsystem so importieren kann, dass die Links funktioneren, könnte ich auf dem Testsystem das distributedvideodir-Plugin benutzen und müsste nicht das vdrffs-Dateisystem des Servers benutzen.
-
Mittlerweile habe ich noch einen ganz anderen Verdacht: Kann es sein, dass der alte Server (Intel Pentium 4 541 3.20 GHz) für das Testsystem (Xeon E3-1226 v3 3.30 GHz) schlicht zu langsam liefert? Denn der Server wird nicht nur durch das Software-RAID belastet. Mehr Rechenleistung erfordert sicherlich mein selbstgeschriebenes vdrffs, das mittels FUSE die Partitionen des historischen verteilten VDR-Dateisystems zu einem zusammenfasst, das leicht per NFS exportiert werden kann. Für die RPi-2 MLD-Clients erfüllt vdrfffs seinen Zweck, aber die sind ja auch selbst hübsch langsam.
-
Ich habe jetzt alle beteiligten Kabel und Switches stückweise ersetzt oder überbrückt - und die Fehler treten immer noch auf. Gleich geblieben sind nur die (onboard) Netzwerkkarten der beiden Rechner.
Ich hoffe, ihr habt noch Vorschläge zur Suche nach Problemen mit dem Netzwerk:: Ich haber derzut nur eine: Ein Programm, mit dem ich Netzwerkverbindungen unabhängig von NFS und VDR testen kann? Vielleicht zunächst wischen den beiden Rechnern, dann zwischen einem dritten Rechner und jeweils einem der beiden Rechner?
-
schlechte LAN-Dosen-Verkabelung
Nur um ein mögliches Missverständnis aufzuklären: Nur die langsamen, aber funktionierenden Netzwerkverbindungen zu den MLD-Clients laufen über LAN-Dosen.
Ich habe den Switch im Verdacht.
Meinst Du den am Server oder den am Testsystem?
Ich hatte gehofft, es gäbe vielleicht ein Diagnoseprogramm, das die Fehlerursache zumindest einkreisen könnte. Stattdessen also komponentenweise austauschen oder überbrücken. Ich hatte es befürchtet :-).
Ich werde berichten, ob und wie ich eine Fehlerursache gefunden habe.
-
Antworten in umgekehrter Reihenfolge:
Im Code von VDR prüfen, [...]
Die Fehlermeldungen stammen von LOG_ERROR_STR in recording.c. Zeilen 262 bis 301:
C
Alles anzeigenint cResumeFile::Read(void) ... if (fileName) { ... int f = open(fileName, O_RDONLY); if (f >= 0) { ... else if (errno != ENOENT) LOG_ERROR_STR(fileName); ... FILE *f = fopen(fileName, "r"); if (f) { ... else if (errno != ENOENT) LOG_ERROR_STR(fileName);
und Zeilen 831 bis 900
CodecRecording::cRecording(const char *FileName) ... FILE *f = fopen(InfoFileName, "r"); if (f) { ... else if (errno != ENOENT) LOG_ERROR_STR(*InfoFileName);
Timeouts wenn Festplatten schlafen und geweckt werden müssen
Die Platten auf Server und Testsystem laufen durch.
Stabilität des Netzwerks
Der (dankenswerterweise wiederholte) Hinweis, dass es sich um ein Netzwerkproblem handeln könnte, hat mich zu folgendem Test veranlasst:
Coderoot@taco:~# find /srv/vdr/video/VDR_Recordings_on_spiro\(nfs\)/* -name info -exec cat {} \; > /dev/null
Und in der Tat: Für ein paar Dateien geht alles gut und dann kommen die Fehler:
Codecat: '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Virginia_Woolf/2016-03-27.22.30.10001-0.rec/info': Eingabe-/Ausgabefehler find: ‘/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Max_Frisch’: Eingabe-/Ausgabefehler cat: '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Gerhart_Hauptmann/2016-06-05.23.50.10001-0.rec/info': Eingabe-/Ausgabefehler find: ‘/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Hans_Christian_Andersen’: Eingabe-/Ausgabefehler find: ‘/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Jane_Austen’: Eingabe-/Ausgabefehler ...
Wenn ich find nach jedem Aufruf von cat eine Pause verordne, geht alles gut (zumindest habe ich irgendwann die Geduld verloren, auf eine Fehlermeldung zu warten :-)):
Coderoot@taco:~# find /srv/vdr/video/VDR_Recordings_on_spiro\(nfs\)/* -name info -exec cat {} \; -exec sleep 1 \; > /dev/null
Server und Testsystem hängen jeweils mit einem kurzen Ethernet-Kabel an ihrem Gigabit-Switch. Von Switch zu Switch liegt ein langes Ethernet-Kabel (ich glaube etwa 20 m). Andere Netzwerkprobleme habe ich in der Vergangenheit noch keine festgestellt. Am gleichen Switch wie mein Testsystem hängt u.a. mein Arbeitsplatz und damit dessen Internetverbindung. Und ich habe schon gigabyteweise Dateien von zwischen einem alten Testsytem und dem Server hin- und herkopiert.
Im Vergleich dazu haben meine beiden RPi 2 MLD-Clients, auf denen keine Probleme auftreten, eine abenteuerliche LAN-Verbindung: Vom Switch beim Server führt Ethernet-Kabel zur Wanddose, von dort eine umfunktionierte Telefonleitung (4 Adern, nicht verdrillt) zwei Stockwerke in den Keller zu einem Megabit-Switch und von dort geht es wieder über ehemalige Telefonleitungen in die Zimmer, in denen hinter Dose und Ethernet-Kabel die Clients werkeln. Das funktioniert seit Jahren ohne Probleme.
Ist jetzt die Verbindung zwischen Server und Testsystem "zu schnell" für einen der beteiligten Rechner, oder ist eher eine der Komponenten zwischen Switch am Server und Testsystem (Kabel, Switch am Testsystem, Netzwerkkarte) die Fehlerquelle? Mit Netzwerk-Hardware habe ich leider keine Erfahrung. Wie sollte ich bei der Fehlersuche vorgehen?
-
Hat deine NAS vielleicht ein Dateisystem, was bestimmte Zeichen im Dateinamen nicht akzeptiert?
Das Dateisystem auf auf Server mit vdr 2.2.0 (spiro, Debian Stretch) und yaVDR-Testsystem mit vdr 2.6.1 (taco, Ubuntu Yammy) ist ext4. Wenn meine MLD-Clients auf die Aufzeichnungen auf dem Server zugreifen, gibt es keine Probleme.