ubuntuusers.de

pm-utils

Archivierte Anleitung

Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

pm-utils steht für PowerManagement-Utils. Dieses Paket ist bis Ubuntu 14.10 Standard für den Wechsel in unterschiedliche Energiesparmodi.

Hinweis:

Seit Ubuntu 15.04 wird systemd für den Wechsel der Energiesparmodi verwendet. Dadurch sind viele Funktionen von pm-utils nicht mehr nutzbar.

Das Paket pm-utils beinhaltet (hauptsächlich) Skripte, die SUSPEND- und RESUME-Vorgänge (siehe auch Archiv/Energiesparmodi mit ACPI) ausführen. Dabei können die pm-utils-Skripte direkt (in einer Shell) oder indirekt (vom gnome-power-manager unter GNOME, bzw. von kpowersave / powerdevil unter KDE) im Auftrag von HAL aufgerufen werden [4]. Die pm-utils-Skripte greifen automatisch auf uswsusp zurück, sofern das Paket uswsusp [5] installiert ist und nicht explizit auf Kernel-Methoden zurückgegriffen werden sollte.

Die PowerManagement-Funktionen des Pakets pm-utils sollten ohne weiteres Zutun des Benutzers funktionieren. Ist dies nicht der Fall, so liegt es sehr häufig an den fehlerhaften Treibern oder an einer fehlerhaften Konfiguration des Systems. STR (=Suspend-to-RAM) und STD (=Suspend-to-Disc) funktionieren auf einem frisch installierten Ubuntu-System und auf Systemen, in denen nicht die aktuellste Hardware verbaut ist, häufiger als auf Systemen, die die neueste bzw. spezielle Hardware beinhalten oder im Laufe der Zeit Änderungen erfahren haben. Beispiele:

Durch solche Veränderungen am System kann es passieren, dass die zunächst ermittelten Werte über die SWAP-Partition, deren Größe usw. nicht mehr korrekt sind. Damit funktioniert STR oder/und STD dann nicht mehr.

Andererseits funktionieren STR und/oder STD auf anderen Systemen von Anfang an nicht, weil z.B. spezielle Hardware, die Ärger verursacht, verbaut ist.

Die Gründe und die Fehlerursachen für nicht funktionierende Energiesparmodi sind sehr vielfältig. Dieser Artikel sollte helfen, diese Fehlerursachen zu finden und zu beheben. Dazu muss ein wenig ausgeholt werden. Zuerst werden das Paket pm-utils, dessen Bestandteile (die pm-utils-Hooks) und der grundsätzliche Ablauf von SUSPEND und RESUME mit pm-utils erläutert. Im darauf folgenden Abschnitt ist erklärt, wie man herausfinden kann, welche Energiesparmodi auf dem eigenen System möglich sind. Anschließend wird erklärt, wie man STR und/oder STD einrichtet. Das letzte Kapitel behandelt Fehlersuche, Aktivierung des DEBUG-Modus u.ä.

Das Paket pm-utils

Installation

pm-utils ist in der Standardinstallation immer enthalten. Bei einer Minimalinstallation oder anderen Ubuntu-Varianten muss ggf. das folgende Paket installiert werden [1]:

  • pm-utils

Paketliste zum Kopieren:

sudo apt-get install pm-utils 

Oder mit apturl installieren, Link: apt://pm-utils

Die Dokumentation findet man unter /usr/share/doc/pm-utils.

Achtung!

Das Paket pm-utils sollte nie entfernt werden, da sonst Energiesparfunktionen nicht mehr genutzt werden können!

Mit pm-utils werden u.a. folgende Verzeichnisse und Dateien installiert. Dunkler hinterlegt sind die Namen der Dateien und Verzeichnisse, die vom Benutzer verwendet werden bzw. deren Inhalte von Benutzer verändert werden dürfen. Heller hinterlegt sind die Dateien und Verzeichnisse, die man nur dann braucht, wenn man sich mit Details beschäftigen möchte.

Datei/Verzeichnis Beschreibung/Inhalt
/etc/pm/config.d/ Verzeichnis, in dem Konfigurationsdateien abgelegt werden können, mit denen dann die Standardeinstellungen aus /usr/lib/pm-utils/ überschrieben werden.
/etc/pm/power.d/ Das Verzeichnis für die eigenen Hooks für Energiesparmodi , in denen kein SUSPEND gemacht wird.
/etc/pm/sleep.d Das Verzeichnis für die eigenen Hooks für Suspend-Energiesparmodi.
/usr/bin/pm-is-supported Programm, mit dem geprüft werden kann, welche SUSPEND-Modi erreichbar sind
/usr/lib/pm-utils/defaults Standard-Einstellungen für pm-utils
/usr/lib/pm-utils/functions Funktionen, die von pm-utils-Skripten verwendet werden
/usr/lib/pm-utils/bin/pm-action Das Skript, dass die Arbeit verrichtet
/usr/lib/pm-utils/power.d/ Das Verzeichnis mit den Hooks für Energiesparmodi , in denen kein SUSPEND gemacht wird. Zum Beispiel, anacron stoppen, wenn Notebook nicht am Netz ist, sondern vom Akku mit Spannung versorgt wird.
/usr/lib/pm-utils/sleep.d/ Das Verzeichnis mit den Hooks für Suspend-Energiesparmodi.
zusätzlich im Paket enthalten
/etc/pm/config.d/00sleep_module Datei, in die Benutzer Module eintragen sollten, die entladen und geladen werden sollen
/usr/lib/pm-utils/module.d/ In diesem Verzeichnis existieren Dateien kernel, tuxonice, uswsusp, mit den Definitionen der Funktionen, die bei der entsprechenden SUSPEND & RESUME-Methode angewendet werden. Die Variable $SLEEP_MODULE definiert, welche der SUSPEND & RESUME-Methoden kernel, tuxonice, uswsusp gilt. Voreinstellung ist kernel.
/usr/lib/pm-utils/pm-functions pm-functions enthält nur die Funktionalitäten für pm-utils-"Frontends" pm-action, pm-is-supported, pm-powersave. Die Datei functions wird auch von pm-utils-Hooks verwendet.

pm-utils - Hooks

