Komplett-Havarie (0.3)

Gestern ist das passiert, was ich immer gefürchtet habe: mein yaVDR ist komplett unbrauchbar geworden, und ich blicke nicht mehr durch..

Das ganze passierte einfach so, ohne dass ich mir irgendeiner Schuld (Basteln) bewusst wäre: nach dem Booten verschwand dauernd das Bild nach wenigen Sekunden, um dann wieder kurz aufzutauchen - also dauernder Frontend-Restart. Bootete man neu, war es dann anfangs manchmal wieder OK. Dann lief es mal eine Weile gut, dann fing das wieder an. Und schliesslich war es immer so. Auf der Kommandozeile konnte man mit Müh und Not sowohl vdr wie auch vdr-frontend stoppen - aber eine vdr Instanz blieb noch da, und die konnte sogar Aufnahmen machen. Killt man alles komplett weg (-9), so bleibt noch Xorg mit beträchtlicher Last - killt man das, ersteht es sofort wieder auf. Woher kommt die Last?

Ich habe dann, nachdem eh schon nix mehr ging, ein dist-upgrade gemacht. Danach war das Flackern noch viel schneller, zwischen Schwarz und yavdr-Logo.
Im Log entsprechend (auch vorher schon) vdr-segfaults. Ich habe sämtliche plugins ausser den xine* aus /usr/lib/vdr/plugins/ entfernt - keine Besserung. Ich habe über das Webfrontend (erreichbar, der eine erste vdr Prozess scheint ja "stabil" zu laufen, obwohl ein zweiter vdr Prozess ständig crashed und neu gestartet wird, ebenso wie die vdr-sxfe bzw. xine) von xineliboutput auf xine umgestellt - nun zeigt er halt das nosignal-Logo (immer noch ständige segfaults).

Fazit: komplett unbrauchbar. Vermutlich dank des Update auch noch die FB ausser Gefecht.
In meiner Verzweiflung hatte ich zuletzt auch noch explizit das "zurückgehaltene" yavdr-essentials per apt-get install aktualisiert - eine grundsätzlich schlechte Idee?
Wie könnte man dieses einzelne Paket wieder zurücksetzen? (einige Grundlagen der Ubuntu-Paketverwaltung kenne ich ja inzwischen, aber sowas..)

Was könnte man probieren? Gibt es sowas wie einen "ReInstall" auf Paket-Ebene? Ein Zurücksetzen der Konfiguration?

Oder riecht das gar nach HW-Defekt?

Danke für alle Tips! -
Leider kann ich sie erst ab Freitag Abend nächster Woche umsetzen oder Rückfragen beantworten (es sei denn aus dem Gedächtnis), wenn ich wieder dort vor Ort bin (das kann lustig werden, bis das wieder läuft - man sollte sich für Zweitwohnungen wohl wirklich keinen VDR bauen sondern einfach eine Dreambox kaufen.. aber da kann scheints ja auch wild gebastelt werden..)

Putzfrau? Um Himmels Willen nein, weder bin ich Krösus noch würde ich das Eindringen in meine Privatsphäre haben wollen (aber das ist wohl Geschmackssache, Putzen macht mir auch keinen Spass..) Also der steht da ganz unbehelligt und wohlbehütet in seinem Fach!

Gegen die HW-Theorie spricht halt, dass zB während des dist-upgrade alles glatt lief, da wird ja auch langwierig kompiliert (irgendwas dkms), sowas würde doch auch gerne abbrechen, wenn was Gröberes bei der HW nicht mehr stimmt. Aber klar, memcheck werde ich dann schon mal anwerfen.

((OT: ich sagte mir macht Putzen keinen Spass, nicht dass ich nicht putze. So zweimal im Jahr.. ;))

Kühlung ist gut, liegt ein grosser Lüfter auf allem.
Log-Auszüge: schon klar, nur leider wird das wie gesagt dauern.. war gestern einfach schon zu spät.

Ich war auch erstaunt, dass nach dem dist-upgrade noch was als "zurückgehalten" angezeigt wurde. Ist aber so. Ein yavdr-essentials, das laut Liste installierter Pakete vorher sowas wie 0.2xxxx war und danach nun 0.3xxxx, nach explizitem apt-get install.
Nein, ich habe nie irgendwelche testing/unstable Quellen aktiviert. Lediglich mal eine aus der ich was grauzoniges probiert hatte, wenn auch ohne Erfolg, ist aber schon lange her, und deinstalliert - aber die Quelle ist wohl noch in den apt-sources drin. Aber ist wohl unwahrscheinlich dass von dort ein yavdr-essentials kommt. (definitiv verifizieren geht leider wie gesagt nicht so bald)

