nvram-wakup funktioniert aber kein reboot

Kann man davon ausgehen, dass sich dein Rechner wie gewünscht ausschaltet, dein Board aber einen einmaligen reboot benötigt?

Dann wäre noch interessant, welchen bootloader Du verwendest?

Hallo auch,

ich muss doch noch einmal den Thread hervor holen. Mittlerweise habe ich das gleiche Problem wie gehlhajo. Die gentoo-vdr-scripts (Version 0.4.5) führen shutdown-halt.sh aus, obwohl mein System für den Reboot konfiguriert ist. Ich bin mir sogar ziemlich sicher, dass es in den aktuellen Konfiguration funktieniert hat.

Weiß inzwischen jemand die mögliche Ursache oder wie diese herauszufinden ist?

Gruß
pluto

Also der entsprechende Code um nvram-wakeup aufzurufen und dann den reboot auszuloesen steht in /usr/share/vdr/bin/vdrshutdown-wakeup-helper.sh.

Am einfachsten sollte es sein, ganz am anfang DEBUG=1 einzufuegen, und dann sich die angelegte log-Datei /tmp/vdrshutdown-wakeup-helper.log anzusehen, bzw. zu posten.

Gruss
Zzam

Hallo,

ich habe der Vollstädnigkeit halber, meine Ausgabe auch begefügt:

Started debug output of /usr/share/vdr/bin/vdrshutdown-wakeup-helper.sh 1232715480
+ VDR_WAKEUP_TIME=1232715480
+ reboot_mark_file=/var/vdr/shutdown-data/shutdown-need-reboot
+ _need_reboot=0
+ WAKEUP_METHOD=nvram
+ _set_wakeup
+ for method in '${WAKEUP_METHOD}'
+ run_wakeup_method nvram
+ local mod=nvram
+ '[' -f /usr/share/vdr/shutdown/wakeup-nvram.sh ']'
+ . /usr/share/vdr/shutdown/wakeup-nvram.sh
++ NVRAM_WAKEUP=/usr/bin/nvram-wakeup
++ CMD='/usr/bin/nvram-wakeup --syslog'
++ '[' '!' -x /usr/bin/nvram-wakeup ']'
++ '[' -n /etc/nvram-wakeup.conf ']'
++ CMD='/usr/bin/nvram-wakeup --syslog -C /etc/nvram-wakeup.conf'
++ '[' -n --directisa ']'
++ CMD='/usr/bin/nvram-wakeup --syslog -C /etc/nvram-wakeup.conf --directisa'
++ CMD='/usr/bin/nvram-wakeup --syslog -C /etc/nvram-wakeup.conf --directisa -s 1232715480'
++ /usr/bin/nvram-wakeup --syslog -C /etc/nvram-wakeup.conf --directisa -s 1232715480
--syslog parameter specified. All output goes to the syslog
++ case $PIPESTATUS in
++ set_reboot_needed
++ date +%s
++ _need_reboot=1
++ return 0
+ return 0
+ _do_shutdown
+ SHUTDOWN_METHOD=halt
+ need_reboot
+ local TSTAMP= BOOT=
+ '[' 0 = 1 ']'
+ '[' -e /var/vdr/shutdown-data/shutdown-need-reboot ']'
+ read TSTAMP
++ stat -c %Y /proc
+ BOOT=1232710087
+ '[' 1232710087 -lt 1232706999 ']'
+ return 1
+ f=/usr/share/vdr/shutdown/shutdown-halt.sh
+ '[' '' = 1 ']'
+ '[' -f /usr/share/vdr/shutdown/shutdown-halt.sh ']'
+ mesg 'Executing shutdown-halt.sh'
+ type logger
+ logger -t vdrshutdown-wakeup 'Executing shutdown-halt.sh'
+ . /usr/share/vdr/shutdown/shutdown-halt.sh
++ /sbin/shutdown -h now
+ return 0
+ exit 0

In Zeile 37 werden wohl die Weichen für den shutdown gestellt:

$BOOT = 1232710087 (Fr 23. Jan 12:28:07 CET 2009)
$TSTAMP = 1232706999 (Fr 23. Jan 11:36:39 CET 2009)