"Hooks" sind pm-utils-Skripte, die bei SUSPEND- und RESUME-Vorgängen abgearbeitet werden:

  • beim SUSPEND-Vorgang werden die Hooks abhängig von der SUSPEND-Art mit dem Parameter suspend respektive hibernate in der alphabetischen Reihenfolge aufgerufen.

  • beim RESUME-Vorgang werden die Hooks in der umgekehrten Reihenfolge abgearbeitet, wobei sie beim RESUME_from_STR mit dem Parameter resume aufgerufen werden, beim RESUME_from_STD hingegen mit dem Parameter thaw.

Die Parametrierung der Aufrufe ermittelt pm-action automatisch ohne Zutun des Benutzers.

Hinweis:

Eigene Hooks werden in den Verzeichnissen /etc/pm/sleep.d bzw. /etc/pm/power.d gespeichert. Ein Beispiel-Hook ist weiter unten im Kapitel Eigene Hooks erstellen enthalten.

Mehr Informationen befinden sich in der Datei /usr/share/doc/pm-utils/HOWTO.hooks.

SUSPEND- und RESUME mit pm-utils

SUSPEND-Vorgänge mit pm-utils

  • Beim Auswählen von "Bereitschaft" im GNOME-Abmeldemenü wird das Skript /usr/sbin/pm-suspend aufgerufen.

  • Beim Auswählen von "Ruhezustand" im GNOME-Abmeldemenü wird das Skript /usr/sbin/pm-hibernate aufgerufen.

  • Künftig wird womöglich eine dritte Schaltfläche vorhanden sein, mit der man in einen Hybrid-Energiesparmodus wechseln können wird, sogenannter SUSPEND-HYBRID-Modus. Dabei würde das Skript /usr/sbin/pm-suspend-hybrid aufgerufen werden.

Diese Skripte können auch manuell ausgeführt werden, wobei alle Befehle/Skripte Root-Rechte[6] benötigen:

  • /usr/sbin/pm-suspend

  • /usr/sbin/pm-hibernate

  • /usr/sbin/pm-suspend-hybrid

Dies sind allerdings "nur" symbolische Links auf das Skript /usr/lib/pm-utils/bin/pm-action, das die eigentliche Arbeit verrichtet. Das Skript pm-action erkennt aus dem Aufruf (über die o.g. symbolischen Links) heraus, ob es von /usr/sbin/pm-suspend oder von /usr/sbin/pm-hibernate aufgerufen wurde. Daraufhin arbeitet das Skript die Hooks ab, indem sie in der entsprechenden Reihenfolge mit dem Parameter suspend bzw. hibernate aufgerufen werden. Anschließend wird der Rechner in den Schlaf geschickt.

Bei STD wird das Image auf die SUSPEND-Partition geschrieben:

  • STD über Userspace: Wenn uswsusp installiert ist UND in keinem der aufgerufenen pm-utils-Skripte HIBERNATE_METHOD="kernel" gesetzt ist, dann gilt HIBERNATE_METHOD="autodetect". Das Skript pm-suspend findet /usr/sbin/s2disk bzw. /sbin/s2disk und setzt HIBERNATE_METHOD="userspace". Dabei wird die uswsusp-Konfiguration (standardmäßig) aus der Datei /etc/uswsusp.conf gelesen.

  • STD über Kernelspace: Wenn uswsusp nicht installiert ist ODER in mindestens einem der augerufenen pm-utils-Skripte HIBERNATE_METHOD="kernel" gesetzt ist, dann wird auf Kernelspace zurückgegriffen, indem folgende Befehle (automatisch) abgesetzt werden:

echo -n "platform" > /sys/power/disk 
echo -n "disk" > /sys/power/state  

RESUME-Vorgang mit pm-utils

RESUME aus STR (S3) ist ein relativ einfacher Vorgang, in dem, vereinfacht gesagt, im Wesentlichen die Hardware-Komponenten mit Spannung versorgt werden, und der Rechner in den Arbeitszustand versetzt wird.

Nachdem ein "Wake-up-Event" erkannt wurde, prüft das BIOS, ob RESUME_from_STR oder ein normaler Boot-Prozess gestartet werden soll. Wenn RESUME_from_STR erkannt wird, startet das BIOS den "Kernel-Wake-up-code". Die Hooks werden dabei, wie oben erwähnt, in der umgekehrten Reihenfolge abgearbeitet. Die entladenen Module werden ggf. wieder geladen, die angehaltenen Dienste ggf. wieder gestartet. Bei Notebooks wird noch die Hintergrundbeleuchtung eingeschaltet etc.

RESUME aus STD (S4) ist ein etwas komplexerer Vorgang. Der Rechner bootet. Da das BIOS keinen Resume_from_STR erkannt hat, startet GRUB zuerst "ganz normal". Der Kernel liest die Boot-Parameter aus /boot/grub/menu.lst. Die initrd wird geladen, und an dieser Stelle kann (muss) der Kernel erkennen, dass der Rechner aus STD (S4) erwacht. Aus den Kernel-Parametern und/oder der initrd erfährt der Kernel, auf welcher Partition ein SUSPEND-Image vorhanden sein könnte. Wird nun kein SUSPEND-Image gefunden, so startet das System "normal weiter". Wird aber ein SUSPEND-Image gefunden, so wird dieses Image geladen und der RESUME_from_STD-Vorgang wird eingeleitet. Dabei wird der Inhalt des Images in den Arbeitsspeicher (zurück)geschrieben und die Hooks in der umgekehrten Reihenfolge abgearbeitet. Die entladenen Module werden wieder geladen, die angehaltenen Dienste wieder gestartet. Bei Notebooks wird noch die Hintergrundbeleuchtung eingeschaltet etc.

Vorbereitung, Entscheidung, Zieldefinition

Zuerst muss man herausfinden, welche Energiesparmodi erreicht werden können. Will man zum Beispiel STD erreichen, das System STD aber im aktuellen Zustand nicht unterstützt, so muss man zuerst das System in die Lage versetzen, STD erreichen zu können. Erst dann ist es sinnvoll, die Einrichtung von STD zu starten.

Sind SUSPEND/HIBERNATE möglich?

