0.4 WFE vergesslich

  • Es bereitet zwar nicht wirklich Probleme, aber mich würde schon interessieren, woher das kommt (und wieso es anscheinend nur mir passiert - oder ob die SuFu mich überfordert hat):
    Jedes mal, wenn ich in's WFE schaue, sind jede Menge Einstellungen verschwunden, beispielsweise das ausgewählte frontend, die Audio-Einstellung, die Video-Einstellungen (z.B. die 50Hz).
    Eine direkte Auswirkung hat das nicht, der vdr läuft weiterhin mit den zuletzt gesetzten Einstellungen, nur das WFE kann sich diese Einstellungen nicht über längere Zeit merken.
    [edith] ich weiß, "längere Zeit" ist etwas schwammig, aber frei nach Murphy tritt es natürlich nicht auf, wenn ich es gezielt beobachten will (zB Rechner direkt nach Änderungen im WFE rebooten)


    Hat jemand einen Tip, wo es da hakt - oder wie man es einkreisen könnte?


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

    Einmal editiert, zuletzt von NullP ()

  • Hat jemand einen Tip, wo es da hakt - oder wie man es einkreisen könnte?


    Warst Du wieder mal als root unterwegs?


    Albert

  • root? im WFE? ... in's Hotel?
    Wenn du meinst, ob ich mir was kaputtgespielt habe - lässt sich natürlich nie ganz ausschließen, aber im G&G läuft die Kiste wie im Auslieferungszustand. Ein paar Plugins (per WFE) installiert, fstab etwas geändert, ebenso xine-keymap und kürzlich aus bekannten Gründen xine-config. Ansonsten nur aptget update/dist-upgrade.


    Hast du denn eine Idee, wo ich root-Rechte anwenden könnte, um den Effekt zu erzielen?
    Nachtrag: Das wird doch in /var/lib/yavdrdb.hbf gespeichert, oder? Da hab ich garantierz noch nie dran rumgefummelt.


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

    Einmal editiert, zuletzt von NullP ()

  • fstab etwas geändert, ebenso xine-keymap


    Es geht sicher genauer. :D


    Albert

  • Ja, wäre aber sinnlos.
    Weder ein fstab-Eintrag noch das Eintragen von Sondertasten in die keymap dürfen so etwas hervorrufen.
    Wenn ich an irgendwelchen Templates oder Scripten oder der yavdrdb rumgebastelt hätte, dann hätt ich das erwähnt.
    (ich weiß, ich bin grad schrecklich humorlos)


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • * schubs *
    Heute ist es wieder aufgetreten.


    /var/lib/yavdrdb.hdf hat Zeitstempel vom Booten und ist quasi leer.
    /etc/xine/keymap und ...config sind auch nicht mehr Meine (Auslieferungszustand?).
    (Weiter hab ich noch nicht nachgeforscht)
    Nichst besonderes im syslog.


    Seit Tagen keine upgrades und keine Spielereien meinerseits.


    Einzige Besonderheit: Beim ersten Einschalten wurden die Tuner nicht erkannt (passiert leider regelmäßig), zum Neustart hab ich versehentlich reset statt power getroffen. Ist diese *hdf beim Starten etwa schreibend geöffnet? Dann könnte so ein reset die Datei natürlich zerdeppern, so dass sie beim nächsten Start neu angelegt wird.


    Kann jemand was dazu sagen?


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • Dann könnte so ein reset die Datei natürlich zerdeppern, so dass sie beim nächsten Start neu angelegt wird.


    Unwahrscheinlich, weil trotzdem vorhanden, aber wer weiß.


    Hast Du schon mal an SSD FW gedacht?


    Albert


  • Unwahrscheinlich, weil trotzdem vorhanden, aber wer weiß.


    Vorhanden ja, aber wie gesagt mit neuem Zeitstempel und einem leeren Grundgerüst als Inhalt - als ob yavdr eine Art factory reset durchgeführt hätte. Was m.E. denkbar wäre, wenn die Datei beim Starten als defekt erkannt wurde. (Obwohl ich dann einen entsprechenden Log-Eintrag erwarten würde)

    Zitat

    Hast Du schon mal an SSD FW gedacht?

    Ehrlich gesagt: nein.
    1. Lief vor der Inst von yavdr 0.4 und der Oktopus etwa zwei Jahre lang ohne Auffälligkeiten
    2. ein FW-Problem wäre wohl nicht so selektiv, immer nur die Konfigurationsdateien von yavdr zu resetten


    Denkst du da an was spezielles?


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • ein FW-Problem wäre wohl nicht so selektiv, immer nur die Konfigurationsdateien von yavdr zu resetten


    Nein, nichts spezielles und ja, das Problembild ist sehr selektiv. Andererseits hast Du jetzt einen 64 Bit OS.


    Das mit dem Prüfen beim Start auf defekte Dateien bezweifle ich stark. Die Kapazität der Entwickler ist begrenzt. Beantworten kann das nur eine von ihnen, ich kann an diese Stelle nur Vermutungen anstellen.


    Albert

  • ich kann an diese Stelle nur Vermutungen anstellen.


    Da haben wir ja was gemeinsam ;)
    Werd ich wohl noch 'n bisserl beobachten müssen. Vielleicht mal versuchen, in der Startphase alle Dateizugriffe zu protokollieren...


    Danke dir erstmal.


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • Update


    Es wird immer ominöser.
    Heute folgender Ablauf:

    • Rechner kurz nach dem Start wieder sauber runtergefahren
    • Neustart führt zu Hänger, deswegen reset
    • dieser dritte Start funktioniert, aber: etliche Konfigs sind wieder weg

    Und jetzt kommts: Schritt 2 taucht in keinem Log auf! im Syslog folgt auf den shutdown aus 1 direkt der start aus 3 (mit etwa 5 Minuten Pause dazwischen). Im mittlerweile eingerichteten audit-Log genauso. Nur eine leere dmesg.0 hat ainen Zeitstempel aus dem "verschwundenen" Zeitraum.


    Werd mich wohl mal nach einem Exorzisten umschauen müssen. :evil:


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • Werd mich wohl mal nach einem Exorzisten umschauen müssen.


    Ist manchmal auch mein Spruch dem Kunden gegenüber, war aber noch nie nötig. :D


    Also, bevor Du das tust:


    - Sichtprüfung Hardware (Kondensatoren!)
    - Netzteil Tester (falls vorhanden)
    - BIOS Update (welche Ver. ist darauf)
    - SSD FW Update
    - Kabelverbindungen lösen und neu anstecken (auch Steckkarte/n)
    - fsck


    Software-Fehler halte ich für unwahrscheinlich, klingt nach Hardware bzw. FS.


    Ist schon bescheuert, wenn es alle 3-4 Tage auftritt, schlecht reproduzierbar.


    Viel Erfolg.


    Albert

  • SSD FW Update

    Werd mich mal danach umschauen. Dass zum fraglichen Zeitpunkt mehrere Minuten in den Logs fehlen, könnte schon in die Richtung weisen.
    Wackelkontakte etc. halte ich da eher für unwahrscheinlich, da würd ich andere Symptome erwarten - Mainboard und RAM hab ich schon getauscht, Steckkarte auch schon mehrfach neu gesteckt. BIOS-update wäre machbar, hab ich aber Angst vor: hab noch 'n anderes Zotac-Mb, da war jede BIOS-Version schlechter als die vorhergehende... muss ich mir erst mal Mut antrinken.


    Danke für die Hinweise.


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • BIOS-update wäre machbar, hab ich aber Angst vor: hab noch 'n anderes Zotac-Mb, da war jede BIOS-Version schlechter als die vorhergehende


    Version vorher notieren, downgraden geht immer noch.


    Albert

  • OT
    <Wutbürger>
    Da schreibt OCZ auf der FW-Downloadseite in fetten roten Lettern, dass man so ein update nur durchführen sollte, wenn man sich ganz sicher ist, dass man es auch wirklich benötigt - und dann geben sie einem nicht den kleinsten Anhaltspunkt, um das herauszufinden: weit und breit keine Revision History.
    Also einfach mal die neueste (bzw. am wenigsten älteste) Version 1.7 runtergeladen. Im Archiv steckt sogar ein readme mit einem Mini-Changelog - leider nur gegenüber V.1.6, die es aber gar nicht gibt; Klasse.
    Für die noch ältere V.1.51 gibt's sogar eine Anleitung als PDF - narülich ohne Changelog, dafür aber mit Bearbeitungsschritten, die im readme von 1.7 nicht stehen, z.B. dass man erst einen Jumper umstecken muss... ja wie denn jetzt?
    Immerhin wird da erklärt, was für die 1.7 in einem Nebensatz als "destruktive update" fast untergegangen wäre: you WILL loose ALL data
    </Wutbürger>
    Jetzt brauch ich erst mal was flüssiges, um meine Begeisterung zu dämpfen.
    Sry für's auskotzen, aber das musste raus, bevor ich zur Kettensäge greife.


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • man so ein update nur durchführen sollte, wenn man sich ganz sicher ist, dass man es auch wirklich benötigt


    Übersetzung: Problemfall. :D


    Albert

  • In winzigen Trippelschrittchen geht's weiter. Neue Erkenntnisse:

    • Gestern trat das Problem auch nach ordnungsgemäßem shutdown auf, also liegt's nicht am versehentlichen drücken der Reset-Taste.
    • Nach der x-ten Analyse des syslog habe ich endlich herausgefunden, warum das auditing bisher nichts Brauchbares lieferte - es meldet zwar sehr früh, dass es initialisiert und gestartet sei, nimmt seine Arbeit tatsächlich aber erst etwa drei Sekunden später auf. :wand

    Nach einem Neustart mit passendem Kernelparameter sieht das Ganze schon spannender aus: statt popeliger zwei oder drei db-get's tauchen da auch bei einem fehlerfreien Boot zwischen etlichen weiteren db-get's auch drei db-set's auf - damit rückt die Möglichkeit, dass da gelegentlich ein script á la "komplettiere-Erstinstallation" Amok läuft wieder in den Bereich des Möglichen.


    Jetzt kann ich's kaum erwarten, dass es endlich wieder passiert...


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!