ubuntuusers.de

Warum werden hier 2 Swap-Partitionen verwendet?

Status: Ungelöst | Ubuntu-Version: Ubuntu 16.04 (Xenial Xerus)
Antworten |

Kellerkind_2009

Avatar von Kellerkind_2009

Anmeldungsdatum:
26. November 2009

Beiträge: 19614

Wohnort: Schleswig-Holstein

UlfZibis schrieb:

Und außerdem steht da noch, dass RESUME=UUID=<UUID> per GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub eingetragen werden muss.

Ähmmm wo steht das? 😲

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

Kellerkind_2009 schrieb:

UlfZibis schrieb:

Und außerdem steht da noch, dass RESUME=UUID=<UUID> per GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub eingetragen werden muss.

Ähmmm wo steht das? 😲

Sowohl in dem SwapFaq unter Making the swap partition work for hibernate (optional) auf Ubuntu.com, das Du mir verlinkt hast, als auch hier.

Allerdings frage ich mich, wie weit die Angaben im Artikel pm-utils überhaupt noch aktuell sind, denn ab Ubuntu 15.04 wird systemd für den Wechsel der Energiesparmodi verwendet.

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

Inzwischen kam ich auch mal in den Genuss der 4. noch fehlenden Kombination:

Filename				Type		Size	Used	Priority
/dev/sda14                             	partition	3145724	0	-2
/dev/sda13                             	partition	3145724	0	-1

Auch damit funktioniert der Ruhezustand nicht. Die Priorität scheint also schnurz zu sein, lediglich die Reihenfolge in /proc/swaps scheint zu bestimmen, wohin das SUSPEND-Image geschrieben wird.

Weiß jemand, wo das offiziell steht, dass immer sämtliche auffindbaren Swap-Partitionen automatisch verwendet werden, und welche Bewandnis dann der Eintrag in der fstab hat? Gibt es einen Schalter, mit dem man die automatische Verwendung verhindern kann?

Auf anderen Rechnern, wo ich den Ruhezustand lediglich per /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla aktiviert hatte, kann ich mich nicht erinnern, RESUME=UUID=<UUID> irgendwo eingetragen und sudo update-initramfs -u ausgeführt zu haben, um den Ruhezustand zum funktionieren gebracht zu haben. Alles irgendwie komisch hier.

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

Ich habe mir nun spaßeshalber mittels gzip -k -d initrd.img-4.4.0-77-generic.orig.gz (Kopie von /boot/initrd.img-4.4.0-77-generic in Home) und anschließendem Entpacken per Archivverwalter mal den Inhalt des initrd-Images angesehen. Darin finde ich die Datei conf/conf.d/resume mit dem Inhalt (das entspricht sda13):

RESUME=UUID=38e6603c-6b17-488a-9613-7341e8e89274

ohne dass ich jemals /etc/initramfs-tools/conf.d/resume angelegt (und existiert auch bisher nicht) und sudo update-initramfs -u ausgeführt hätte. Der Eintrag wird also automatisch, vermutlich aufgrund dem swap-Eintrag in der fstab beim Installieren von /boot/initrd.img-4.4.0-77-generic, angelegt.

Das Problem bleibt also: STD schreibt das SUSPEND-Image in eine beliebige Swap-Partition, wenn es mehrere gibt, und ich weiß bisher nicht, wie ich das steuern kann.

Wenn ich spaßeshalber sudo update-initramfs -u ohne /etc/initramfs-tools/conf.d/resume ausführe, wird in der /boot/initrd.img-4.4.0-77-generic in conf/conf.d/resume ein in meinem System ungültiger Eintrag erzeugt:

RESUME=UUID=93782983-700c-4084-84b1-5e3f8c1e788f

Damit kann natürlich gar nichts mehr funktionieren, also schnell /boot/initrd.img-4.4.0-77-generic wieder durch mein Backup wiederhergestellt.

rennradler

Anmeldungsdatum:
27. Februar 2010

Beiträge: 1833

