Posts by Thyor

    Hi,


    Quote

    TomJoad schrieb:
    Wenn irgendwelche in der fstab verzeichneten Dateisysteme nicht montiert werden können, wird vom upstart kein event local-filesystems erzeugt.
    Dann startet kein sshd, kein syslogd, kein X usw. und der Rechner wirkt tot. Aber der vdr startet in yavdr 0.3 unabhängig von den Dateisystemen, wenn die DVB-Treiber geladen sind.
    Es läuft kein Frontend, aber wenn die Partition, wo die Aufzeichnungen landen, montiert ist, kann sogar die Aufnahme gut gehen.


    Das wäre eine logische Erklärung!
    Wenn der Fehler dann auch nicht die erste Platte (yaVDR mit LVM) betraf, sondern die 2. Platte (NAS), die neu eingesetzten 3. Platte oder einen Eintrag in der fstab dazu, dann wäre ein Schreiben auf der yavdr-Platte möglich gewesen und das Mysterium des lebenden toten yaVDR wäre dann auch keins.

    Was mich noch verwirrt:
    Beim fsck der ungemounteten Platten (2 und 3) werden diese als clean angezeigt. Der Mount-Counter steht bei 0 bzw. 1. Ich starte neu und beim Herunterfahren wird dann, ein zeitintensiver Check der 2. Platte durchgeführt. (Den Fortschrittsbalken habe ich nur durch Zufall gefunden, ansonsten hätte ich schon wieder Panik-Attacken bekommen!)

    Wie und wann wird eigentlich entschieden, dass eine Partition beim Herunterfahren geprüft werden soll?


    Nachtrag:
    Bei jedem Shutdown wollte der yaVDR aber weiterhin ein fsck der 2. Platte ausführen. Es waren aber keine FS-Probleme erkennbar.
    Vor längerer Zeit (noch unter easyvdr) hatte ich den automatischen fsck der NAS-Platte nach x Mounts per tune2fs -c0 /dev/sdb1 abgestellt. (u.a. häufiges rebooten wegen Ton-Problemen mit der NVIDIA-Karte und ruck-zuck lag wieder ein fsck an). Jetzt habe ich jetzt eine (hohe) Zahl reingeschrieben. Danach versucht der yaVDR beim Shutdown die Platte nicht mehr ständig zu prüfen.

    Im Forum stand eine Anmerkungen, dass der yaVDR die Zahl nicht korrekt auswerten kann (k.a. ob das korrekt ist) und bisher gab es die ständigen fsck auch nicht.

    Hi,


    Quote

    Hemingway schrieb:
    Da war die System-Partition wohl ro-gemounted, aber yavdr hat wohl kein error-handling, wenn so etwas passiert.


    Also wenn ich nicht die Aufnahmen aus der vermeintlichen downtime gefunden hätte, könnte ich Deiner Einschätzung folgen, da es definitiv keine Logs aus der Zeit gibt! - Das habe ich noch einmal auf der am Freitag gespiegelten Platte überprüft.
    Aber wie haben es die Aufnahmen auf eine Read-only gemounteten Partition geschafft?
    Warum konnte das Logo (init logo-start) nicht angezeigt werden? Beim remount-ro hätte das Script die Dateien ja finden können.


    Was hat sich durch 'defaults' geändert? Die Platte wird wieder RW gemountet - unabhängig, ob ein Error vorliegt oder nicht? Also ist erst mal nur die Sicherung überbrückt und der Fehler nicht behoben!?


    Wie finde ich den Fehler?
    Ich habe die Logs schon mal nach error, mount, yavdr-root "durchgegrept" aber bisher nichts gefunden!
    Das FS scheint sauber zu sein:


    Wie könnte ich den Fehler doch noch finden?

    Hi,


    was ich heute morgen gefunden habe, gehört eigentlich in die Mysterie-Serie X-Faktor!
    yaVDR war tot, aber ich habe dennoch Aufnahmen zwischen dem Crash vom 18.11.10 vormittags und der Reanimation 20.11.10 abends auf der Platte - also immer dann wenn ich den vermeintlichen fsck durchlaufen lassen wollte.
    Wie geschrieben, waren die letzten Logs vom 18.11.2010 9:02 Uhr.

    Hi,


    da im logo-start nicht wirklich was aufregendes passiert und bestenfalls das Fehlen der Logo-Dateien zu einem Fehler führen könnte, aber die Dateien da sind, wo sie seien sollten und auch keine Logs seit dem letzten funktionierenden Lauf vorhanden waren, habe ich mal vermutet, dass es evtl. Probleme mit dem Mounten der Platte geben könnte. In der /etc/fstab konnte ich aber nichts ungewöhnliches entdecken,.
    Mangels besserer Ideen habe ich den folgenden Eintrag geändert:

    Code
    # /dev/mapper/yavdr-root /               ext4    errors=remount-ro 0       1
    /dev/mapper/yavdr-root /               ext4    defaults 0       1


    reboot und der yavdr war sofort wieder da!


    Warum das funktioniert hat ist mir aber noch nicht klar!

    Hi,


    so die /ect/init/black.conf ist zur Seite geschoben und endlich sieht man etwas von den Symptomen:


    Von Hand übertragen:


    Ein CTRL+ALT+DEL führt nur zu einem - so wie es aussieht - sauberen Herunterfahren des Systems.
    (Ein rotes "fail" taucht kurz vorm Abschalten auf, weil der vdr-Prozess nicht gekillt werden konnte oder mount / is busy - konnte ich nicht so schnell lesen. - das rote fail habe ich aber auch bei laufenden System gesehen)


    Was sagt den dieser status 2 vom main process aus?


    Btw.: Beim Startversuch wird nichts in die Logs der Platte geschrieben.


    Nachtrag: Der VDR lässt sich anpingen - aber SSH geht nicht.

    Hi,


    Quote

    Norbert Holze schrieb:
    Erst wenn ich über die Konsole im alsamixer die Nvidia Soundkarte mit F6 auswähle, habe ich Sound.


    Wird mit der F6 im alsamixer nicht lediglich, die Karte für den mixer-Einstellungsdialog ausgewählt? Die Auswahl hat meines Verständnis nach nichts mit Auswahl des/der Sound-Wiedergabegerätes des Systems zu tun. Das passiert in der /etc/asound.conf bzw. per Webinterface.



    Hast du mal versucht, die Onboard-Soundkarte per BIOS abzustellen?
    Dann sollest du eigentlich nicht mehrere Soundkarten haben.



    Evtl. findest Du hier ja einige Anregungen.

    Hi,


    da das vdr-portal down war habe ich zwischenzeitlich bei forum.yavdr.com gepostet. - Ich bin aber noch nicht wirklich weiter.
    Derzeit klone ich die Platte, um die Aufnahmen und anderen Daten zu sichern. (Zieht sich ganz schön! Bisher 770GB in 4h)


    Den Bootvorgang hatte ich über 6h laufen lassen, ohne dass es weiter ging. Hatte ja auf fsck "gehofft".
    Eine Info fehlte noch: Ich habe meinen yavdr mit LVM installiert, was den Zugriff auf die Dateisysteme etwas vorkompliziert.


    Von einer Ubuntu-Live-CD konnte ich auf alle Daten (incl. LVM) zugreifen.
    (LVM-Mount-from-LiveCD-Howto)
    Von hier aus konnte ich auch fsck auf /dev/yavdr/root (= /) und /dev/sda2 (= /boot) absetzen. Per tune2fs -l /dev/yavdr/root konnte ich prüfen, dass die FS als clean eingestuft wurden und die Mount-Counter wieder auf 0 gesetzt wurden.



    Wie komme ich blos an weitere Infos, wo das System hakt?


    Hemingway: Wie bist du an den Recovery-Eintrag gekommen?


    Quote

    gerdh schrieb:
    ich habs die live cd eingelegt den eintrag korrigiert und dann gings auf anhieb wieder...


    Welchen Eintrag? (/etc/fstab für 2. Platte?)

    Hi,


    nach einem kleinem Update (da stand was SSL-Dateien..) hängt derzeit mein yaVDR seit einigen Stunden (es geht in die vierte!) beim Booten fest. Nach einem Reset ändert sich der Effekt leider auch nicht.
    (Hier im Forum laufen aber keine Meldungen anderer Betroffener ein, so dass es vermutlich doch nicht mit dem Update zu tun hat.)


    Beim Booten kommt für einige Sekunden "yaVDR 0.3 wird gestartet" dann verschwindet die Einblendung und nichts weiter ist zu erkennen.


    Die Konsolen Strg + Alt F2-F6 lassen sich auswählen, aber es erscheint nur ein blinkender Cursor. Im Netz ist der yaVDR erst recht nicht zu erreichen.


    Ich beruhige mich damit, dass es ja einer der Festplattenchecks sein könnte. Bei den aktuellen Plattengrößen in TB-Bereich kann sich der Check recht lange hinziehen.



    Gibt es nicht eine Konsole mit Bootlog, an der man Ablesen kann wo er hängt?


    Habe ich mir mein System "abgeschossen"?
    oder brauche ich nur noch etwas mehr Geduld?


    Grub-Meldungen habe ich leider nicht gesehen. (Geht immer recht schnell bzw. der Kontrollmonitor schaltet an der Stelle gerne mal weg.)

    Hi,


    die Karte läuft wieder!


    Im Log ist mir dann doch noch was aufgefallen. Es wurde gewarnt, dass der IRQ der Karte irgendwie nicht sichergestellt werden kann:

    Code
    IRQ 18/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs

    U.a. läuft die NVIDIA-Graka auch auf IRQ18.


    Auf Verdacht habe ich die Karte in den anderen PCIe-Slot gesteckt.
    Jetzt läuft die Sat-Karte auf IRQ16 - nur mit USB.
    Naja, die Warnung kommt jetzt auch für IRQ16 - aber die Karte läuft.

    Code
    16:          0          1   IO-APIC-fasteoi   ohci_hcd:usb2, cx23885[0]



    Insgesamt tippe ich darauf, dass ich durch das Umstecken der Karte ein neues Einspielen der Firmware ausgelöst habe.!?


    Geht das auch auf Befehl?

    Hi,


    anfangs lief die Tevii S470 (als Drittkarte!) endlich mit 0.3 und ich konnte die HD-Kanäle hinzufügen und auch gucken.
    Dann irgendwann viel mir auf, dass ich bei zwei laufenden Aufnahmen nur noch ein schwarzes Bild auf den übrigen Kanälen/Transpondern bekomme. Meldungen, wie Kanal nicht verfügbar gibt es hier nicht.


    Inzwischen habe ich v4l-dvb-dkms und jetzt auch mal s2-liplianin-dkms wechselweise probiert.
    Die Karte wird erkannt, aber es gibt kein Bild.
    dmesg (Auszug):

    Code
    [   16.763293] cx23885_dvb_register() allocating 1 frontend(s)
    [   16.763405] cx23885[0]: cx23885 based dvb card
    [   16.773790] DS3000 chip version: 0.192 attached.
    [   16.773794] DVB: registering new adapter (cx23885[0])
    [   16.773798] DVB: registering adapter 2 frontend 0 (Montage Technology DS3000/TS2020)...
    [   16.801278] TeVii S470 MAC= 00:18:BD:5B:3D:14
    [   16.801283] cx23885_dev_checkrevision() Hardware revision = 0xb0
    [   16.801292] cx23885[0]/0: found at 0000:02:00.0, rev: 2, irq: 18, latency: 0, mmio: 0xfe800000
    [   16.801299] cx23885 0000:02:00.0: setting latency timer to 64


    Signalinformationen lassen sich per VDR-Plugin im OSD abrufen. Die Karte wird als DVB-S2 #2 - Montage Technology DS3000/TS2020 geführt. Die Signalstärke liegt fest bei 94%. Nur der SN-Wert springt zufällig zwischen rot und grün hin und her. Die Symbole für Lock, Signal, Carrier usw. sind auf rot.
    Ein Tausch der Sat-Kabel führte auch zu keiner Änderung.


    In den Logs sind mir auch keine Besonderheiten aufgefallen.


    Derzeit tappe ich völlig im Dunkeln.


    Kennt jemand einen Trick oder die Ursache?
    Könnte die Karte defekt sein?


    Firmware-Dateien sind vorhanden. Ich finde in den Logs aber keinen Hinweis, dass diese auch gelesen wurden oder dass es Probleme gab.

    Hi Annell,


    was für eine Karte / MoBo setzt du ein?


    In der aplay-Meldung steht was von Karte 0 und 1. Daher tippe ich auf ein zusätzliche Onboard-Soundkarte. Daher würde ich als erstes die interne Soundkarte im BIOS deaktivieren. Das erleichtert auch yaVDR die Konfiguration via Web-Frontend. (Wenn es läuft, kann du die Onboardkarte nachkonfigurieren.)


    Ist die ATI HDMI Karte im alsamixer schon "ent-mutet"?


    Evtl. kannst du ja einige Vorgehensweisen hieraus recyclen.
    (Ist für NVIDIA geschrieben, aber entmuten und Speakertest sind universell.)

    Hi,


    der HDMI-Ton war zu meiner Überraschung nach dem Update auf 0.3 (noch) da.
    Auch nach dem Reboot. (Die /etc/modprobe.d/sound.conf wurde nicht verändert.)


    Nach dem Entfernen einiger jetzt als ungenutzt gemeldeter Pakete (u.a. alsa-dkms) war der Bildschirm wieder stumm.
    Auch wenn alsa-dkms beim Deinstallieren als "unused in this kernel" gekennzeichnet war, vermute ich hier die Ursache für die Stille.
    Jedenfalls war danach die Soundkarte nicht mehr per 'aplay -l' zu finden
    Ein erneutes Installieren via (apt-get install alsa-dkms) war nicht möglich, da es dieses Paket scheinbar nicht mehr gibt.

    Code
    apt-get --reinstall install alsa-dkms
    Paketlisten werden gelesen... Fertig
    Abhängigkeitsbaum wird aufgebaut       
    Status-Informationen einlesen... Fertig
    E: Paket alsa-dkms konnte nicht gefunden werden


    Mangels anderer Alternativen habe ich die Lösung von knaxman probiert und die vorher verschmähten Backport-Treiber aufgespielt. Den alsa-dkms hatte ich ja schon vorher runtergeworfen.:

    Code
    sudo apt-get remove alsa-dkms  
    sudo apt-get install linux-backports-modules-alsa-lucid-generic 
    sudo alsamixer 
    F6 
    NVIDA 
    ESC  
    sudo alsactl store


    Die Karte war wieder da! Und der Ton kam auch nach der HDMI-Konfiguration via yaVDR-Web-Konfigurationsänderung. Leider gibt es immer noch das Timing-Problem beim Booten!
    Aber dafür gibt es ja die Lösung mit der /etc/init/vdr-frontend.conf (s.o.)


    Der HDMI-Ton läuft jetzt also wieder!
    Ich vermute aber, dass ich irgendwie die neue yaVDR-Automatik - bei der auf Sound und Sat-Karten gewartet werden sollte, irgendwie umgangen wird.


    Also wer eine bessere Lösung kennt: Bitte posten!

    Hi,


    bei meinem Streaming-Client (S100, Zendeb 0.3) bekomme ich kein aktuelles EPG mehr von meinem yaVDR 0.2 per Streaming-Plugin eingespielt. (Live TV geht per Netzwerk!)


    Mit dem dem easyVDR 0.6 (VDR 1.4) funktionierte es noch tadellos, aber schon beim easyVDR 0.8 (VDR 1.7?) kam schon kein neues EPG mehr.


    Ist das evtl. ein Fehler in meiner Konfiguration oder hat sich da grundlegend was geändert?


    Ich meine dazu auch mal was gefunden zu haben, dass der EPG-Transfer beim VDR 1.7 nicht mehr kompatibel zu älteren Versionen sei. Ich kann die Info aber nicht mehr finden.
    Falls es eine Inkompatibilät ist, hätte ich vermutet, dass ich es schon ein work-around gibt - aber das Problem wird scheinbar auch nicht diskutiert.


    Wer kann mir da einen Tipp geben?

    Hi,


    dank der Unterstützung von steffen_b und Frounts habe meine Asus NVIDIA EN210 (G210) dazu gebracht HDMI Sound am TV auszugeben.


    Voraussetzung:
    Die On-Board Soundkarte sollte im BIOS deaktiviert sein und keine zusätzliche Soundkarte eingebaut sein.
    (Ansonsten ist die Reihenfolge/Nummerierung der Karten im Alsa-System noch zu berücksichtigen.)
    Wichtig: Alle Eingaben werden als root ausgeführt! (Gefährlich aber bequem, einmal vorgweg sudo su oder sicherer vor jedem Befehl ein sudosetzten)


    yaVDR ist auf dem aktuellesten Stand. (apt-get update && apt-get upgrade && apt-get dist-upgrade)
    Aktueller Kernel ist derzeit: 2.6.32.-26. ( check mit: uname -a)


    Da die alsa-dkms nicht länger zur Verfügung stehen, muss man auf die linux-backports-alsa-lucid-generic zurückgreifen (Tipp kam von Knaxmann).

    Code
    apt-get remove alsa-dkms  
    apt-get install linux-backports-modules-alsa-lucid-generic


    Dann eine neue Datei anlegen und editieren (/etc/modprobe.d/sound.conf)

    Code
    options snd-hda-intel enable_msi=0  probe_mask=0xfff2 
    alias snd-card-0 snd-hda-intel 
    alias sound-slot-0 snd-hda-intel


    Das System neu starten. (reboot)
    Der Zusatz probe_mask=0xfff2 sorgt dafür, dass nur ein Device verfügbar ist. Mit 4 Devices habe ich es unter yaVDR nicht ans laufen bekommen.
    Weitere Infos (z.B. wie man bei mehreren Soundkarten, die nVidia immer als erste einsortiert bekommt): s. xbmc-Wiki zu GeForce G210, GT220 or GT240]XMBC-Wiki


    Bei einem kleiner Test, sollte folgendes erscheinen:

    Code
    aplay -l
    **** Liste der Hardware-Geräte (PLAYBACK) ****
    Karte 0: NVidia [HDA NVidia], Gerät 3: NVIDIA HDMI [NVIDIA HDMI]
      Sub-Geräte: 0/1
      Sub-Gerät #0: subdevice #0


    Falls mehr als eine Karte gefunden wird, dann Soundkarte rausnehmen oder On-Board-Soundkarte deaktivieren.
    Falls hier mehr als 1 Gerät angezeigt wird, stimmt etwas mit der /etc/modprobe.d/sound.conf nicht oder es wurde noch nicht neu gestartet.


    Dann per

    Quote

    alsamixer


    die Soundkarte "entmuten".
    Es sollte nur eine S/PDIF angezeigt werden, über der '00' steht.
    Falls da 'MM' steht, einmal die Taste 'M" drücken.
    das Programm mit 'Esc' beenden.


    Per

    Code
    alsactl store


    wird die Einstellung gespeichert.


    Im yaVDR-Webfrontend unter System/Sound HDMI Stereo anklicken und "Setze Soundeinstellungen"
    Damit wird die /etc/asound.conf gesetzt:

    Code
    cat /etc/asound.conf
    
    
    pcm.!default {
    	type hw
    	card 0
    	device 3
    }


    reboot


    Die Einstellung ist soweit komplett. Der VDR startet jedoch derzeit so schnell, dass die Sound-Karte nicht initialisiert werden kann. (ca. 2 Sekunden nach dem das Bild kann man ein leises Knacken hören)
    Man kann dann entweder per "Esc"-Taste das VDR-Frontend neu starten oder per "stop vdr && start vdr" restarten. Dann sollte der Ton am TV zu hören sein.


    Besser ist die Lösung von Frounts / Soulfly2xs:
    In der /etc/init/vdr-frontend.conf eine Zeile (hier Zeile 3) eingefügt, damit der Start des vdr-frontends so lange verzögert wird, bis die NVIDIA-Karte sich meldet:

    Code
    pre-start script
      while ! DISPLAY=:1 xset -q; do sleep 0.1 ; done
      while ! [ $(cat /proc/asound/cards|grep -c "\- HDA NVidia") -gt 0 ] ; do sleep 1 ; done
    end script


    Ich hoffe mal, alle wesentlichen Schritte beschreiben zu haben.


    Hilfreich waren auch:


    Ausgabe Testsignal (hier Karte 0, Gerät 3):

    Code
    speaker-test -c2 -twav -Dplughw:0,3


    XBMC-Wiki:
    xbmc-Wiki zu GeForce G210, GT220 or GT240

    Hi,


    danke Frounts! :respekt Deine Ergänzung funktioniert perfekt!
    Danke!


    Meine Versuche mit einem unspezifischen sleep hatte nichts gebracht!


    Da steffen_b ja schon festgestellt hatte, das die Lösungsfindung nicht ganz on topic ist (obwohl ohne Update hätte vermutlich die NVIDIA-Karte gar nicht funktioniert), werde ich die Einstellungen noch mal in einem eigenen Thread kopieren und somit für spätere Leidensgenossen verdichten.

    Hi steffen_b,


    mit deiner Vermutung liegst Du scheinbar richtig!


    Inzwischen habe ich mich wieder ein paar Schritte näher rangetastet:
    Derzeit bin ich bei folgender /etc/modprobe.d/sound.conf angekommen:

    Code
    options snd-hda-intel enable_msi=0  probe_mask=0xfff2 
    alias snd-card-0 snd-hda-intel 
    alias sound-slot-0 snd-hda-intel


    Mit dieser Konfiguration hat man nur ein SPDIF-Ausgang statt der vier.
    Die Webkonfiguration findet den einen und trägt dann auch genau diesen in /etc/asound.conf ein:

    Code
    pcm.!default {
    	type hw
    	card 0
    	device 3
    }


    Beim Start kommt erst das VDR-Frontend und nach ca. 2-3 Sekunden kommt ein leises Knacken, wie beim "entmuten".
    Wenn dann per Esc-Taste das VDR-Frontend neu startet ist der Ton da!
    (Ohne die obere Konfiguration - mit den vier SPDIF - , klappt der der "Esc-Tasten-Trick" nicht. Da musste ich ja erst den Test-Ton absetzen. )


    Wie verzögert man den VDR Start so lange bis der ALSA-Treiber so weit ist?



    Beziehung zum Update:
    Ich bin erst mit dem Update (Zufall) auf den yaVDR umgestiegen. Ohne das Kernel-Update war die NVIDIA-Karte jedoch nicht sichtbar. Ist mir gleich aufgefallen, da - wie geschrieben - easyVDR die Karte auch nicht direkt sehen konnte.

    Hi,


    Quote

    gda schrieb den Vorwurf:
    Kein Problem, nur ist es eine Gemeinheit uns so was nicht zu sagen und uns im Trüben fischen zu lassen.


    Also ich habe das gleich in dem ersten Post (ca. 8 Beiträge höher) von mir zu dieser Randbedingung "gesagt":

    Quote

    Thyor schrieb:
    Der Effekt ändert sich durch die Installation oder De-Installation der linux-backport-modules-alsa-lucid-generic nicht


    Das ich die De-Installation nicht sauber hin bekommen hatte, habe ich jetzt ja gelernt! (Und konnte wenigstens als schlechtes Beispiel für alle späteren Leidensgenossen dienen!)


    Aber zurück zum Problem:
    1) Die Asus EN210 (NVIDIA G210) gibt von alleine keinen Mucks von sich.
    2) Per Testsignal lässt sich problemlos ein Ton ausgeben.
    3) Nach dem VDR-Restart kommt auch beim VDR der Ton.
    4) Nach einem Reboot, ist man wieder bei Punkt 1)


    Wo könnte es noch haken?
    Beim easyVDR 0.8 lief der Ton nach dem die G210 durch die Nachinstallation von ALSA 1.0.23 sichtbar wurde und /etc/modprobe.d/sound und /etc/asound.conf passend konfiguriert wurden.


    Hier habe ich zig Varianten mit Webinterface, von Hand, von Hand wie bei easyVDR, von Hand wie im XBMC-WIKI, ohne sound / asound.conf ausprobiert. (yaVDR startet ja zum Glück sehr schnell ;) )


    Hat den jemand die G210 unter yaVDR am laufen? Mit welcher Einstellung?

    Hi,


    die Backports waren installiert. Man lässt ja keinen Strohhalm aus, über den man per Google stolpert.
    Derzeit sind sie nicht mehr drauf.

    Code
    apt-cache policy linux-backports-modules-alsa-lucid-generic linux-backports-modules-alsa-lucid-generic:   
    Installiert: (keine)   Kandidat: 2.6.32.25.27   
    Versions-Tabelle:      2.6.32.25.27 0
             500 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages      2.6.32.24.25 0
             500 http://security.ubuntu.com/ubuntu/ lucid-security/main Packages      2.6.32.21.22 0
             500 http://de.archive.ubuntu.com/ubuntu/ lucid/main Packages


    Das dpkg -L lässt sich ohne konkreten Paketnamen nicht anwenden.


    Beim deinstallieren von einem alten Kernel gab es einen Hinweis, dass u.a. von den Backports noch was übergeblieben sei, man ein apt-get autoremove durchführen sollte.


    Also ein apt-get autoremove ausgeführt
    und dann ein apt-get --reinstall install alsa-dkms und dann reboot.


    Code
    dkms status
    nvidia-current, 195.36.24, 2.6.32-22-generic, i686: built 
    nvidia-current, 195.36.24, 2.6.32-24-generic, i686: built 
    nvidia-current, 195.36.24, 2.6.32-25-generic, i686: installed 
    alsa, 1.0.23, 2.6.32-22-generic, i686: built 
    alsa, 1.0.23, 2.6.32-25-generic, i686: installed 
    nct677x, 1.0.1, 2.6.32-22-generic, i686: built 
    nct677x, 1.0.1, 2.6.32-24-generic, i686: built 
    nct677x, 1.0.1, 2.6.32-25-generic, i686: installed 
    nct677x, 1.0.1, 2.6.32-18-generic, i686: built


    Die Warnungen sind weg - nur der Ton kommt immer noch nicht!
    Bzw. nur mit meinem Work-Around (Testsignal + VDR restart).


    Zur Sicherheit habe ich noch ein dpkg-reconfigure alsa-dkms
    durchlaufen lassen. Auch keine Verbesserung!