Für diese Prüfung verwendet man das Skript pm-is-supported aus dem Paket pm-utils, dass i.d.R. vorinstalliert ist.

  • In einer Konsole diesen Einzeiler eingeben:

    echo; for i in --suspend --hibernate --suspend-hybrid; do pm-is-supported $i && echo "$(echo $i | tr [:lower:] [:upper:] | tr -d -) is supported"; done; echo 

  • Alternativ: dieses Skript speichern, ausführbar machen und ausführen (läuft auch als nicht privilegierter Benutzer):

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    #!/bin/bash 
    
    # check if we can test acpi power states with pm-is-supported 
    if ! which pm-is-supported 1>/dev/null 
    then 
       echo 
       echo "pm-is-supported not found" 
       echo "Please install the package pm-utils if not installed" 
       echo 
       echo "Otherwise check \$PATH" 
       echo "pm-is-supported should be in /usr/bin/" 
       echo 
       exit 1  
    fi 
    
    # a new line 
    echo 
    
    # check POWER MANAGEMENT MODES 
    # for MODE in suspend hibernate suspend-hybrid 
    # do 
    #    pm-is-supported --$MODE && echo "Kernel supports $(echo $MODE | tr [:lower:] [:upper:] ) " 
    # done 
    
    pm-is-supported --suspend         && echo "Kernel supports SUSPEND (SUSPEND to RAM)" 
    pm-is-supported --hibernate       && echo "Kernel supports HIBERNATE (SUSPEND to DISK)" 
    pm-is-supported --suspend-hybrid  && echo "Kernel supports HYBRID-SUSPEND (to DISK & to RAM)" 
    # a new line 
    echo 
    
    exit 0 
    

Die Ausgabe nennt die möglichen Energiesparmodi, die das System im aktuellen Zustand erreichen kann.

Was ist das Ziel?

Nachdem festgestellt wurde, ob und welche Energiesparmodi erreicht werden können, muss man die Entscheidung treffen, ob diese Energiesparmodi über Kernelspace oder Userspace (zum Beispiel mit Hilfe von uswsusp) erreicht werden sollen.

Suspend_To_RAM

STR kann mit Hilfe von pm-suspend aus den pm-utils über den Kernelspace erreicht werden. Für die Alternative mit uswsusp im Userspace wird das dazu gehörige Programm s2ram genutzt.

Suspend_To_Disk

Will man STD einrichten, so muss man sich u.U. zuerst entscheiden, wohin das SUSPEND-Image (der Inhalt des Arbeitsspeichers) vor dem Einschlafen des Rechners geschrieben werden soll. Wenn vorhanden verwendet Ubuntu dafür standardmäßig die SWAP-Partition. Wenn ein Teil des Arbeitsspeichers im Betrieb schon dorthin ausgelagert ist, muss der erhalten bleiben, darf also nicht einfach durch das STD-Image überschrieben werden. Für STD muss die SWAP-Partition also immer groß genug sein, um den gesamten genutzten virtuellen Speicherbereich aufnehmen zu können.

Hat man keine SWAP-Partition im System (z.B. weil man großen Arbeitsspeicher hat) und möchte man trotzdem STD nutzen, so kann eine separate SUSPEND-Partition erstellt werden. Z.Zt. ist keine Lösung bekannt, wie man das SUSPEND-Image alternativ wie z.B. bei Windows auch in eine Datei schreiben kann.

