[0.3] acpi-wakeup meckert "Need Acpi!" auch nach komplettem yavdr Reinstall

Hi,

ich bin gerade dabei meinen ehemals SD only VDR von debian mit e-tobi nach yavdr umzuziehen.
Da acpi-wakeup mit debian funktioniert bin ich gerade der Verzweiflung nahe, denn bei yavdr erhalte ich immer folgendes im Log:

Jan 29 01:27:59 video vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.acpiwakeup as shell script
Jan 29 01:27:59 video vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2011-01-29 01:00:00
Jan 29 01:27:59 video vdr-addon-acpiwakeup: No writeable /proc/acpi/alarm or /sys/class/rtc/rtc0/wakealarm found. ACPI needed!!!
Jan 29 01:27:59 video vdr-shutdown: Shutdown aborted by /usr/share/vdr/shutdown-hooks/S90.acpiwakeup with exitcode 1

Dabei gibt es das /sys......

goebel@video:/lib$ ll /sys/class/rtc/rtc0/wakealarm 
-rw-r--r-- 1 root root 4096 2011-01-29 01:25 /sys/class/rtc/rtc0/wakealarm

Allerdings bringt ein cat davon immer genau nichts als Rückgabewert.
Da ich bei der Kernelumstellung von /proc/acpi/alarm auf /sys/class/rtc/rtc0/wakealarm damals (unter Debian) schon Probleme hatte das zum laufen zu kriegen habe ich dort weiterhin /proc/acpi/alarm genutzt. Das steht mir mit dem yavdr Kernel aber nicht zur Verfügung.

Ich habe schon HPET im Bios deaktiviert (obwohls früher mit wunderbar lief) und hpet=disabled als Kernelparameter übergeben. Es ändert sich aber leider nichts.

Habt ihr eine Idee für mich was ich noch falsch machen könnte? Board ist ein Asus M3N-H HDMI.

Ein wenig weiter ausprobieren zeigt mir, dass sich die richtige Stelle in /proc/driver/rtc ändert wenn ich in /sys/class/rtc/rtc0/wakealarm schreibe - allerdings geht das Schreiben nur als root.
Wenn ich mal ein chown vdr auf wakealarm mache kann auch acpi-wakeup schreiben und fährt runter.

Wo muss ich nun bei yavdr dran drehen damit vdr immer auf wakealarm schreiben darf?

Zitat

Original von ofenheizer
Hi.

Mal ne ganz blöde Frage. ACPI hast Du aber in der entsprechenden Datei auf 'enable' gestellt (/etc/vdr/vdr-addon-acpiwakeup.conf)?

Gruss
Markus

Ja, habe ich, auch acpi selbst habe ich nachinstalliert und aktiviert.
Wie im 2. Posting gesagt meckert VDR ja auch nicht mehr das es da nicht reinschreiben kann wenn ich händisch dem User VDR Schreibrechte auf /sys/class/rtc/rtc0/wakealarm gebe.

Ich hab zwar noch nicht getestet ob der Rechner dann auch wirklich aufwacht, aber das was in wakealarm geschrieben wird lässt sich per /proc/device/rtc wieder auslesen.

Es ist definitiv eine Installation vom ISO.

Zitat

Original von gda

Das verstehe ich nicht. Aus welcher Quelle hast du das denn nachinstalliert? Das ist doch per default installiert. Die Probleme, die du hast, gibt es nicht nach einer normalen yaVDR-Installation.

Gerald

Vielleicht war es ja schon installiert, das war letzte Nacht um 2 oder so
Nachdem ich gelesen habe "ACPI Needed!" bin ich davon ausgegangen das es nicht installiert ist und hab ein apt-get install acpid gemacht.

Ich hab jetzt erstmal ein
chown vdr /sys/class/rtc/rtc0/wakealarm
in meine rc.local gepackt.

Nun stehe ich vor dem nächsten Problem.
s2disk scheint solange zu funktionieren wie kein timer exisitert. Existiert ein Timer so wird brav nach wakealarm geschrieben und der Rechner scheint auch sonst das meiste des shutdowns durchzuführen, der Rechner geht aber niemals aus und bleibt pingbar (sonst geht aber nix mehr).

Zitat

Original von gda
Das hört sich für mich eher so an als wäre ACPI im BIOS ausgeschaltet.

Das ist definitiv an, lief ja seit ca. 2 Jahren mit etch und nachher mit lenny.

Zitat

Hmmm, der ist auch per default installiert. Hoffentlich hast du damit nicht irgendwie die Konfiguration kaputt gemacht. Wurdest du bei der Installation des acpid gefragt, ob du Konfigurationsdateien überschreiben willst?

Eine solche Abfrage kam definitiv nicht.
Wenn mir gerade einfallen würde in welchem Log noch gleich das Installationslog von apt versteckt wird würd ich mal eben nachgucken.

Zitat

Das absolut unnötig, weil der User vdr gar nicht dahin schreibt sondern root. Der user vdr benutzt dazu einen SUID-Wrapper. Mir ist völlig unklar was du da gemacht hast um in diese Situation zu kommen.

