In den zurückliegenden Artikeln dieser Serie hatte ich Vorüberlegungen und konkrete Maßnahmen zur Installation eines voll-verschlüsselten Laptops dargestellt:

Auf dieser Basis hatten wir zuletzt eine einfache “Opensuse Leap 15”-Variante auf einer externen SSD mit “LUKS on LVM”-Volumes zum Laufen gebracht. Wir können diese Installation bereits in einen Konsolen-Modus booten und Shutdowns durchführen.

Sowohl Grub2 als auch der Kernel fragen uns im Boot-Vorgang erwartungsgemäß nach LUKS-Passphrases für den Zugang zum jeweiligen Master-Key der bislang verschlüsselten zwei Raw-Volumes, die uns quasi als Krypto-Container für das root-Filesystem [“/”-FS] und den SWAP dienen. Wir haben die Volumes aus Gründen der Flexibilität in zwei separaten Volume Groups [VGs] untergebracht; die Passphrases für die Volumes wurden identisch gewählt, um statt 4 nur 2 Eingaben durchführen zu müssen. So weit – so gut.

Der Einsatz eines Laptops ist allerdings auch dadurch geprägt, dass man das System manchmal zügig in einen inaktiven (und stromsparenden) Zustand versetzen muss – ohne dass man dabei den Status laufender Applikationen verlieren will. Ein typisches Beispiel ist etwa das Schließen eines Laptops für einen Raum-, Zug- oder Flugzeug-Wechsel. Unsere Anforderung ist dabei weniger Geschwindigkeit als vielmehr Sicherheit. Dies spricht für Hibernation (s.u.).

Wir wollen in diesem Beitrag deshalb einen ersten Kurztest des Hibernation-Verhaltens unseres Laptops durchführen. Im Zuge dieser Aktivitäten lernen wir leider auch, dass weder das Herunterfahren in den Hibernation-Zustand – noch der Resume-Vorgang unter Leap 15 frei
von Fehlermeldungen sind. Dennoch funktioniert Hibernation – zumindest auf meinem System.

Einschränkungen:

Ich betrachte hier – wie in den vorhergehenden Artikeln – nur ein klassisches BIOS-System und keine UEFI-basiertes System. Das wirkt sich (je nach Linux-Distribution) u.a. auf die Grub2-Konfiguration aus; u.a. können die Namen der Konfigurationsdateien abweichen. Die dort zu setzenden Kernel-Parameter sind typischerweise aber gleich.
Hibernation und ein später folgender Resume-Vorgang aus einem Hibernation Zustand sind relativ komplexe Prozesse. Für eine erfolgreiche Wake-Up-Phase sind initial ggf. auch BIOS- oder UEFI- und ACPI-Funktionen erforderlich. Das BIOS muss den sog. S4-Zustand unterstützen. Sind diese Funktionen nicht standardgerecht implementiert, kann es auf bestimmten Systemen zu Problemen kommen, die ich hier nicht aufgreifen kann. Man muss sich ggf. um ein BIOS-Update bemühen. Die Linux-Kernel-, GRUB- und systemd-Entwickler haben aber versucht, das Thema Hibernation so weit als möglich unter eigene Kontrolle zu bringen.
Wir betrachten im Moment nur einen Start/Resume-Vorgang in einen Konsolen-Modus (früher Runlevel 3; heute Multi-User-Target). Diese Einschränkung ist durchaus bedeutsam, da im Falle von grafischen Komponenten Video-Systeme restauriert werden müssen; das ist bei bestimmten Systemen, u.a. Optimus-Systemen, durchaus ein problembehaftetes Thema. Ich komme in einem späteren Artikel darauf zurück.

Hibernation

Hibernation ist eine Möglichkeit des Power-Managements. Die Informationen zum Systemzustand – u.a. die Informationen im RAM – werden dabei als Image auf die Platte geschrieben. Die meisten Linux-Systeme nutzen hierfür den SWAP. Ausgelöst wird Hibernation typischerweise durch Schließen des Laptop-Deckels, Drücken einer bestimmten Keyboard-Taste oder aber durch ein Kommando am Linux-Prompt.