Die Angabe über die Partition, auf die das SUSPEND-Image geschrieben wird, findet man an mehreren Stellen:

  • In der Datei /etc/initramfs-tools/conf.d/resume

    • Dabei kann sowohl der Partitionsname verwendet werden (RESUME=/dev/sda2), als auch der UUID-Identifier der Partition (z.B: RESUME=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Der UUID-Identifier ist eindeutig fuer jedes Gerät. Laufwerksbuchstaben dagegen koennen leicht wechseln, beispielsweise bei Verwendung von Wechselplatten und USB-Sticks, aber auch bei Umhängen der Festplatte an einen anderen Controller oder "Um-Jumpern" einer IDE-Platte von Master zu Slave oder umgekehrt. Deswegen wird die Verwendung des UUID-Identifiers empfohlen, da weniger fehleranfällig.

    • Jedes Mal, wenn initrd neu erzeugt bzw. aktualisiert wird (zum Beispiel bei der Installation eines neuen Kernels), wird diese Datei gelesen und die Angabe in initrd geschrieben.

    • Diese Datei ist oft die Fehlerursache, weil diese Datei i.d.R. nicht vom Benutzer aktualisiert wird, wenn die SWAP-Partition aufgrund eines Platten-Umbaus, -Einbaus oder -Ausbaus, oder im Rahmen einer Um-Partitionierung eine neue Bezeichnung erhält!

  • In der Datei /etc/uswsusp.conf

    • Diese Datei wird bei der Installation des Pakets uswsusp erstellt und mit Benutzer-Angaben befüllt, wenn die Konfiguration des Pakets uswsusp nicht abgebrochen wird. Ansonsten steht irgendein Wert darin! Man kann diese Datei manuell anpassen oder "halb-automatsich" durch den Aufruf

      sudo dpkg-reconfigure uswsusp 

      mit neuem Inhalt befüllen. Empfohlen wird hierzu die Lektüre der Manpage zu uswsusp oder des Wiki-Artikels uswsusp [5].

  • Kernel-Bootparameter in der GRUB-Konfiguration

    • Häufig funktioniert das Resume nur, wenn auch in der GRUB-Konfigurationsdatei eingetragen ist, wo das Resume-Speicherabbild gespeichert ist. Diese Eintragung fehlt oft, so dass nach einem Hibernate der Rechner einen ganz normalen Neustart durchfuehrt. Auch wenn bei dieser Eintragung der Laufwerksbuchstabe/Partitionsnummer, beispielsweise resume=/dev/sda2, angegeben werden kann, wird empfohlen, die eindeutige Partitionskennung in der Form resume=UUID=xxxxxxxxxxxxxx zu verwenden (s.o.). Für GRUB 2 ergänzt man die Variable GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub. Zum Schluss lässt man die GRUB-Konfiguration mit diesen Änderungen aktualisieren:

      sudo update-grub 

Die o.g. Dateien sind nun kontrolliert und man weiß, wo man bei der Einrichtung hinlangen muss.

Einrichtung

Nachdem oben festgestellt wurde, dass

  • der gewünschte Energiesparmodus (STR und/oder STD) erreicht werden kann und

  • ob Kernelspace oder Userspace genutzt werden soll

kann man nun mit der Einrichtung anfangen.

STD auf SWAP-Partition

Hat man nur eine SWAP-Partition und keine Fehler im System (Standard), d.h. die SWAP-Partition ist korrekt definiert und aktiv, dann sollte man so verfahren:

  1. Partitionsname der SWAP-Partition z.B. aus der Ausgabe von

    sudo fdisk -l | grep Swap | awk '{print $1}' 

    ablesen

  2. Partitionsname bzw. UUID der SWAP-Partition z.B. aus /etc/fstab ablesen:

    grep swap /etc/fstab 
  3. UUID der SWAP-Partition ("/dev/xxxy" von oben) aus der Ausgabe

    ls -l /dev/disk/by-uuid 

    ablesen.

  4. Die abgelesenen Informationen sollten übereinstimmen! Sonst bei Sonderfälle unten weitermachen

  5. Überprüfen, ob die gewünschten Angaben schon in den entsprechenden Dateien (korrekt) eingetragen sind (siehe oben). Am wichtigsten ist dabei die Datei /etc/initramfs-tools/conf.d/resume. Wenn nicht, dann die Angaben in die entsprechenden Dateien schreiben bzw. korrigieren (und ggf. die GRUB-Konfiguration aktuallisieren).

  6. initrd aktualisieren:

    sudo update-initramfs -u 
  7. System neu starten und STD testen.

  8. Wenn Fehler auftreten, dann bei Fehlersuche weitermachen.

Der folgende Einzeiler fasst die Schritte 1. bis 4. zusammen und liefert Partitions-Namen ("/dev/xxxy") und UUID, wenn alles in Ordnung ist (andernfalls manuell überprüfen):

dev=$(tail -n 1 /proc/swaps | awk '{print $1}'); uuid=$(ls -l /dev/disk/by-uuid/ | grep $(awk -F/ '{print $3}' <<<"$dev") 2> /dev/null | awk -F' ' '{print $9}'); echo "Partition: $dev; UUID: $uuid" 

Der gleiche Einzeiler ohne den awk:

dev=$(tail -n 1 /proc/swaps | cut -d" " -f1 | cut -d/ -f3); uuid=$(ls -l /dev/disk/by-uuid/ | grep $dev | cut -d" " -f9); echo "Partition: /dev/${dev}; UUID: $uuid" 

STD auf separater Partition

Salopp gesagt: In diesem Fall ist man (sehr) fortgeschrittener Anwender, man kennt sich gut aus und man weiß i.d.R, was man hat und was man will. Folgendes ist zu tun (analog zu weiter oben):

  1. Ggf. zuerst eine SUSPEND-Partition erstellen

  2. Partitionsname aus der Ausgabe von

    sudo fdisk -l 

    ablesen

  3. Partitionsname bzw. UUID-Identifier der Partition aus /etc/fstab ablesen

  4. UUID-Identifier aus der Ausgabe von

    ls -l /dev/disk/by-uuid 

    ablesen (Vergleich mit Ausgabe von sudo fdisk –l)

  5. Überprüfen, ob die gewünschten Angaben schon in den entsprechenden Dateien (korrekt) eingetragen sind (siehe oben). Am wichtigsten ist dabei die Datei /etc/initramfs-tools/conf.d/resume. Wenn nicht, dann die Angaben in die entsprechenden Dateien schreiben bzw. korrigieren (und ggf. die GRUB-Konfiguration aktuallisieren).

  6. initrd aktualisieren:

    sudo update-initramfs –u 
  7. System neu starten und STD testen.

  8. Wenn Fehler auftreten, dann bei Fehlersuche weitermachen.

Sonderfälle

Auf einem System können mehrere SWAP-Partitionen existieren, so zum Beispiel wenn mehrere Linux-Installationen mit jeweils separater SWAP-Partition vorhanden sind oder auch wenn zRam verwendet wird. Nicht jede SWAP-Partition muss zur Verwendung aktiviert sein. Das ist zum Beispiel dann der Fall, wenn der Eintrag zu SWAP-Partition(en) in fstab nicht korrekt ist, oder wenn aus Umbau-Maßnahmen mehrere SWAP-Partitionen vorhanden sind, aber nur eine verwendet wird. Vom aktuellen Ubuntu 16.04 werden im Ggs. dazu auch nicht in der fstab eingetragene SWAP-Partitionen verwendet.

Die UUID-Bezeichner für alle aktiven SWAP-Partitionen, die tatsächlich im Einsatz (aktiv) sind, kann man so herausfinden:

cat /proc/swaps # zeigt die aktiven SWAP-Partitionen an
ls -l /dev/disk/by-uuid/ # zeigt die Zuordnung Partitionen <=> UUID-Identifier 

Man sucht sich nun die "richtige" SWAP-Partition heraus und verwendet diese. Dabei ist es höchstwahrscheinlich auch nötig, diese wie oben beschrieben als Kernel-Bootparameter in der GRUB-Konfiguration anzugeben. Außerdem hat man nun womöglich einen ganz anderen Fehler entdeckt, den es zu beheben gilt.

Fehlersuche

Hinweis:

In der Datei "/etc/default/grub" steht typischerweise bei dem Wert GRUB_CMDLINE_LINUX_DEFAULT eingetragen "quiet splash". Das unterdrückt Bootmeldungen und zeigt einen graphischen Splashscreen an. Wird dieser Eintrag geändert in "noplymouth", verschwindet der Splashscreen und alle Bootmeldungen werden sichtbar. Das ist gelegentlich hilfreich, um zu sehen, wo es "hakt".

Log-Datei /var/log/pm-suspend.log

Die Log-Datei für pm-utils ist /var/log/pm-suspend.log. Diese Datei wird bei jeder Einleitung eines SUSPEND-Vorgangs geleert und neu beschrieben. In dieser Datei wird sowohl der SUSPEND-, als auch der RESUME-Vorgang protokolliert. Hat man nach einem missglückten SUSPEND-RESUME-Vorgang Veränderungen vorgenommen, so kann man eine Kopie der Log-Datei /var/log/pm-suspend.log speichern um sie mit ihrem Nachfolger zu vergleichen.

Aussagekräftiger wird diese Datei, wenn man den SUSPEND auf der Konsole startet und davor der Variable $PM_DEBUG den Wert true zuweist:

export PM_DEBUG=true 

SUSPEND und/oder RESUME funktioniert nicht

Das kann viele Ursachen haben. Einige davon sind oben angesprochen. Für die einzelnen Ursachen sind die Maßnahmen in den entsprechenden nachfolgenden Unterkapiteln beschrieben. An dieser Stelle sind noch weitere Fehlerursachen beschrieben, die in manchen Fällen SUSPEND und RESUME verhindern:

Fehlerursache - Kategorie Beschreibung von Maßnahmen
Module Module, die beim SUSPEND entladen und beim RESUME wieder geladen werden müssen.
Beispiele: WLAN-Karten, Netzwerk-Karten, Bluetooth-Geräte, USB-Geräte, ...
Dienste Manche Dienste verhindern das Entladen von Modulen. Daher müssen Dienste beim SUSPEND gestoppt und beim RESUME wieder gestartet werden.
Beispiel: USV-Dienst verhindert das Entladen von USB-Modulen
Grafik Bei bestimmten Grafik-Einstellungen kann es vorkommen, dass SUSPEND ebenso nicht möglich ist.
Beispiele:
  • radeon statt fglrx verwenden

  • Nvidia-Treiber Version 180:

    • durch andere Version ersetzen

    • In xorg.conf eintragen:

Option          "NvAGP"       "1"
  • die Option "NoDRI" aus xorg.conf enfernen

SWAP-Einstellung falsch Verschiebt man die SWAP-Partition, ohne den Eintrag in der Konfigurationsdatei für RESUME anzupassen, so kann der Kernel das STD-Image nicht finden.
ACPI abgeschaltet Manche Systeme booten nur dann, wenn ACPI abgeschaltet wird (acpi=off, dann ist die Nutzung von ACPI-Energiesparmodi nicht möglich), oder das BIOS aktualisiert wird.
Hardware-Besonderheiten Bei manchen Systeme kann der Linux-Kernel nicht fehlerfrei direkt die Energiesparmodi steuern, durch Verwendung der entsprechenden BIOS-Funktionen (siehe Energiespar-Bootoptionen können diese Modi aber u.U. trotzdem (indirekt) umgeschaltet werden.

Module vor SUSPEND entladen, nach RESUME wieder laden

In der Regel ist es ausreichend, Kernelmodule für die problematische Hardware automatisch vor SUSPEND entladen und während RESUME neu laden zu lassen. Die Module, die häufiger Ärger bereiten können, sind die Module für:

  • WLAN-Karten und USB-WLAN-Sticks: *802*, ndiswrapper, ...

  • LAN-Karten: forcedeth, *8139*, ...

  • USB- und Firewire-Module: ehci-hcd, uhci-hcd, *usb*, *1394, ...

  • Bluetooth- und TV-Karten: ivtv, bttv, btusb, ...

Mit dem folgenden Einzeiler kann man sich die "üblichen Verdächtigen" anzeigen lassen:

lsmod | grep -iE '802|ndiswr|forced|8139|hci|usb|1394|hid|..tv' 

Diese Liste erhebt allerdings keinen Anspruch auf Vollständigkeit.

Die benötigte Datei /etc/pm/config.d/00sleep_module muss oft zunächst noch erstellt und anschließend ausführbar gemacht werden:

sudo touch /etc/pm/config.d/00sleep_module               # Datei erstellen
sudo chmod +x /etc/pm/config.d/00sleep_module            # ausführbar machen 

Hat man herausgefunden, dass die Module ehci-hcd uhci-hcd usbcore forcedeth SUSPEND (und/oder RESUME verhindern), bearbeitet man die Datei mit einem Texteditor [3] und fügt folgende Zeilen ein:

# USB-Kernelmodule und forcedeth (Netzwerkkarte) machen Aerger bei SUSPEND & RESUME mit pm-utils
# daher sollen sie automatisch ent- und geladen werden
SUSPEND_MODULES="$SUSPEND_MODULES ehci-hcd uhci-hcd usbcore forcedeth" 

Durch die o.g. Zuweisung werden diejenigen Module, die bereits an einer anderen Stelle in der Variable SUSPEND_MODULES hinterlegt wurden, nicht überschrieben. Nachdem diese Datei erstellt wurde, testet man SUSPEND und RESUME. In der Tabelle unten sind die Module aufgelistet, die in der jeweiligen Ubuntu-Version bei einem oder mehreren Benutzern SUSPEND (und RESUME) verhinderten.

Version Module Weiteres
Ubuntu 10.10 xhci_hcd tpm_tis r8187se xhci_hcd: Treiber für eXtensible Host Controller 🇩🇪 USB 1.0 - 3.0
tpm_tis: Treiber für TPM-Chip, voraussichtlich ab Kernel 2.6.37 gefixt
r8187se: Treiber für eine Notebook-WLAN-Karte von Realtek
Ubuntu 10.04 xhci xhci: Treiber für eXtensible Host Controller USB 1.0 - 3.0
Ubuntu 8.04 ehci-hcd uhci-hcd usbcore forcedeth ivtv ohci1394 ieee1394 bttv

Diese Liste kann als "Start-Liste" benutzt werden. Wenn SUSPEND und RESUME klappen, dann kann man ein Modul nach dem anderen aus der o.g. Liste entfernen, und SUSPEND und RESUME wieder testen, bis man den/die Übeltäter gefunden hat. Es schadet natürlich nicht, wenn man zu Testzwecken alle Module (für alle Versionen) in einer eigenen SUSPEND_MODULES-Liste aufführt. Dies erreicht man, indem man die folgende Ausgabe:

cat /proc/modules | cut -d " " -f1 | xargs 

in die oben genannte Datei kopiert. Oder man lässt diese Liste so wie sie ist, da der Zeitgewinn nur minimal ist, wenn man ein oder zwei Module weniger als erforderlich entladen und neu laden lässt. Selbstverständlich erhebt diese Liste keinen Anspruch auf Vollständigkeit.

Falls jemand einen oder mehrere weitere Module entdeckt, die entladen und neu geladen werden müssen, damit SUSPEND und RESUME klappen, bitte die Liste für die entsprechende Version vervollständigen! Dabei sollen nur diejenigen Module eingetragen werden, bei denen es sichergestellt ist, dass sie SUSPEND und RESUME tatsächlich verhindern.

Bei Ubuntu 10.04 auf älteren ASUS-Boards mit PS/2-Anschlüssen war es beispielsweise offenbar erforderlich, im BIOS die Funktion USB Legacy Support abzuschalten. Dies war natürlich nur sinnvoll, falls man eine PS/2-Tastatur benutzt. Weitere Details dazu findet man auf Launchpad und im Forum und speziell zu Ubuntu 10.04 hier.

Eine gute Anleitung, um solche Module aufzuspüren, ist hier zu finden: "resume-trace" debugging procedure for finding buggy drivers 🇬🇧.

Hinweis:

Mehr Informationen befinden sich in der Datei /usr/share/doc/pm-utils/HOWTO.modules.

Dienste vor SUSPEND stoppen, nach RESUME wieder starten

Mit den Diensten, die nach dem RESUME nicht funktionieren, sollte man analog zu den Kernelmodulen verfahren:

  • Zuerst herausfinden, welcher Dienst gestoppt und wieder gestartet werden muss

  • Einen Hook unter Verwendung des Beispiel-Hooks (siehe unten) erstellen

ACPI abgeschaltet

Aus mehreren Gründen kann es vorkommen, dass entweder alle oder nur bestimmte ACPI-Funktionen abgeschaltet sind. Dies kann entweder im BIOS oder über Kernelparameter erreicht werden. Daher sollten unter [4] die BIOS-Einstellungen und ACPI-Kernelparameter kontrolliert werden.

Grafikkartentreiber und Desktop-Effekte

Nvidia

Es wurde mehrmals festgestellt, dass der Nvidia-Treiber in der Version 180 SUSPEND verhindert. In diesem Fall sollte der Treiber durch eine ältere Version ersetzt werden.

ATI

Oft wird berichtet, dass SUSPEND funktioniert, wenn radeon statt fglrx verwendet wird.

Desktop-Effekte

Manchmal wird berichtet, dass SUSPEND funktioniert, nachdem Desktop-Effekte abgeschaltet werden.

SUSPEND und RESUME stufenweise testen

Zur Fehlersuche ist es ratsam, stufenweise vorzugehen. Das bedeutet, dass man zuerst den XServer beendet und SUSPEND von einer Konsole aus startet. Wenn das funktioniert, dann startet man SUSPEND aus X heraus.

SUSPEND und RESUME ohne X (aus RUNLEVEL 1) testen:

  1. Von Desktop abmelden

  2. Mit Strg + Alt + F1 zu einer virtuellen Konsole wechseln

  3. Anmelden

  4. sudo init 1 
  5. SUSPEND oder HIBERNATE starten:

    /usr/sbin/pm-suspend 

    oder

    /usr/sbin/pm-hibernate 

  6. Anschließend RESUME einleiten, indem der Rechner wieder eingeschaltet wird.

Man kann das auch testen, indem man nicht (mit sudo init 1) in den RUNLEVEL 1 wechselt, sondern direkt nach der Anmeldung in der Konsole mit sudo /usr/sbin/pm-suspend bzw. sudo /usr/sbin/pm-hibernate den SUSPEND-Vorgang startet.

STD wird ausgeführt, kein RESUME

Der Rechner wird in den Schlaf versetzt. Nach dem Wiedereinschalten startet das System "normal". Meistens liegt es daran, dass die Angabe zur "SUSPEND & RESUME-Partition" an einer oder mehreren der folgenden Stellen falsch ist:

  • /etc/initramfs-tools/conf.d/resume (und damit auch in initrd)

  • /etc/uswsusp.conf

  • /boot/grub/menu.lst

Eventuell sind die Angaben sogar korrekt, nur das abschließende sudo update-initramfs -u wurde vergessen. Weiter oben unter Suspend_To_Disk ist beschrieben, wie man feststellen kann, welche Partition die richtige ist, und wie man die Angaben dazu aktualisiert.

Nach RESUME kein Ton (Intel HDA)

Intel HDA ist eine Definition von Intel für integrierte Soundlösungen. Auf unterschiedlichen Mainboards kommen unterschiedliche Chipsätze zum Einsatz. Das bedeutet, das der "Intel HDA"-Treiber eine ganze Gruppe von Soundchips unterstützt. Derzeit funktioniert diese Gruppe von Soundchips nicht richtig mit dem Kernel 2.6.24-15/16. Die Bugs sind in Launchpad immer noch offen, und viele Anwender sind davon betroffen. Meistens funktionieren die Chips selber ohne Probleme mit diesem Kernel, aber nur bis zum SUSPEND. Sie werden beim RESUME nicht richtig aufgeweckt, aber vom System als wieder aktiviert erkannt. Die lspci-Ausgabe zeigt die Soundchips als aktiv an, und die Systemprotokolle zeigen nichts ungewöhnliches.

Lösung für dieses Problem: Mit dem folgenden Befehl den Chipsatz herausfinden.

aplay -l 

Das Ergebnis könnte so aussehen:

aplay -l 
**** Liste von PLAYBACK Geräten ****
Karte 0: Intel [HDA Intel], Gerät 0: ALC268 Analog [ALC268 Analog]
  Untergeordnete Geräte: 0/1
  Untergeordnetes Gerät '0: subdevice #0

Im Beispiel oben ist ALC268 der gesuchte Begriff. Mit:

zless /usr/share/doc/alsa-base/driver/ALSA-Configuration.txt.gz 

nach dem Chipsatz (im Beispiel oben ALC268) suchen. Das Ergebnis könnte so aussehen:

ALC268
          3stack        3-stack model
          toshiba       Toshiba A205
          acer          Acer laptops
          dell          Dell OEM laptops (Vostro 1200)
          zepto         Zepto laptops
          test          for testing/debugging purpose, almost all controls can
                        adjusted.  Appearing only when compiled with
                        $CONFIG_SND_DEBUG=y
          auto          auto-config reading BIOS (default)

Auf Acer-Notebooks wäre acer der gesuchte Begriff. In den Dateien /etc/modprobe.d/snd-hda-intel.modprobe und /etc/modprobe.d/alsa-base muss folgende Zeile eingetragen werden:

options snd-hda-intel model=acer

Im Forum wird oft die Anweisung gegeben, in der Datei /etc/default/acpi-support noch folgende Änderung vorzunehmen:

# Add services to this list to stop them before suspend and restart them in
# the resume process.
STOP_SERVICES="alsa"

Dies dürfte sich allerdings auf SUSPEND & RESUME mit pm-utils nicht auswirken, da pm-utils die Dateien aus dem Paket acpi-support nicht verwendet. Möchte man aber sowohl pm-utils als auch acpi-support für SUSPEND & RESUME nutzen, so sollte die Änderung in /etc/default/acpi-support vorgenommen werden.

Anschließend muss man die Dienste neu starten, ggf. Module entladen und neu laden. Wenn´s nicht klappt, einen Neustart durchführen.

Weitere Informationen zu diesem Problem können dem Thread Nach Standby kein Ton mehr im Forum entnommen werden.

Nach RESUME kein Netzwerk

Als Erstes soll man herausfinden, welche Kernel-Module für die vorhandenen Netzwerk-Schnittstellen zuständig sind. Dies kann man mit dem folgenden Befehl erreichen:

sudo lshw -C network 

Die Ausgabe soll ungefähr so aussehen:

  *-network               
       Beschreibung: Wireless interface
       (...)
  *-network               
       Beschreibung: Ethernet interface
       Produkt: VT6102 [Rhine-II]
       Hersteller: VIA Technologies, Inc.
       (...)
       Konfiguration: autonegotiation=on broadcast=yes driver=via-rhine driverversion=1.5.1 duplex=full ip=192.168.0.62 latency=64 link=yes maxlatency=8 mingnt=3 multicast=yes port=MII speed=100Mbit/s
       Ressourcen: irq:23 ioport:4800(Größe=256) memory:d9300400-d93004ff

Das Kernelmodul sieht man in der Zeile "Konfiguration" (in diesem Fall driver=via-rhine). Man soll noch herausfinden, wie das entsprechende Modul tatsächlich heißt, in diesem Fall z.B. so:

$ lsmod | grep rhine
via_rhine              27653  0 
mii                    13654  1 via_rhine

Man sieht, dass in diesem Fall die Namen von Treiber und Modul sich leicht unterscheiden. Den Modulname trägt man in die oben beschriebene Datei /etc/pm/config.d/00sleep_module ein:

SUSPEND_MODULES="$SUSPEND_MODULES via_rhine"

Wichtig dabei ist, dass der Network-Manager vor SUSPEND gestoppt und nach RESUME wieder gestartet wird. Dies wird im Skript /etc/pm/sleep.d/50_network_suspend.sh implementiert:

#!/bin/sh
# /etc/pm/sleep.d/50_network_suspend.sh

case "${1}" in
    hibernate|suspend)
	service network-manager stop ;;
    resume|thaw)
        service network-manager start ;;
