staging.inyokaproject.org

Hallo,

ich bin gerade dabei, kUbuntu von 18.04 auf 22.04 zu wechseln. Da das doch ein weiter Weg ist, habe ich beschlossen, eine Neuinstallation von 22.04 zusätzlich auf die Platte zu packen und von Hand mein "Zuhause" zu transferieren: Installation von Software, Konfiguration, etc.

Das klappt so weit auch ganz gut. Ein Problem ist hibernate. Das funktioniert unter 18.04 sehr gut (auf swap partition). Unter 22.04 sieht es erstmal gut aus. Hibernate scheint RAM auf swap partition zu schreiben (HD-LED zeigt das dafür übliche "Leucht-Muster". Aber beim Aufwecken wird nicht erkannt, dass sich das System im hibernate befindet. Es ist einfach ein Start. Die Dinge, die in https://wiki.ubuntuusers.de/Ruhezustand/ beschrieben sind, habe ich alle so durchgeführt.

Wo kann ich nach der Ursache suchen?

jochen-02 schrieb:

[…] Aber beim Aufwecken wird nicht erkannt, dass sich das System im hibernate befindet.

Ein Grund dafür ist, dass das für's Aufwecken zuständige Skript in der Ubuntu-Version von initramfs-tools zu doof ist und die Notation für die Partition mit dem Hibernation-Abbild nicht versteht. Dies betrifft auch die von initramfs-tools selbst empfohlene Methode über die Dateisystem-UUID.

[…] Wo kann ich nach der Ursache suchen?

Die Hintergründe, Diagnose-Prozeduren und auch Methoden zur Abhilfe werden hier beschrieben: Baustelle/Besser Schlafen

Momentan verwende ich Methode 3 mit dem zusätzlichen Skript /etc/initramfs-tools/scripts/local-premount/01-resume; dieses ist jedoch noch nicht für Swap-Dateien getestet!

Danke.

Methode 1 ist bei mir schon bei 18.04, dann auch bei 22.04 in Betrieb. /etc/default/grub:

GRUB_CMDLINE_LINUX="auto noplymouth cgroup_disable=memory resume=UUID=e15479d8-eda3-43bc-a27d-c5df9767d14f"

Methode 2 auch: /etc/initramfs-tools/conf.d/resume:

RESUME=UUID=e15479d8-eda3-43bc-a27d-c5df9767d14f

Da bleibt dann, Methode 3 zu versuchen. Mach' ich und gebe anschließend Laut. Wobei ja die UUID die Partitions-Identifikation sein sollte, die persistent und eindeutig ist, oder?

Das Problem war ein anderes (eigene Dämlichkeit). Ich habe, auch nach dem resume, das 22.04 aus dem zusätzlichen grub-Eintrag meines 18.04 gestartet. Als ich mal auf die Idee gekommen bin, das Boot-Menü des BIOS zu bemühen, hat hibernate/resume wie vorgesehen funktioniert.

Jetzt klemmt noch die Anmeldung nach resume. Der grafische Anmelde-Bildschirm erscheint, ich kann auch ein Passwort eingeben. Das wird allerdings immer abgewiesen. Ein "Neustart" der login screen mittels "anderer Benutzer" führt dazu, dass der Anmelde-Bildschirm einfriert. Über's Netz (ssh) ist der Rechner noch erreichbar und operabel, ein reboot -now führt aber dazu, dass der Rechner überhaupt nicht mehr reagiert.

Meine Frage wäre hier, warum ein richtiges Passwort für den richtigen Benutzernamen nicht funktioniert. Das ist ausschließlich nach resume so.

EDIT: Es ist sogar schlimmer: Nach resume aus hibernate friert die Sitzung ein. Ein per ssh durchgeführter reboot funktioniert auch nicht, obwohl die ssh-Sitzung normal reagiert.

Ich habe jetzt die Nase voll. Die NVidia-Grafikkarte ist 'rausgeflogen, die im alten i7 enthaltene Grafik-Einheit ist kräftig genug, ich habe auch kein echte Bedürfnis, mehr als 3 Displays anzuschließen.

Insofern: Zwar nicht gelöst, aber umgangen.

Zu dem Thema eine Nachfrage eines Laien:

Gibt es inzwischen eine Lösung für hibernate/resume für 22.04?

Ich habe bei 20.04 hibernate/uswsusp verwendet, aber das scheint es für 22.04 nicht mehr zu geben?

tembo schrieb:

Gibt es inzwischen eine Lösung für hibernate/resume für 22.04?

Ich habe bei 20.04 hibernate/uswsusp verwendet, aber das scheint es für 22.04 nicht mehr zu geben?

Ja, das ist bescheuert. Zum Glück funktionieren hier auch die entsprechende Pakete aus Ubuntu 20.04 uswsusp und hibernate. Die können mit dpkg nachinstalliert werden. Musst die Pakete eben dann von Hand 'runterladen.

Ah ja, prima, damit funktioniert ja Gott sei Dank wieder alles wie gehabt. Danke!