Fragen zu Howto "debian etch mit vdr"

Und warum wird die firmware nicht automatisch geladen, aber mit modprobe dvb_ttpci schon?
Da ist doch noch etwas faul. Wenn Du die Möglichkeit hast, könntest Du mal ssh freischalten,
dann könnte man "aus der Ferne" mal gucken, woran es liegt.

Gestern klappte es zeitlich nicht mehr. Alles weitere mal per PN.

So, das Problem stellt sich wohl folgendermaßen dar.

Beim Rechnerstart wird die firmware beim Laden von dvb_ttpci per /etc/modules nicht gefunden.
Ist der Rechner hochgefahren, kann das Modul per modprobe geladen werden, die firmware
wird gefunden. Dies funktioniert auch, wenn runvdr das Modul lädt. Dazu darf es aber nicht in
/etc/modules stehen bzw. muß vorher entladen werden.

Da PASST mit initrd¹ arbeitet, ging meine Vermutung, daß das eigentliche Dateisystem zum
Zeitpunkt des Modulladens noch nicht gemountet sei. Darauf weist dann auch die dmesg
Ausgabe hin:

Linux video capture interface: v2.00
saa7146: register extension 'dvb'.
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 21
saa7146: found saa7146 @ mem f898e000 (revision 1, irq 21) (0x13c2,0x000e).
dvb-ttpci: could not load firmware, file not found: dvb-ttpci-01.fw
dvb-ttpci: usually this should be in /usr/lib/hotplug/firmware or /lib/firmware
dvb-ttpci: and can be downloaded from http://www.linuxtv.org/download/dvb/firmware/
ACPI: PCI interrupt for device 0000:01:07.0 disabled
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.

vdr:/tmp# mount|grep ext3
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
/dev/sda9 on /home type ext3 (rw)
/dev/sda8 on /tmp type ext3 (rw)
/dev/sda5 on /usr type ext3 (rw)
/dev/sda6 on /var type ext3 (rw)

Die firmware liegt unter /usr was auf sda5 liegt, welches nun erst *nach* dem Modulladen
zur Verfügung steht.

Lösungsvorschläge:

• auf initrd verzichten
• initrd passend neu bauen
• Festplatte mit nur einer Partition einrichten²
• Das Modul per runvdr laden lassen (aus /etc/modules) austragen

Ich habe jetzt erstmal die letzte Möglichkeit aktiviert, so daß vdr nun läuft

¹ Ich weiß schon, warum ich initrd nicht mag.
² auf solch einem System bringt die Zerstückelung m.E. keinen Vorteil

ich finde an

Zitat

Das Module per runvdr laden lassen (aus /etc/modules) austragen

fuehrt sowieso kein Weg vorbei, da sonst der Emergency-Exit des VDR keinen rechten Sinn macht. Ich habe nie so recht verstanden warum in manchen Distributionen DVB-Module ausserhalb von runvdr ge/entladen werden.

Zitat

¹ Ich weiß schon, warum ich initrd nicht mag.

seit dem Umstieg auf diskless, dank deines preisverdaechtigen HOWTOs mag ich auch keine initrd mehr:-)

Zitat

Original von sparkie
ich finde an

fuehrt sowieso kein Weg vorbei, da sonst der Emergency-Exit des VDR keinen rechten Sinn macht. Ich habe nie so recht verstanden warum in manchen Distributionen DVB-Module ausserhalb von runvdr ge/entladen werden.

Der "Emergency-Exit" sollte ja trotzdem funktionieren. Das Problem ist (oder war?), daß sich
die Reihenfolge der Karten z.T. veränderte, so daß "primary device" plötzlich ein anderes war
oder der "IR receiver" eine neue Nummer bekam. Ich muß aber dazu sagen, daß ich schon ewig
keinen "Emergency-Exit" mehr hatte. Lädt runvdr denn die Module reproduzierbar in der gleichen
Reihenfolge?

Zitat

Lädt runvdr denn die Module reproduzierbar in der gleichen Reihenfolge?

bei mir schon, da ich jedes einzelne Modul aus der runvdr per insmod (nicht modprobe) separat lade:-)

Explizites insmod zu verwenden hat noch den Vorteil, dass ich im Kernel-Build ueberhaupt kein DVB mehr aktivieren muss . Stattdessen lade ich fuer jeden meiner VDRs (die haben ganz unterschiedliche DVB Karten) aus 'ihrem' separat kompilierten DVB-Repos per insmod die entsprechenden Treiber. Das war zumindest bis vor kurzem noch noetig, da es kein mir bekanntes DVB-Repos gab, das alle meine DVB Karten gleich gut bedienen konnte. Hat sich bis heute moeglicherweise aber gebessert.

Zitat

Original von sparkie

bei mir schon, da ich jedes einzelne Modul aus der runvdr per insmod (nicht modprobe) separat lade:-)

Da ich fertige Pakete (TomG/Tobi) verwende, vermeide ich es normal, dazugehörige Dateien
zu modifizieren. Das gibt beim nächsten upgrade bloß Ärger.

Zitat

Original von PASST
Es wäre jetzt noch schön, wenn du mir im Detail erklären könntest, was du genau gemacht hast.

Steht eingentlich schon in obigem Posting. Der "Trick" war, dvb_ttpci nicht per /etc/modules
zu laden, weil es aus oben genannten Gründen nicht funktioniert, sondern duch den Start des
vdr (via runvdr).

runvdr gehört zum Paket vdr:

zaphod:~# dpkg -L vdr | grep runvdr
/usr/sbin/runvdr
/usr/share/man/man8/runvdr.8.gz

Zitat

zu modifizieren. Das gibt beim nächsten upgrade bloß Ärger.

ja klar, das sehe ich auch so. Darum nehme ich inzwischen keine fertigen Pakete mehr. Auch wenn es teilweise ziemliche Knochenarbeit ist:-)

Da muss ich passen. Lirc mit USB sind für mich unbekanntes Terrain.