esac

Neustart bei Hibernate

Manche Geräte starten sofort neu, oder reagieren auf jede Taste, nachdem sie in den Ruhezustand (S4) geschaltet wurden. Dieses Problem kann gelöst werden, indem man die pm-utils anweist, stattdessen ein Shutdown-Signal zu verwenden:

  1. Datei /usr/lib/pm-utils/defaults öffnen

  2. Die Zeile

    # HIBERNATE_MODE="platform"

    einkommentieren.

  3. Anstelle von platform hier shutdown eintragen.

  4. Datei als "/etc/pm/config.d/defaults" speichern.

Auch ein reboot ist möglich, falls gewünscht.

Debug-Modus verwenden

Den Debug-Modus schaltet man auf diese Weise ein:

echo 1 | sudo tee /sys/power/pm_trace 

Die gezielte Suche nach den Modulen oder Geräten, die Ärger bei SUSPEND und RESUME verursachen, ist nach diesem Schema durchzuführen:

  1. Ggf. vom Desktop (KDE, GNOME, ...) abmelden

  2. mit Strg + Alt + F1 in eine virtuelle Konsole wechseln

  3. Anmelden

  4. Debug-Modus aktivieren:

    echo 1 | sudo tee /sys/power/pm_trace 
  5. SUSPEND oder HIBERNATE starten:

    /usr/sbin/pm-suspend 

    oder

    /usr/sbin/pm-hibernate 
  6. Das System geht in SUSPEND über.

  7. Wenn der Ruhezustand eingekehrt ist, dann RESUME einleiten durch Drücken der Power-Taste.

  8. RESUME startet

