Bootfehler mit 2. verschlüsselter btrfs Festplatte sowie verschlüsselter SWAP Partition - ERROR: resume: hibernation device

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?

Hibernation Parameter in /etc/mkinitcpio.conf und /etc/default/grub entfernen, wie auch linux images und grub menu neu erstellen:

sudo update-grub
sudo mkinitcpio -P

Dann evtl. auch noch hier eine Datei erstellen:

sudo mkdir  -pv /etc/systemd/sleep.conf.d/
sudo nano /etc/systemd/sleep.conf.d/disable-hibernation.conf

mit dem inhalt:

AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

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 …)

Zu Deinem Lösungsvorschlag @megavolt
verschlusselte btrfs festplatte sowie verschlusselte swap partition error resume hibernation device
Da erscheint jetzt beim Booten

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.

Sollte alles nicht fruchten, dann müsste ich doch den sehr aufwendingen Weg zur Fehlerbeseitigung von Dir wählen:
How to enable btrfs with hibernation (error: resume: hibernation device)

Entweder du entfernst den Hook openswap aus /etc/mkinitcpio.conf oder setz die korrekten Werte in /etc/openswap.conf

Wenn ich in /etc/openswap.conf das hier aus lsblk -fi einsetze
gemäß dieser Anleitung openswap - error resume hibernation device

## 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!

Tief atmen

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?

In die etc/crypttab habe ich die swap eingetragen

luks-XXXXX UUID=XXXXX /crypto_keyfile.bin luks

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.

dm-crypt/Swap encryption

Hier scheint mir das Problem am nähesten gelöst. Doch ich verstehe es nicht ganz. Auch werden 2 verschiedene luks-ID für die gleiche (?) swap reingeschrieben.
openswap Konfiguration Error resume hibernation device

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

  1. Make hibernation swap device properly run while including
    /etc/openswap.conf
    /etc/crypttab
    /etc/mkinitcpio.conf
    /etc/default/grub
  2. 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.

gcc -O2 -o btrfs_map_physical btrfs_map_physical.c

Danke für einen Tipp, Rulinux

go here:

osandov-linux/btrfs_map_physical.c at master · osandov/osandov-linux · GitHub

Der Link ist im wiki.

Ich weiß nicht, wie man das runterladen kann - ich finde die Option nicht.

Also würde ich einfach den Programmtext kopieren
(also: markieren, kopieren … mit der Maus)
und dann in einem Editor einfügen
und die Datei als:

btrfs_map_physical.c

speichern

Dann sollte das Kommando funktionieren.

Genau das habe ich ja gemacht. Vermutlich liegt die Datei nicht im richtigen Verzeichnis bzw. wird sie nicht richtig addressiert!?

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 …

Super, damit und dem richtigen Verzeichnis hat es geklappt.
Zu dem Befehl zu 6.b.

sieht es bei mir so aus:

FILE OFFSET     FILE SIZE       EXTENT OFFSET   EXTENT TYPE     LOGICAL SIZE    LOGICAL OFFSET  PHYSICAL SIZE   DEVID       PHYSICAL OFFSET
0       134217728       0       regular 134217728       9793032192      134217728       1       10875162624
134217728       134217728       0       regular 134217728       9927249920      134217728       1       11009380352
268435456       134217728       0       regular 134217728       10061467648     134217728       1       11143598080
402653184       134217728       0       regular 134217728       10195685376     134217728       1       11277815808

Ich nehme dann für “Captured the first physical offset for the calculation” die Ziffern 134217728 und setze diese in /etc/default/grub ein?

Dass ich die grub nicht schrotte, hier die Frage:
Meine Original grub Zeile sieht so aus (UUID geändert natürlich)

GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=XXXX:luks-XXXX root=/dev/mapper/luks-XXXX apparmor=1 security=apparmor udev.log_priority=3"

Wäre es gemäß Anleitung so richtig?

GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=XXXX:luks-XXXX root=/dev/mapper/luks-XXXX apparmor=1 resume=/dev/mapper/luks-XXXX security=apparmor udev.log_priority=3 resume_offset=134217728"

In der “Musterlösung” ist der Aufbau nämlich ohne die Befehle apparmor und udev…

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.

… ich hatte ja zwar alles stehen gelassen, aber dazu später noch eine “Korrektur!” geschrieben …

PHYSICAL OFFSET in Deiner Ausgabe ist:
10875162624
diesen Wert durch die pagesize teilen -
getconf PAGESIZE
bei mir sind das
4096

resume_offset wäre also:
10875162624 / 4096 = 2655069

wenn Deine Pagesize auch 4096 ist.

Ich beziehe mich hier auf das Arch Wiki.

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 …

Vielen Dank. Das macht Sinn. Die /etc/default/grub fülle ich wie hier angegeben hoffentich korrekt.

GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=XXXX:luks-XXXX root=/dev/mapper/luks-XXXX apparmor=1 security=apparmor udev.log_priority=3" resume_offset=2655069"

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 … :wink:

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