Hi,
läuft der Apatsche auf demselben Rechner wie der vdr? Dann müsste es eigentlich gehen.
Ansonsten hilft's, statt der 127.0.0.1 den Hostnamen des vdr-Rechners einzutragen. Evtl. brauchst Du auch noch das "ProxyPassReverse"-Statement dazu. Systax wie bei ProxyPass, nur "ProxyPass" durch "ProxyPassReverse" ersetzen.
HTHH
Jürgen 
Hi,
gibt es eine Möglichkeit, die Standardfunktionen des VDR so zu erweitern, dass nicht nur das normale Kommando (z.B. "Aufnahme") ausgeführt wird, sondern noch was selbst definiertes (Script, Shell-Kommando...)davor und/oder danach zusätzlich?
Der Hintergrund: Ich benutze athcool. Damit der Rechner nicht beim nächsten Plattenzugriff (z.B. auf Logdatei)einige Sekunden hängenbleibt, muss ich dazu den DMA-Modus der Festplatte abschalten.
Das Ganze klappt aber nur, wenn ich ganz normal "fernsehe". Will ich nun unterbrechen und drücke die Pause-Taste (oder auch beim Aufnehmen), so gibt's üble Aussetzer, weil ohne DMA dass Zeugs einfach nicht schnell genug auf die Platte rüber kommt. Also müsste ich zum Aufnehmen 1) athcool abschalten, 2) DMA einschalten und 3) aufnehmen. Über die commands.conf kann man natürlich zumindest die athcoll/DMA-Geschichte regeln, aber praktischer wäre und "bedienungssicherer" wäre das bei Druck der Aufnahme-Taste etc.
Lassen sich die Funktionen irgendwo so umdefinieren?
Danke + Greetz
Jürgen
Hi,
nein
ja
nein
--> also nichts zu befürchten. Bei mir läuft's so prima. Wichtiger ist's, DECT-Telefone vom VDR fern zu halten!
Ciao
Jürgen
Hi,
wie sieht denn der Eintrag in Deiner inittab aus? Falls da "respawn" drinne steht, so workt's as designed. 
Ich starte das Dingens über ein rc-Script, da krieg ich die Probleme nicht. Allerdings muss ich den runvdr-Prozess mitkillen, sosnt schlägt der Watchdog zu.
HTHH
Jürgen
Vielleicht ist Dein Lüfter schon älter und die Lager nicht mehr so gut? Man sollte die Dinger wohl regelmäßig säubern, da der Dreck zu Unwucht führen kann und die Kugelager für radiale Lasten nicht besonders gut geeignet sind.
Ansonsten habe ich über die SuperSIlents eigentlich nur Gutes gelesen, besonders in Bezug auf Preis/Leistung. Ich werde mir einen SSPro mit Temperaturregelung (TC-Variante) besorgen und das PC-Gehäuse zusätzlich dämmen. Mal sehen (hören) ob's dann wohnzimmertauglich ist.
Die 55°C sollten noch o.k. sein. Was für ein Prozi isses denn?
Ciao
Jürgen
Hi,
ich habe ein K7SOM+ 7.5A, Du hast ein 7.5C. Da geht's schon mal los. Es gibt vom K7SOM+ noch mehr Versionen (mit 3 und mit 2 PCI-Slots), und jede hat ein anderes BIOS. Ich habe mal versucht, das aktuelle BIOS für 7.5 C bei mir aufzuspielen. Die Mühle war tot danach. Glücklicherweise habe ich durch wiederholtes CMOS-löschen und unzählige EIn-/Ausschaltvorgänge es geschafft, das Board zumindest wieder von Diskette booten zu lassen und das BIOS für 7.5A zu flashen.
Ich denke, schon aufgrund solcher "Feinheiten" wird es schwierig, Images zu erstellen. Dazu kommen noch die Freiheitsgrade bei der Peripherie (IDE, SCSI, Partitionen, Interrupts, DMA-fähige Geräte, USB, Firewire etc. pp), so dass man da sicher viel, viel Zeit und Gehirnschmalz investieren müsste.
Das K7SOM+ ist übrigens explizit ein OEM-Board von ECS, so dass die OEMs evtl. noch Spezilitäten reinkonfigurieren. Das macht's auch nicht leichter.
BTW: runtertakten geht nur, indem Du im BIOS 100/100 beim FSB einstellst. Evtl. bringt athcools was, such mal im Forum danach. Kühlen kannst Du das Ding wohl ganz gut z.B. mit einem Arctic SuperSilentPro o.ä. Der Originallüfter läuft bei mir mit 5.400 rpm! Der fliegt aber in Bälde raus, sobald die Kiste das "laborstadium" verlassen hat.
Just my 0,02 EURO
Jürgen
An dieser STelle noch 'ne Gegenfrage von mir:
Geht das mit der IR-Tastatur mit einer lernfähigen Standard-FB (z.B. CV1000 von Conrad)? Ich überlege diese Lösung nämlich auch.
Und vor allem: Ist auf der IR-Tastatur ein Power-on-Knopf, den die FB lernen kann? (lechz!)
Ciao
Jürgen
Wenn Du mit -t /dev/tty1 startest, kriegst Du wahrscheinlich Probleme, da tty1 auf eingaben der Tastatur wartet. Du müsstest dann den Eintrag für tty1 in der iniitab rausnehmen:
1:2345:respawn:/sbin/mingetty --noclear tty1
(telinit -q danach nicht vergessen, dann den entspr. mingetty-Prozess für tty1 killen!)
Macht aber keinen Sinn, du hast ja genug virtuelle Terminals.
Ciao
Jürgen
Hi,
ich hatte es so interpretiert, als würde er wohl mit -t /dev/tty starten, aber will nicht erst ALT+STRG+F7 drücken, sondern tty7 sofort sehen. Und dafür kann er chvt z.B. im runvdr-Script einsetzen.
Ciao
Jürgen
Hallo Leute,
so einem Forum tut es sicher gut, wenn nicht nur bei Problemen was geschrieben wird, sondern auch gelöste Probleme mal geschildert werden.
Ich will das jetzt mal für meine Umgebung tun. Der Text ist sehr lang geworden, aber ich habe auch sehr viel Zeit und Arbeit in die Lösung der diversen Probleme gesteckt. Und vielleicht kann ja der eine oder andere davon profitieren. Also, schnell noch 'ne Tüte Chips und ein Bier oder eine Flasche Rotwein geholt, es geht los!
Das HW-Umfeld:
AMD Duron 1300 auf MB K7SOM+ Rev. 7.5A, TT DVB-S Rev. 1.6
Aufgabenstellung:
Dieses System mit einem VDR zu betreiben, und zwar sowohl mit nvram-wakeup als auch mit swsusp. Ausgangsgbasis ist SuSE 8.2, vdr 1.2.5, DVB 1.0/1.0.1
Vorgehensweise:
Nach der SuSE-Installation mit dem Orig-Kernel (2.4.20) und der VDR-Umgebung (zunächst ohne swsusp, ohne nvram-wakeup) nach "Sandmann" lief alles auf's erste Mal --> gut.
Dann wollte ich swsusp installieren, um die Boot-Zeiten zu verkürzen. Das "stable" Release ist derzeit 1.0, aber die aktuellen Release-Candidates für Version 1.1 sollen funktional schon wesentlich verbessert ggü. 1.0 sein. Also 1.1-rc9 runtergeladen. Das erfordert einen 2.4.22-Kernel --> Vanilla 2.4.22-Sourcen gezogen. Zusätzlich noch den neuesten acpi-Patch. Kernel gemäß swsusp-Anleitung konfiguriert und übersetzt --> Internal Compiler Error! Nachforschungen ergaben, dass SuSE mit der 8.2 einen gcc 3.3. "prerelease" ausgeliefert hat. Also den aktuellen gcc 3.3.1 geholt. Damit ließ sich der Kernel und die Module dann bauen.
Das "Hibernate" von swsusp blieb hängen. Debugging ergab, dass ein Kernel-Bug im Highmem-Modul der Auslöser war. Da ich bei 128MB auf Highmem getrost verzichten kann, habe ich es ausgeschaltet (gibt aber wohl auch einen Patch dafür) und den Kernel neu übersetzt. Dann ging Hibernate und das Wiederaufwachen (zunächst noch ohne VDR) super.
swsusp bei laufendem VDR machte dann Probleme dergestalt, dass beim Aufwachen zwar das Bild wieder da war, der Ton aber nicht. Auch die Bedienung des VDR klappte nur noch über Tastatur, über's Netz (vdradmin) ging nichts mehr. Die Logs wiesen auf einen Ressourcenkonflikt hin. Ein sauberer händischer Restart des VDR, inklusive entladen und laden der DVB-Treiber (wichtig!), dann war wieder alles im Lot. Also muss das automatisiert werden. Dem swsupend kann man mitteilen, dass es Services vor dem Hibernate stoppen und beim Resume wieder starten soll. Voraussetzung ist ein SystemV-konformes start/stop-Script in /etc/init.d. Nun, das hatte ich sowieso schon erstellt, damit der VDR beim "normalen" Hochfahren gestartet wird (die inittab-Methode gefällt mir nicht so). Also die /etc/suspend.conf entsprechend angepasst. Aber es hatte keine Wirkung :-(. Irgendwie wurde der VDR nicht gestoppt. ich hatte nach dem Resume zwar nicht immer, aber immer wieder (unregelmäßig) die beschriebenen Ressourcen-Konflikte. Nach Umschiffung diverser Klippen und Untiefen in den Weiten der Unix-Meere war der Auslöser gefunden: der Watchdog-Timer! Es gibt keine (mir bekannte) saubere Prozedur für das Beenden des VDR mit aktivem Watchdog. Da ja normalerweise ein shutdown oder reboot erfolgt, ist das normalerweise auch egal. Ich muss aber ja die Treiber entladen, und das geht nur bei beendetem VDR. Also killte ich in meinem VDR-Initscript die VDR-Prozesse raus, und machte danach einen "make rmmod". Aber gleich nach dem Killen schlug wohl meistens (nicht immer!) der Watchdog zu und verhinderte durch den Restart, dass die Treiber entladen werden konnten ("device or ressource busy"). So wurde beim Hibernate das Image des Systems wieder mit laufender VDR-Umgebung abgelegt--> Konflikt beim Resume. Andererseits wollte ich auf den Watchdog nicht verzichten. Die Lösung war schließlich, vor dem Killen der VDR-Prozesse auch den runvdr-Prozess (ich starte im init-Script diesen per nohup) explizit rauszuschmeißen. Seitdem klappt das mit dem Hibernate und dem Restart des VDR sauber.
Hochfahrzeit des VDR bis das Bild kommt ist ab Drücken des Einschaltknopfes incl. Selbsttest, BIOS etc. ca. 30 Sekunden.
Nächste Baustelle: nvram-wakeup. Mein Board wird unterstützt, braucht aber den (doofen) reboot. Also musste ich dem swsusp einen Reboot beibringen. Es sieht wohl so aus, als würde dies (bei meinem Board) nur in der Debug-Variante von swsusp gehen. Jedenfalls hat es ohne Debug-Opotion nicht auf das entspr. Flag reagiert und immer einen power-off gemacht. Im Debug-Modus geht's. Die Flags für Power-off oder Reboot stellt man über die /etc/suspend.conf ein. Das ist natürlich schwierig zu automatisieren. Es erschien mir deswegen elegant, das Hibernate-Script so zu "customizen", dass es einen entsprechenden Parameter "--reboot" mit bekommt. Dann noch das vdrshutdown-Script angepasst, damit es den Grub richtig behandelt, und das war's!
Also momentaner Stand der Dinge:
VDR mit swsusp und nvram-wakeup tut wie gewünscht. Nachdem dies ja die unbedingte Mindestvoraussetzung ist (ok, swsusp hätte man zugunsten längerer Anlaufzeiten weglassen können, aber der "Jagdistinkt" war geweckt), werde ich mich nun den Plugins widmen.
Achja, schön wäre noch die Möglichkeit, vielleicht über einen "Special Key" auf der FB die Kiste zu veranlassen, beim vdrshutdown wahlweise einen "ordentlichen" shutdown -h zu machen, damit man auch mal "von Grund auf" booten kann. Aber solange man über's Netz noch an die Büchse (bzw. eine Shell) kommt, geht ja alles. Zudem werde ich mir eine "Web-Console" (Terminalserver) an die serielle Schnittstelle anschließen. Damit habe ich auch Zugriff auf die Büchse, wenn sie nicht mehr ins Netz kommt .
So, das war lang, aber es steckt ja auch genug Arbeit drin. Vielleicht hilft's ja jemandem...
So long
Jürgen
Hi,
das geht mit dem Kommando "chvt" (change virtual therminal)
# man chvt
NAME
chvt - change foreground virtual terminal
SYNOPSIS
chvt N
DESCRIPTION
The command chvt N makes /dev/ttyN the foreground terminal. (The corre
sponding screen is created if it did not exist yet. To get rid of unused
VTs, use deallocvt(1).) The key combination (Ctrl-)LeftAlt-FN (with N in
the range 1-12) usually has a similar effect.
Das kannst Du am Anfang ins init-Skript für Deinen vdr eintragen.
Funktioniert nur für root, also im Falle des Falles mit sudo arbeiten.
HTHH
Jürgen
Hi,
Das hört sich ja gut an! Ich werde heute abend mal bei mir testen.
Ich habe nämlich die Problematik, dass zwar nvram-wakeup bei mir funzt, aber nur mit dem Pseudo-Reboot. Dadurch kann ich aber swsuspend, welches den Rechner wesentlich schneller als ein Boot hochbringt, nicht nutzen. Die Lösungsmöglichkeiten wären nun
1) swsuspend den Reboot-Zyklus beibringen
2) genau Deine Lösung. Ich hatte mir das selbst auch schon ausgedacht, zumal bei mir auch ein Server 7x24h läuft. Danke, dass Du Dir meinen Kopf zerbrochen hast
Ciao
Jürgen
Hi,
bei mir sah es genauso aus (SuSE 8.2 Pro mit selbstgebautem Kernel 2.4.22, ACPI-Patch und swsusp). Letztendlich war wohl ACPI das Problem, denn ohne ACPI klappte alles. ACPI brauche ich aber wegen des Software-Hibernate (swsusp). Was dann schließlich geholfen hat, war der Parameter
pci=noacpi
beim Booten.
Damit funktionieren die Power-Modi von ACPI, aber es lässt den PCI-Bus (und damit die Sat-Karte) in Frieden.
Hoffe geholfen zu haben
Jürgen