Wenn der RESUME-Vorgang durchgelaufen ist, dann den Rechner ausschalten und neu starten (booten). Zwischen dem Erreichen des Ruhezustands und dem aktuellen Zeitpunkt (Neustart) darf nicht mehr Zeit als 2 bis 3 Minuten vergehen! Da in die Hardware-Uhr (real-time clock, RTC) geschrieben wird, werden beim nächsten Start des Systems höchstwahrscheinlich Dateisystemchecks durchgeführt. Nicht verunsichern lassen - einfach abwarten!

  1. Sobald das System gestartet ist, mit Strg + Alt + F1 zu einer virtuelle Konsole wechseln

  2. Anmelden

  3. cd /tmp
    dmesg > dmesg.txt
    grep "hash matches" dmesg.txt > dmesg_hash_matches.txt 
  4. Die Dateien /tmp/dmesg.txt und /tmp/dmesg_hash_matches.txt können nun bei der Fehlersuche verwendet und im Forum gepostet werden.

Ist die Datei /tmp/dmesg_hash_matches.txt nicht leer, so hat man entweder direkt den Modulnamen oder aber zumindest einen Hinweis auf das entsprechende Gerät. Der Modulname sollte nun in die Liste der Module eingefügt werden, die vor SUSPEND entladen und während RESUME neu geladen werden sollten. Details dazu weiter oben.