Ob das System nach Abspeichern des Image runtergefahren wird (Power-Off), in wieweit ACPI-Funktionen des (UEFI-) BIOS die Kontrolle übernehmen und danach einen Restart aus dem sogenannten S4-Zustand des Systems garantieren, ist abhängig von SW- und HW/BIOS-Einstellungen. Hibernation spart gegenüber anderen Power-Management-Verfahren am meisten Energie. Der aus HW/BIOS-Sicht erreichte S4-Zustand ist ferner relativ unempfindlich gegenüber einem Verlust der externen Stromversorgung. Hibernation hat gegenüber “Suspend to RAM” aber den Nachteil, dass die Erstellung des Images vor Erreichen des Hibernation-Zustands, vor allem aber das Laden der Image-Informationen beim Resume-Vorgang Zeit kosten. Hier zahlt sich das Arbeiten mit SSDs aus 🙂 .

Unter Linux ist ein geordnetes Herunterfahren des OS nach Anlage des Images mit Power-Off nach meiner Erfahrung die verlässlichste Variante. Die beteiligten Komponenten – systemd-Services, Grub2, ggf. Plymouth, Kernel und initramfs – arbeiten in den meisten Linux-Systemen zudem so zusammen, dass der Restart weitestgehend unabhängig von ACPI möglich ist.

Dass BIOS-Funktionen beim Start des Systems dennoch im Spiel sind, erkennt man ggf. auch an einem leicht veränderten Startschirm des Laptops gegenüber einem normalen Start des Systems (bei mir tauchen bestimmte Optionen nicht auf – wie etwa Zugriff auf das BIOS-Setup oder Boot-Device-Auswahl). Sobald aber GRUB2 die Kontrolle übernimmt, unterliegt das Hochfahren unter Nutzung des erzeugten Images der Kontrolle der Linux-Komponenten: Die wiederum erkennen einen speziellen Startup-Vorgang nicht allein (?) an Werten von BIOS-Zustandsgrößen, sondern an bestimmten Datei-Einträgen einer Datei im “/boot”-Verzeichnis und an der Existenz des Images im SWAP.

Unter Opensuse Leap 15 löst das Kommando “systemctl hibernate” eine Image-Erzeugung und einen Übergang in
den Hibernation-Zustand mit Power-Off des Systems aus. Ich werde keine abweichenden Varianten in Betracht ziehen.

Warum Hibernation und nicht “Suspend to RAM”?

Der Vollständigkeit halber rekapitulieren wir kurz, dass die Bevorzugung von Hibernation gegenüber “Suspend to RAM” in Sicherheitsaspekten liegt: Der RAM beinhaltet sicherheitskritische Informationen (u.a. den Master-Key für LUKS-kryptierte Volumes !) und kann – solange er unter Spannung steht – von Angreifern ausgelesen werden, wenn sie Zugriff auf das System erlangen (Diebstahl, Verlust). “Suspend to RAM” ist daher gefahrenträchtig. Ist der SWAP dagegen verschlüsselt, so stellt die Ablage der RAM-Inhalte auf der Platte keine Gefährdung dar, sobald der RAM seinen Inhalt im Zuge des Hibernation-Übergangs verliert.

In unserem Fall ist der SWAP in einem kryptierten LVM-LUKS-Volume angelegt worden (“LUKS on LVM”). Ohne Master-Key kann der SWAP auch im Falle des Verlustes oder Diebstahls nicht ausgelesen werden. Beim Hochfahren muss ein Anwender eine gültige Passphrase für den Zugang zum zugehörigen LUKS-Volume eingeben. Als Sicherheitsrisiko verbleibt hier eine evtl. zeitlich eng begrenzte Persistenz der Inhalte im RAM-Chip nach dem Herunterfahren des Systems (zeitlicher Verlauf des Spannungsabfalls an den RAM-Speicher-Elementen). Das ist aber immer noch besser als ein Einfrieren des Systemzustandes im aktiven RAM.

Platzbedarf im SWAP

Zur Erinnerung: Wir hatten das kryptierte Volume (/dev/vgs/lvs1) mit dem SWAP in einer eigenen Volume Group [VG] (/dev/vgs) untergebracht; das root-Filesystem befindet sich dagegen auf einem Volume (dev/vga/lva1) einer anderen VG. Wir hatten das SWAP-Volume groß genug eingerichtet, um den gesamten Hauptspeicher (und ggf. etwas mehr) darin unterzubringen.