Also die Kiste ist zwar noch kein Jahr alt, aber ich werde dann (Ende nächster Woche) auf jeden Fall auch mal in ein Live-Ubuntu reinbooten und sehen was passiert.. Gebe dann Bescheid.

Neues vom Problemkind.

Gestern Abend erst mal in Ubuntu Live gebootet - keinerlei Anzeichen für Hardware-Probleme, auch memtest OK.
Dann daran erinnert, dass ich ein Komplett-Backup der Systempartition gemacht hatte, ca 1 Monat vor der Havarie. Drüberkopiert, und damit war erst mal alles wieder soweit OK - abgesehen davon dass nur das DVB-T interface ging, aber kein Bild auf den Satellitenkanälen über die Satix-Dual-S2 (ngene). Extrem schlechte Werte bei femon, unverändert wenn man Kabel ganz abzieht. Kabel mit Kaufreceiver probiert, OK, Kabel wieder dran. Erst mal nix.

Heute will ich in Ruhe der Sache auf den Grund gehen. Kiste schaltet sofort aus. Jedesmal. OK, erwischt wohl immer PowerOff im grub (gestern ganz normal abgeschaltet, kein Timer). Also per USBStick gebootet und den Eintrag in grubenv entfernt. Bootet wieder.

lspci: Karte da. grep auf kern.log: ngene lädt, inklusive firmware. grep auf user.log: VDR findet beide frontends. Und siehe da: Bild! Alles läuft scheinbar wieder normal. Doch erst mal Reboot probieren.

Und siehe da - wieder alles kaputt: alle 7s VDR-Neustart.

Hier ein typischer Zyklus aus der user.log:
http://pastebin.com/pSSfEFKG

Auffällig sicherlich das "ERROR: can't open DVB device 0/0" - nur dafür gibt es keinen Grund, ausserdem habe ich in jedem Zyklus kurz ein Bild (und manchmal auch eine halbe Sekunde Ton).

# ll /dev/dvb/adapter0/
insgesamt 0
drwxr-xr-x 2 root root 	160 2011-05-21 19:37 ./
drwxr-xr-x 3 root root  	60 2011-05-21 19:37 ../
crw-rw---- 1 root video 212, 0 2011-05-21 19:37 demux0
crw-rw---- 1 root video 212, 3 2011-05-21 19:37 demux1
crw-rw---- 1 root video 212, 1 2011-05-21 19:37 dvr0
crw-rw---- 1 root video 212, 4 2011-05-21 19:37 dvr1
crw-rw---- 1 root video 212, 2 2011-05-21 19:37 frontend0
crw-rw---- 1 root video 212, 5 2011-05-21 19:37 frontend1

Und schliesslich im kern.log:

May 21 20:08:17 xx kernel: [ 1889.027503] vdr[31314]: segfault at 5a0bcc ip 08130a72 sp bf9dcfa0 error 4 in vdr[8048000+143000]
May 21 20:08:24 xx kernel: [ 1895.766426] vdr[31420]: segfault at 219bcc ip 08130a72 sp bffd3980 error 4 in vdr[8048000+143000]
May 21 20:08:31 xx kernel: [ 1902.445934] vdr[31526]: segfault at 421bcc ip 08130a72 sp bfa6ca50 error 4 in vdr[8048000+143000]
May 21 20:08:38 xx kernel: [ 1909.126518] vdr[31633]: segfault at 4bbbcc ip 08130a72 sp bfe3cd50 error 4 in vdr[8048000+143000]
May 21 20:08:44 xx kernel: [ 1915.889086] vdr[31739]: segfault at 18dbcc ip 08130a72 sp bfc31dd0 error 4 in vdr[8048000+143000]

Unendlich so weiter, eben alle 7s.
Warum crasht der bloss andauernd..

Ich habe mal den ein oder anderen kosmetischen Fehler korrigiert, das iptv-plugin gelöscht (apt-get remove hätte jede Menge Pakete deinstallieren wollen, darunter yavdr-essentials, darauf habe ich lieber verzichtet) usw - aber das hatte nicht wirklich was damit zu tun.

Die Fehlermeldung dass er die DVB-devices nicht öffnen kann ebenso wie die Fehler von streamdev-server (Konfiguration ist Standard - nur localhost - wird bisher nicht benutzt - ich hatte ja auch schon mal fast alle Plugins entfernt ohne dass es was gebracht hat) liegen wohl daran, dass da ein vdr nicht wirklich weg ist und noch seine Hand auf den device-files bzw. ports hält. Nach "stop vdr" muss ich noch per "killall -9 vdr" den hängenden Prozess killen.
Die PID der crashenden VDRs ist jeweils die des Haupt-Prozesses, steht dann auch bei "vdr main process (xxxx) killed by SEGV signal" im syslog.

