laden des hibernation images crasht bei 90%

[Nygma]

hallo zusammen

bin ein vollgaslinuxnoob und neu hier an bord
aber ich hab mir echt mühe gegeben bevor ich hier nach hilfe schreie
hab viele stunden tage an trial und error hinter mir
darum seid bitte sanft zu mir

habe ein vollverschlüsseltes acer aspire one d270 das bei jedem kernel ob selbst kompliert oder aus den repositories beim resume abstürzt.

einzig und alleine kernel 3.16.0-4-586 aus den old stable repositories funktioniert absolut 100% zuverlässig

hab mittlerweile alle experimente durch die ich via suchmaschine finden konnte:

mit und ohne pm-utils & uswsusp
grub, fstabs, /etc/initramfs-tools/conf.d/resume mit mapper oder UUID
grub mit video=SVIDEO-1:d acpi=off maxcpus=1
mit und ohne mehrkern optionen gebaute kernel 3.x und 4.x kernel jeglicher couleur

scheinbar ist das problem bei 32bit systemen sehr häufig und ist offensichtlich immer noch nicht gefixt???!

bitte, bitte helft mir wenn ihr irgendeine idee habt oder auch wenn ihr sicher wisst dass ich meine zeit hier nur verschwende.

vielen dank




cat /proc/cpuinfo
free -m
swapon -s
lspci -nnk | grep "VGA\|'Kern'\|3D\|Display" -A2
journalctl -b -p err
dmesg | grep -i ACPI
cat /etc/apt/sources.list

----> 40177 <----

[NAB]

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?

[Nygma]

erst mal vielen herzlichen dank für deine schnelle antwort tut echt gut, denn es ist die hölle sich als linux neuling und einzelkämpfer mit solchen problemen rumzuschlagen

neuestes bios (v1.1 von 2013) ist installiert.
intel-microcode aus den repositories ist installiert.

den verlinkten artikel habe ich tatsächlich vor ewigkeiten schon einmal ersuchmaschint aber es überfordert mich völlig mich da einzuarbeiten. fängt bei fehlenden englischvokabeln an und hört beim komplett fehlenden hintergrundwissen auf

ich erinnere mich den punkt "2.13 disk mode" versucht zu haben. leider ohne erfolg

das image wird im swap gespeichert:

Code: Alles auswählen

NAME                FSTYPE  LABEL UUID                                   MOUNTPOINT
sda                                                                      
├─sda1              ext2          xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   /boot
├─sda2                                                                   
└─sda5              crypto_       yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy   
  └─sda5_crypt      LVM2_me       zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz 
    ├─xxx--vg-root  ext4          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   /
    └─xxx--vg-swap_1
                    swap          bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb   [SWAP]

gebt bescheid falls noch eine wichtige information fehlen sollte.
vielen dank im voraus

[NAB]

Du kannst es noch mit "no_console_suspend" (2.2) versuchen. Dabei lässt er den Bildschirm so lange wie möglich leben - eventuell siehst du da, ob es schon beim Suspend Fehler gibt.

Mir hat pm_async (2.7) geholfen, aber das war ein Suspend-to-Ram Problem. Ich bin mir nicht sicher, wie das bei Suspend-to-Disk helfen soll, aber ein Versuch kostet ja nichts.

Und wie da auch steht ... es sind häufig Treiber, also Kernelmodule, die Ärger machen. Es ist zwar hässlich, mit nomodeset modprobe.blacklist=gma500 zu booten, aber einen Versuch ist es wert. Ebenso kannst du andere verdächtige Module testweise blacklisten.

Mir ist nicht so ganz klar, wie im Moment mit Spectre und Meltdown verfahren wird, aber eigentlich müsste KPTI in sämtliche alten Longter-Kernel zurückportiert werden. Und das könnte jede Menge Ärger machen. Ein Versuch mit "pti=off" kann also auch nicht schaden.

Ach ja ... klappt denn Suspend-to-Ram bei dir?

Was ich längst gemacht hätte wäre ein Test mit memtest86+.

Und was ich ausprobiert hätte wäre, ob ein Suspend auf eine andere unverschlüsselte Swap-Partition klappt - einfach aus Neugier. Zur Not auf einen USB-Stick.

Dein Text macht es übrigens schwer dich einzuschätzen ... wer sich als "Vollgaslinuxnoob" vorstellt und ein paar Zeilen später von zig selbst-kompilierten Kerneln erzählt, der hinterlässt so einen zwiespältigen Eindruck zwischen "Holla, der ist aber fit!" und "Na? Wieviele Fehler mag der gemacht haben?". Das kriegen wir aber eh nicht rekonstruiert ... aber vielleicht kannst du ja in kritischer Retrospektive mal überlegen, welche Versuche Murks gewesen sein könnten und eine Wiederholung lohnen. Selbst-Kompilieren halte ich für übertrieben, aber ein paar Versuche mit fertigen Debian-Kernel kannst du ruhig machen, bis hin zu den allerneusten aus Testing.

