Besteht Interesse an einem VDR Client als TFTP Bootimage?

    Zitat

    Original von HolgerRjo..gut. Nochwas: Bei mir hatte das smbfs-Paket Probleme, die Codepage zu laden. Folge= fehlende Umlaute bei den Aufzeichnungen. Erst nachdem ich die "samba_lpt.txt" aus dem "config" Verzeichnis rübergeholt und Samba aktiviert habe, funktioniert das jetzt.


    Ist das bei dir nachstellbar, oder tritt auch dieses Problem nur bei mir auf?

    Das smbfs Paket kennt noch keine Codepages weil bisher nur cp437 und cp850 beim Kernel mitcompiliert worden sind. Aber ich habe gestern den fli4l Kernel neu compiliert und habe alle NLS Module miterzeugt. In den nächsten Tagen gibt es also eine neue Version, die auch die NLS Module mitbringt und benutzt.

    Zitat

    Original von cjhbabel
    Das smbfs Paket kennt noch keine Codepages weil bisher nur cp437 und cp850 beim Kernel mitcompiliert worden sind. Aber ich habe gestern den fli4l Kernel neu compiliert und habe alle NLS Module miterzeugt. In den nächsten Tagen gibt es also eine neue Version, die auch die NLS Module mitbringt und benutzt.


    Alles klar... das erklärt es natürlich. Neuer Kernel ist klasse. Mit aktiviertem Samba funktioniert es jetzt zwar auch so, aber eigentlich ist das ja unnötiger Balast. Je weniger davon, umso besser. Das ist ja gerade das gute an dieser fli4l-Lösung.


    Gruß,
    Holger

    Zitat

    Original von HolgerR
    das hört sich ja sehr interessant an! Viel Erfolg! Nur mal so für meine weitere Planung: Ist eine Integration des Streamdev-Clients angedacht?


    Ja natürlich! Ich sehe das als einen der grossen Vorteile eine VDR-Clients an. Man braucht nicht mal eine DVB-Karte einzubauen. Ich würd mir dadurch das Verlegen eines zusätzlichen Sat Kabels ersparen.


    cjhbabel
    Wie siehts mit FB aus? Klar, für Fli4L ist sowas tödlich, aber einem VDR-Client würds gut tun (Graphtft zB)


    Gruß,
    Sevo

    Du meinst ob ich den fli4l Kernel mit dem Support für ein Framebufferdevice neu übersetzen könnte? An sich spricht da nichts dagegen wenn der Kernel dadurch nicht fetter wird. Ich teste es nachher einfach mal aus und berichte.

    Bad news. Der Kernel wird durch die Framebuffer ca. 40kb größer. Das ist viel zu viel. Ich kapiere nicht warum das so viel ausmacht wenn alle FB Treiber als Modul compiliert werden. Falls jemand einen Tipp hat warum das soviel ausmacht kann ich es gerne nochmal versuchen kleiner zu kriegen.

    Hi Zusammen,
    Hat leider etwas länger gedauert, da mein Testrechner den Geist aufgegeben hat und ich mit VMware weitertesten musste.


    Ich habe das Paket von cjhbabel etwas aufgeräumt und erstmal nur das nötigste eingepackt. Wenn etwas fehlt, einfach bescheid sagen. Folgende Opts sind jetzt drin:


    base: ohne Windows Teil um Platz zu sparen


    dhcp: nur der Client, den Server habe ich entfernt (oder soll der VDR Client etwa als DHCP Server fungieren?)


    dvb: Treiberversion 1.1.1 (CVS 06-06-2005) aus den Eisfair Sourcen. Unterstützt werden fast alle DVB-S/T/C Karten die auch unter Eisfair laufen (Liste gibts im Wiki) Zusätzlich habe ich einen mehr oder weniger automatischen Modus eingebaut und einzelne Module können wie bisher mit DVB_DRIVER_ADVANCED='yes' direkt geladen werden. Hier is es jetzt auch möglich mehrere Module zu laden, sowie Optionen mitzugeben.


    dxr3: Eine aktuelle CVS Version (ich glaub von vorgestern) der dxr3 Treiber mit dem Setup Utility von Eisfair. Leider krieg ich immer ein "segmentation fault" beim Aufruf, wenn ich versuche das Programm in der Fli4l-fbr zu erzeugen. Das Binary von Eis läuft mit entsprechenden Libs problemlos.


    lirc: keine Änderungen. Konnte wegen kaputter Hardware nicht mal testen :(


    smbfs: Sonderzeichen werden auch ohne samba_lpd korrekt angezeigt.


    sshd: Keine Änderung


    vdr: Hier hat sich das meiste getan. Die Optionen dürften selbserklärend sein. Folgende Plugins können in der Config aktiviert werden:
    - dummydevice
    - dxr3
    - remote
    - serialremote


    vdr-plugin-streamdev: Dient als Beispiel für ein opt_Plugin. Die Konfiguration wird automatisch von runvdr erkannt und aktiviert.


    TODO:
    - Weitere Plugins (kommen heute Abend)
    - Shutdown (muss noch schaun wie ich das mit nvram mache)
    - Record.sh mit NOAD (die ganzen Perl Scripts aus dem Portal gehen nicht, da kein Perl auf dem Fli drauf ist)
    - Remote Videoschnitt (kommt wahrscheinlich erst in Verbindung mit nem richtigen Eisfair-Paket)
    - Sound mit OSS
    - Paket für Eisfair
    - mal gucken was danach noch so ansteht :)


    Das VDR Paket (vor allem runvdr) basiert auf dem Eisfair VDR Paket von maverick-me, an dieser Stelle ein riesen Dankeschön für die tolle Arbeit. Auch ein riesen Dankeschön für die Hilfe mit Fli4L und die inoffizielle Fli4L Version an cjhbabel.


    cjhbabel: kannst du vielleicht die Busybox mit awk, wc, openvt, chvt übersetzen? Die werden von runvdr benötigt, deshalb hab ich vorerst die libs und bins von Eisfair genommen. Wenn eine neue Busybox drin wäre, könnte man einiges an Platz sparen.


    Download unter: http://www.kukol.info/fli4l-vdr-client.tar.bz2


    Gruß,
    Sevo

    so, ich noch mal, bin leider an den freien Tagen außer einigem lesen zu nichts weiter gekommen und hänge noch ziemlich am Anfang.
    ich habe noch das TFTP Paket nachinstalliert (apt-get install atftpd, die Frage zum autom. Starten mit inetd bejaht). Starte ich jetzt den client bekomme ich auf dem Bildschirm folgende Fehlermeldung:


    Code
    Node: xxxx
