ubuntuusers.de

Hallo,

Nach vielen Fallen ist es mir gelungen, Hibernation hier zum Laufen zu bekommen.

Nach dem Aufwachen sehe ich allerdings nur statisches "Schneegestöber" auf dem Schirm. Ich denke, das muss an der Grafikansteuerung liegen.

Deshalb wollte ich hier noch mal die Grafikspezialisten fragen, ob Ihr noch eine Idee habt, was ich noch probieren kann.

Hier schon mal ein paar Daten:

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-159-generic
$ lspci -k | grep -EA4 'VGA|Display|3D'
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0c)
	Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx Series Graphics & Display
	Kernel driver in use: i915
	Kernel modules: i915
00:13.0 SATA controller: Intel Corporation Atom Processor E3800 Series SATA AHCI Controller (rev 0c)
	Subsystem: ASUSTeK Computer Inc. Atom Processor E3800 Series SATA AHCI Controller

Es wundert mich dass da was von Atom-Prozessor steht, denn unter "Über diesen Rechner" bekomme ich:

ASUS-F200M
1,6 GiB
Intel® Celeron(R) CPU N2815 @ 1.86GHz × 2
Intel® HD Graphics (BYT)
32-Bit Ubuntu 18.04 mit Unity Desktop

Dein System ist EOL. Bitte 20.04 nehmen, das läuft auf deinem System.

32-Bit Ubuntu 18.04 mit Unity Desktop

??? Wie bitte .... 😎

Atom hatte sich einen so schlechten Ruf erarbeitet, daß man den Markennamen Celeron wieder ausgegraben hat. "N", "Atom", "Celeron" - nix gut!

P.S. das ist ein Bay Trail, der ist Windows "exklusiv";

DJKUhpisse schrieb:

Dein System ist EOL. Bitte 20.04 nehmen, das läuft auf deinem System.

Eben nicht!

UlfZibis schrieb:

DJKUhpisse schrieb:

Dein System ist EOL. Bitte 20.04 nehmen, das läuft auf deinem System.

Eben nicht!

Doch, denn bei 18.04 sind universe und multiverse aus dem Support - Lubuntu beinhaltet Pakete daraus und viele andere Applikationen sind da auch drinnen. Man kann sowas nur sicher betrieben wenn man universe und multiverse aus den Quellen wirfst und dann alle Pakete deinstalliert, die nicht in den jetzt noch vorhandenen Quellen abrufbar sind.

UlfZibis schrieb:

Eben nicht!

Eben doch: https://lubuntu.me/bionic-eol/

Lubuntu 18.04 (Bionic Beaver) was released April 27, 2018 and will reach End of Life on Friday, April 30, 2021. This means that after that date there will be no further security updates or bugfixes released. We highly recommend that you re-install with 20.04 as soon as possible if you are still running 18.04.

After April 30th, the only supported releases of Lubuntu will be 20.04 (until April 2023), 20.10 (until July 2021), and 21.04 (until January 2022). All other releases of Lubuntu will be considered unsupported, and will no longer receive any further updates (or support) from the Lubuntu team.

Und es wird noch besser:

Note, due to the extensive changes required for the shift in desktop environments, the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install.

Der TS bekommt meines Wissens 64Bit nicht installiert. Der ist sich durchaus bewußt das Lubuntu 18.04 EoS ist.

Er ist seit 2012 dabei!

Wenn man bedenkt, daß bei Bay Trail die proprietäre Energiefunktion nie korrekt umgesetzt wurde, sind die Probleme mit dem Ruhezustand logisch. Das liegt nur sehr in der Vergangenheit.

Zu Bay Trail gibt es ja reichlich Threads. ☹

hakel2020 schrieb:

Der TS bekommt meines Wissens 64Bit nicht installiert. Der ist sich durchaus bewußt das Lubuntu 18.04 EoS ist.

Es gibt durchaus noch genügend Distributionen für 32Bit. Hier hat mal jemand eine Auflistung gemacht. Ein EOS-System zu betreiben muß nicht sein.

DJKUhpisse schrieb:

UlfZibis schrieb:

DJKUhpisse schrieb:

Dein System ist EOL. Bitte 20.04 nehmen, das läuft auf deinem System.

Eben nicht!

Doch, denn bei 18.04 sind universe und multiverse aus dem Support - Lubuntu beinhaltet Pakete daraus und viele andere Applikationen sind da auch drinnen. Man kann sowas nur sicher betrieben wenn man universe und multiverse aus den Quellen wirfst und dann alle Pakete deinstalliert, die nicht in den jetzt noch vorhandenen Quellen abrufbar sind.

Ich wollte nicht bestreiten, dass 18.04 in welcher Weise auch immer teilweise EOL ist, sondern dass das Grafik-Problem auf 20.04 nicht auftauchen sollte, denn das oben erwähnte "Bay Trail"-Problem wird ja nicht nur 18.04 betreffen.

Ich habe es nun aber mal doch mit dem 20.04 probiert, und zwar auch unter Unity. Zu meiner Überraschung funktioniert es damit. Nur was heißt das jetzt? Der Artikel wurde ja mit 18.04 getestet, als es noch nicht EOL war. Was einmal funktionierte, kann ja nicht durch später nicht vorhandene Updates zunichte gemacht werden.