Ich habe den vdr gegen 11:30 Uhr hochefahren, d.h. die Zeit in $BOOT ist eine Stunde voraus und verhindert damit den notwendigen Reboot des Systems.

Die Ursache dafür liegt wohl in der Einstellung von CLOCK="local" in /etc/conf.d/clock. Die ich auf Grund der Multi-Boot-Umgebung meines
Test-VDR gern beibehalten würde.

Gruß
pluto

Hallo!

Also ich sehe gerade das die Kommunikation via Variable _need_reboot=1 nicht gehen kann, da nvram ja in einer subshell aufgerufen wird

Und das mit der Uhrzeit klappt durch die verwendete Zeitzone wohl nicht.

Man koennte das ganze ja jetzt mal durch ein komplett anderes System ersetzen.

Man muss das Flag need_reboot irgendwie setzen koennen. Und nach einem reboot sollte es nicht mehr gesetzt sein.
Da gibt es dann zB die Moeglichkeit eine Datei zu nehmen.
touch /tmp/need_reboot

if [ -f /tmp/need_reboot ]; then
SHUTDOWN_METHOD=reboot
fi

und dann bevor shutdown-reboot.sh aufgerufen wird die Datei wieder loeschen.
rm /tmp/need_reboot

Dann muss man nichts mehr rechnen ...

Ich hab das mal implementiert und als Patch angehaengt.

Hallo Zzam,

ich habe einige Tests mit dem Patch gemacht und es scheint bisher gut zu funktionieren. Danke!

Das einzige, was mir auffiel: Wenn kein neuer Timer exisitiert, rebootet das System trotzdem. Aber das wird bei einem produktiven VDR eh nicht vorkommen :).

Gruß
pluto

Schön, dass es funktioniert

Zitat

Original von pluto

Das einzige, was mir auffiel: Wenn kein neuer Timer exisitiert, rebootet das System trotzdem. Aber das wird bei einem produktiven VDR eh nicht vorkommen :).

Naja, dem sollte man trotzdem auf den Grund gehen.
Wenn du so lieb bist und das Debugging nochmal aktivierst, würde ich mich über die logs freuen im Fall, dass ein neuer Timer angelegt wurde, und im anderen Fall.

Wenn der Patch dann soweit geht kommt er auch in die gentoo-vdr-scripts mit rein.

Gruß
Zzam

Das Debugging ist noch aktiv. Allerdings gab es kein /tmp/vdrshutdown-wakeup-helper.log File!?

Wird denn /usr/share/vdr/bin/vdrshutdown-wakeup-helper.sh ausgeführt, wenn es keinen Timer umd somit nichts zu wecken gibt?

Den LOG für einen neuen Timer kann ich noch nachliefern.

Gruß
pluto

Ich habe versucht, die relevanten Varianten durchzuspielen. Alle dazugehörigen LOGs finden sich im Anhang:

A)
- System-Start: händisch
- Aktion: 2 Timer angelegt
- System-Stop: REBOOT

B)
- System-Start: nvram
- Aktion: 1. Timer aufgenommen
- System-Stop: REBOOT

C)
- System-Start: nvram
- Aktion: 2. Timer aufgenommen
- System-Stop: REBOOT

D)
- System-Start: händisch
- Aktion: keine
- System-Stop: HALT

Variante C braucht eigentlich keinen Reboot. Hilft Dir das weiter?

Gruß
pluto

Hi ploto!

Ja, die logs helfen gut weiter.

Also soweit ich das sehe ist das alles in Ordnung so. Variante C braucht den Reboot auch.
Denn da wird "wakeup" deaktiviert, und dafür scheint dein Board eben auch einen Reboot zu benötigen.

Gruß
Zzam

So, jetzt gibt es die gentoo-vdr-scripts-0.4.6, die diesen Patch beinhalten.

Zzam

Hi Zzam,

danke für das neue Ebuild!

Das Variante C auch einen Reboot braucht, hatte ich gar nicht in Erwägung gezogen. Aber jetzt, wo Du es sagst ...

Gruß
pluto