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

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:

Quote

Original von dirk.bae
Das Verzeichnis wird nach der Wartezeit nicht eingebunden.
Portmap wird kurz vorher geladen, auf dem server läuft er auch.
So kann ich das Verzeichnis von Hand einbinden:
mount /var/lib/video.00/
Und noch die fstab:

Code

#
/dev/loop/0      none            swap    sw,noauto              0       0
192.168.1.2:/var/netboot/nfsroot/ctvdr / nfs  defaults,hard,intr,rsize=65536,wsize=65536 0 0
192.168.1.2:/var/public/multimedia/video/vdr/vdr_client /var/lib/video.00          nfs     auto,rw,nosuid,hard,intr,rsize=65536,wsize=65536 0 0

Display More

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

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:

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:

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:

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:

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:

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

Loading vmlinuz-2.6.24.1.....

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

Bin für jeden Hinweis dankbar...

Gruß

Andreas

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

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.

vdr-wz:~# cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# folgendes vor exit 0 einfuegen
losetup /dev/loop/0 /var/swap
swapon /dev/loop/0
mount 192.168.1.10:/var/lib/video.00 /var/lib/video.00
mount 192.168.1.10:/var/lib/video.01 /var/lib/video.01
mount 192.168.1.10:/var/lib/video.02 /var/lib/video.02
mount 192.168.1.10:/var/lib/video.03 /var/lib/video.03
mount 192.168.1.10:/mnt/mp3 /mnt/mp3
mount 192.168.1.10:/mnt/net-streams /mnt/net-streams
cd /var/lib/vdr/plugins/dvdswitch
ln -s /dev/dvd1 dvdlink
exit 0

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

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(?)...

Quote

Original von Thomas
Feedback auf diesen Beitrag ist ja durchweg positiv.

Macht es aus Eurer Sicht sinn, dieses HOWTO sticky zu machen?

Ja, dann finde ich es am WE wieder

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

... allerdings schafft dein Server sicher mehr als 2MB/s, oder?

Kannst du einschätzen, ob mein Vorhaben Sinn macht, bei den 2-3 MB/s?

Gruß,
Hendrik

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

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

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ß

*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

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.

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:

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:

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