[yaVDR 0.4]: "Fake suspend to disk Alternative für Suspend to RAM." nicht auswählbar.

Die gleiche Frage stelle ich mir auch gerade. Vielleicht hat vom yaVDR Team ja eine Idee!

Falcon83 & poggenpower

Ja habe ich, die Funktion wurde für yaVDR 0.4 aus dem Funktionsumfang genommen.

Suspend-to-disk war ein Quell an Problemen, der nicht in den Griff zu bekommen war, Aufgrund dieser Erkenntnisse war es sicherer diese Funktion nicht weiter anzubieten und Nutzer sehenden Auges in langwierige Ergebnis-offene Problemanalysen zu schicken.

Ausserdem startet einigermaßen aktuelle Hardware heute oft schneller aus S5 als aus S4, das man selbst in diesen Fällen überlegen muß, ob S3 Sinn macht. Letzteres nutze ich z.B. nur auf einem Gerät um Wakeup-from-USB zu ermöglichen ...

Regards
fnu

Oder anders gesagt, wir müssen die Funktion anders implementieren, wenn wir es weiterhin anbieten wollen - bis das passiert ist ist es disabled.

Hallo

vielen Dank für den Status.
Ich habe einen Shuttle Barebone, der einen Wakeup nur aus S4 aber nicht aus S5 macht, daher wäre interessant, was für Probleme das waren.
Würde auch gerne bei der Fehlerbehebung unterstützen.

Gruß
Thomas

Zitat von poggenpower

Würde auch gerne bei der Fehlerbehebung unterstützen.

Kannst du das denn?

Gerald

Der fake S4 hat einen normalen S4 gemacht und beim Starten wurde das resume image ignoriert, es hat also kein geordneter Shutdown stattgefunden. Dies bedeutet das die Platten nicht sauber ausgehängt wurden was dann verschiedentliche Probleme nach sich zog welche fnu angesprochen hat.

Um das wiederzubeleben müsste man schauen ob man dem System beibringen kann, z.B. im /etc/init.d/halt ein s2disk zu benutzen anstatt halt (Das wäre meine momentane Arbeitsthese ich habe aber momentan keine Zeit sie zu verfolgen) Mein "Use Case" wäre mein NAS , welches WOL nur aus S4 beherrscht. Bei S5 oder S3 gibt es einen sofortigen Neustart.

Alternative Ideen und dessen Umsetzung wäre natürlich auch interessant

Reicht Dir ja oder brauchst Du einen Lebenslauf
Seit 2000 setzte ich privat nur Linux ein (Debian/Ubuntu), seit 2002 habe ich einen VDR.
Auch beruflich ist mir das ganze nicht fremd.
Bin allerdings kein Kernel-Developer, daher meine Frage wo es harkt, dann kann ich auch sagen, wo ich mit anpacken kann.

Viele Grüße
Thomas

Zitat von steffen_b

Der fake S4 hat einen normalen S4 gemacht und beim Starten wurde das resume image ignoriert, es hat also kein geordneter Shutdown stattgefunden. Dies bedeutet das die Platten nicht sauber ausgehängt wurden was dann verschiedentliche Probleme nach sich zog welche fnu angesprochen hat.

Ich könnte mir auch vorstellen einen angepassten PowerOff-Kernel zu nutzen, dann sind die Änderungen im Produktiven-Teil gering und den PowerOff-Kernel "unsauber" zu beenden sollte nicht so schlimm sein, da es ja eine RAM DIsk ist.

Gruß
Thomas

Auch denkbar, wenn man die Suspend Binaries und die Konfiguration mit vertretbaren Aufwand in die dazupassende initrd bekommt.

Hi,

ich habe noch ein bisschen rum probiert und recherchiert.

Meine Idee ist nicht einen Poweroff Kernel zu booten, da das erstellen und warten einer initrd zu aufwendig ist, sondern per Kernelparameter ein abgespecktes System zu booten, dass dann den S4 auslöst.
Dabei bin ich auf einen Konfigurationsparameter von "init" gestoßen:

Aus der man-Page, bzw. --help

thl@lenz:~$ sudo init --help
Usage: init [OPTION]...
Prozessverwaltungsdienst


Options:
      --confdir=DIR           specify alternative directory to load configuration files from

Damit könnte man z.b. in /etc/init-s4 nur die Scripte ablegen, die man wirklich braucht um runter zu fahren.

Doof ist nur folgendes:

thl@lenz:~$ sudo init --confdir /etc/init
init: invalid option: --confdir
Try `init --help' for more information.
thl@lenz:~$

Der Parameter funktioniert bei mir nicht. Auch auf einem "normalen" Ubuntu nicht. Hat jemand eine Idee?

Gruß
Thomas

P.S: ein Boot mit init=/usr/sbin/pm-hibernate funktioniert leider auch nicht, da das script auf der Platte rumschreiben will und die FIlesysteme noch readonly gemountet sind.

Du hast "=" vergessen.

Gerald

Zitat von gda

Du hast "=" vergessen.

Gerald

habe beide Varianten versucht. --help und man haben da unterschiedliche Syntax.

Gruß
Thomas

Zitat von poggenpower

thl@lenz:~$ sudo init --confdir /etc/init
init: invalid option: --confdir
Try `init --help' for more information.
thl@lenz:~$