Versuchen würde ich nur noch:
systemctl hibernate
bzw.
echo disk > /sys/power/state
(macht beides das gleiche). Alles andere wird nicht mehr weiterentwickelt.

Was ich übrigens auch erst gerade eben erfahren habe, aus diesem Artikel:
https://lwn.net/Articles/701639/
Bei einem Resume-from-Hibernate lädt zwar erst der neue Kernel (logisch), aber der setzt dann wirklich nach und nach den alten Kernel aus dem Swap-Image wieder in Betrieb. Du hast es also mit zwei Kerneln mit jeweils ihren eigenen Bootoptionen und geladenen Treibern zu tun.

[Nygma]

wirklich vielen dank dass du dir zeit nimmst

bin zwar absoluter linuxnoob aber kenne mich ein wenig mit osx aus. das terminal macht mir also keine angst und ich habe unglaublich viel zeit in recherche sowie trial and error verschwendet die letzten wochen. habe mit sicherheit vieles falsch gemacht und war selbstverständlich völlig unstrukturiert auf der fehlersuche

habe heute mit dem repositories kernel 4.9.0-6-686-pae getestet - mit den optionen: no_console_suspend initcall_debug ignore_loglevel.

viel information - einiges was wichtig sein könnte mit dem ich aber nichts anfangen kann. sowas in der art kommt im kern.log hin und wieder beim komprimieren zwischen 60-90%:
perf: interrupt took too long (3233 > 3156), lowering kernel.perf_event_max_sample_rate to 61750

wie copy paste ich euch die resume-momente am elegantesten? die sind ja nicht persistent wenn ich das richtig verstanden habe?

pm_async habe ich versucht - leider ohne erfolg.

habe auch mit nomodeset modprobe.blacklist=gma500_gfx modprobe.blacklist=gma500 gebootet - ohne modul genau das gleiche verhalten wie mit dem modul

zu spectre und meltdown - die probleme gab es schon vor den spectre und meltdown patch-versuchen aber ich werde es wohl zum debuggen einfach auslassen.

suspend-to-ram funktioniert aber ich habe oft mouse-lags und dns-probleme nach dem resume.
akku-technisch ist es für mich leider auch keine option zu suspend-to-disk.

habe einen usb-stick linux-swap formatiert und seine UUID wie gehabt in grub, fstab und /etc/initramfs-tools/conf.d/resume eingetragen - genau das gleiche problem.

die stretch backports kernel 4.xx ergaben das gleiche problem und die lan-, wlan-treiber streikten bzw. liessen sich nicht bauen.

was ist denn an 3.16.0-4-586 so besonders, dass es funktioniert und wie bekomme ich den hibernation-tauglich nachgebaut mit 3.16.55 - oder noch viel besser mit 4.x?

was wäre den eine gute möglichkeit um leute zu finden die sich schon vor mir mit dem gleichen setup rumgeärgert haben?

gebt mir anweisungen was ich weiter machen könnte und ich versuche es am besten auf dau-level erklären den memtest86+ versuche ich vielleicht heute nacht noch

[NAB]

Ah ... den Text hier habe ich schon letztes mal gesucht:
https://www.kernel.org/doc/Documentatio ... ugging.txt
Ich habe keine Ahnung, wie aktuell der noch ist, aber Versuch macht kluch

Hast du eigentlich mal 64 Bit versucht? So richtig klar ist mir die Prozessorbeschreibung nicht, aber Fedora meint, es geht auch mit 64 Bit:
https://fedoraproject.org/wiki/Acer_Aspire_One
(Die berichten aber auch von Problemen bei Suspend/Hibernate)

viel information - einiges was wichtig sein könnte mit dem ich aber nichts anfangen kann. sowas in der art kommt im kern.log hin und wieder beim komprimieren zwischen 60-90%:
perf: interrupt took too long (3233 > 3156), lowering kernel.perf_event_max_sample_rate to 61750

Die Meldung ist eigentlich völlig harmlos ... der Kernel sagt dir, dass er gerade zu viel zu tun hat, um sich um "perf" zu kümmern. perf ist ein Analysewerkzeug, also nichts Wichtiges. Interessant ist, warum diese Meldung mehrmals nacheinander kommt ... das klingt, als ob der Prozessor immer mehr zu tun und immer weniger Zeit hat. Aber das Hibernation-Image einzulesen müsste doch konstanten Aufwand verursachen. Sag mal, kann das sein, dass dein Prozessor sich schlicht überhitzt? Lebt der Lüfter noch?