Eine Beobachtung des RAM-Bedarfs ist aber dennoch erforderlich; es ist sicherzustellen, dass eine vollständige Abbildung des aktuell benötigten Speicherplatzes auf der Platte jederzeit möglich ist. Der RAM wird im Besonderen bei Inbetriebnahme mehrere virtueller Gastsysteme auf dem Laptop schnell ausgelastet. Hat man den verfügbaren RAM-Platz bereits (unabsichtlich) überschritten und wird der SWAP deshalb bereits im laufenden Betrieb genutzt, so kann es beim Übergang in den Hibernation-Zustand möglicherweise Probleme geben – selbst wenn das Image komprimiert erzeugt wird. Anwender, die mit mehreren virtualisierten Gastsystemen gleichzeitig arbeiten, sollten von vornherein passende Limits für den gesamten RAM-Verbrauch aller Gäste setzen.

Einstellungen

Im Grunde haben wir bei der Konfiguration des SWAP im letzten Beitrag bereits alle notwendigen Einstellungen vorgenommen, um ihn für Hibernation nutzen zu können:

In der Datei “/etc/default/grub” sind folgende Einstellungen wichtig:

GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX_DEFAULT='nomodeset splash=silent quiet showopts resume=/dev/mapper/cr-swap'

Der erste Punkt reguliert den zu verwendenden Grub-Standardeintrag, den wir auch mit dem Kommando “/usr/sbin/grub2-set-default” setzen können. Die zugehörige Information wird in der Date “/boot/grub2/grubenv” unter dem Eintrag “saved-entry” hinterlegt. Der zweite Eintrag muss den korrekten Wert für das “resume”-Device gem. Mapper-Bezeichnung in der “/etc/crypttab” erhalten.

Die Datei “/etc/crypttab” muss existieren und Verweise auf die Krypto-Devices für die unter “/dev/mapper” angelegten Filesystem-/Swap-Devices beinhalten:

cr-root /dev/vga/lva1 none
cr-swap /dev/vgs/lvs1 none

Die über “mkinitrd” oder “grub-mkconfig -o /boot/grub/grub.cfg” aktualisierte Datei grub.cfg sollte darauf kontrolliert werden, ob der “resume”-Parameter den verschiedenen Grub-Menü-Einträgen auch tatsächlich hinzugefügt wurde. initramfs- und systemd-Konfigurationen
erfordern in jedem Fall korrekte Einträge in der “/etc/crypttab”. Die neue bootfähige System-Konfiguration erzeugt man unter Opensuse Leap nach Abänderung der Konfigurationsdateien am einfachsten durch den Befehl “mkinitrd”; das Wrapper-Skript involviert “dracut” und erledigt auch ein Update der Grub-Konfiguration.

Test

Unser Leap 15-System ist bislang ohne grafischen Desktop installiert. Der einfachste Hibernation-Test besteht daher im Absetzen des Kommandos

systemctl hibernate

Ich beschreibe das nachfolgende relativ unspektakuläre Verhalten textuell; viel zu sehen gibt es dabei nicht.

Übergang in den Hibernation-Zustand: Nach Absetzen des Kommandos “systemctl hibernate” erfolgt ein Schirmwechsel mit blinkendem Cusrsor; das System schaltet sich dann nach kurzer Zeit ab.

Resume aus dem S4-Hibernation-Zustand
Typischerweise muss man die Power-Taste drücken, um den Resume-Vorgang auszulösen.

