Beiträge von Schlunz

Hast ja recht. Hatte noch ein wenig Frustration und Verärgerung wegen der 2 verschwendeten Tage im Blut...

So, habe jetzt einen anderen Lösungsansatz verfolgt, der nun auch bestens funktioniert:

c't VDR 5 deinstalliert und dafür LinVDR 0.7 mit VDR1.4.0 und Kernel 2.6.15 installiert.

Und schon braucht mein Board kein reboot mehr, weil das System nicht in den Tiefschlaf versetzt wird und somit funktioniert auch das WOL.

Sorry Heise, aber das wars bei mir für eure VDR-Distri.

So, habe jetzt einen anderen Lösungsansatz verfolgt, der nun auch bestens funktioniert:

c't VDR 5 deinstalliert und dafür LinVDR 0.7 mit VDR1.4.0 und Kernel 2.6.15 installiert.

Und schon braucht mein Board kein reboot mehr, weil das System nicht in den Tiefschlaf versetzt wird und somit funktioniert auch das WOL.

Sorry c't, aber das wars bei mir für eure VDR-Distri.

Den Befehl
ethtool -s eth0 wol g
habe ich in einem Shutdown-Script stehen. Wie ja gesagt, wenn ich den Rechner einfach runterfahren lasse (ohne reboot), funktioniert das WOL ohne Probleme. Nur sobald der reboot über die vdr-nvram-wakeup.conf mit poweroff-Kernel oder halt-Befehl in Grub ins Spiel kommt, funktioniert WOL nicht mehr.
Deshalb inzwischen meine Vermutung, das es evtl. mit der Reboot-Funktion der c't-Scripte zu tun haben könnte.
Denn wenn ich den Rechner ohne reboot herunterfahre und danach den reboot manuell auslöse, also Rechner von Hand einschalten und z.B. den poweroff-Kernel boote, geht WOL auch immer noch. Nur halt beim autom. reboot bleibt der Rechner danach regungslos.

Hallo,
ich habe hier ein kleines Problem mit WOL und dem für mich notwendigen reboot für nvram-wakeup.
Wenn ich den reboot über die vdr-nvram-wakeup.conf aktiviere (SPECIALSHUTDOWN und FORCE_REBOOT) und dann z.B. einen Poweroff-Kernel oder aber den halt - Befehl in der Grub menu.lst verwende, kann ich den Rechner danach nicht mehr via Wake On Lan aufwecken. Lasse ich den Rechner allerdings ohne reboot runter fahren, schalte ihn danach von Hand wieder ein und wähle dann manuell z.B. den Poweroff Kernel aus, kann ich den Rechner via WOL aufwecken !?

Meine Vermutung ist nun, das es evtl. an irgendeinem Script, das c't VDR5 beim runterfahren mit aktiviertem reboot verwendet, liegt. Nur leider ist mir bislang noch nicht so ganz transparent, was hier bei einem solchen shutdown alles für Scripte aufgerufen werden.

Welche Scripte werden denn aufgerufen, wenn der Rechner mit einem nachfolgendem reboot herunterfährt?

Viele Grüssen, Frank

Das habe ich alles schon probiert.
Leider ist es bei mir so, das wenn ich den normalen Kernel mit der Option 0 boote (Runlevel 0), wacht der Rechner zum gesetzten Zeitpunkt nicht mehr auf. Mit einem Poweroff-Kernel oder mit "halt" in der menu.lst von Grub wacht er ohne Probleme auf, nur habe ich dann halt das WOL-Problem. Scheint irgendwie ein Problem mit der c't VDR 5 Distro zu sein.

Bei meinen weiteren "Forschungen" habe ich inzwischen herausgefunden, das es irgendwie mit dem shutdown-Script der c't Disto zu tun haben muss. Sobald ich in der vdr-nvram-wakeup.conf den reboot aktiviere, tritt das WOL-Problem auf. Lasse ich den Rechner ohne reboot herunter fahren, schalte ihn danach von Hand ein und wähle dann in Grub den Menue-Eintrag mit dem "halt" Befehl oder den Poweroff-Kernel aus, funktioniert danach das WOL komischerweise noch.

Ich werde mal weiter schauen. Muss doch in den Griff zu kriegen sein

Gruss, Frank

Hi,
nach anfänglichen Schwierigkeiten mangels laufender Config für nvram-wakeup für mein Asus K7V habe ich das setzen des Bios-Timers nun in den Griff bekommen.
Nun stellt sich mir leider ein weiteres Problem. Und zwar fällt meine Rechner nach dem Shutdown aus dem normalen System in den Tiefschlaf, aus dem das Bios Ihn auch nicht mehr herausholen kann. Festgestellt habe ich das, weil ich erst einen Reboot in den Runlevel 0 mit dem ursprünglichen Kernel versucht habe und er auch dann nicht aufwacht. Deswegen muss ich meinen Rechner im Moment mit dem Halt-Befehl in Grub oder aber mit einem Poweroff-Kernel rebooten.
So weit, so gut.
Nur leider wird bei dem reboot meine Netzwerkkarte (D-Link DFE-530TX Rev A3-1) resettet, sodass die vorher aktivierte Wake On Lan-Funktion wieder deaktiviert ist und ich den Rechner so nicht mehr via WOL aufwecken kann (ein Teufelskreis ).

