Posts by elle

    Moin,


    habe etwas aehnliches kuerzlich bei jemandem gemacht mit einer DS215+:
    - Windows Server 2012 wird per Veeam auf die DS gesichert
    - 2 Linux VMs per rsync


    Die DS hat morgens einen Cronjob laufen, der die 3 Verzeichnisse per rsync (script, das vom task scheduler des DSM gestartet wird) auf externe Laufwerke, die einmal woechentlich getauscht und ausser Haus gebracht werden, sichert. Zunaechst hatten wir USB3 Laufwerke fuer's externe Sichern im Einsatz, hier war die Performance grottig und die DS wurde ziemlich warm - ich habe dann irgendwo gelesen, dass das USB Interface der Synologies nicht wirklich der Knaller ist; nun sind eSATA Laufwerke im Einsatz, die deutlich performanter sind, aber warm wird die Kiste immer noch.


    Nach dieser Erfahrung ist der Gen8 Server besser, da ihn USB Transfers nicht so jucken sollten - allerdings nur, wenn du XPenology voll vertraust ...


    Das Script macht nichts anderes als die externe Platte zu unmounten, falls sie gemountet sein sollte (DSM mountet die automatisch beim anstecken), dann den rsync durchzufuehren und die Platte wieder abzuhaengen.


    Gruss


    /elle


    P.S.: das bei den Platten mitgelieferte eSATA Kabel musste am Steckergehaeuse auf Seiten der Synology leicht abgefraest werden, da der Stecker sonst nicht vernuenftig Kontakt bekam...



    Hi elle


    kannst du mal schreiben was du genau gemacht hast?


    Hi,


    ich versuch's mal komplett aus dem Gedaechtnis zusammenzuschreiben:

    • MLD lt. Beschreibung auf der Website auf der SD Karte installieren
    • Server: NFS System installieren (da kommt IIRC noch der portmapper und ein oder zwei rpc daemons mit) - die OS Installations eines solchen Servers ist ein eigenes Thema :-D

      Code
      1. Debian: apt-get install nfs-kernel-server


    • Server: Verzeichnis anlegen, auf dem die NFS Root liegen soll - da ich plane, dort auch noch andere abzulegen, habe ich die MLD fuer den PI in ein eigenes Unterverzeichnis unter dem Share gelegt

      Code
      1. mkdir -p /srv/nfsroots/mld


    • Server: ein share fuer die NFS roots in /etc/exports definieren - der Stern unten bestimmt, welche Clients den Share mounten duerfen

      Code
      1. /srv/nfsroots *(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,sec=sys,rw,no_root_squash,no_all_squash)


    • Server: ein share in /etc/exports fuer das VDR Aufnahmeverzeichnis definieren - der Stern unten bestimmt, welche Clients den Share mounten duerfen (mein video_dir ist /srv/VDR)

      Code
      1. /srv/VDR *(rw,no_root_squash,no_subtree_check)


    • Server: die exports neu laden

      Code
      1. exportfs -rav


    • Client: Mounten des MLD Verzeichnisses im NFS Share nach /mnt2 (auf dem MLD Client ist /mnt in Benutzung):

      Code
      1. mkdir /mnt2 && mount <ServerIP>:/srv/nfsroots/mld /mnt2


    • Client: Kopieren des Inhalts der Rootpartition auf den Server:

      Code
      1. rsync -avx / /mnt2 # Das x sorgt dafuer, dass rsync in dem einen Filesystem bleibt, dadurch wird der Inhalt von /dev /sys usw. nicht mitkopiert


    • Client: Unmount des Datenverzeichnisses

      Code
      1. umount /mnt/data


    • Client: Erstellen des Aufnahmeverzeichnisses bzw. Mountpoints:

      Code
      1. mkdir /mnt/data/tv


    • Client oder Server: Anpassen der geteilten fstab (nicht die des Servers!!!!) - auskommentieren des bisherigen Eintrags fuer das rootfs und einbinden des Serververzeichnisses; auf dem Server
      Code
      1. vi /srv/nfsroots/mld/etc/fstab

      auf dem Client

      Code
      1. vi /mnt2/etc/fstab


      Code
      1. #UUID=<eine lange UUID> / btrfs errors=remount-ro 0 1
      2. <ServerIP>:/srv/nfsroots/mld / nfs defaults 0 0
      3. #UUID=<eine lange UUID> /mnt/data nfs defaults 0 0
      4. <ServerIP>:/srv/VDR / nfs defaults 0 0


    • Client: Aendern der /boot/cmdline fuer DHCP

      Code
      1. root=/dev/nfs rootfstype=nfs nfsroot=<ServerIP>:/srv/nfsroots/mld quiet splash=quiet ip=dhcp nodialog smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0


      fuer static IP

      Code
      1. root=/dev/nfs rootfstype=nfs nfsroot=<ServerIP>:/srv/nfsroots/mld quiet splash=quiet ip=<clientIP>:<serverIP>:<gateway>:<netmask> nodialog smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0


    • Client: Aendern der /boot/config.txt - dort den Eintrag fuer die initramfs entfernen oder mit einem # auskommentieren


    Ich hoffe, ich habe nichts vergessen ... :-D


    Ruhig fragen, falls Du Fragen hast - wie gesagt, bin nicht sicher, ob ich alles richtig aus dem Gedaechtnis zusammenbekommen habe...
    Gruss


    /elle


    Hallo Claus,


    wie Johns bereits schrieb, kann der Kernel das selbst; m.W. sollte das aber unabhaengig davon, ob eine initramfs geladen wird oder nicht funktionieren - bin mir da aber nicht sicher.


    Werde das heute abend mal probleren - bin im Moment nicht zu Hause und habe hier keinen Pi, mit dem ich es probieren koennte.


    Waere es eventuell denkbar, einfach zum Test einen anderen Kernel zu verwenden oder hat der MLD Kernel irgendwelche Spezialitaeten eingebaut, sodass MLD mit einem anderen Kernel nicht laufen wuerde?


    Johns - die U-Boot Geschichte brauche ich doch nur, wenn ich auch den Kernel ueber's Netz laden moechte. Den lade ich hier aber nach wie vor von der SD-Karte.


    Danke + Gruss


    /elle

    Hallo zusammen,


    bin gerade dabei, mit einem Raspberry Pi 2 herum zu experimentieren. Nachdem das System problemlos von SD Karte laeuft, wuerde ich gerne root ueber NFS mounten, um eben die SD Karte etwas zu schonen. Der Server laeuft eh ...


    Nun bekomme ich aber beim Booten die Meldung (quiet und splash=quiet habe ich aus /boot/cmdline rausgenommen, um die Meldungen lesen zu koennen), dass der NFS share ein

    Code
    1. Unknown root device

    ist.


    Der NFS Server laeuft, von meinem Laptop aus kann ich den Share auch problemlos mounten, aber auf dem Pi lande ich in der Busybox der initrd. Wenn ich dort manuell versuche zu mounten bekomme ich die Meldung, dass die Verbindung verweigert wird (connection refused).


    Kann es sein, dass der MLD Kernel kein NFS root device kann? Lt. der config im GIT scheint es einkompiliert zu sein, aber muss ev. die initrd neu gebaut werden oder bin ich einfach nur zu bloed?


    Auf dem Server:

    Code
    1. root@helos:~# exportfs -v
    2. <snip>
    3. /srv/nfsroots <world>(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,sec=sys,rw,no_root_squash,no_all_squash)
    4. </snip>


    cmdline auf Raspberry:

    Code
    1. root=/dev/nfs rootfstype=nfs nfsroot=192.168.2.100:/srv/nfsroots/mld ip=dhcp nodialog smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0


    Danke + Gruss


    /elle

    Hallo zusammen,


    nachdem mir anscheinend mal wieder eine Satkarte kaputt gegangen ist und ich nur noch einen Tuner in meinem Server zur Verfuegung habe, stehe ich vor der Auswahl eines Ersatzes fuer die kaputte Karte.


    Zur Auswahl stehen:

    • Octopus + DuoFlex S2
    • Cine S2
    • DVBSky S952
    • Digibit R1 (SAT->IP)
    • Octopus Net (SAT->IP)


    Leider kann ich nirgends einen Vergleich der Karten finden und weiss nicht, welche ich mir anschaffen soll.


    Hat eventuell jemand mal einen Vergleich anstellen koennen?


    Ebenfalls interessant waere zu wissen, wie problemlos (oder -behaftet) der Einsatz eines SAT->IP Receivers (e.g. Octopus Net oder Digibit R1) mittlerweile mit VDR ist.


    Kann mir da jemand behilflich sein?


    Der Server ist headless mit einem AsRock Q1900M Pro3 Mainboard (2x PCIe + 2x PCI) und 8GB RAM und steckt in einem Miditower.


    Danke vorab schonmal.


    Gruss


    /elle

    Moin,


    ich habe einen VDR Server laufen (bzw. meist eher nicht), der per acpi-wakeup fuer Aufnahmen geweckt wird und per etherwake/wakeonlan bei Bedarf ueber die /etc/rc.local von den Clients geweckt wird. Es gibt keinen Grund, den Server auf Verdacht staendig laufen zu lassen.


    Klappt wunderbar - das Einzige, das ein wenig laestig ist, ist, dass die Clients etwas laenger brauchen, bis sie ein Bild anzeigen und der Mount des Aufnahmeverzeichnisses erst etwas spaeter verfuegbar ist.


    Gruss


    /elle

    Sah ganz normal aus - das ist ja das merkwuerdige: Ich konnte keinerlei Unregelmaessigkeiten beobachten ...


    Habe die Kiste damals mit munin monitored (via lmsensors) und dabei sind die Temperaturen der Cores nie weit von 40 Grad abgewichen - mal 2 oder 3 Grad mehr aber das war's - aehnlich mit den HDD Temperaturen, die immer so zwischen 28 und 40 Grad lagen (jetzt liegt die eine Platte bei 30 Grad - und das auf dem Speicher bei dem Wetter :-).


    Gruss


    /elle

    Moin,


    das ist interessant - aehnliches hatte ich auch bei meinem Server (siehe Sig.), allerdings nicht reproduzierbar und ohne Backtrace o.ae.. Auch zeitlich war alles zwischen 2 Minuten nach Boot sowie mehreren Tagen alles drin. Die Kiste lief damals 24x7 (wenn sie denn lief) und sollte als Server laufen.


    Nun laeuft das Ding nur noch on demand (acpi wakeup) mit ausgelagertem NFS und ich habe keine Probleme mehr damit. :-D


    Meine Beobachtungen (nach Durchtauschen mehrerer Speicherriegel) haben mich vermuten lassen, dass es ein Temperaturproblem gab. Die Probleme traten weniger haeufig bei geoeffnetem Gehaeuse (so betreibe ich die Kiste im Moment) auf.


    Auch habe ich mit verschiedenen DVB Kombinationen, Kerneln usw. experimentiert, aber keinen echten Erfolg gehabt, ausser dass beim backported 3.2.0 Kernel (das System laeuft unter Debian squeeze) das Problem weniger stark zu sein schien.


    Gruss


    /elle

    Code
    1. frontend 1/0 timed out while tuning to channel 3, tp 394


    Falls mich mein Alzheimer nicht taeuscht, heisst dies doch, dass der VDR nicht auf den Tuner zugreifen kann, oder irre ich mich da?!


    Kann es sein, dass tvheadend noch laeuft und somit die Tuner blockiert?


    Gruss


    /elle


    Versucht Dein Client ev. ueber IPv6 zu mounten und ist daher nicht zugelassen?


    Ersetze mal Dein konkretes 192. Netz einfach nur durch * und versuch's dann noch mal. Dass localhost nicht geht, ist bei Deiner exports klar - 127.0.0.1 ist nicht erlaubt.


    Gruss


    /elle

    Ich waere mir da nicht so sicher - ich hatte das Problem auch und musste feststellen, dass aus Clientsicht alle Dateien nobody:nogroup gehoerten und ich nicht darauf schreiben konnte.


    Ich musste in der fstab explizit die Option

    Code
    1. nfsvers=3

    setzen, damit er mit NFS v3 connected und alles wie gehabt funktioniert.


    Gruss


    /elle


    Edit: P.S.: Ich war einfach zu faul, mir NFS v4 anzulesen und den Kram dann umzustellen :-)

    Hi Darkstar,


    ich denke, dass XBMC fuer die Dockstar doch etwas zu viel des Guten ist - zu hoher RAM Verbrauch, zu hohe Anforderung an CPU usw.


    Anscheinend braucht's zum Betrieb des XBMC nach dem Stacktrace zu urteilen auch noch Zugriff auf nen RTC, den die Dockstar nicht hat.


    Wenn's nur um Musik auf der Dockstar selber abspielen mit Fernsteuerung via WLAN/LAN geht, solltest Du Dir mpd ansehen (http://mpd.wikia.org/); das habe ich auch laufen und funktioniert wunderbar und bietet Clients/"Apps" fuer jedes gaengige OS und Mobiltelefon an.


    Falls Du auf der Dockstar Debian installiert hast - reicht ein

    Code
    1. apt-get install mpd ncmpc

    auf der Kiste selbst zur Installation aus. Dann noch Dein Musikverzeichnis nach /var/lib/mpd/music verlinken, die Dateien von mpd einlesen lassen und das war's dann ...


    Gruss


    /elle



    Quote

    Originally posted by Darkstar
    Hi,
    ich würde gerne XBMC auf der Dockstar laufen lassen um so über das Webfrontend bzw eine iPhone App Musik abspielen zu können. Nach ein bischen rumprobieren mit Xvfb und xserver-xorg-video-dummy komme ich aber leider nicht weiter, da das ganze immer mit einer "Illegal Instruction (core dumped)" abstürzt. Im crashlog finde ich einen zimelich kurzen Stracktrace der mich aber leider auch nicht wirklich weiter bringt:

    Code
    1. Thread 1 (Thread 3231):
    2. #0 0x00262438 in CThread::CThread() ()
    3. #1 0x001f7b48 in CAlarmClock::CAlarmClock() ()
    4. #2 0x001f7bd0 in ?? ()
    5. #3 0x001f7bd0 in ?? ()
    6. Backtrace stopped: previous frame identical to this frame (corrupt stack?)


    Hat jemand vielleicht eine Idee wie das ganze laufen könnte?


    Gruß Darkstar

    Hi,


    ich war von einem Standard-Ubuntu oder Debian ausgegangen und mir nicht bewusst, dass die yaVDR-Jungs autofs veraendert haben, sorry.



    Aber vielleicht kriegst Du's ja trotzdem an's rennen ...


    Gruss


    /elle

    Moin,


    man koennte es aber auch per autofs machen - dabei gibt es aber mehrere Varianten, hier die einfachste, quasi out-of-the-box Variante:
    - apt-get install autofs
    - In /etc/auto.master die Zeile mit /net aktivieren
    - autofs neu starten
    - cd /net/<hostname>/<sharename> mountet automatisch den NFS-Share vom NAS
    - nach einer zeit der nichtnutzung wird automatisch unmountet


    Gruss


    /elle