Es erscheint ein BIOS-Schirm ohne Optionen (das BIOS erkennt offenbar einen Boot-Vorgang aus einem S4-Zustand). Danach wird GRUB2 gestartet – mit der üblichen Startup-Meldung und der Abfrage nach der Passphrase für das Device mit dem root-FS.
GRUB loading ..
Welcome to GRUB!
Attempting to decrypt master key …
Enter passphrase for lvm/vga-lva1 (…KRYPTO-UUID …):
Nach den bei mir notwendigen 6 Sek. für hunderttausende PBKDF2-Iterationen wird nicht das grafische Boot-Menü angezeigt. Zunächst blinkt (sehr) kurz eine Fehlermeldung auf (s.u.).
Es erfolgt ein Schirmwechsel; es wird direkt angekündigt, dass das zuletzt gebootete System hochgefahren wird. Genauer gesagt: Es wird angezeigt, dass der GRUB2-Eintrag genutzt wird, der dem zuletzt gebooteten System entspricht. (Frage: Woher weiß Grub das eigentlich? S.u.!).
Einige Zeit später erkennen wir an den Meldungen, dass der Kernel übernimmt; wir werden dann nach der Passphrase für “vgs-lvs1 (cr-swap)” gefragt. Das erscheint mehr als sinnvoll, da das Image ja aus dem SWAP ausgelesen werden muss. Wenn jemand nun die “quiet”-Option für den Kernel deaktiviert hatte, kann er danach ggf. schnell durchlaufende Meldungen zum Laden des Images sehen.
Danach landen wir genau in dem Zustand (inkl. Schirmbild) wieder, in dem wir “systemctl hibernate” abgesetzt hatten – also in einer aktiven Shell.

Wer dem Frieden nicht traut, kann nun über verschiedene User-Logins Dateien auf den virtuellen Konsol-Terminals öffnen und den Test wiederholen. Alle geöffneten Dateien sollten danach im Editier-Zustand erhalten sein. Das war bei mir der Fall. Im Prinzip funktioniert Hibernation also auf meinem alten BIOS-Laptop!

Reboot statt Resume mit Image im SWAP
Einen interessanten Testfall liefert ein absichtliches Vertippen bei der durch GRUB2 zuerst abgefragten Passphrase. Man landet dann auf einer Grub-Emergency-Shell. Danach kann man ggf. das System einfach neu starten; d.h. einen Warm- oder Kalt-Start mit “Standard-Boot”-Initialisierung starten. Ich erhalte auf meinem Laptop dann den Standard-Startschirm mit BIOS-Optionen. Für das BIOS liegt in diesem Fall offenbar kein Start aus einem Hibernation-Zustand vor. Danach übernimmt Grub2 die Kontrolle.

Grub2 weist nach Eingabe des korrekten Passwords aber genau dasjenige Verhalten auf, das wir schon für einen Hibernation-Resume-Vorgang kennen:
Das zuletzt gebootete System-Kernel wird gestartet, das SWAP-Password wird abgefragt und das dort immer noch vorhandene Image wird restauriert.

Ganz offenkundig ist das Verhalten von GRUB2 unabhängig davon, ob ein echter S4-Zustand gegeben ist oder nicht … Entscheidend für das Boot-Verhalten sind offenbar andere Faktoren.

Woher wissen Grub2, der Kernel und systemd eigentlich, was zu tun ist?

An dieser Frage kann man eine Weile knabbern – besonders, wenn man sich vor einer Detail-Analyse der hinter dem “hibernate”-Kommando liegenden Skripte drücken will. Den Schlüssel stellte in meinem Fall die Beobachtung dar, dass die Datei “/boot/grub2/grubenv” unmittelbar vor dem Herunterfahren in den Hibernation-Zustand upgedated wird. Nach dem Neustart erkennt man aber keine Änderungen des Datei-Inhalts. Also liegt nahe, dass vor dem Hibernation-Übergang ein Eintrag geschrieben und später im Verlauf des Resume-Vorgangs wieder rückgängig gemacht wird.

Deshalb muss man sich also doch ein wenig um die Skripte kümmern, die den Hibernate-Zustand herbeiführen. “systemctl” weist auf “systemd” hin. Ein wenig Analyse des Services “/usr/lib/systemd/system/systemd-hibernate.service” und seiner Voraussetzungen führt uns zum Skript “/usr/lib/systemd/system-sleep/grub2.sleep“. Dort stoßen wir nach ein wenig Code-Analyse auf die Funktion “prepare-grub()“:

Sie führt ein Kommando “/usr/sbin/grub2-once” aus. Das zugehörige Perl-Skript von SuSE absolviert zunächst etliche Analysen und mündet schließlich in das Schreiben eines Eintrags in die Datei “grubenv” (dabei wird das Skript “/usr/sbin/grub2-reboot” verwendet).

Wir können dies auch manuell testen; grub2-once erfordert einen Parameter, der der Nummer des Eintrags im Grub2-Menü entspricht; gezählt wird dabei ab 0! Ein Absetzen des Kommandos