Nun bräuchte ich eine schlaue Idee, wie ich beides zusammen zum laufen bekomme. Entweder bräuchte ich einen Tipp, weswegen der Rechner, wenn er aus dem normalen Kernel bzw. System herunterfährt, über den gesetzten Timer im Bios nicht wieder aufzuwecken geht, sondern erst, wenn ich einen reboot mit Poweroff-Kernel oder den Halt-Befehl in der menu.lst von Grub mache.
Oder aber, wie kann ich nach dem reboot die WOL-Funktion auf der Netzwerkkarte wieder aktivieren?

Bin wirklich für jeden Hinweis dankbar!

Gruss, Frank

Hi,
da hier ja häufig die Frage aufkommt, ob das Mainboard XYZ von nvram-wakeup unterstützt wird, möchte ich hier mal einen kleinen Tipp los werden, wir man schnell und einfach zu einer Antwort kommt.
Mein Board wurde von nvram-wakeup nämlich auch nicht autom. erkannt aber trotzdem unterstützt.

Als erstes holt man sich auf der Projekt-Seite den aktuellen Source-Code (nvram-wakeup -0.97.tar.bz2) und entpackt diesen.
Dann die Datei "nvram-wakeup-mb.c" in einem Texteditor öffnen und nach dem fraglichen Board suchen lassen. Wenn man Glück hat, findet man sein Board in einer Zeile die dann ungefähr so aussehen wird:

{ asus_cuv4xe,      "asus_cuv4xe",      "ASUSTeK Computer INC.", "<A7V133>", "REV 1.xx", "Award Software, Inc.", "ASUS A7V-133 ACPI BIOS Revision 1009", "04/23/2002" },

Die ersten beiden Einträge in der Zeile (asus_cuv4xe) geben dann an, unter welchem iwname das Programm das gesuchte Board unterstützt. Das heisst also in diesem Fall für ein Asus A7V-133 mit Bios Rev.1009 muss nvram-wakeup mit der Option "--iwname=asus_cuv4xe" aufgerufen werden.
Es darf dann aber in der Commandline auf keinen Fall mehr die Option "-C /etc/nvram-wakeup.conf" verwendet werden, weil bei Verwendung eines Config-Files der --iwname Eintrag ignoriert wird.

Dann mal schönes Rechner aufwecken!

Gruss, Frank

Das "-c" in der Commandline muss auf jedenfall raus!
Das könnte der Grund sein, weswegen er den timer nicht setzen konnte. Wenn nämlich die Option -c gesetzt ist, wird --iwname ignoriert. Und da Du -c angegeben hast, allerdings nun ohne entsprechende Config-Datei, kommt es vermutlich zu dem Fehler.
Ansonsten gehe mal ins Bios und aktive das wakeup von Hand (mit Datum und Uhrzeit), boote den Rechner und kontolliere noch einmal mit

nvram-wakeup --iwname=asrock_k7vt4

ob die Einstellungen so stimmen.
Vielleicht hat nvram-wakeup aufgrund eines fehlenden Timers im VDR richtiger Weise das wake-up deaktiviert. Die zuletzt gesetzte Aufwachzeit steht aber deshalb immer noch in den entsprechenden Registern.

Hast Du es mal ohne Configfile (nvram-wakeup.conf) und stattdessen mit

nvram-wakeup --iwname=asrock_k7vt4

versucht?
Also die Option "-C /etc/nvram-wakeup.conf" durch "--iwname=asrock_k7vt4" ersetzen.

Könnte so klappen.

Gruss, Frank

Dein Board wird von NVRam-Wakeup unterstützt. Leider erkennt das Programm nicht alle Boards von alleine (war bei mir auch so).

Versuche mal folgenden NVRam Aufruf:

nvram-wakeup --iwname=asus_cuv4xe

Falls die Fehlermeldung wegen fehlendem /dev/nvram kommt, das Device entweder mit

mknod /dev/nvram c 10 144

anlegen, oder aber beim Aufruf noch die Option -A (für --directisa) anhängen.

Sollte eigentlich klappen.

Und noch ein Tipp für alle, die wissen wollen, ob Ihr Board von nvram-wakeup unterstützt wird:
Einfach mal den Quellcode saugen (Link) und entpacken und dann die Datei "nvram-wakeup-mb.c" mit einem Texteditor öffnen und dort nach dem eigenen Mainboard suchen. Am Anfang der entsprechenden Zeile steht dann die Bezeichnung des MB für die --iwname Option.

Gruss, Frank