Hinweis:

Mehr Informationen befinden sich in der Datei /usr/share/doc/pm-utils/README.debugging.

Experten-Info:

Man kann auch das Original der Datei /usr/lib/pm-utils/pm-action speichern (z.B. als /usr/lib/pm-utils/pm-action.bak) und dann Änderungen an dieser Datei vornehmen, z.B. set -x in der zweiten Zeile im Skript eintragen. Dann wird ersichtlich, was das Skript macht, da jeder Aufruf/Befehl inkl. Ergebnis ausgegeben wird.

Eigene Hooks erstellen

Für den sehr unwahrscheinlichen Fall, dass man selbst Hooks erstellen muss, hier das Beispiel /usr/lib/pm-utils/sleep.d/05led. Daraus ist ersichtlich, dass beim Betreten von STR und STD echo "7 blink" >/proc/acpi/ibm/led, beim Wiedererwachen hingegen echo "7 off" >/proc/acpi/ibm/led aufgerufen wird. Nach dem Erstellen muss der Hook noch ausführbar gemacht werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
#!/bin/bash

[ -f /proc/acpi/ibm/led ] || exit 0

case "$1" in
	hibernate|suspend)
		{ echo "7 blink" >/proc/acpi/ibm/led ; } 2>/dev/null
		;;
	thaw|resume) 
		{ echo "7 off" >/proc/acpi/ibm/led ; } 2>/dev/null
		;;
	*)
		;;