Der Artikel wurde ja mit 18.04 getestet, als es noch nicht EOL war.

Richtig, aber es ist nicht definiert, unter welcher Kernel-Version und mit welcher GraKa. Das ist hier aber relevant. Daher kann es gut sein, dass es in Bestimmten Konstellationen nie zu Problemen kam, in anderen aber dazu kommt.

hakel2020 schrieb:

32-Bit Ubuntu 18.04 mit Unity Desktop

??? Wie bitte .... 😎

Bitte gönne mir Unity. Auf einem 1366x768 Display ist das platzverschwendende Lubuntu eine Zumutung.
Basis-Sytem ist Lubuntu-32 18.04 minimal (dürfe wohl ohne uni- und multiverse sein) mit aufgesetztem ubuntu-unity-desktop.
Wenn ich mich aber mit dem Displaymanager mit "Lubuntu" anmelde, taucht das gleiche Grafik-Problem auf. An Unity liegt's also nicht.

Atom hatte sich einen so schlechten Ruf erarbeitet, daß man den Markennamen Celeron wieder ausgegraben hat. "N", "Atom", "Celeron" - nix gut!

Aha, interessant.

hakel2020 schrieb:

Der TS bekommt meines Wissens 64Bit nicht installiert.

Doch, das geht schon, aber bei netto 1,6 MiB RAM renne ich damit zu schnell ins Swapping. Und dann ist aus die Maus.

Der ist sich durchaus bewußt das Lubuntu 18.04 EoS ist.

Richtig. Danke, und ich hoffe wir kommen so wieder zu eigentlichen Thema: Grafik-Problem.

Wenn man bedenkt, daß bei Bay Trail die proprietäre Energiefunktion nie korrekt umgesetzt wurde, sind die Probleme mit dem Ruhezustand logisch. Das liegt nur sehr in der Vergangenheit.

Was ist denn mit "Bay Trail" gemeint? Hab' ich zu meiner Schande noch nie gehört.

dingsbums schrieb:

Es gibt durchaus noch genügend Distributionen für 32Bit. Hier hat mal jemand eine Auflistung gemacht. Ein EOS-System zu betreiben muß nicht sein.

Interessant! Auf welcher davon kann man denn Unity nutzen, oder eine vergleichbar komfortable und vor allem platzschonende Oberfläche.

DJKUhpisse schrieb:

Richtig, aber es ist nicht definiert, unter welcher Kernel-Version und mit welcher GraKa. Das ist hier aber relevant. Daher kann es gut sein, dass es in Bestimmten Konstellationen nie zu Problemen kam, in anderen aber dazu kommt.

Das ist natürlich möglich. Und schade, wenn durch Updates später neue Bugs reingekommen sind.

Aber vielleicht finden wir ja noch des Pudels Kern, in Anbetracht dessen, dass Ubuntu-64 20.04 mit meiner "schrottigen" Hardware dann doch klarkommt. Im schlimmsten Fall muss ich halt auf Ruhezustand verzichten. Schade eigentlich, wenn aus Unachtsamkeit der Akku mal leer wird.

Hm, jetzt habe ich hibernate und uswsusp auf 20.04 mal wieder deinstalliert (per purge), /etc/default/grub wieder zurückgesetzt, update-grub ausgeführt und auch /etc/initramfs-tools/conf.d/resume gelöscht, um nochmal was anderes zu probieren. Und nun bekomme ich – auch nach Neustart – immer noch:

$ sudo update-initramfs -u -k all
[sudo] Passwort für ich: 
update-initramfs: Generating /boot/initrd.img-5.11.0-36-generic
I: The initramfs will attempt to resume from /dev/sda5
I: (UUID=b89855fb-dc4f-42fb-9ee0-053b7cb5c683)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-5.8.0-59-generic
I: The initramfs will attempt to resume from /dev/sda5
I: (UUID=b89855fb-dc4f-42fb-9ee0-053b7cb5c683)
I: Set the RESUME variable to override this.

$ echo $RESUME


$ sudo dpkg-reconfigure -pmedium uswsusp
dpkg-query: Paket »uswsusp« ist nicht installiert und es ist keine Information verfügbar
Verwenden Sie dpkg --info (= dpkg-deb --info) zum Untersuchen von Archiven.
/usr/sbin/dpkg-reconfigure: uswsusp ist nicht installiert

Wie werde ich das wieder los?

Gar nicht, weil die Meldung nichts mit diesen Paketen zu tun hat. Für das Aufwachen aus einem Suspend to Disk ist alleine der Kernel verantwortlich, jene Software übernimmt lediglich die Vorbereitungen dafür. Allein wegen dieser Trennung wird das Initramfs immer für das Aufwachen aus einem möglichen Suspend to Disk konfiguriert, weil der Kernel eben wissen will, auf welcher Partition er nach den möglicherweise gespeicherten Daten eines Suspends suchen soll. Zur Erinnerung: Zu diesem frühen Zustand beim Boot-Prozess hat der Kernel noch gar keinen Zugriff auf die Dateien in seinem eigenen Dateisystem, alles was er für den weiteren Startvorgang braucht wird vorab über das Initramfs in den RAM kopiert.

Das zuständige Skript sucht sich einfach selbstständig die nächste verfügbare Swap wenn keine dafür konfiguriert worden ist.