[HOWTO] VDR Client via Netz per NFS booten (Neu: mit debootstrap Installation)

  • Quote

    Original von DonGyros
    - da geplant ist im Betrieb keine Client-seitigen Änderungen vorzunehmen (nur Kanalwechsel, Aufnehmen und Aufnahmen abspielen), wird somit auch kein persistentes Filesystemtem für die Clients benötigt


    Theoretisch kannst Du das System in einer RAM-Disk laufen lassen, aber das wäre
    dann ein anderes Konzept als das hier vorgestellte.

  • Hallo!


    Nachdem ich meinen vdr erfolgreich auf diskless umgestellt und nun als streaming-client betreibe (nochmal Dank an kilroy für das prima Howto...), hänge ich im Moment an der Einbindung der Aufnahmen (liegen auf dem vdr-server). Der Fehler von Dirk:



    macht mir dabei auch zu schaffen, den Umweg über die rc.local habe ich dabei im Blick, mounte derzeit das Video-Verzeichnis aber noch per Hand. Zwar kann ich dann die Aufnahmen nach Einbindung des entsprechenden Verzeichnisses unter vdr-admin auf beiden vdr sehen, jedoch fehlen diese bei Abruf der Aufnahmen über OSD ?( (nur client, server ohne Ausgabedevice - kann ich nicht prüfen). Dieses Problem stellt sich für mich derzeit als nicht lösbar dar. Vielleicht hat jemand einen Tipp, wo ich ansetzen kann?


    Eigentümer der Aufnahme-Verzeichnisse ist vdr, die Aufnahmen selbst liegen sowohl auf dem Server als auch dem client unter /var/lib/video.00. Symbolische Links (video --> var/lib/video.00; /var/lib/video --> /var/lib/video.00) sind jeweils erstellt. Auf beiden Rechnern läuft vdr-admin in der gleichen Version (3.6.0 meine ich)... Vielleicht hat jemand ja mal ein ähnliches Problem gehabt...


    Gruß


    Andreas

    registered vdr-user: 1318


    file/vdr-server: ASRock Q1900M, SSD, 2TB HD, 1xDVBSky S952 v3 mit 2xDVB-S2, stretch+e-tobi, vdr 2.4.0-2~etobi1

  • So, nach langem Probieren, Testen und Grübeln scheine ich dem Problem auf die Spur zu kommen: Problem scheint doch die Vergabe von User/Gruppe für das Aufnahmeverzeichnis des vdr zu sein.


    Nach Start des VDR-Servers steigt dieser zunächst mit dem Hinweis aus, dass auf das Video-Verzeichnis nicht zugegriffen werden kann. Der Grund hierfür liegt offensichtlich in den vergebenen User/Gruppen-Rechten des Verzeichnisses:

    Code
    vdr-server:/var/lib# ls -la | grep video.00
    lrwxrwxrwx  1 root        root    8 2008-04-30 15:32 video -> video.00
    drwxr-xr-x 18 ntp         ntp  4096 2008-05-01 01:01 video.00


    Wenn ich meinen vorher beschriebenen Zustand:

    Quote

    Originally posted by Andi011
    Eigentümer der Aufnahme-Verzeichnisse ist vdr,


    auf dem Server mit chown -R vdr.vdr /var/lib/video.00 per Hand sicherstelle:

    Code
    vdr-server:/var/lib# ls -la | grep video.00
    lrwxrwxrwx  1 root        root    8 2008-04-30 15:32 video -> video.00
    drwxr-xr-x 18 vdr         vdr  4096 2008-05-01 01:01 video.00


    heißt dies aber nicht unbedingt, dass der client diese Einstellungen auch übernimmt. Auf diesem sind nach Einbinden des Verzeichnisses User/Gruppe auf vdradmin-am eingestellt:

    Code
    vdr-wz:/var/lib# ls -la | grep video.00
    lrwxrwxrwx  1 root        root           8 2008-02-23 19:34 video -> video.00
    drwxr-xr-x 18 vdradmin-am vdradmin-am 4096 2008-05-01 01:01 video.00


    Stelle ich nun diese wiederum per Hand auf vdr um und starte vdr auf der Konsole neu, sehe ich die Aufnahmen auch endlich im OSD des clients.


    Soweit zwar alles ok, die Sache läuft, aber ist das normal? Ich erhalte auch beim Einbinden des Video-Verzeichnisses über rc.local:


    Code
    vdr-wz:/etc/rc2.d# cat /etc/rc.local
    #!/bin/sh -e
    #
    losetup /dev/loop/0 /var/swap
    swapon /dev/loop/0
    mount 192.168.1.10:/video var/lib/video.01
    exit 0


    nur die Boot-Meldung ": Invalid option" (direkt vor Erscheinen des logins, dürfte rc.local sein).


    Also habe ich das mal direkt unter rc2.d laufen lassen:

    Code
    vdr-wz:/etc/rc2.d# cat S99rc.local.custom 
    #!/bin/sh -e
    #
    losetup /dev/loop/0 /var/swap
    swapon /dev/loop/0
    mount 192.168.1.10:/varlib/video.00 var/lib/video.00
    chown -R vdr.vdr var/lib/video.00
    exit 0


    Auch hier erhalte ich dann (2x) ":Invalid option" als Rückmeldung. Das anschließende Einbinden des Verzeichnisses per Hand funktioniert jedoch reibungslos, jedoch wie oben beschrieben mit den User/Group vdradmin-am als Folge.


    Meine Frage: Ist der beschriebene Ablauf normal? Wenn ja: Wie habt ihr das dauerhaft gelöst? Wenn nein: Wo liegt ggf. das Problem?


    Traue es mir in Anbetracht der Länge des threads eigentlich gar nicht zu sagen, aber ein weiteres Problem habe ich beim Starten des clients: Nur wenn dieser mehrere Sekunden vom Netz genommen wurde, bootet er sauber durch. Beim Einschalten per FB z.B. bleibt der client beim Laden des Kernels

    Code
    Loading vmlinuz-2.6.24.1.....

    hängen. Hoffentlich nicht wieder ein Problem der NIC?


    Bin für jeden Hinweis dankbar...


    Gruß


    Andreas

    registered vdr-user: 1318


    file/vdr-server: ASRock Q1900M, SSD, 2TB HD, 1xDVBSky S952 v3 mit 2xDVB-S2, stretch+e-tobi, vdr 2.4.0-2~etobi1

  • So, nachdem ich lange gesucht, probiert und gebastelt habe, ich werde mal ein Update nachschieben...


    1. Problem des Einbindens der Video-Verzeichnisse habe ich wie folgt lösen können: uid/gid des Benutzers vdr musste auf client und server gleich sein. Andernfalls mountete der client die Verzeichnisse mit der uid/gid des servers und konnte damit nicht adäquat auf die Verzeichnisse zugreifen. Stellte man mittels chown -R vdr.vdr den Zugriff sicher, änderte sich die uid/gid der Verzeichnisse auf dem Server und das gleiche Problem entstand hier. So habe ich uid/gid des users vdr auf dem client angepasst und anschließend mit

    Code
    find / -uid 104 -print0 | xargs -0r chown 105
    #bzw. auch möglich
    find / -gid 104 -print >/tmp/gid.104
    cat /tmp/gid.104   | xargs chgrp 105

    alle Dateien hinsichtlich des nutzers/gruppe angepasst.


    2. Video-Verzeichnisse muss ich immer noch per /etc/rc.local einbinden. Nach Neuanlegen der Datei waren auch die Fehlermeldungen beseitigt.

    3. Aufhängen beim Laden des Kernels per PXE:

    Code
    Loading vmlinuz-2.6.24.1.....

    Problem trat entgegen der vorherigen Annahme sporadisch (unabhängig von der Unterbrechung der Stromzufuhr nach shutdown) auf. Grund konnte ich nicht klären. Problem ist nach Umstellung der uid(gid (und der damit nicht mehr durchgeführten Änderung der uid/gid des gemounteten Video-Verzeichnisses) bisher (> 10 reboots) nicht mehr aufgetreten. Ob das so bleibt vermag ich nicht zu sagen. Wenn, dann ggf. fehlerhaftes unmounten der nfs-gemounteten Verzeichnisse beim shutdown(?)...

    registered vdr-user: 1318


    file/vdr-server: ASRock Q1900M, SSD, 2TB HD, 1xDVBSky S952 v3 mit 2xDVB-S2, stretch+e-tobi, vdr 2.4.0-2~etobi1

  • Hallo,


    ich habe einen laufenden VDR mit zwei Platten. Diesen hätte ich ganz gerne diskless. Nun habe ich keinen Server, sondern eine FritzBox 7270. Die hat zwar USB 2.0, schafft aber nur Übertragungsraten von rund 2-3MB/s.


    Ist es dennoch denkbar, alles via Netz zu machen? Inklusive Swap, /tmp, ...?


    Wie ist eure Erfahrung mit der Geschwindigkeit des Systems nach dem Umstellen auf Netboot im Vergleich zu einem System mit Festplatte?


    Angenommen, die Netzwerkverbindung ist nicht stabil, dann wäre es doch evtl sinnvoll mhddfs zu nutzen. Man könnte ein CF Modul und den NFS Share joinen. Wenn der NFS Share zur Verfügung ist, wird darauf gespeichert, ansonsten auf dem CF.
    Ist sowetwas sinnvoll, oder garnicht nötig?


    Gruß,
    Hendrik

  • Quote

    Original von henfri
    Wie ist eure Erfahrung mit der Geschwindigkeit des Systems nach dem Umstellen auf Netboot im Vergleich zu einem System mit Festplatte?


    Die Systemgeschwindigkeit wird für mein Empfinden nicht merklich beeinflusst. vdr läuft auf dem client wie vorher auch. Probleme habe ich hin und wieder, wenn der client wie hier beschrieben beim Laden des Kernels "hängenbleibt". Dann dauert es in dieser Phase so an die zwei Minuten, bis er den Kernel übertragen hat (dachte vorher er bleibt wirklich hängen...). Nach den Reaktionen auf dieses Problem zu urteilen, bin ich aber der Einzige, der das zur Zeit hat...


    Ansonsten keine Änderung zur Geschwindigkeit zuvor (aus meiner Sicht)...


    Gruß


    Andi

    registered vdr-user: 1318


    file/vdr-server: ASRock Q1900M, SSD, 2TB HD, 1xDVBSky S952 v3 mit 2xDVB-S2, stretch+e-tobi, vdr 2.4.0-2~etobi1

  • Ich glaube eher nicht, dass es Sinn macht. Wenn ich das richtig in Erinnerung habe, ist allein der stream netto mit gut ca. 1 MB/s dabei. Da das Ganze bei WLAN schon immer nur mit bester Netzverbindung kritisch wird, glaube ich dürftest du ebenfalls am Limit liegen.


    Wegen des Bootvorgangs würde ich eher weniger Bedenken haben, wird sicherlich deutlich länger dauern aber ich persönlich sehe keinen Grund warum es grundsätzlich nicht gehen sollte...



    Gruß


    Andi

    registered vdr-user: 1318


    file/vdr-server: ASRock Q1900M, SSD, 2TB HD, 1xDVBSky S952 v3 mit 2xDVB-S2, stretch+e-tobi, vdr 2.4.0-2~etobi1

  • Achja: Server schafft deutlich mehr als 2 MB/s...

    registered vdr-user: 1318


    file/vdr-server: ASRock Q1900M, SSD, 2TB HD, 1xDVBSky S952 v3 mit 2xDVB-S2, stretch+e-tobi, vdr 2.4.0-2~etobi1

  • Moin,


    es steht schon lange bei mir auf der "todo" Liste meine vdr Systeme auf Netzwerkboot umzustellen.
    Es läuft eh ein Server wegen nfs - dann kann mein Netzwerkkonzept auch gleich das System bereitstellen.


    Nachdem ich kurz vor Weihnachten den dritten defekten usb Stick in die Tonne gehauen habe und ein
    paar freie Tage vor mir lagen bin ich es nun einmal angegangen.

    Bin nun aber an einem Punkt wo ich nicht weiterkome :(


    Was habe ich bislang gemacht ?


    Auf meinem Server (Eisfair.org) läuft nfs, dhcp u. tftp


    Auf meinem Client (Easyvdr 0.6) läuft ein 2.6.22.15 Kernel, welchen ich mit den Optionen:
    CONFIG_IP_PNP=y, CONFIG_IP_PNP_DHCP=y, CONFIG_NFS_FS=y, CONFIG_ROOT_NFS=y und eben
    mein Netzwerkkartentreiber CONFIG_FORCEDETH=y neu kompiliert habe.
    Den neuen Kernel (vmlinuz-2.6.22.15-netboot) in /boot kopiert und grub angepasst,
    damit läuft local alles wunderbar.


    Auf dem Server einen Pfad (/tftpboot/vdr) angelegt und per nfs freigegeben:
    /etc/exports -> /tftpboot/vdr 192.168.123.0/255.255.255.0(sync,rw,no_root_squash)


    Diese nfs Freigabe am Client unter /nfs eingehängt. Einige Verzeichniss erzeugt:
    mkdir /nfs/initrd /nfs/media /nfs/mnt /nfs/proc /nfs/sys
    den Rest vom läuffähigen System kopiert mit:
    cp -av /bin /boot /dev /etc /home /lib /opt /root /sbin /srv /tmp /usr /var /nfs


    Den dhcp/tftp Server entsprechend konfiguriert:
    /tftpboot/pxelinux.cfg/default


    LABEL vdr
    KERNEL vdr/boot/vmlinuz-2.6.22.15-netboot
    APPEND root=/dev/nfs ip=dhcp nfsroot=192.168.123.1:/tftpboot/vdr


    Die /tftpboot/vdr/etc/fstab angepasst:
    192.168.123.1:/tftpboot/vdr / nfs defaults,hard,intr,rsize=65536,wsize=65536 0 0


    Dann am Client die Platte abgeklemmt und Daumen gedrückt. Er startet vom Netz
    bekommt vom dhcp eine ip und bootet den Kernel bleibt aber stehen mit der Meldung:
    (abgetippt)


    IP-Config: Complete:
    device eth0, addr=192.168.123.100, mask=255.255.255.0, gw=192.168.123.246,
    host=vdr, domain local.sfa, nis-domain=(none), bootserver=192.168.123.1, rootserver=192.168.123.1, rootpath=
    Looking up rot of RPC 100003/2 on 192.168.123.1
    Looking up port of RPC 100005/1 on 192.168.123.1
    VFS: Mounted root (nfs filesystem) readonly-
    Freeing unused kernel memory: 400k freed
    Warning: unable to open an initial console.


    Woran hackt es ab da ? Habe versucht an den Parametern in der fstab zu schrauben… ohne Erfolg.


    Unter dev gibt es console...


    Bin für jede Hilfe dankbar.


    Munter bleiben, Rossi

  • Versuch mal das lokale /dev Verzeichnis mit "cp -r /dev /nfs-path..." zu kopieren, also rekursiv.


    EDIT: OK, "cp -a" sollte es eigentlich auch tun. Sind /dev/console und /dev/tty[0-9] vorhanden?


    Gruß

    Edited 2 times, last by tecfreak ().

  • *update


    Der Fehler lag in der fstab.


    Nachdem ich es auf:
    192.168.123.1:/tftpboot/vdr / nfs defaults,rsize=65536,wsize=65536 0 0
    geändert hatte, ging es weiter.


    Jetzt hängt er allerdings bei Mounte Filesystememounts
    das wird aber ein Easyvdr spezifisches Problem sein, wenn ich die NFS Mountpoints aus der fstab entferne startet das System durch.
    Wie ich die NFS Mounts nun einbinde muss ich sehen...


    Achja, easyvdr spezifisch muss noch in der sysconfig Network="AUS" stehen.


    Jetzt gehts erstmal ins Bett ;)


    Munter bleiben, Rossi

  • Bei einem aktuellen Debian darf (sollte) man das / (root) Filesystem nicht mehr in der /etc/fstab des Clients eintragen (s.a. [HOWTO] VDR NFS Client auf Debian 5.0 (64bit) lenny mit debootstrap Installation)


    Wegen der weiteren NFS-Mounts schau' mal hier: http://www.vdr-portal.de/board…?postid=800175#post800175


    HTH

  • Quote

    Original von kilroy
    Bei einem aktuellen Debian darf (sollte) man das / (root) Filesystem nicht mehr in der /etc/fstab des Clients eintragen...


    Wenn ich / in der fstab auskommentiere, meckert mein easyvdr 0.6 System das / in der fstab fehlt. Also bleibt es drin.


    Quote

    Original von kilroy
    Wegen der weiteren NFS-Mounts schau' mal hier: http://www.vdr-portal.de/board…?postid=800175#post800175


    Das ergänzen von ASYNCMOUNTNFS=no brachte nix.


    Habe jetzt easyvdr typisch es über die /etc/init.d/RCStartBeforeVDR.d/RCStartPersonal gelöst.


    Code
    portmap
    mount -t nfs 192.168.123.1:/home/rossi/daten/filme/video0 /media/video0 -o rsize=8192,wsize=8192
    ...


    Der Tip NFS v3 zu erzwingen ist gut. Allerdings funktioniert es nach dem Muster nicht bei mir:


    Code
    APPEND root=/dev/nfs nfsroot=172.17.42.4:/netboot/nfsroot/client,v3,rsize=32768,wsize=32768


    Ein abschliessenden v3 geht, aber die rsize & wsize Geschichte mag er an dieser Stelle nicht.
    Das habe ich in der fstab eingesetzt.


    Jetzt bin ich am Performance rauskitzeln... und wundere mich bei meiner GBit Kiste (vdr1) das nur ca. 17MB/sek durchgehen.
    Mein Testmühle mit Festplatten (auch GBit Netzw.), schafft im gleichen Netz und mit gleichen Parametern verbunden knappe 40MB/sek.


    Gemessen mit:

    Code
    dd if=/dev/zero of=/zeros.out bs=256k count=1024


    Naja, jetzt freue ich mich das es läuft. Und der Alltag hat auch schon wieder begonnen...
    Mal sehen ob ich über den Jahreswechsel noch zum weiteren testen bzw. optimieren komme.


    Munter bleiben, Rossi

  • Quote

    Original von vdr_rossiJetzt bin ich am Performance rauskitzeln... und wundere mich bei meiner GBit Kiste (vdr1) das nur ca. 17MB/sek durchgehen.
    Mein Testmühle mit Festplatten (auch GBit Netzw.), schafft im gleichen Netz und mit gleichen Parametern verbunden knappe 40MB/sek.


    Ja, damit kann man viel Zeit verbringen. Wenn mein Netz es gerade gut meint, schiebe ich per rsync und nfs 50-60 MB/s durch, das hängt aber von der Tagesform ab. :unsch
    Ansonsten lässt sich mit NetIO die reine Netzwerkperformance recht gut testen. Bei einem real laufenden System spielen meist viele (z.T. nicht beeinflussbare) Faktoren eine Rolle.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!