Die 16.04 dürfte noch Hilbernate out-of-the-box unterstützt haben, da es da standartmäßig eine SWAP-Partition gab. Mit der 17.04 gibt es das nicht mehr wegen dem SWAP-File. Hab ich explizit ausprobiert. pm-hilbernate hat ihn zwar schlafen gelegt, aber beim Hochfahren hat er das Image nicht geladen. Erst nach dem Resume-Eitrag ging es. Es ist gut möglich, daß es in der 16.4 ein Skript gibt, daß das automatisch erledigt und das Dir jetzt in die Knie schießt. Mir ist da bei Ubuntu manchmal zu viel Black Magic drin.

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

rennradler schrieb:

UlfZibis schrieb:

Ja genau, und dann funktioniert die Aktualisierung leider nicht mehr, wie oben beschrieben.

Dann machst Du was falsch.

Hm, wäre nur interessant zu wissen, was ich da falsch mache. Und auf anderen Rechnern hat die Anleitung bei mir auch immer funktioniert.

Und außerdem steht da noch, dass RESUME=UUID=<UUID> per GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub eingetragen werden muss.

Du solltest bedenken, daß die Anleitungen von einer SWAP-Partition ausgehen und nicht von zwei, bei denen verschiedene Installationen im Hilbernate sind.

Auch wenn nur eine davon im Hibernate ist, entstehen Probleme. 1.) Die 2. hätte dann gar kein Swap mehr zur Verfügung. 2.) GRUB merkt leider nicht, dass z.B. die 2. Installation durch Akku-Leerlauf ins Hibernate gegangen ist, und bootet dann evtl. die 1. Installation, die dann a) kein Swap mehr zur Verfügung hätte und b) das Dateisystem korrumpieren kann, wenn es auf Dateien zugreift, die von der 2. Instanz in geöffnetem Zustand hinterlassen wurden.

Wenn Du schon solche Sachen weit ab vom Standart machst,

Na so weit von Standard ist das aber nun auch nicht weg, 2 Linux-Installationen auf einem Rechner zu haben.

mußt Du Dich da durchbeißen und den Mechanismus verstehen lernen.

Genau das ist ja mein Ansatz hier. Deshalb würde ich super gerne wissen:

  1. Wo und wie wird festgelegt, auf welcher Partition das SUSPEND-Image im Fall der Fälle abgespeichert wird, und wie kann man das konfigurieren?

  2. Wo und wie wird festgelegt, von welcher Partition das SUSPEND-Image im Fall des Aufwachens geladen wird, und wie kann man das konfigurieren?

  3. Für mich wäre es logisch, wenn die UUID-Einträge in initrd und in der grub.cfg nur einen Einfluss auf das Hochfahren – also 2. – hätten, denn im laufenden System werden diese Stellen ja nicht mehr genutzt.

Die GRUB_CMDLINE_LINUX_DEFAULT dürfte für beide Instanzen gelten, was Du aber nicht willst.

Das hätte ich auch mal so angenommen, doch probieren geht über studieren. Die damit definierten Kernel-Optionen werden tatsächlich nur in die grub.cfg-Einträge der aktuellen Partition (hier sda7) übernommen. Da hat also mal jemand richtig nachgedacht.

Das Thema GRUB ist ziemlich verzwickt. Die ganzen Skripte zur automatischen Generierung von grub.cfg sind nicht auf so ein Setup ausgerichtet. Da mußt Du händisch nacharbeiten.

Wie soeben bemerkt, ist es halb so schlimm. Die GRUB-Leute haben also ganz Arbeit gemacht, nur Canonical oder Debian nimmt's mit dem Ruhezustand nicht so genau.

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

rennradler schrieb:

Die 16.04 dürfte noch Hilbernate out-of-the-box unterstützt haben, da es da standartmäßig eine SWAP-Partition gab. Mit der 17.04 gibt es das nicht mehr wegen dem SWAP-File.

Ja es ist schon schade, dass Hibernate von Ubuntu so stiefmütterlich behandelt wird. Ist doch für Laptops eigentlich lebenswichtig, wenn der Akku mal überraschend leer geht.