esac

exit $?

Bildschirm nach 5-10 min wieder schwarz

Nach Bereitschaft oder Ruhezustand kann die Bereitschaftszeit zurückgesetzt sein, etwa bei Xubuntu oder Lubuntu 14.04. Das führt dazu, dass die Zeit bis zum schwarzen Bildschirm, je nach Voreinstellung, zu kurz gesetzt ist. Mögliche Lösungen werden in Bildschirmschoner (Abschnitt „Bildschirm-nach-5-10-min-schwarz“) vorgestellt.

STR wird nach wenigen Sekunden unterbrochen

Der Rechner startet den Bereitschaftsmodus, wird aber nach einer, bzw. nach wenigen Sekunden "aus dem Schlaf gerissen" und läuft normal weiter. Dies passiert immer dann, wenn ein Gerät ein Aufwachsignal sendet. Nun kann man, wie oben beschrieben, die entsprechenden Module vor dem Bereitschaftsmodus entladen und danach wieder laden, oder man entzieht dem entsprechenden Gerät die Erlaubnis, den Rechner aus dem Bereitschaftsmodus zu wecken.

Zuerst werden alle Geräte aufgelistet, welche ein Aufwachsignal senden können:

nl /proc/acpi/wakeup 

     1	Device	S-state	  Status   Sysfs node
     2	SMB0	  S4	*disabled  pci:0000:00:03.2
     3	NMAC	  S5	*disabled
     4	PBB0	  S4	*disabled  pci:0000:00:09.0
     5	HDAC	  S4	*disabled  pci:0000:00:08.0
     6	XVR0	  S4	*disabled
     7	P0P5	  S4	*disabled
     8	P0P6	  S4	*disabled
     9	P0P7	  S4	*disabled  pci:0000:00:16.0
    10	P0P8	  S4	*disabled
    11	P0P9	  S4	*disabled  pci:0000:00:18.0
    12	XVR1	  S4	*disabled
    13	USB0	  S3	*enabled   pci:0000:00:04.0
    14	USB2	  S3	*enabled   pci:0000:00:04.1
    15	US15	  S3	*enabled   pci:0000:00:06.0
    16	US12	  S3	*enabled   pci:0000:00:06.1
    17	SLPB	  S4	*enabled   platform:PNP0C0E:00

Am Beispiel ist zu erkennen, dass Zeile 13-17 Aufwachsignale senden dürfen (*enabled) während Geräte von Zeile 1 bis 12 keine Aufwachsignale senden dürfen (*disabled).

Um jetzt herauszufinden welches Gerät den Bereitschaftsmodus unterbricht, deaktiviert man ein Gerät nach dem anderen und testet jeweils danach den Bereitschaftsmodus. Hierzu werden alle Geräte nacheinander auf *disabled gesetzt bis das "schuldige Gerät" gefunden wurde.

In den permanenten root-Modus wechseln:

sudo -i 

Nun deaktiviert man das erste Gerät

echo USB0 > /proc/acpi/wakeup 

und kontrolliert das Ergebnis mit:

nl /proc/acpi/wakeup 

     1	Device	S-state	  Status   Sysfs node
     2	SMB0	  S4	*disabled  pci:0000:00:03.2
     3	NMAC	  S5	*disabled
     4	PBB0	  S4	*disabled  pci:0000:00:09.0
     5	HDAC	  S4	*disabled  pci:0000:00:08.0
     6	XVR0	  S4	*disabled
     7	P0P5	  S4	*disabled
     8	P0P6	  S4	*disabled
     9	P0P7	  S4	*disabled  pci:0000:00:16.0
    10	P0P8	  S4	*disabled
    11	P0P9	  S4	*disabled  pci:0000:00:18.0
    12	XVR1	  S4	*disabled
    13	USB0	  S3	*disabled   pci:0000:00:04.0
    14	USB2	  S3	*enabled   pci:0000:00:04.1
    15	US15	  S3	*enabled   pci:0000:00:06.0
    16	US12	  S3	*enabled   pci:0000:00:06.1
    17	SLPB	  S4	*enabled   platform:PNP0C0E:00

Nun muss der Bereitschaftsmodus getestet werden. Ist der Bereitschaftsmodus immer noch nicht permanent, so deaktivert man testweise das nächste Gerät. Sobald das entsprechende Gerät gefunden wurde, ergänzt man einfach die Datei /etc/rc.local um folgenden Zeile: (USB0 ist hier nur das Bespiel, bitte entsprechendes Geräte (DEVICE) eintragen):

echo USB0 > /proc/acpi/wakeup 

Zum Schluss muss dann noch die Root-Shell verlassen werden:

exit 

Diese Revision wurde am 7. Februar 2020 10:50 von Heinrich_Schwietering erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: hibernate, suspend, Ruhezustand, Bereitschaft, System, Hardware