wie copy paste ich euch die resume-momente am elegantesten? die sind ja nicht persistent wenn ich das richtig verstanden habe?

Stimmt. Wenn er nicht mal den richtigen Kernel laden kann, kann er auch nichts irgendwo hinschreiben. Solange du da nichts auffälliges siehst, macht's aber auch keinen Sinn. Und sonst ... Foto? (Okay, einige werden weinen;)

was ist denn an 3.16.0-4-586 so besonders, dass es funktioniert und wie bekomme ich den hibernation-tauglich nachgebaut mit 3.16.55 - oder noch viel besser mit 4.x?

Öhm ... dass die Debian-Kernelkonfiguration unter /boot/config-* liegt, weißt du? Die könnte man natürlich auf 4.x anwenden ... und gucken, was passiert.

Und soweit ich weiß, bietet Slackware noch i586 Kernel an:
https://mirrors.slackware.com/slackware ... -14.2-iso/

[KP97]

Ich erwähne auch noch das Debian Archiv:
http://snapshot.debian.org/binary/?cat=l

[Nygma]

hallo ihr lieben

der memtest86+ ergab keine probleme.

den text von kernel.org hatte ich schon durchgearbeitet.

64 bit wäre warscheinlich eine gute lösung aber das läuft auf meinem lapi nicht.
denke das ist ein 32 bit kernel bug um den sich einfach niemand mehr kümmert

die perf meldung taucht selten und wenn dann nur 1x auf.
die temperatur habe ich geprüft. alles im grünen breich.

hab heute keine grosse zeit gefunden. versuche aber morgen mal ein resume photo zu erstellen, auch wenn da auf den ersten blick nicht wirklich etwas sinnvolles oder auffälliges zu sehen ist.

ja ich hab viel gelesen was das kernel bauen angeht. hab auf basis von der 3.16.0-4-586 config auch schon so einige experimente mit dem 4.9 quellcode gestartet. der resume funktioniert auch hier nicht. mit 4.9 bin ich erst mal durch. ich teste demnächst nochmal systematisch ein paar andere.

slackware? ne andere linux distro zum 586 kernel testen wäre natürlich auch noch ne alternative wenn mir das selbst kompilieren irgendwann zu sehr auf die nerven geht.

@KP97 was genau meinst du mit dem verweis auf das debian archiv? ich verstehe nicht ganz. das ist doch ganz offiziell oder? übersehe ich etwas? wie gesagt, ich habe ja schon erfolgreich mit dem OLD stable kernel 3.16.0-4-586 experimentiert.


liebe grüsse und vielen dank für die unterstützung

[MSfree]

64 bit wäre warscheinlich eine gute lösung aber das läuft auf meinem lapi nicht.

Woher willst du das wissern?
Die CPU ist jedenfalls ein 64Bit-fähiger Atom N2600.

[NAB]

Unter dem Link von KP97 findest du zum Beispiel noch einen linux-image-4.3.0-rc3-586 (das neuste, was ich für 586 entdecken konnte).

[KP97]

@KP97 was genau meinst du mit dem verweis auf das debian archiv? ich verstehe nicht ganz. das ist doch ganz offiziell oder?

Klar ist das ein offizielles Repo. Bei Snapshot handelt es sich im das Debian-Archiv, in dem sich sämtliche jemals gebaute Pakete zu allen Zweigen und Versionen befinden.
Da kann man unbesorgt sein, abhängige Pakete mußt Du u.U. aber selber nachladen.

[Nygma]

kleiner zwischenbericht zu später stunde

hab nach langem hin und her einen 4.4.1204.4.120 kernel gebastelt bekommen mit dem wirklich alles läuft - usb, wlan uuund sogar auch hibernation

keine chance dagegen mit 4.9, 4.14, 4.15!
definitiv 'nur' ein kernel bug.

der prozessor ist 64bit aber ich könnte schwören installieren hat damals mit 64bit mint nicht funktioniert. umziehen mag ich jetzt auch nicht mehr wirklich und 2gb ram bringen es für 64bit ja eh nicht. was wäre denn die einfachste möglichkeit hibernation mit EINEM debian live 64bit stick zu testen?

ist echt traurig das kein funktionierender kernel in den stretch stable repositories ist und es scheinbar auch keinen kümmert. würde glaube ich schon gerne dran bleiben und einen bugreport einreichen wenn ihr mir helft



vielen dank fürs händchenhalten