[gelöst] Dell Latitiude D510: Schwarzer Bildschirm nach Ruhezustand

[EinSteiGer]

Wertes Forum,

ich habe vor kurzem Debian 10 mit Mate auf einem alten D510 installiert. Ich bin damit eingentlich sehr zufrieden, habe heute aber probiert den Rechner über Mate (Ausschaltknopf-Icon und das dortige Auswahlmenü) in den Ruhezustand zu versetzen (ich gehe davon aus, dass es sich dabei um "hibernate" handelt, denn beim Aufwachversuch lese ich

Resuming from hibernation

). Beim "Aufwachen" endet dies jedoch bei einem Schwarzen Bildschirm.

Im Forum habe ich u.a. vom der Tatenkombination Strg + Alt F7/F8 gelesen. Die jedoch nichts bewirkte.

Ich bezweifle, dass es nur am Bildschirm liegt, denn Tastenkombinationen wie Fn + F10, die z.B. zum öffnen des CD-Laufwerks führen, funktionieren in diesem Zustand ebenfalls nicht.

Einzig die Leuchte dafür das der Rechner eingeschaltet ist ist zu sehen (rechts oben hinter der Tastatur im Schanier des Bildschirms.

Gerne poste ich ggf. dazu relevante log-Daten o.ä., weiß jedoch z.Z. nicht, was relevant sein könnte.

Mit freundlichen Grüßen

edit:
Auch wenn oben von hibernation die Rede ist, habe ich folgendes festgestellt:

Code: Alles auswählen

# hibernate
bash: hibernate: Kommando nicht gefunden.

edit 2:
edit 1 war mein Fehler. Der oben beschriebene Fehler lässt sich mit

Code: Alles auswählen

systemctl hibernate

reproduzieren.

edit 3:
Könnte es evtl. an der Datei sleep.conf bzw. ihren (fehlenden bzw. von vornherein auskommentierten) Einträgen liegen? (40970)

edit 4:
Wenn ich allerdings viewtopic.php?f=26&t=175197#p1220613 richtig verstehe, funktioniert das i.d.R. auch ohne sleep.conf...

edit 5:
Sehe ich das richtig, wenn das Resuming fehlschlägt gibt es auch keine log-Datei dazu, die hilfreich sein könnte?

edit 6: Gibt es noch andere Möglichkeiten, intendiert zu loggen, damit ich erahnen kann, wo das Problem liegen könnte?

edit 7: Suspend funktioniert "besser". Hier ist eine Rückkehr möglich. Danach wird allerdings dauernd das W-LAN-Passwort abgefragt und keine Verbindung kommt zustande. Der Rechner "wacht" allerdings wieder auf.

edit 8: Was in einem anderen Fall und Forum (https://www.linux.org/threads/hibernate ... ion.22557/) an output u.a. interessant/angefragt war und ggf. weiterhelfen könnte:

Code: Alles auswählen

$ cat /sys/power/state
freeze mem disk

Code: Alles auswählen

$ df -Th

-> 40974

Code: Alles auswählen

$ cat /etc/default/grub

-> 40975

Code: Alles auswählen

$ cat /etc/fstab

-> 40976

edit 9:
Link zu Infos zu systemctl: https://net2.com/how-to-shut-down-resta ... ate-linux/

edit 10:
In Bezug auf https://forums.bunsenlabs.org/viewtopic.php?id=4305 poste ich hier noch den Inhalt von /etc/initramfs-tool/conf.d/resume

Code: Alles auswählen

RESUME=UUID=e21bdfa0-1ff8-4009-a0b2-efda0f8e55a2

edit 11:
Zu Hibernation allgemein: https://de.wikipedia.org/wiki/Ruhezustand#Linux

edit 12:
Für die Freunde verschlüsselter SWAP-Partitionen: https://gist.github.com/HacKanCuBa/b856 ... 75ee836857 (Hat aber mit meinem Thema m.W. nichts zu tun.)
(Vgl. auch http://forums.debian.net/viewtopic.php? ... ibernation)

edit 13:
Weil Hibernation ja immer auch etwas mit dem Kernel zu tun hat, hier die kern.log: 40977

edit 14:
Der Inhalt von sys/power/image_size lautet:

Code: Alles auswählen

802357248

(vgl. dazu https://legacy.thomas-leister.de/arch-l ... inrichten/)

edit 15:
Noch eine Erweiterung für die Link-Sammlung; diesmal wieder nicht ganz so nahe am Thema: Hibernate Debugging (ohne dass ich sage könnte, ich verstehe, worum es geht.)

Kennst du das hier?
https://01.org/blogs/rzhang/2015/best-p ... ate-issues

Und ... neustes BIOS ist drauf?

Ist das Image in einer Partition/LVM oder eine Datei im Dateisystem?

Das Zitat stammt aus viewtopic.php?f=33&t=168892&hilit=hibernate

edit 16:
Probleme mit dem Hibernate auch in Kubuntu mit dem selben Rechner: https://wiki.ubuntu.com/KubuntuPowersave Dass es allerdings tatsächlich das selbe Problem sei, lässt sich nicht sagen.

edit 17:
Bei opensuse hat das Rechner-Modell für Suspend to Disk jeweils einen grünen Haken: https://en.opensuse.org/HCL:Dell_laptops

edit 18:
Gleiche Fehlermeldung, aber in anderem Kontext und mit anderer Lösung:
viewtopic.php?f=12&t=174026
(Vgl. auch http://forums.debian.net/viewtopic.php? ... ibernation)

edit 19:
Andere lösten ihr Problem mit dem Umstieg auf pm-utils: http://forums.debian.net/viewtopic.php? ... on#p707924

edit 20:
Ein neuer Post hier im Forum zum Ruhezustand:
viewtopic.php?f=12&p=1229043#p1229021

[EinSteiGer]

Wertes Forum,

mittlerweile habe ich das System leicht verändert:
Ich habe

Code: Alles auswählen

apt-get full-update

durchgeführt; hin zu linux-image-686-pae (4.19+105+deb10u3).

Und mit Blick auf eine Fehlermeldung im Vorfeld (viewtopic.php?f=12&t=176365) auf towos Anregung hin

Wenn Du Intel Grafik hast, solltest Du das Paket firmware-misc-nonfree installieren.
Anderenfalls kannst Du diese Meldung ignorieren.

das genannte Pakte installiert. (Edit: Und später wieder deinstalliert.)

Das ändert jedoch nichts am oben beschriebenen Hibernate-Problem.

Die Swap dürfte groß genug sein:

Code: Alles auswählen

:~# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 149,1G  0 disk 
├─sda1   8:1    0 147,1G  0 part /
├─sda2   8:2    0     1K  0 part 
└─sda5   8:5    0     2G  0 part [SWAP]
sr0     11:0    1  1024M  0 rom  

bzw.

Code: Alles auswählen

~# free -m
              total        used        free      shared  buff/cache   available
Mem:           1943         726         500         149         716         853
Swap:          2037           0        2037

Falls es weiterhilft, habe ich noch einen Wert zur Info ausgeben lassen:

Code: Alles auswählen

:~# sysctl vm.swappiness
vm.swappiness = 60

Über Ideen, wie ich dem Problem nachgehen könnte, würde ich mich sehr freuen.

Mit freundlichen Grüßen

[MSfree]

Und mit Blick auf eine Fehlermeldung im Vorfeld (viewtopic.php?f=12&t=176365) auf towos Anregung hin

Wenn Du Intel Grafik hast, solltest Du das Paket firmware-misc-nonfree installieren.
Anderenfalls kannst Du diese Meldung ignorieren.

das genannte Pakte installiert.

Firmware wird für Intelgraphik erst ab Kaby-Lake (oder war es Sky-Lake?) Core-i CPUs benötigt. Für deine Kiste ist das also völlig belanglos.

[EinSteiGer]

Werter MSfree,

besten Dank für den Hinweis:

Für deine Kiste ist das also völlig belanglos.

Dann werde ich das non-free-"Ding" wieder entsorgen (via apt-get purge).
Ich habe -- ganz wie oben im Zitat benannt -- die Hardware beim Überfliegen von https://packages.debian.org/buster/firm ... sc-nonfree auch nicht gelistet gesehen.

Über Ideen zu meinem Hibernate-Problem würde ich mich nach wie vor sehr freuen.

Mit freundlichen Grüßen

[EinSteiGer]

Wertes Forum,

mit Blick auf viewtopic.php?f=2&t=176342 poste ich hier noch folgendes:

Code: Alles auswählen

:~$ xset q
...
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  0
...
DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Enabled
  Monitor is On

Die vollständige Ausgabe findet sich unter 40985.

Mit freundlichen Grüßen

[EinSteiGer]

Wertes Forum,

ich versuche es noch einmal und poste nun ein log (

Code: Alles auswählen

journalctl

) der letzten reboots:40988

Nach Fehlern gefiltert ergibt sich nicht so viel:

Code: Alles auswählen

:~# journalctl -p err -b
-- Logs begin at Mon 2020-02-10 14:30:58 CET, end at Tue 2020-02-11 13:39:07 CET. --
Feb 11 13:04:04 laptop wpa_supplicant[411]: ioctl[SIOCSIWENCODEEXT]: Invalid argument
Feb 11 13:04:04 laptop wpa_supplicant[411]: ioctl[SIOCSIWENCODEEXT]: Invalid argument
Feb 11 13:04:06 laptop wpa_supplicant[411]: Failed to add supported operating classes IE
Feb 11 13:04:06 laptop wpa_supplicant[411]: bgscan simple: Failed to enable signal strength monitori
Feb 11 13:21:13 laptop wpa_supplicant[411]: dbus: wpa_dbus_property_changed: no property SessionLeng
Feb 11 13:21:14 laptop wpa_supplicant[411]: Failed to add supported operating classes IE
Feb 11 13:21:14 laptop wpa_supplicant[411]: bgscan simple: Failed to enable signal strength monitori
Feb 11 13:21:25 laptop wpa_supplicant[411]: dbus: wpa_dbus_property_changed: no property SessionLeng
Feb 11 13:21:26 laptop wpa_supplicant[411]: Failed to add supported operating classes IE
Feb 11 13:21:26 laptop wpa_supplicant[411]: bgscan simple: Failed to enable signal strength monitori
Feb 11 13:21:41 laptop wpa_supplicant[411]: dbus: wpa_dbus_property_changed: no property SessionLeng
Feb 11 13:21:42 laptop wpa_supplicant[411]: Failed to add supported operating classes IE
Feb 11 13:21:42 laptop wpa_supplicant[411]: bgscan simple: Failed to enable signal strength monitori
lines 1-14/14 (END)

Ich habe hibernate in dieser Zeit noch einmal ausprobiert (also auch den Fehler reproduziert), kenne mich damit nicht wirklich mit dem log aus, gehe aber davon aus, dass wegen des crash nach dem Ruhezustand keine verwertbaren Infos darin zu finden sind.
Ich würde mich freuen, wenn jemand, der logs versteht das mal überfliegen könnte, um zu sagen, ob das etwas austragen könnte oder ob meine Vermutung (Crash zerstört log) richtig ist.

Mit Blick darauf, dass ich bisher nicht weiter gekommen bin und noch keine weiteren greifbaren Zwischenergebnisse habe, habe ich überlegt, ob es sich um einen Bug handeln könnte und frage mich mit Bezug auf viewtopic.php?f=33&t=175170 wie ich das mit Blick auf mein Problem ausschließen/abklären könnte und welche logs/Infos/Daten für eine solche Abklärung in diesem Fall relevant sein könnten. (Ich tippe ja immer noch eher darauf, dass ich etwas total Offensichtliches übersehe, was ziemlich simpel abzustellen sein könnte.)

Mit freundlichen Grüßen

[MSfree]

ich versuche es noch einmal und poste nun ein log ... der letzten reboots:

Ein Aufwachen aus dem Ruhezustand ist aber kein Reboot. Das hilft also nicht.

Nach Fehlern gefiltert ergibt sich

Das ist nur wpa_supplicant, wenn es versucht, die WLAN-Verbindung aufzubauen. Da kann es schonmal zu mehreren Versuchen kommen. Hat also auch nichts mit dem Problem ansich zu tun.

Was man brauchen würde ist:

• Rechner in den Ruhezustand versetzen
• Auf die Uhr schauen
• Rechner aufwecken und warten bis schwarzer Bildschirm "da" ist
• Einloggen per SSH von einem Zweitrechner
• und dann die Logs und dmesg-Ausgabe seit dem Aufwecken (siehe zwei Punkte weiter oben) ansehen

[EinSteiGer]

Werter MSfree,

das würde ich gerne probieren. Dazu habe ich nur noch eine Frage:

Einloggen per SSH von einem Zweitrechner

Was ist damit gemeint? Müsste dann auf dem Rechner mit dem schwarzen Screen nicht ein ssh-Server (https://wiki.ubuntuusers.de/SSH/) laufen?
Oder anders: Welche Pakete/Software bzw. welche Info dazu könnte hilfreich sein und wie bekomme ich den Zugriff auf den Rechner, auf dem ich ja dann in diesem Moment keinen ssh-Zugang freigeben kann?

Also lange Rede kurzer Sinn: Ich würde mich über einen Link oder zumindest ein paar weitere Sätze zum genannten Punkt sehr freuen.

Mit freundlichen Grüßen

[MSfree]

Müsste dann auf dem Rechner mit dem schwarzen Screen nicht ein ssh-Server (https://wiki.ubuntuusers.de/SSH/) laufen?

Genauso ist es. Es ist immer eine gute Idee, einen SSH-Server am laufen zu haben. Falsch konfiguriert kann es aber eine Sicherheitslücke darstellen, so daß Debian im Normalfall keinen Zugang einrichtet.

Das nötige Paket, das installiert sein muß, ist openssh-server.
Du solltest dir mit ssh-key ein Schlüsselpaar erzeugen, und den öffentlichen Schlüssel auf dem Server (also deiner Dell-Kiste) ablegen und den privaten Schlüssel auf dem Zweitrechner. Kommt dann der Moment, logst du dich von dem Zweitrechnermit ssh auf der Dellkiste ein, das ist dann zwar nicht graphisch, aber du kommst von der Kommandozeile an alles wichtige ran.

Anlegen eines Schlüsselpaares:

Code: Alles auswählen

ssh-keygen -t rsa -C username@d510 -f username.rsa

Es
es entstehen zwei Dateien:
username.rsa.pub und username.rsa.
Die username.rsa.pub hängst du an die Datei /home/username/.ssh/authorized_keys mit dem Befehl:

Code: Alles auswählen

cat username.rsa.pub >> /home/username/.ssh/authorized_keys

an

Die Datei username.rsa bringst du auf den Zweitrechner und legst sie dort im Homeverzeichnis des Benutzers unter .ssh ab. Also

Code: Alles auswählen

cp username.rsa /home/username/.ssh

"username" ist entsprechend zu ersetzen.

Von da an kannst du dich mit

Code: Alles auswählen

ssh username@RechnernameOderIP -i ~/.ss/username.rsa

jederzeit vom Zweitrechner auf der Dellkiste einloggen.

[EinSteiGer]

Werter MSfree,

besten Dank für die ssh-Anleitung! Jetzt bin ich endlich dazu gekommen, sie auszuprobieren.
(Mit ein paar Kleinigkeiten, die ich noch machen musste wie einen Ordner anlegen oder die Rechte für den Zugriff auf den Schlüssel zu verändern hat das wunderbar geklappt.)

Leider habe ich dadurch jedoch kein log-Daten bekommen, da der Rechner nach dem "Aufwachen" bei schwarzem Bildschirm weder per W-LAN noch per LAN zu erreichen ist. Das "resuming" scheint vorher schon zu enden/hängen.

Hat noch jemand einen Tipp, wie ich zu ggf. relevanten logs kommen könnte?

Mit freundlichen Grüßen

[EinSteiGer]

Wertes Forum,

da ich nun schon eine ganze Weile suche, aber (trotz der Hilfe und Unterstüztung für die ich mich ausdrücklich bedanken möchte) nicht weiterkomme, überlege ich, den Ruhezustand auf anderem Weg zu erreichen.

Falls ich das richtig verstanden haben sollte, ist

Code: Alles auswählen

systemctl hibernate

ein Kommandozeilenwerkzeug für systemd (soweit https://wiki.ubuntuusers.de/systemd/systemctl/).

Wenn dem so sein sollte, stellt sich mir die Frage, ob ich mit einem anderen Paket den Ruhezustand herstellen kann und falls ja mit welchem.

Was ich dezidiert nicht möchte ist eine Fass aufmachen, wie ob systemd sinnvoll ist oder welche Wege hier Debian einschlägt. Da bin ich beim Suchen zu meinen Gedanken ausführlich drauf gestoßen...

Falls sich mein Hibernate-Problem mit Debian nicht lösen lassen sollte, könnte ich dann mit Devuan mehr Erfolg haben? (Ich möchte -- weil es da viel verbrannte Erde zu geben scheint -- betonen, es geht mir um die Lösung meines Problems, nicht um das generelle für und wieder und schon gar nicht das Auslösen eines Kriegs-Pingpongs pro und contra systemd oder whatever.)

Ich freue mich auf konstruktive Ideen und natürlich auch auf Hinweise, wo ich falsch liege bzw. wo ich weitere Informationen mit berücksichtigen müsste.

Mit freundlichen Grüßen

[MSfree]

Um hier irgendwie weiter zu kommen, brauchen wir Logs.

Systemd ist jedenfalls ein ganz zentraler Bestandteil fast aller Linuxdistributionen. Es ist der erste Prozeß, der vom Kernel gestartet wird und dieser kümmert sich um das Starten in der richtigen Reihenfolge aller weiteren Prozesse. Auch für die Hibernation führt praktisch nichts an systemd vorbei.

systemctl hibernate ist im Grunde auch der Befehl, der von der Graphischen Umgebung abgesetzt wird, wenn man den entsprechenden Menüpunkt betätigt.

Prüf doch bitte mal folgendes:

• Gibt es das Verzeichnis /var/log/journal?
• gibt es dort Dateien?

Falls nicht, lege das Verzeichnis als root an und reboote deinen Rechner. Danach sollte es unter /var/log/journal das Journal geben, das ist eine "Datenbank", in die die Systemmeldungen geschrieben werden.

Log dich per SSH von deinem Zweitrechner ein und gebe dann
journalctl -f
ein. Du solltest dann sehen, welche Meldungen da so auflaufen.

Nimm dann die Dellkiste und leite von dort den Hibernationvorgang ein.

Auf dem Zweitrechner sollten jetzt Meldungen auftreten, die vielleicht weiterhelfen. Und mit etwas Glück Fehlermeldungen oder zumindest der letzte Vorgang, der vollzogen wurde.

Da du jetzt hoffentlich auch noch das Journal auf der Festplatte hast, kannst du nach dem Neustart die Meldungen nochmal ansehen. Hilfreich ist hier besonders, sich die Uhrzeit zu merken, wann man den Hibernationvorang gestartet hat. Dann kann man nur die Meldungen seit dieser Uhrzeit nachträglich untersuchen.

[EinSteiGer]

Werter MSfree,

danke für die Antwort

Prüf doch bitte mal folgendes:

• Gibt es das Verzeichnis /var/log/journal?
• gibt es dort Dateien?

Ja und nochmals ja:
/var/log/journal enthält den Ordner "8b262426661e4208aa65ef8f8959225c"
Darin befinden sich folgende Dateien:

Code: Alles auswählen

$ dir
system@00059e3f034d7840-33dbe9140ea8b09c.journal~
system@00059e3f33a0c195-e56af8f9566ff81e.journal~
system@00059e4b9339a0bd-6dda7350a01b4dfd.journal~
system@00059e4ba5c5a1be-42d530a12f4cb47b.journal~
system@00059ef0d2441205-c2a7c5c712005c66.journal~
system@00059f657a067b51-6d74dade004c5dc1.journal~
system@1e55a04005f44a6aac4484252991b16b-0000000000000001-00059e4ba5ad0d13.journal
system@5352c15f330b4814af1710f1d3831d45-0000000000000001-00059f6579f0af15.journal
system.journal
user-1000@00059e3f366e9ced-d8dc615c41b0a370.journal~
user-1000@00059e4ba89fb864-0a87e0871f81c1e9.journal~
user-1000@067865553ae442a0bf37a30ae15c934e-000000000000041f-00059e4ba89dc967.journal
user-1000@f14e2a074b9d448ba1cf07c4f3d7c923-000000000000110f-00059eeb0ad00304.journal
user-1000.journal

Log dich per SSH von deinem Zweitrechner ein und gebe dann
journalctl -f
ein. Du solltest dann sehen, welche Meldungen da so auflaufen.

Nimm dann die Dellkiste und leite von dort den Hibernationvorgang ein.

Auf dem Zweitrechner sollten jetzt Meldungen auftreten, die vielleicht weiterhelfen. Und mit etwas Glück Fehlermeldungen oder zumindest der letzte Vorgang, der vollzogen wurde.

Beim ersten Versuch (als user) kam nichts heraus, beim zweiten Versuch als root habe ich folgende Ausgabe erhalten (interessant ist es ab 14.11 Uhr, wenn ich den Ruhezustand einleite):

Code: Alles auswählen

~# journalctl -f
-- Logs begin at Mon 2020-02-10 14:30:58 CET. --
Feb 25 14:07:28 laptop dbus-daemon[624]: [session uid=1000 pid=624] Successfully activated service 'org.gtk.vfs.Metadata'
Feb 25 14:07:28 laptop systemd[600]: Started Virtual filesystem metadata service.
Feb 25 14:07:29 laptop dbus-daemon[624]: [session uid=1000 pid=624] Activating service name='org.freedesktop.Notifications' requested by ':1.41' (uid=1000 pid=726 comm="nheko ")
Feb 25 14:07:30 laptop dbus-daemon[624]: [session uid=1000 pid=624] Successfully activated service 'org.freedesktop.Notifications'
Feb 25 14:08:28 laptop sshd[838]: Accepted publickey for ph from 192.168.1.6 port 47590 ssh2: RSA SHA256:AJUgaSIaKZElfrpgqxVininE0E7EdkOwYcRzoxdP9+c
Feb 25 14:08:28 laptop sshd[838]: pam_unix(sshd:session): session opened for user ph by (uid=0)
Feb 25 14:08:28 laptop systemd-logind[410]: New session 4 of user ph.
Feb 25 14:08:28 laptop systemd[1]: Started Session 4 of user ph.
Feb 25 14:09:16 laptop su[859]: (to root) ph on pts/0
Feb 25 14:09:16 laptop su[859]: pam_unix(su-l:session): session opened for user root by ph(uid=1000)
Feb 25 14:11:08 laptop NetworkManager[404]: <info>  [1582636268.0007] manager: sleep: sleep requested (sleeping: no  enabled: yes)
Feb 25 14:11:08 laptop kernel: b44 ssb0:0 eth0: powering down PHY
Feb 25 14:11:08 laptop NetworkManager[404]: <info>  [1582636268.0009] device (eth0): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Feb 25 14:11:08 laptop NetworkManager[404]: <info>  [1582636268.0422] manager: NetworkManager state is now ASLEEP
Feb 25 14:11:08 laptop systemd[1]: Reached target Sleep.
Feb 25 14:11:08 laptop systemd[1]: Starting Restart Syncthing after resume...
Feb 25 14:11:08 laptop systemd[1]: Starting Hibernate...

Fehlermeldung kann ich darunter keine erkennen.
Zuletzt startet systemd den Ruhezustand...

Mit freundlichen Grüßen

[MSfree]

Das sieht soweit alles ganz OK aus.

Wenn du die Kiste nun aber wieder anstellst und wartest, bis sie hängt, sollten weitere Einträge im Journal landen. Nach einem Reset und Start der Kiste sollest du die Zeile:

Code: Alles auswählen

Feb 25 14:11:08 laptop systemd[1]: Starting Hibernate...

Im Journal suchen und die darauf folgenden Meldungen ansehen.

[EinSteiGer]

Werter MSfree,

unter 40993 sind die Logs ab dem benannten Zeitpunkt zu finden.

Die ersten Zeilen ab dem Initialisieren des Ruhezustands sehen so aus:

Code: Alles auswählen

Feb 25 14:11:08 laptop systemd[1]: Starting Hibernate...
Feb 25 14:11:08 laptop systemd[1]: syncthing-resume.service: Succeeded.
Feb 25 14:11:08 laptop systemd[1]: Started Restart Syncthing after resume.
Feb 25 14:11:08 laptop kernel: PM: Image not found (code -22)
Feb 25 14:11:08 laptop systemd-sleep[888]: Suspending system...
Feb 25 14:11:08 laptop kernel: PM: hibernation entry
Feb 25 14:11:08 laptop kernel: PM: Syncing filesystems ... 
-- Reboot --
Feb 25 14:28:28 laptop kernel: Linux version 4.19.0-8-686-pae (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)

Mit freundlichen Grüßen

Edit:
Die Zeile mit

Code: Alles auswählen

Image not found (code -22)

scheint mir nicht ganz so toll zu klingen...

[MSfree]

Code: Alles auswählen

Feb 25 14:11:08 laptop kernel: PM: Image not found (code -22)

Das sieht mir sehr danach aus. daß der Kernel die Swap-Partition, auf der sich das Resume-Image befindet, nicht findet.

[EinSteiGer]

Werter MSfree, wertes Forum,

Das sieht mir sehr danach aus. daß der Kernel die Swap-Partition, auf der sich das Resume-Image befindet, nicht findet.

Code: Alles auswählen

~# blkid -o list -w /dev/null
device             fs_type   label      mount point            UUID
---------------------------------------------------------------------------------------------------
/dev/sda1          ext4                 /                      79bfca72-c003-4dbe-a5ff-ab37d290ac19
/dev/sda5          swap                 [SWAP]                 e21bdfa0-1ff8-4009-a0b2-efda0f8e55a2

Ich weiß nicht, inwiefern das (Edit: damit meine ich die hier gepostete Ausgabe von blkid) etwas mit dem Kernel und dem Resume-Image zu tun hat, aber "das System" findet zumindest eine als swap eingehängte Partition. (Oder irre ich da?)
Gibt es da noch andere Möglichkeiten, zu sehen, ob mit der Swap oder UUID-"Verlinkung" etwas schief geht?

Mit freundlichen Grüßen

Edit: Ein ähnliches Problem wird hier beschrieben: https://www.reddit.com/r/archlinux/comm ... linux419x/

[MSfree]

Ich weiß nicht, inwiefern das (Edit: damit meine ich die hier gepostete Ausgabe von blkid) etwas mit dem Kernel und dem Resume-Image zu tun hat, aber "das System" findet zumindest eine als swap eingehängte Partition. (Oder irre ich da?)

Puh, da muß ich jetzt weit ausholen.

Der Linuxbootvorgang besteht aus mehreren Schritten:
1. der Kernel wird durch grub geladen, hierbei werden ggfls. Parameter dem kernel mitgegeben.
2. der Kernel lädt eine Initial RAM-Disk (initrd), von der der erste Teil der Systeminitialisierung stattfindet.
3. über die RAM-Disk wird die Root-Partition gemountet.
4. erst jetzt kann die Dastei /etc/fstab gelesen werden
5. über die fstab werden weitere Partitionen gemountet, falls vorhanden.
6. der Swapbereich wird über die Referenz in der fstab eingebunden.
7. der ganze Rest vom Bootvorgang.

Beim Hibernate wird der RAM-Inhalt in den Swapbereich geschrieben.

Beim Resume wird nur der Kernel geladen und der Speicherinhalt vom Swapbereich zurück gelesen. Die o.g. Schritte 2-7 entfallen. Der Kernel weiß also eigentlich gar nicht, welche Partition den Swapbereich beinhaltet und dann kommt es zu dem genannten Fehler.

Gibt es da noch andere Möglichkeiten, zu sehen, ob mit der Swap oder UUID-"Verlinkung" etwas schief geht?

Ich bin auch nur durch eine Internetsuche auf die nicht gefundene Swappartition gestoßen. Ich habe aber leider nicht die Lösung gefunden. In einigen Foren wird davon gesprochen, daß es im Zusammenhang von btrfs und Resume Probleme gibt, allerdings trifft das auf dich nicht zu, dein Root ist ja ext4.

In anderen Foren habe ich was über Kernelparameter gelesen, mit der die UUID der Swap-Partition dem Kernel übergeben wird, damit der Kernel möglichst früh an die Swap-Partition rankommt. In einigen Forenthreads wird empfohlen, die Kernelparameter in die Datei /etc/default/grub einzutragen und dann update-grub aufzurufen. Eine weitere Möglichkeit habe ich über die Dateien unter /etc/initramfs-tools gefunden, in die dann irgendwo die Swap-UUID eingetragen werden solle.

Der Thread, den du verlinkt hast sagt gar, daß Kernel 4.19 den Resume-Prozeß vergeigt hat. Ich kann das aber nicht ganz glauben und vermute immer noch eine Fehlkonfiguration oder eine Fehler in der Grub-Konfiguration.

Welche Lösung jetzt für dich funktioniert, kann ich nicht voraussagen.

[EinSteiGer]

Werter MSfree,

besten Dank fürs Ausholen und die Infos.

In einigen Foren wird davon gesprochen, daß es im Zusammenhang von btrfs und Resume Probleme gibt, allerdings trifft das auf dich nicht zu, dein Root ist ja ext4.

Ja, nach dem, was ich unter https://wiki.ubuntuusers.de/Btrfs-Dateisystem/ gelesen habe, ist das auszuschließen.

In anderen Foren habe ich was über Kernelparameter gelesen, mit der die UUID der Swap-Partition dem Kernel übergeben wird, damit der Kernel möglichst früh an die Swap-Partition rankommt. In einigen Forenthreads wird empfohlen, die Kernelparameter in die Datei /etc/default/grub einzutragen und dann update-grub aufzurufen.

Unter https://wiki.ubuntuusers.de/GRUB_2/Konfiguration/ konnte ich nichts zur Swap finden, aber unter https://superuser.com/questions/383140/ ... ibernation war dann folgender Lösungsansatz zu finden:

Open up /etc/default/grub with root privledges and add GRUB_CMDLINE_LINUX="resume=/dev/sdXY" Where XY is the swap partition location, which can be found by sudo fdisk -l. It looks like you are using UUID instead and that's fine. /etc/default/grub only affects the current operating system so don't worry about every linux OS using grub to start using that swap. After finishing your edits, run sudo grub-mkconfig -o /boot/grub/grub.cfg (substitute grub.cfg with whatever file grub reads at boot, e.g. it may be named /boot/grub/grub.efi) to update your grub startup information with what you changed in /etc/default/grub

Ich bin nicht ganz so wie dort beschrieben vorgegangen, sondern folgendermaßen:
-- Ich habe mit nano /etc/default/grub als grub.old gesichert
-- In /etc/default/grub habe ich GRUB_CMDLINE_LINUX="" zu GRUB_CMDLINE_LINUX="resume=/dev/sda5" verändert.
-- Anschließend habe ich update-grub ausgeführt (und damit anders als im obigen Zitat grub aktualisiert). Hier bin ich mir am wenigsten sicher, ob diese Abweichung dazu führt, dass es nicht funktioniert hat.

Zum gewünschten Erfolg hat es nicht geführt. Hibernate führt beim Resuming weiterhin zum Black Screen.

Also habe ich die neue grub-Datei gelöscht, die grub.old wieder unter grub gespeichert und erneut update-grub ausgeführt.

Eine weitere Möglichkeit habe ich über die Dateien unter /etc/initramfs-tools gefunden, in die dann irgendwo die Swap-UUID eingetragen werden solle.

Unter habe ich in der Datei /etc/initramfs-tools/conf.d/resume bereits folgenden Eintrag vorgefunden:

Code: Alles auswählen

RESUME=UUID=e21bdfa0-1ff8-4009-a0b2-efda0f8e55a2

Damit bleibt mir einerseits zu sagen:
Herzlichen Dank, MSfree, für die Geduld und all die Infos und Tipps!

Und andererseits (mit Blick auf mein Problem):
Da steh' ich nun ich armer Tor...

Mit freundlichen Grüßen

Edit:
Wenn ich nun noch einmal auf den Bug-Report zurückkommen wollte: Welche logs bzw. Beschreibung wäre dazu nötig/sinnvoll und lässt sich das Problem überhaupt einem "Stück Software" zuordnen?
Ist da der Kernel oder systemd oder ... am Werk oder buggy oder liegt das am Zusammenspiel?

Und mit Blick auf mein Problem: Wie wahrscheinlich wäre das auch ohne systemd (z.B. mit Devuan) da? Oder anders könnte ein Umstieg mein Problem ggf. lösen?

[MSfree]

Ich bin nicht ganz so wie dort beschrieben vorgegangen, sondern folgendermaßen:
-- Ich habe mit nano /etc/default/grub als grub.old gesichert
-- In /etc/default/grub habe ich GRUB_CMDLINE_LINUX="" zu GRUB_CMDLINE_LINUX="resume=/dev/sda5" verändert.

Ich würde es noch mit

Code: Alles auswählen

GRUB_CMDLINE_LINUX="resume=UUID=e21bdfa0-1ff8-4009-a0b2-efda0f8e55a2"

(bitte kontrolliere die UUID nochmal selbst)
probieren. Die UUID ist einfach die sicherere Bank im Vergleich zum Device.

Wenn ich nun noch einmal auf den Bug-Report zurückkommen wollte: Welche logs bzw. Beschreibung wäre dazu nötig/sinnvoll und lässt sich das Problem überhaupt einem "Stück Software" zuordnen?

Im Grunde müßte die Logzeile:

Code: Alles auswählen

Feb 25 14:11:08 laptop kernel: PM: Image not found (code -22)

Für einen Bugreport ausschlaggebend sein. Vielleicht sollte man einfach noch 4 Zeilen vorher und nachher mitgeben.

Ist da der Kernel oder systemd oder ... am Werk oder buggy oder liegt das am Zusammenspiel?

Mein Gefühl sagt, daß der Kernel das Swapdevice nicht kennt. Entweder, der Startparameter, der das Swapdevice übergeben soll, ist syntaktisch falsch, was auf eine Fehlkonfiguration in Grub deuten würde. Oder der Kernel ignoriert den Parameter, was dann ein Kenerlbug wäre. Eine diesbezügliche Aussage für den Kernel 4.19 habe ich auch irgendwo im Internet gefunden. Hier könnte es helfen, einfahch mal einen aktuelleren Kernel aus den Backports zu installieren. Grub gibt dir dann die Auswahl, welchen der beiden installierten Kernel du booten möchtest. Du brauchst also keine Angst zu haben, dir ein nicht mehr bootendes System einzuhandeln.

Wie wahrscheinlich wäre das auch ohne systemd (z.B. mit Devuan) da? Oder anders könnte ein Umstieg mein Problem ggf. lösen?

Ich bin fast sicher, daß es nichts mit systemd zu tun hat. Der Kernel muß beim Starten die Swappartition kennen und einlesen, lange bevor der alte SysV-Init (Devuan) oder systemd (Debian) gestartet wird.

[EinSteiGer]

Werter MSfree,

besten Dank!

Ich würde es noch mit

Code: Alles auswählen

GRUB_CMDLINE_LINUX="resume=UUID=e21bdfa0-1ff8-4009-a0b2-efda0f8e55a2"

(bitte kontrolliere die UUID nochmal selbst)
probieren. Die UUID ist einfach die sicherere Bank im Vergleich zum Device.

Gesagt getan: Ich habe es noch einmal wie oben beschrieben probiert und zwar mit dem Eintrag:

Code: Alles auswählen

GRUB_CMDLINE_LINUX="resume=UUID=e21bdfa0-1ff8-4009-a0b2-efda0f8e55a2"

Der Vollständigkeit halber poste ich diesmal auch die folgende Ausgabe von update-grub (https://manpages.debian.org/stretch/gru ... .8.en.html)

Code: Alles auswählen

~# update-grub
GRUB-Konfigurationsdatei wird erstellt …
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-8-686-pae
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-8-686-pae
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-6-686-pae
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-6-686-pae
erledigt

Das Ergebnis: Alles wie gehabt: Resuming führt zum Black Screen
Also habe ich auch das wieder rückgängig gemacht.

Damit sehe ich gerade keine Chance dem Problem Herr zu werden.

Daher wende ich mich nun dem Melden des Fehlers zu (Bug-Report).
Dazu verwende ich entsprechend der Seite, die KH im (weit) oben verlinkten Thread (in dem es u.a. um den Report von Bugs geht) verlinkt hat, reportbug: https://www.debian.org/Bugs/Reporting

Mein erstes Problem ist schon, bei welchem Paket der Bug zu suchen ist.

Mein Gefühl sagt, daß der Kernel das Swapdevice nicht kennt. Entweder, der Startparameter, der das Swapdevice übergeben soll, ist syntaktisch falsch, was auf eine Fehlkonfiguration in Grub deuten würde. Oder der Kernel ignoriert den Parameter, was dann ein Kenerlbug wäre. Eine diesbezügliche Aussage für den Kernel 4.19 habe ich auch irgendwo im Internet gefunden. Hier könnte es helfen, einfahch mal einen aktuelleren Kernel aus den Backports zu installieren. Grub gibt dir dann die Auswahl, welchen der beiden installierten Kernel du booten möchtest. Du brauchst also keine Angst zu haben, dir ein nicht mehr bootendes System einzuhandeln.

Daher installiere ich zunächst einen älteren Kernel. Zur Zeit ist folgender Kernel in Benutzung:

Code: Alles auswählen

~$ uname -rm
4.19.0-8-686-pae i686

Als erstes habe ich dazu /etc/apt/sources.list auf stretch umgestellt, dann:

Code: Alles auswählen

~# apt-get update
Ign:1 http://ftp.fau.de/debian stretch InRelease
Holen:2 http://ftp.fau.de/debian stretch Release [118 kB]
Holen:3 http://ftp.fau.de/debian stretch Release.gpg [2.410 B]
Holen:4 http://ftp.fau.de/debian stretch/main i386 Packages [7.063 kB]
Holen:5 http://ftp.fau.de/debian stretch/main Translation-de_DE [830 B]
Holen:6 http://ftp.fau.de/debian stretch/main Translation-en [5.381 kB]
Holen:7 http://ftp.fau.de/debian stretch/main Translation-de [1.620 kB]
Es wurden 14,2 MB in 23 s geholt (615 kB/s).                                   
Paketlisten werden gelesen... Fertig

um anschließend via

Code: Alles auswählen

~# apt-get install linux-image-4.9.0-12-686-pae

den Kernel zu installieren. Den Output dazu kann man hier einsehen: 40994
Das Booten mit dem neuen alten Kernel hat problemlos funktioniert.
Der Versuch von Hibernation scheitert erneut beim Resuming.
Daher probiere ich es mit noch einem älteren Kernel:

Code: Alles auswählen

~# apt-get update
Holen:1 http://security.debian.org/debian-security jessie/updates InRelease [44,9 kB]
Holen:2 http://security.debian.org/debian-security jessie/updates/main i386 Packages [750 kB]
Holen:3 http://security.debian.org/debian-security jessie/updates/main Translation-en [383 kB]
Es wurden 1.178 kB in 3 s geholt (340 kB/s).                   
Paketlisten werden gelesen... Fertig

und

Code: Alles auswählen

~# apt-get install linux-image-3.16.0-10-686-pae

. Output siehe: 40995

Das Booten mit den neuen noch älteren Kernel klappt und auch das Resuming from hibernation ist hier erfolgreich!
Das stützt die Vermutung, dass es sich um einen Kernelbug oder einen Bug im Zusammenspiel mit dem Kernel handeln könnte. Somit ist anzunehmen, dass MSfrees "Gefühl" stimmt.

All das mündet dann in einem Bugreport, der künftig unter der Nummer #952631 (https://bugs.debian.org/cgi-bin/bugrepo ... bug=952631) läuft, so nicht doch noch ein Bug gefunden wird, den ich nicht gefunden habe, mit dem mein Problem identisch ist.

Dann bleibt nur noch eine Frage:
Wenn nun der 3er Kernel (linux-image-3.16.0-10-686-pae) kein Problem mit dem Ruhezustand hat, welche Probleme und Risiken würde ich mir einhandeln, wenn ich damit arbeiten würde?

Nochmals besten Dank an MSfree für die lange, geduldige Betreuung

Mit freundlichen Grüßen

[MSfree]

All das mündet dann in einem Bugreport, der künftig unter der Nummer #952631 (https://bugs.debian.org/cgi-bin/bugrepo ... bug=952631) läuft, so nicht doch noch ein Bug gefunden wird, den ich nicht gefunden habe, mit dem mein Problem identisch ist.

Ein Bugreport ist in diesem Fall sicherlich angebracht. Vielleicht hat das Problem ja auch nur eine kleine Ursache, z.B. eine vergessene Option beim Kompilieren des Kernels.

Mich hätte jetzt allerdings interessiert, ob das Problem mit dem 4.19er Debiankernel auch in der 64Bit-Version auftritt. Das kannst du mit dem D510 allerdings nicht testen, der Pentium-M ist in reiner 32Biter.

Dann bleibt nur noch eine Frage:
Wenn nun der 3er Kernel (linux-image-3.16.0-10-686-pae) kein Problem mit dem Ruhezustand hat, welche Probleme und Risiken würde ich mir einhandeln, wenn ich damit arbeiten würde?

Erstmal wahrscheinlich keine. Der 3.16er Kernel wird voraussichtlich noch bis Juni 2020 gepflegt und mit Updates bei Sicherheitslücken versorgt. Danach sollte man sich halt immer wieder selbst über eventuelle Sicherheitslücken informieren. Wenn da etwas wirklich kritisches auftritt, kannst du immer noch den Kernel wechseln.

Du könntest es natürlich auch mal mit einem 5.2er Kernel probieren, den man über Backports in Buster installieren kann:
https://www.taste-of-it.de/debian-buste ... stallieren

[EinSteiGer]

Werter MSfree,

Du könntest es natürlich auch mal mit einem 5.2er Kernel probieren, den man über Backports in Buster installieren kann:
https://www.taste-of-it.de/debian-buste ... stallieren

Ich habe den Kernel aus den backports getestet:

Code: Alles auswählen

~$ uname -rm
5.4.0-0.bpo.3-686-pae i686

Booten klappt, und der Ruhezustand samt Aufwachen (Resuming from hibernation) auch!

Ich bin begeistert!
Herzlichen Dank für den Tipp!!!

Mich hätte jetzt allerdings interessiert, ob das Problem mit dem 4.19er Debiankernel auch in der 64Bit-Version auftritt. Das kannst du mit dem D510 allerdings nicht testen, der Pentium-M ist in reiner 32Biter.

Das kann ich hier leider nicht testen, aber dazu meine Idee:
Schön wäre es, wenn -- jemand hier aus dem Forum, der Möglichkeit hat das zu testen -- das Ergebnis (positiv oder negativ) dann zum Bug-Report (Nummer #952631 [https://bugs.debian.org/cgi-bin/bugrepo ... bug=952631]) hinzufügen würde.

Somit bleibt mir nur noch den Post zu schließen und noch einmal "vielen Dank" an MSfree zu senden!

Mit freundlichen Grüßen