So kenne ich das auch von e-tobis Paketen und den shutdown-hooks.
Lustigerweise meckert der acpi-wakeup shutdown-hook aber nicht wenn ich vdr zum owner mache und schreibt dann auch brav die Weckzeit rein.
Mit owner root bricht der shutdown wie im oberen Log gezeigt einfach ab.

So, ich kann nun mein Problem definitiv mit einer komplett neuen Installation von yavdr ohne meine Acpi Pfuscherei reproduzieren.

Ich habe Schritt für Schritt mit dem System bisher genau das gemacht was ich hier http://egalus.wordpress.com/20…3-0a-auf-asus-m3n-h-hdmi/ beschreibe.

Das einzige was mir jetzt noch einfällt ist, dass yavdr irgend ein wrapper Script einsetzt das nur auf die yavdr Standard UID bzw. GID von vdr anspringt, denn diese habe ich beide auf 1001 umgebogen (incl. aller Filerechte) damit meine NFS-Clients nicht alle auch umgemodelt werden müssen.

Und um mich völlig fertig zu machen funktioniert mein workaround mit
chown vdr /sys...../wakealarm nun auch nur noch in soweit als das es die wakeupzeit nun schreibt. Dafür fährt der vdr nun aber garnicht mehr runter, er läuft einfach weiter und blendet stattdessen irgendwann "VDR wird in 5:00 Minuten ausschalten" ein. Ich glaube heute ist nicht mein Tag.

Und nachdem ich gerade mal s2disk mit dem frisch installierten System ausprobiert habe muss ich feststellen das es zwar ein Image zu speichern scheint, der nächste Boot aber eben ein Boot und kein Resume ist - könnte das an eurem Default Linux Kernel Parameter -noresume liegen? Jedenfalls ist meine screen session nach einem s2disk - resume cycle immer weg.

Zitat

Original von gda

Na ja, das ist ja schon ein heftiger Eingriff. Hast du es denn erstmal ohne probiert?

Nein, habe ich nicht, da bisher noch nie irgendeine Distribution damit Probleme hatte, schließlich gibt es nicht umsonst die Übersetzungstabellen für UID und GID damit jeder User bzw. jede Gruppe eine beliebige eigene UID/GID haben kann.
Und das Umwandeln der GID und UID ist auch keine schwarze Magie sondern mit vier einfachen Befehlen durch.

Zitat

Richtig, bei uns ist das eigentlich ein Boot, weil der Resume aus s2disk keine Vorteile bringt. Der VDR muss ja sowieso runter, weil die DVB-Treiber entladen werden müssen. Die überleben den Suspend ja nicht. Der Unterschied zum Boot ist, dass er schneller durchs BIOS kommt.

Gerald

Aua, ihr könnt doch nicht ein suspend 2 disk durchführen und dann kein Resume machen.
Das trägt doch effektiv dazu bei Filesysteme zu zerstören und schießt so völlig unkontrolliert Prozesse ab.
Wenn man etwas so zerstörerisches macht, dann sollte man da vorallem eine Warnung zu ins webfrontend packen.
Und genau deshalb bringt der Resume extreme Vorteile, er zerstört nichts und sorgt dafür das Prozesse wieder da sind wo sie vor dem suspend mal waren. Auch braucht man sich keine Sorgen um etwaige Filesystemchecks zu machen, da die Filesysteme nicht neu gemounted werden müssen - weil der Zustand ja den Suspend-Resume überlebt und es daher keine Notwendigkeit dazu gibt.
Viel tragischer ist da diesen Resume nicht zu machen und dann nichtmal fscks auszuführen.

Ich stell mir das besonders lustig vor wenn user nebenbei noch irgendeine vm installieren und da was drin laufen haben und ihr schießt da einfach mal eben alles krass ab - sorry, aber das finde ich tatsächlich ziemlich unglaublich.

Ok, das der normale shutdown nicht funktionierte nach der Neuinstallation lag tatsächlich am GID/UID Renaming, da fehlte dann noch ein
chmod u+s /var/lib/vdr/shutdown.wrapper
da das chown auch das suid löscht.

Außerdem habe ich dann mal das noresume und quiet aus /etc/default/grub mit der template Methode entfernt damit ein s2disk auch wirklich ein resume macht.
Leider habe ich aber immer noch das Problem das die Kiste sich bei einem s2disk alle 3-4 mal nicht abschaltet sondern pingbar bleibt aber ansonsten tot ist - ganz ohne Ausgabe auf dem TV.
Gibts einen Weg wie ich zumindest mal die normale Konsole sehe während das s2disk läuft, sprich nachdem vdr vom shutdown-hook beendet wurde?

Danke, nun gibts endlich was zu sehen

Und das zeigt mir, dass s2disk immer wenn es hängen bleibt direkt nach der Ausgabe von
s2disk: snapshotting system
einfach stehen bleibt.

Eine Idee woran das liegen könnte?