grub2-once 0

führt dann in meinem Fall zu zwei (!) Einträgen in der “grubenv”-Datei der Form

saved_entry=0
next_entry=openSUSE Leap 15.0

Entscheidend für das Boot-Verhalten von Grub2 ist dabei der Eintrag “next-entry“. Im Verlauf des Resume-Vorgangs aus dem Hibernation-Zustand wird der “next-entry” aber wieder gelöscht. (Wenn Grub das selbst das nicht übernehmen kann, so können das immer noch ein später gestartetes systemd-Skript!)

Fehlermeldungen Grub2: “error: diskfilter writes are not supported”

Kurz bevor Grub2 den Reboot der zuletzt aktiven OS-Variante startet, flackert eine Fehlermeldung auf, die man nur mit Mühe dingfest machen kann, da unmittelbar danach ein Schirmwechsel erfolgt:

error: diskfilter writes are not supported

Das ist harmlos; Grub2 nutzt ein Feature “recordfail“, um im Boot-Vorgang Updates vorzunehmen. Das geht aber nicht, wenn das “/boot”-Verzeichnis in einem LVM-Volume liegt – was bei uns der Fall ist. Siehe hierzu:
https://askubuntu.com/questions/468466/ diskfilter-writes-are-not-supported-what-triggers-this-error.

Das “recordfail”-Feature wird mit einem kurzen Timeout übersprungen. Das Auslesen des Files “/boot/grub2/grubenv” kann in jedem Fall stattfinden; dies genügt, um die richtige Boot-Variante auszuführen. SuSE umgeht das Problem des Updates der Datei “/boot/grub2/grubenv” über Skripts.

Errors im Shutdown: device-mapper: remove ioctl on system-root failed

Ich wende mich nun einer hässlicheren Seite des gesamten Themenkreises zu: Eine interessante Frage ist, ob die systemd-Scripts im Hibernation-Vorgang die “Luks on LVM”-Struktur korrekt berücksichtigen (unmount, LUKS-Device schließen, LVM stoppen). Es gibt Hinweise, dass das leider nicht der Fall ist; man schalte mal die Silent/Quiet-Optionen für den Kernel in der Grub-Konfiguration ab und beobachte die Meldungen im Shutdown oder Hibernation-Vorgang. Man erhält dort ca. 40 Zeilen der Art :

device-mapper: remove ioctl on system-root failed

Erst danach gibt “dracut” auf, und das System wird
abgeschaltet. Man macht sich dann natürlich Sorgen um die Konsistenz sowohl des Filesystems als auch des Krypto-Devices. Bisher habe ich keinen Einschränkungen oder Konsequenzen wahrnehmen können. Ein ungutes Gefühl bleibt aber. Das spricht übrigens auch für den Einsatz von LUKS2 für die Devices, in denen später die wirklich wichtigen Daten lagern sollen.

Es handelt sich bei dem Fehler vermutlich um einen Plymouth Bug. Siehe hierzu:

https://forums.opensuse.org/showthread.php/ 530530-device-mapper-remove-ioctl-on-system-root-failed
https://bugzilla.opensuse.org/show_bug.cgi?id=1080485
https://bugzilla.redhat.com/show_bug.cgi?id=1402073
https://bugzilla.redhat.com/show_bug.cgi?id=1575376#c8

Der Fehler ist weder bei Red Hat noch SuSE als gelöst markiert.

Man kann die Fehlermeldungen vermeiden und den Shutdown zu S4 beschleunigen, indem man Plymouth abschaltet. Dass man sich dann mit Schirmwechseln und System-Meldungen beim Hochfahren des Systems konfrontiert sieht, stört mich persönlich wenig.

Eine Deaktivierung von Plymouth hat allerdings auch die seltsame Konsequenz, dass nun in einem normalen Boot-Vorgang tatsächlich die Passphrase zu den zwei kryptierten Volumes separat abgefragt wird. Fragt mich nicht warum. Es erscheint offenkundig, dass auch Plymouth im Boot-Vorgang rumpfuscht.

Off Topic: Meiner Meinung nach zeigen sich hier erneut eher negative Auswirkungen des gesamten Ansatzes aus systemd/udev, Grub2, plymouth: zu komplex, zu viele gegenseitige Abhängigkeiten. Über die letzten 6 Jahre hinweg haben sich vor allem Grub und systemd immer mehr zu eigenen kleinen Betriebssystemen entwickelt, welche – jedes für sich – viele Funktionalitäten (HW-Erkennung, LVM, LUKS, Video, …) integrieren müssen, die man früher alle dem Linux-Kernel und seinen Modulen zugeordnet hätte. Die Chancen des normalen Users, die Abläufe nachvollziehen und selbständig Fehler umschiffen zu können, sind inzwischen minimal. (Nebenbei: Die Abhängigkeit des gesamten Linux-Öko-Systems von Red-Hat-Entwicklern wuchs in den letzten Jahren stetig; IBM profitiert davon nun direkt).

logind.conf: Zuordnung Hibernation zu Keyboard-Tasten und dem Schließen des Laptop-Deckels (LID close)

Abschließend hat mich interessiert, wo man denn eigentlich Einstellungen vornehmen muss, um den Hibernation-Vorgang auf eine Taste zu legen. Auf den meisten Laptops findet sich ja einen Taste, die einen Sleep-Vorgang des Systems auslöst. Auch das Schließen des Laptop-Deckels (LID) sollte so interpretiert werden.

Normalerweise nimmt einem ein Konfigurationsprogramm eines grafischen Desktops diese Arbeit ab; aber ein solcher Desktop läuft bei uns ja noch gar nicht. Mein Laptop weist eine Sleep-Taste auf (Fn-F12); selbige löst aber “Suspend” und nicht Hibernate aus. Auch das Schließen des Laptop-Deckels löst ohne spezielle Einstellungen keinen Hibernation-Vorgang aus.

Für das gewünschte Hibernate-Verhalten müssen wir Einträge in der Datei “/etc/systemd/logind.conf” ändern. In meinem Fall:

HandleSuspendKey=hibernate
HandleHibernateKey=hibernate
HandleLidSwitch=hibernate
LidSwitchIgnoreInhibited=yes

Danach führen wir ein

linux-5l8q:~ # systemctl restart systemd-logind 
linux-5l8q:~ # loginctl show-session
....
HandleSuspendKey=hibernate
HandleHibernateKey=hibernate
HandleLidSwitch=hibernate
....

aus. Die in der Sitzung aktiven Einstellungen kann man übrigens mittels der Kommandos “loginctl show-session” und “systemd-inhibit –list” kontrollieren.

nIm Anschluss funktionieren (zumindest bei mir) die Sleep-Taste wie auch das Schließen des Laptop-Deckels und münden in den Hibernation-Zustand. Leider gilt das für den Laptop-Deckel ohne weitere Maßnahmen nur genau einmal 🙁 .

Wichtiger sicherheitsrelevanter Hinweis:

Ihr solltet nach einem erfolgreichen Hibernate per Sleep-Taste ODER Laptop-Deckel (LID) unbedingt prüfen, ob nach dem Resume ein erneutes Hibernate über das Schließen des Laptop-Deckels funktioniert. Bei mir tut es das nämlich nicht! U.a., weil man sich nach dem Resume nämlich in einer offenen Shell befindet. Der “system-logind.service” greift dann für den Laptop-Deckel nicht mehr. Die genaue Ursache ist mir noch unklar; es gibt aber eine Fehlermeldung zum LID während des Resume-Vorgangs, die man wegen der Geschwindigkeit der vorbeirollenden Meldungen leicht übersieht. So etwas ist natürlich tödlich – man schließt nach einem ersten Hibernation/Resume Vorgang den Deckel für ein zweites Hibernate, das dann leider aber gar nicht ausgeführt wird.

Zuverlässig funktioniert bei mir dagegen dauerhaft die Sleep-Taste – also über mehrere Hibernation/Resume-Vorgänge hinweg. Ich habe mir daher angewöhnt, nur die Sleep-Taste für Hibernation zu nutzen.

Manueller Workaround für den Laptop-Deckel (LID) nach einem Resume-Vorgang:

Wenn man den Laptop-Deckel nach einem ersten Hibernate/Resume erneut benutzen will, kann man entweder gezielt einen neuen Login durchführen. Alternativ kann man am Prompt einer laufenden Shell
“sudo systemctl restart systemd-logind”
absetzen.

Das ist nicht befriedigend; wenn man mehr “Automatik” will, muss man in systemd-Konfiguration eingreifen, sich einen Service anlegen, der bei Hibernation/Resume zusätzlich gezogen wird und Statusdaten schreibt und auf dieser Basis am Ende des Resumes “systemctl restart systemd-logind” ausführt. Hierzu sollte man ein modifiziertes hibernate.target (s. /usr/lib/systemd/system/hibernate.target) unter “/etc/systemd/system” anlegen. Einen direkten Eingriff in die systemd-sleep-Skripts von SUSE würde ich vermeiden. Auf Details zur systemd-Modifikation kann ich hier aus Zeit- und Platzgründen nicht eingehen; vielleicht in einem späteren Beitrag.

Fazit und Ausblick

Hibernation in Kombination mit Voll-Verschlüsselung und “LUKS on LVM” ist unter Opensuse Leap 15 (bei adäquater Hardware) durchaus möglich. Der SWAP muss hinreichend groß angelegt werden. Es gibt in dem komplexen Hibernate/Resume-Ablauf, in dem systemd (initramfs, normaler Start unter Kernel-Kontrolle) , Grub2, plymouth, initramfs und natürlich der Linux-Kernel mitwirken, allerdings Unstimmigkeiten. Plymouth trägt zu Fehler-Meldungen im Shutdown bei, die hinsichtlich der Konsistenz der Datenhaltung beunruhigen. Eine Deaktivierung von Plymouth scheint daher sinnvoll.

Eine Zuordnung des Hibernate-Übergangs zu speziellen Tasten oder Events ist möglich. U.U. ist ein LID-Close mit Hibernate nach dem ersten Resume ohne Restart des systemd-logind-Service aber nicht mehr wirksam. Tests zum erwarteten Verhalten sind über mehrere Hibernate/Resume-Vorgänge hinweg unbedingt notwendig.

Im nächsten Beitrag
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – XI – Keyfiles, LUKS2-Volumes
gehe ich darauf ein, wie man ein Keyfile einsetzen kann.

Links

Ein paar Basics
https://www.kernel.org/doc/ Documentation/power/states.txt
https://wiki.ubuntu.com/Kernel/Reference/S4
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
https://forums.linuxmint.com/viewtopic.php?t=176711 (s. dort die Erläuterungen in einem Kommentar)
https://wiki.ubuntuusers.de/Energiesparmodi _mit_ACPI/

Grub und Hibernation
https://robbinespu.github.io/eng/2018/01/07/ Fedora_hibernate.html
https://www.mankier.com/8/grub2-reboot
https://askubuntu.com/questions/17079/what-is-grub-2s-role-in-the-suspend-hibernate-process
https://www.linuxsecrets.com/archlinux-wiki/wiki.archlinux.org/index.php/GRUB.1.html
https://gist.github.com/klingtnet/ c972b8182e4e2818d6d551b0cbeac44b

Grub skips menu
https://forums.opensuse.org/showthread.php/ 511255
https://forums.opensuse.org/showthread.php/ 501545-13-2-RC-1-sparse-file/page3
https://build.opensuse.org/package/view_file/ openSUSE:Factory/grub2/grub2.changes
https://en.opensuse.org/SDB:Suspend_to_disk

Laptop-Deckel (Lid close) und Hibernation
https://ask.fedoraproject.org/en/question /120359/fedora28-hibernate-problem/
https://forums.opensuse.org/showthread.php/ 528291-How-to-make-lidclose-suspend
https://legacy.thomas-leister.de/arch-linux-suspend-disk-hibernate-einrichten/

Kernel and Hibernation
https://www.linuxquestions.org/questions/linux-kernel-70/what-happens-to-the-kernel-when-you-resume-from-hibernation-4175604308/
https://legacy.thomas-leister.de/arch-linux-suspend-disk-hibernate-einrichten/

Problems – open device during shutdown
https://bugzilla.redhat.com/show_bug.cgi?id=1402073

Linux-Blog – Dr. Mönchmeyer / anracon

Notes about Linux, ML and some simple math …

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – X – Hibernation