BOOTP.
TFTP..
No reply from TFTP server.


Network boot aborted


    in /etc/default/atftpd dann versuchsweise:
    --mcast-addr 192.168.1.0-255
    geändert, vollständig sieht's so aus:


    Code
    USE_INETD=true
OPTIONS="--daemon --port 69 --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 192.168.1.0-255 --mcast-ttl 1 --maxthread 100 --verbose=6  /tftpboot"

    Wenn ich mit ps aux nachsehe finde ich keinen gestarteten atftpd! eigenartigerweise läßt sich der Befehl /etc/init.d/atftpd start auf der Konsole absetzen, es kommt aber keinerlei Rückmeldung (gleichfalls mit der Option stop usw.). Was fehlt denn da?
    Gruß seaman

    Zitat

    Original von seaman

    Code
    USE_INETD=true
OPTIONS="--daemon --port 69 --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 192.168.1.0-255 --mcast-ttl 1 --maxthread 100 --verbose=6  /tftpboot"

    Wenn ich mit ps aux nachsehe finde ich keinen gestarteten atftpd! eigenartigerweise läßt sich der Befehl /etc/init.d/atftpd start auf der Konsole absetzen, es kommt aber keinerlei Rückmeldung (gleichfalls mit der Option stop usw.). Was fehlt denn da?
    Gruß seaman


    Hi seaman,


    ich weiß zwar nicht, ob es dein Problem löst, aber eigentlich sollte man den atftpd entweder über den inetd starten oder als daemon. Nimm doch mal eine der beiden Optionen raus. Wie gesagt, nur ein Schuß in's Blaue.


    Gruß,
    Holger

    Hi Holger,
    komme grad vom Mittag und freu mich über die Hilfe.


    Habe jetzt die erste Option geändert (USE_INETD=false), inetd neu gestartet und nun passiert auch schon mehr. TFTP startet auf Anfrage vom client, bleibt dann aber hängen. Es fehlt noch eine Einstellung und ich weiß nicht wo (ob in der dhcpd.conf oder mittels atftpd).
    Beim Lesen fand ich verschiedene Ansätze, u.a dieser Beitrag hier:



    die angegebene Datei (/etc/bootptab) existiert bei mir garnicht, müßte also für dieses Vorgehen neu angelegt werden?
    Oder anders herum, wie ist das bei Dir gelöst, erfolgt die Konfiguration ausschließlich über DHCP?
    Gruß Tobias

    Hi Tobias,


    jo, bei mir läuft das ausschließlich über dhcp/atftp. Alles auf ein- und demselben Rechner. Ich habe im wesentlichen nur das Howto abgearbeitet, dass du ja auch kennst.
    Was meinst du mit

    Zitat

    TFTP startet auf Anfrage vom client, bleibt dann aber hängen

    ? Dein Clientrechner erkennt, dass im Netz ein Server zur Verfügung steht und findet dann kein Image? Oder fängt er an, das Image zu laden?


    Gruß,
    Holger

    Hi Zusammen


    HolgerR
    Hast du meine Version schon probiert?


    seaman
    Ich würd dir gerne helfen, wenn ich wüsste wie das funktioniert. Benutze selber einen Eisfair Server und da wird alles automatisch konfiguriert.


    Gruß,
    Sevo

    Zitat

    Original von Sevo
    HolgerR
    Hast du meine Version schon probiert?


    Hi Sevo,


    sorry, nein :( Jajaaa.... ich weiß: erst große Reden schwingen und dann.... gestern kam mir leider das RL dazwischen. Ich gehe aber davon aus, dass es heute aband was wird, bin heute "Stohwitwer"


    Gruß,
    Holger

    Hi Holger,
    --> bei mir läuft es ausschließlich über dhcp/atftp auf ein- und demselben Rechner, jaa, genauso soll es bei mir auch.
    Der client findet den Server, bekommt seine ip und macht dann nicht weiter ??? Das sieht auf der Konsole so aus:


    Code
    Node: xxxx
BOOTP.
TFTP........._


    vielleicht ist die dhcpd.conf unvollständig? Die sieht so aus:


    hoffnungsvoll - Tobias

    Hi,


    Zitat

    hoffnungsvoll - Tobias


    ... spätestens heute abend könnte ich mehr dazu sagen. Das kriegen wir dann schon hin! Ich habe das auf dem Rechner einmal eingerichtet und es lief -was das reine Booten angeht- sofort. Nie wieder angefasst; daher habe ich die Konfiguration nicht im Kopf.


    Wie sieht denn deine "default" in "/tftpboot/pxelinux.cfg" aus? Kannst du deren Inhalt evtl. mal posten?


    Gruß,
    Holger

    ok, und danke schon mal.


    ich habe ja erstmal versucht, "netboot" einzusetzen. Daher auch die Angabe in dhcpd.conf file "vdr-test.img". Unabhängig davon hatte ich die pxe-Variante auch erzeugt, müßte ich einfach mal damit probieren.


    Und noch was, sicherlich sind diese Fehlermeldungen für einen "wissenden" user eindeutig (aus: /var/log/daemon:(


    und helfen mir auf die Sprünge. Grüße Tobias

    Hi, was die DHCPD Config angeht, bei mir steht noch "next-server" drin also:
    ....
    filename "pxelinux.0";
    next-server 192.168.X.X;
    ....


    Die Ip ist die eigene IP des DHCPD Servers. Vielleicht hilft das.


    Gruß,
    Sevo

    Zitat

    Original von seaman
    ok, und danke schon mal.


    ich habe ja erstmal versucht, "netboot" einzusetzen. Daher auch die Angabe in dhcpd.conf file "vdr-test.img". Unabhängig davon hatte ich die pxe-Variante auch erzeugt, müßte ich einfach mal damit probieren.


    Stimmt ja, hatte ich vergessen. Macht unsere Einstellungen natürlich nicht unbedingt vergleichbar. Aber dein Problem scheint ja wirklich woanders zu liegen...


    Zitat

    Und noch was, sicherlich sind diese Fehlermeldungen für einen "wissenden" user eindeutig (aus: /var/log/daemon:(



    hmmm... na so 100%ig "wissend" bin ich in dem Bereich auch nicht. Sieht aber so aus, als wollte der DHCP-Server die verliehene IP-Adresse dem DNS-Server mitteilen. Was hast du denn als DNS-Server eingetragen? In meinem Fall hatte ich den gleich mit installiert, der steht bei mir also auf "127.0.0.1" Wenn dein Eintrag ins leere verweist, könnte das natürlich ein Problem sein...


    Gruß,
    Holger

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden