Tja, wenn das alles noch unausgereift ist, dann überlege ich ernsthaft, ob ich auf die Hibernation (Ruhezustand) Funktion verzichte und halt nur den Standy-Modus (Bereitschaftszustand) nutze.
Wie muss ich die Einstellungen für das Swap-Laufwerk konfigurieren (Befehle), um vom Hibernation (Ruhezustand) Modus weg zu kommen und halt nur den Standy-Modus (Bereitschaftszustand) zu nutzen?
Vielleicht hilft Dir ja das hier weiter.
(Link zu einem anderen Thread hier im Forum)
Soweit ich das sehe ist das genau das Szenario was Du haben wolltest
und er hat beschrieben, wie er es gemacht hat.
(das allerletzte Kommando ist nicht völlig korrekt
und das hibernator script solltest Du nur einmal laufen lassen - sonst hast Du mehrfache Einträge in Deiner Grub Konfiguration.
ein backup des Originals hilft …)
Starting version 250.4-2-manjaro
Device does not exist or access denied
Error: resume: no device specified for hibernation
Die letzte Fehlermeldung kam bei mir sinngemäß als Warnung beim durchführen von sudo mkinitcpio -P
==> WARNING: consolefont: no font found in configuration
-> Running build hook: [encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
-> Running build hook: [openswap]
==> WARNING: swap_device variable is not set
==> WARNING: crypt_swap_name variable is not set
Bei mir ist die /etc/mkinitcpio.conf komplett leer.
## cryptsetup open $swap_device $crypt_swap_name
## get uuid using e.g. lsblk -f
swap_device=/dev/disk/by-uuid/XXX
crypt_swap_name=luks-YYY
kommt zwar keine diesbezüglich Fehlermeldung mehr, wenn ich sudo mkinitcpio -P laufen lasse, aber beim Booten kommt weiterhin eine Fehlermeldung.
Kommentiere ich alternativ die Zeile 52 in /etc/mkinitcpio.conf aus: # HOOKS="base udev autodetect modconf block keyboard keymap consolefont encrypt openswap resume filesystems"
so erscheint dieser Fehler, wenn ich sudo mkinitcpio -Plaufen lasse.
==> Building image from preset: /etc/mkinitcpio.d/linux515.preset: 'default'
-> -k /boot/vmlinuz-5.15-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.15-x86_64.img
==> ERROR: Invalid config: No hooks found
==> Building image from preset: /etc/mkinitcpio.d/linux515.preset: 'fallback'
-> -k /boot/vmlinuz-5.15-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.15-x86_64-fallback.img -S autodetect
==> ERROR: Invalid config: No hooks found
Irgendetwas ist bei den Einstellungen noch nicht ganz in Harmonie!
Sieht du die den Hook resume ? Der ist dafür zuständig beim Booten nach einen “Ruhezustand-Image” in der Swapfile zu suchen. Also, bitte entfernen, dann kommt da auch keine Meldung.
Lösche ich das Wort “resume” in der Zeile 52, so erscheint nach sudo mkinitcpio -P wieder der Fehler:
==> WARNING: Possibly missing firmware for module: qat_4xxx
-> Running build hook: [openswap]
==> WARNING: swap_device variable is not set
==> WARNING: crypt_swap_name variable is not set
Bin mir jetzt nicht ganz sicher, aber scheint mir, dass openswap nur benötigt wird, wenn man resume auf eine verschlüsselten Partition verwendet. Die Swap Partition wird ja ohnehin in /etc/cryptab aufgelistet oder?
wobei die luks und die UUID Ziffernfolge gleich ist, also nicht UUID des Containerinhalts. Das habe ich bei den anderen Partitionen auch so gemacht und es funktioniert fehlerfrei.
Es scheint mir auch so, aber ganz klar bin ich da auch nicht.
May I write this in English, in case @MaFo joins the discussion refering to his link solutions just above. It looks there are 2 alternatives for swap with btrfs on luks
Make hibernation swap device properly run while including /etc/openswap.conf /etc/crypttab /etc/mkinitcpio.conf /etc/default/grub
Deactivate hibernation swap and simply run it as swap without hibernation.
But none of them I can make run. The available solutions are really good but probably none of them is really fully completely summarized and explained.
Es sieht so aus, als sie der einzige Weg, um btrfs mit Luks Verschlüsselung und hibernation zum Laufen zu bringen mit swapfile funktioniert, nicht mit Swap-Partition.
Bevor ich die recht aufwendige Lösung von Megavolt schließlich doch noch teste, probiere ich auf Empfehlung von @bogdancovaciu diese Lösung noch aus: Linux laptop with encrypted disk and hibernation - #6 by jbkh
Doch ich hänge an Punkt 6 in der Anleitung fest. Leider antwortet der Autor nicht.
Ich habe die Datei btrfs_map_physical.c mit diesem Inhalt gemäß [dieser Anleitung]( Hibernation into swap file on Btrfs) gefüllt. Doch ich kann den folgenden Befehl nicht ausführen. Irgendetwas verstehe ich da offenbar nicht.
Das läßt sich ja leicht rauskriegen.
Es gibt kein richtiges oder falsches Verzeichnis … aber Du mußt wissen, wo sie ist.
Wohin hast Du die Datei denn gespeichert?
Dokumente wahrscheinlich - wenn Du nicht explizit was anderes angegeben hast.
Du mußt das Kommando in dem Verzeichnis ausführen, in dem die Datei ist.
Oder sie halt woanders hin kopieren … wohin Du sie gern haben willst.
Oder das Kommando modifizieren, so daß der Pfad zur Datei mit dabei ist …
Oder Du hast beim copy/paste nicht alles erwischt, oder zuviel - dann ist die Datei natürlich Müll und der compiler kann nichts damit anfangen.
Das einfachste ist, die “Raw” Ansicht dieser Datei auf der github Seite zu wählen,
dann kann man einfach alles markieren/kopieren (STRG+a) - da geht nichts verloren …
Ich lehne mich jetzt hier ganz schön aus dem Fenster
denn mit der Syntax/den Namensregeln für BTRFS volumes bin ich nicht vertraut.
aber:
dieser Pfad /swap/swapfile
scheint mir inkorrekt zu sein
Normalerweise ist das swap file direkt unter / (root)
also: /swapfile
keine Ahnung wie man das in BTRFS referenziert
Daß der Pfad falsch ist sieht man daran, daß die Ausgabe des Kommandos gar nicht den Wert enthält, den man dann zur Berechnung des
resume_offset
verwenden soll.
… unter der Spalte “Physical Offset” taucht bei Dir gar nichts auf. Die ist leer.
Korrektur!:
nein, die ist nicht leer - nur komisch verschoben
Ist also wahrscheinlich alles o.k.
Es ist der letzte Wert in der ersten Zeile:
10875162624
…
Du kannst das Risiko bzw. die Folgen eines Fehlers stark minimieren
indem Du einfach vorher ein backup der Datei machst - dann hast Du das Original und eine Referenz und kannst jederzeit zurück …
z.B.: cp -a /etc/default/grub /etc/default/grub.original
Ich persönlich habe auch Apparmor deaktiviert - d.h. diese beiden Einträge gibt es bei mir auch nicht.
Brauche ich nicht …
Der Pfad findet sich bei mir. Aber trotzdem stimmt irgendetwas da nicht in dem Ganzen (siehe meine Fragen von meinem letzten Beitrag oben).
Mir ist nebenbei aufgefallen, dass ich /home nicht als subvolume angelegt habe, was sicher besser gewesen wäre. Aber ich glaube, das ist kein wirkliches Problem.
Wenn ich das nicht gelöst bekomme, dann lasse ich das Problem. Leider.
Note the the first physical offset returned by this tool. In this example, we use xxxx. Also note the pagesize that can be found with getconf PAGESIZE.
To compute the resume_offset value, divide the physical offset by the pagesize. In this example, it is …
Die Befehle zu apparmor und udev lasse ich mal drin. Die scheinen gar nicht so verkehrt zu sein, wenn man z.B. unter udev in der Wiki nachsieht
Meine ultimative Sicherheits-Frage ist, bevor ich die /etc/default/grub ändere. Wenn das System crasht und ich nicht mehr booten kann, dann boote ich mit dem usb-live-stick system. Ich kann dann dort die /etc/default/grub durch die /etc/default/grub.bakinhaltlich ersetzen.
Doch wenn ich den Befehl sudo update-grubausführe, was muss ich beachten, damit die grub Datei von der Festplatten-Installation aktualisiert wird - nicht die vom live System?
Also wenn Du das wörtlich meinst und das genau so wie hier oben machst
dann ist 100% sicher, daß das nicht funktionieren wird.
Die UUIDs sollten dann doch besser die richtigen sein und nicht xxxx …
Um update-grub ausführen zu können mußt Du ein chroot in Dein nicht funktionables System machen - das korrigieren von /etc/default/grub reicht da nicht.
Kannst Du das wirklich?
Von Live USB booten ist ja kein Problem.
Aber Deine Platte ist ja verschlüsselt.
Weißt Du, wie Du die öffnen/entschlüsseln kannst
damit du dann schlußendlich manjaro-chroot
erfolgreich nutzen kannst?
manjaro-chroot erfordert, bei verschlüsselten Systemen … etwas Handarbeit