Zitat von poggenpower

Der Parameter funktioniert bei mir nicht. Auch auf einem "normalen" Ubuntu nicht. Hat jemand eine Idee?

Ahh jetzt ja, ein --session scheint zu helfen, dann startet Init auf jeden Fall.
Doof ist nur, dass der Parameter von den Entwicklern als "nur für Testzwecke" gekennzeichnet ist.

Mal sehen, wie weit ich komme.

Gruß
Thomas

Update,

ein alternatives /etc/init-Verzeichnis kann ich jetzt ansprechen. Der --confdir Parameter wird nur akzeptiert, wenn noch kein anderes Init läuft.

Das habe ich gebaut:

• Das ganze wird einfach über einen Kernelparameter beim booten angesprochen init=/sbin/init-s4.
• init-s4 ist ein shellscript, dass init mit /etc/init-s4 als Config startet.1
• nach /etc/init-s4 habe ich die notwendigsten conf's kopiert.
• Das System startet in einer Minimalkonfiguration, ohne zusätzliche Module zu laden.
• Es gibt eine s4.conf, die das System automatisch auf der Platte einfriert.

Vorteile aus meiner Sicht.

• kein Eingriff in die bestehenden init-Scripte
• einfach zu warten, da eigens Verzeichnis, kein backen und aktualisieren eine initrd
• Das Haupt-System wird sauber herunter gefahren. Alle Trigger etc. werden abgearbeitet.
• Einfacher Start, Grundgerüst ist schon für den Poweroffkernel gebaut. Es muss nur eine Grub-Konfig in /etc/grub.d abgelegt werden.
• Da das Orignal System gebootet wird, stehen alle Anpassungen auch im S4 zur Verfügung. Packetupdates müssen nicht portiert werden.

Nachteile

• Das System wird einmal mehr gebootet, aber nicht beim starten, sondern beim Beenden, was zu tollerieren ist.
• Das System moutet auch im s4 die Platten RW, damit die Scripte laufen. Die werden nicht sauber unmouted. Da aber an wenig läuft, kann auch wenig kaputt gehen. man könnte noch drüber nachdenken, ein FS drüber zu legen, wie bei den Live-CDs, dass passieren die Änderungen nur im RAM, man hat dann aber auch kein logging.

Was noch zu tun wäre

• Script bauen, dass für den aktuellen Kernel einen angepassten Eintrag im Grub erzeugt.
• Config und Templates bauen, die das ganze in die yaVDR Logik integrieren.
• Paket bauen.

Bevor ich hier in Schönheit sterbe, hier die Frage an die Experten. Was haltet ihr von der Lösung ist das was, was in den yaVDR integriert werden kann/soll? Will jemand mal testen? Kann mir jemand bei der Anpassung für den yaVDR helfen (WFE, Templates, Paket)
Gruß
Thomas

Bis hier las sich das ganz gut:

Zitat von poggenpower

Das System moutet auch im s4 die Platten RW, damit die Scripte laufen. Die werden nicht sauber unmouted. Da aber an wenig läuft, kann auch wenig kaputt gehen.

Soweit waren wir ja auch schon. Deshalb ja der Ansatz mit der Initrd. Da die Skripte reinmachen, dann braucht auch nichts gemountet werden. Wenn man eine extra-Initrd dafür vorhält, dann hält sich der Pflege-Aufwand auch in Grenzen.

Gerald

Zitat von gda

Soweit waren wir ja auch schon. Deshalb ja der Ansatz mit der Initrd. Da die Skripte reinmachen, dann braucht auch nichts gemountet werden. Wenn man eine extra-Initrd dafür vorhält, dann hält sich der Pflege-Aufwand auch in Grenzen.

Das war ja auch meine Idee, nur nach der Untersuchung, ist der Aufwand nicht trivial, denn die pm-utils scripte sind recht umfang reich und mir einem reinen Kernel-Mode-S4 ist mein System nicht sauber suspended.
Das pm-hibernate script will auf die Platte schreiben. Braucht bash und perl.
PM-hibernate greift auf Devices zu, die erst mit dem Start von UDEV existieren.
uswsusp benötigt noch ein paar Dinge mehr.

Das alles in eine intird zu frickeln ist doch eine ganze Menge Aufwand, davon mal ganz abgesehen, dass dann jeder Fehler mit einer kernel panic endet und man kein Logfile hat, macht das Leben auch nicht einfacher.

Daher habe ich mich für den alternativen init-Zweig entschieden.

Das kein richtiger unmount gemacht wird halte ich auch nicht für so tragisch. Zum einen wird ja eine journaling FS eingesetzt und zum anderen sind die Änderungen man FS hier nicht kritisch, so dass keine wichtigen Informationen verloren gehen sollten.

Gruß
Thomas

Zitat von poggenpower

Das kein richtiger unmount gemacht wird halte ich auch nicht für so tragisch. Zum einen wird ja eine journaling FS eingesetzt und zum anderen sind die Änderungen man FS hier nicht kritisch, so dass keine wichtigen Informationen verloren gehen sollten.

Das war aber für uns der Grund S4 nicht mehr zu supporten.

Außerdem, wenn es einfach wäre dann hätten wir es doch schon längst gemacht.

Gerald