Hab ich explizit ausprobiert. pm-hilbernate hat ihn zwar schlafen gelegt, aber beim Hochfahren hat er das Image nicht geladen. Erst nach dem Resume-Eitrag ging es.

Konntest Du dann den Resume-Eintrag auf das SWAP-File verweisen, oder musstest Du eine zusätzliche Swap-Partition anlegen?

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

Ich habe nun doch noch mal /etc/initramfs-tools/conf.d/resume angelegt mit folgendem Inhalt (das entspricht sda13):

RESUME=UUID=38e6603c-6b17-488a-9613-7341e8e89274

Wenn ich die nach sudo update-initramfs -u -k all dann neu entstandene initrd.img-4.4.0-77-generic nach Anfügen von .tar.gz entpacke, finde ich darin dann in conf/conf.d/resume einen in meinem System ungültigen Eintrag (vergleiche hier):

RESUME=UUID=6db4579b-bd05-4b9f-b243-db45da93ce0b

Damit kann das Hibernate ja nicht mehr funktionieren. Hilfe, wie kommt das denn. Kann das bitte mal jemand bei sich verifizieren?

Kellerkind_2009

Avatar von Kellerkind_2009

Anmeldungsdatum:
26. November 2009

Beiträge: 19614

Wohnort: Schleswig-Holstein

Magst du für mich mal deine default grub zeigen?

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

Kellerkind_2009 schrieb:

Magst du für mich mal deine default grub zeigen?

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
#GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=38e6603c-6b17-488a-9613-7341e8e89274 quiet splash"
GRUB_CMDLINE_LINUX=""

Kellerkind_2009

Avatar von Kellerkind_2009

Anmeldungsdatum:
26. November 2009

Beiträge: 19614

Wohnort: Schleswig-Holstein

Ist das jetzt die neue oder alte?

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
#GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=38e6603c-6b17-488a-9613-7341e8e89274 quiet splash"

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

Kellerkind_2009 schrieb:

Ist das jetzt die neue oder alte?

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
#GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=38e6603c-6b17-488a-9613-7341e8e89274 quiet splash"

Die neue.

Wenn ich die 2. statt der 1. Zeile aktiviere, komme ich so weit wie hier: https://forum.ubuntuusers.de/topic/akku-leer-systemzustand-verloren-std-unzuverla/#post-8849455

Wenn das sudo update-initramfs -u -k all Mist produziert, ist natürlich klar, warum man dann die Krücke über den Kernel-Parameter mittels GRUB braucht. Ich würde aber zu gerne mal wissen, ob der update-initramfs-Fehler auch bei anderen auftritt (vorher alle /boot/initrd.img-xyz sichern).

Kellerkind_2009

Avatar von Kellerkind_2009

Anmeldungsdatum:
26. November 2009

Beiträge: 19614

Wohnort: Schleswig-Holstein

Hmm,also auf meinem Laptop (16.04-64) Ist die RESUME=UUID=meine swap Und wird bei sudo update-initramfs -u auch nicht verändert.Default Grub ist GRUB_CMDLINE_LINUX_DEFAULT="noplymouth"

Sollte aber kein Unterschied zu GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" machen.

UlfZibis

(Themenstarter)

Anmeldungsdatum:
13. Juli 2011

Beiträge: 3134

Wohnort: Köln

Kellerkind_2009 schrieb:

Hmm,also auf meinem Laptop (16.04-64) Ist die RESUME=UUID=meine swap Und wird bei sudo update-initramfs -u auch nicht verändert.

Ui, das ging aber schnell. Du hast auch wirklich die entstandene /boot/initrd.img-xyz entpackt und untersucht, nicht etwa die /etc/initramfs-tools/conf.d/resume ?

Sollte aber kein Unterschied zu GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" machen.

Klar!

Kellerkind_2009

Avatar von Kellerkind_2009

Anmeldungsdatum:
26. November 2009

Beiträge: 19614

Wohnort: Schleswig-Holstein

Nein die /boot/initrd.img-xyz habe ich nicht entpackt und kontroliert,werde es aber mal aus Interesse machen 😉