In seltenen Fällen, mit viel Glück, klappt es danach mit einem Neustart "start vdr", und alles läuft. Meistens aber gleicher Ablauf mit ständigen Restarts.

Ich habe jetzt mal an den Anfang der Kette geschaut, der eine erste vdr der am Ende gekillt werden muss.. und es sieht folgendermassen aus: am Anfang starten im Abstand von 1s zwei VDR parallel. Dass die sich dann gegenseitig behindern ist ja naheliegend. Der zweite semmelt ab, zieht die ständigen Restarts nach sich. Der erste läuft bis zum kill -9, dabei steht dann im Log "bak/vdr main process (1197) killed by KILL signal".

Nochmal ein komplettes syslog (ja, noch mit den config-Errors):
http://pastebin.com/8iCRTC01
Fängt oben an mit dem ersten VDR-Start (pid 1197), kurz darauf gefolgt vom zweiten parallelen (1309), und endet als ich den ersten manuell gekillt habe - dazwischen die regelmässigen Neustarts des zweiten.

Bleibt jetzt also die grosse Frage: warum starten da zwei VDR!? Und warum passiert das plötzlich? Wie gesagt, ich hatte den Software-Stand nun ja einfach mal einen Monat zurückgesetzt, und hier nun die gleichen Symptome (die hier beschriebenen) erhalten wie vor zwei Wochen mit dem neueren Stand. Damals ist das nie passiert.

Die Treiber initialisieren laut Ausgabe im syslog übrigens normal, lediglich steht bei beiden frontends "0" - aber der kosmetische Fehler ist glaube ich bekannt vom ngene.

Nebenschauplätze: manchmal ist das Bild "schwarz", man hört Ton. Eingangs-Wechsel am TV hilft nicht. Vielleicht eine Art Screensaver von X?
Shutdown: wenn ich über die Weboberfläche wieder "poweroff kernel" (== grub poweroff / halt) aktiviere, fährt er wieder fortan bei jedem Start direkt sofort wieder runter, erwischt also _immer_ den poweroff. Entferne ich das in grubenv wieder (über Booten vom Stick), führt dafür dann wieder jeder shutdown stattdessen zum Neustart.
Ich hätte ja gerne ein bootmenu, wenigstens für 1 Sekunde, damit einem sowas erspart bleibt. Aber ich nehme mal an eigenes Editieren von /etc/default/grub und Aufruf von update-grub ist nicht kompatibel mit den yavdr-Mechanismen?

Danke fürs Mitdenken!

Heute Nacht fiel es mir wie.. Bretter von den Augen..
Ich hatte dem vdr mal ein -D0 mitgeben wollen - natürlich im /etc/init/vdr.conf - und dabei "vorsichtshalber" das Original in einem Unterverzeichnis bak gesichert. Voila - zwei VDRs. upstart nimmt offensichtlich auch Unterverzeichnisse gerne mit. Man kann sagen "start bak/vdr". Grossartig. Ist auch im Log zu sehen, wäre sicher dem ein oder anderen hier noch aufgefallen.

Ich könnte mich selbst in den A*wertesten treten. Aber ich hasse es auch, wenn solche Automatismen gar zu weit gehen. Wegen so einer Kleinigkeit so viel Zeit vertan.
(Bei der System-Restaurierung hatte ich den alten Stand drüberkopiert, aber nicht vorher komplett gelöscht -> das blieb erhalten)

Offenbar hat manchmal (wo alles klappte) der "richtige" der beiden die Oberhand bekommen, oder das Frontend den richtigen erwischt - und der andere ist vielleicht endgültig gestorben, oder ich habe von den dauernden Restarts des anderen tatsächlich nichts mitbekommen. Mann!

Jetzt wäre es bloss noch schön, wenn man den shutdown/wakeup noch wieder richtig hinbekommen könnte. Ist es falsch, die Zeile in /etc/grub/grubenv zu löschen, wenn er dauernd sofort poweroff macht? Und wie bekomme ich im Einklang mit yavdr ein sichtbares Startmenu für ein paar Sekunden hin??

Natürlich liegt die Datei auch bei mir unter /boot, vertippt noch mal..

Man darf sie nicht editieren, sonst passt die Gesamtgroesse von 1kb (1024 Byte) nicht mehr, und der Befehl grub-reboot, mit dem sie administriert wird, meldet Fehler.
Habe sie auch nochmal vom Backup restauriert, nun klappt es mit dem reboot-shutdown und wakeup wieder. Leiderschaltet der VDR dann aber (wieder wie oben schon berichtet) sofort ab. Also da brauche ich jetzt echt mal Hilfe von jemandem der sich damit genau auskennt, daher mache ich ein neues Topic. Das hier ist ansonsten wohl abgeschlossen, Danke.