Du bist nicht angemeldet.

#1 07.10.2019 15:50:29

prototyp_002
Mitglied

Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

Guten Tag liebe Community!

[spoiler]Sollte dieses Problem in der Form schonmal aufgetreten sein, dann bitte ich um Entschuldigung. Ich habe einige Threads durchgelesen und mich mit Google und der internen Forumsuche bemüht, mir selbst auszuhelfen, es nur leider nicht geschafft.
Ich bin vor kurzer Zeit von Windows auf Arch umgestiegen, nachdem ich einiges vorab in einer VM getestet hatte und ein paar praktische Tipps in der Umsetzung von Bekannten bekommen habe.
Von mir werden 3 Partitionen genutzt:
sda1 als unverschlüsselte Boot-Partition
sda2 als btrfs fs. (root)
sda3 als swap-Partition[/spoiler]

Das Anmelden/Entschlüsseln der Root-Partition hat funktioniert. Nachdem ich hierfür die Passworteingabe hinter mir habe, hat er Probleme mit dem hook "openswap". Hier werden dann ganz viele Wirre mögliche Argumente angezeigt, welche man beim cryptsetup verwenden könnte. Allerdings finde ich bei mir keinen Syntaxfehler und wenn ich den Befehl manuell im Terminal ausführe, funktioniert er einwandfrei:

cryptsetup open --key-file /etc/keyfile-cryptSWAP /dev/sda3 cryptSWAP

- wodurch ich mir sicher bin, dass das keyfile per /urandom richtig erstellt wurde und auch luksAddKey richtig ausgeführt wurde. Im keyslot 0 befindet sich mein manuell eingetragenes Passwort, in keyslot 1 das keyfile.


im folgenden einige meiner Konfigurationen:

[root@Superuser-Playground hooks]# cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/mapper/cryptROOT UUID=36e88f73-d0e4-4453-bd22-c89744210072
LABEL=ROOT              /               btrfs           rw,noatime,nodiratime,compress=lzo,ssd,space_cache=v2,subvolid=256,subvol=/@root,subvol=@root       0 0

# /dev/sda1 UUID=af2d2c3a-6137-49e4-bd59-fffa1d546464
LABEL=BOOT              /boot           ext4            rw,relatime     0 2

# /dev/mapper/cryptROOT UUID=36e88f73-d0e4-4453-bd22-c89744210072
LABEL=ROOT              /home           btrfs           rw,noatime,nodiratime,compress=lzo,ssd,space_cache=v2,subvolid=258,subvol=/@home,subvol=@home       0 0


# /dev/mapper/cryptROOT UUID=36e88f73-d0e4-4453-bd22-c89744210072
LABEL=ROOT              /.snapshots     btrfs           rw,noatime,nodiratime,compress=lzo,ssd,space_cache=v2,subvolid=260,subvol=/@snapshots,subvol=@snapshots     0 0

[...]

# /dev/mapper/cryptSWAP UUID=fc38fbe4-2ac5-4deb-9f9a-43190314b189
LABEL=SWAP              swap            swap            defaults        0 0

[babo@Superuser-Playground ~]$ lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda             8:0    0 931,5G  0 disk 
├─sda1          8:1    0   512M  0 part  /boot
├─sda2          8:2    0   926G  0 part 
│ └─cryptROOT 254:0    0   926G  0 crypt /vm-zoggn
└─sda3          8:3    0     5G  0 part 
  └─cryptSWAP 254:1    0     5G  0 crypt [SWAP]
sr0            11:0    1  1024M  0 rom 

[babo@Superuser-Playground ~]$ df -Th
Dateisystem           Typ      Größe Benutzt Verf. Verw% Eingehängt auf
dev                   devtmpfs  3,5G       0  3,5G    0% /dev
run                   tmpfs     3,5G    932K  3,5G    1% /run
/dev/mapper/cryptROOT btrfs     926G    3,3G  921G    1% /
tmpfs                 tmpfs     3,5G     99M  3,4G    3% /dev/shm
tmpfs                 tmpfs     3,5G       0  3,5G    0% /sys/fs/cgroup
/dev/mapper/cryptROOT btrfs     926G    3,3G  921G    1% /home
[...]
/dev/mapper/cryptROOT btrfs     926G    3,3G  921G    1% /var/cache/pacman/pkg
/dev/mapper/cryptROOT btrfs     926G    3,3G  921G    1% /.snapshots
/dev/sda1             ext4      488M     61M  392M   14% /boot
tmpfs                 tmpfs     3,5G    8,0K  3,5G    1% /tmp
tmpfs                 tmpfs     713M     12K  713M    1% /run/user/1000

[babo@Superuser-Playground ~]$ free -h
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       7,0Gi       1,3Gi       4,8Gi       120Mi       821Mi       5,3Gi
Swap:         5,0Gi          0B       5,0Gi

[root@Superuser-Playground hooks]# blkid
/dev/sda1: LABEL="BOOT" UUID="af2d2c3a-6137-49e4-bd59-fffa1d546464" TYPE="ext4" PARTUUID="de6696a4-01"
/dev/sda2: UUID="1457d621-9039-4a49-93e6-e48d70841d6d" TYPE="crypto_LUKS" PARTUUID="de6696a4-02"
/dev/sda3: UUID="8fc53169-5cee-43c4-8fb7-6219fa16a2f1" TYPE="crypto_LUKS" PARTUUID="de6696a4-03"
/dev/mapper/cryptROOT: LABEL="ROOT" UUID="36e88f73-d0e4-4453-bd22-c89744210072" UUID_SUB="1e90910c-e929-4b5b-8dc3-1fa4cb429e75" TYPE="btrfs"
/dev/mapper/cryptSWAP: LABEL="SWAP" UUID="fc38fbe4-2ac5-4deb-9f9a-43190314b189" TYPE="swap"


[root@Superuser-Playground hooks]# cat /etc/default/grub
# GRUB boot loader configuration

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=fc38fbe4-2ac5-4deb-9f9a-43190314b189"
GRUB_CMDLINE_LINUX="cryptdevice=UUID=1457d621-9039-4a49-93e6-e48d70841d6d:cryptROOT"
GRUB_ENABLE_CRYPTODISK=y
......

[root@Superuser-Playground hooks]# cat /etc/initcpio/hooks/openswap
run_hook ()
{
   ## to avoid race conditions
   x=0;
   while [ ! -b /dev/mapper/cryptROOT ] && [ $x -le 10 ]; do
   x=$((x+1))
   sleep .02
   done
   ## race finished

   mount /dev/mapper/cryptROOT /mnt
   cryptsetup open --key-file /etc/keyfile-cryptSWAP /dev/sda3 cryptSWAP
   umount /mnt
}

[root@Superuser-Playground hooks]# cat /etc/initcpio/install/openswap
build ()
{
    add_runscript
}
help ()
{
cat<<HELPEOF
   This opens the swap encrypted partition /dev/sda3 in /dev/mapper/cryptSWAP
HELPEOF
}

[root@Superuser-Playground hooks]# cat /etc/mkinitcpio.conf
...
HOOKS=(base udev autodetect keymap keyboard modconf block encrypt openswap resume filesystems fsck)
...


_______


bei den Befehlen
grub-mkconfig -o /boot/grub/grub.cfg
sudo mkinitcpio -p linux
sind keine Probleme aufgetreten.
Ich bin mir relativ sicher, dass das Problem in Hook /etc/initcpio/hooks/openswap besteht, denn bis dahin scheint er ja zu kommen.

Ich habe diese Seite als Vorbild benutzt: https://wiki.archlinux.org/index.php/Dm … tcpio_hook
nur haben die Aktionen mit mkdir für mich keinen Sinn gemacht, weshalb ichs einfach direkt auf /mnt gemountet habe.
Ebenso wusste ich nichts mit der Zeile:
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro
anzufangen und wo oder ob ich diese irgendwo einzufügen habe.

zuvor hatte ichs mit dem Packet mkinitcpio-openswap versucht, allerdings hat er dort nie den Schlüssel gefunden und ich musste auch jedesmal 90s+ warten.


Ich wollte die einzelnen einträge in [spioler] packen, allerdings scheint diese Option deaktiviert.
Vielen Dank im Vorraus!

proto

Beitrag geändert von prototyp_002 (11.10.2019 11:59:08)

Offline

#2 07.10.2019 16:49:39

GerBra
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

Hallo und willkommen!

prototyp_002 schrieb:

Das Anmelden/Entschlüsseln der Root-Partition hat funktioniert. Nachdem ich hierfür die Passworteingabe hinter mir habe, hat er Probleme mit dem hook "openswap". Hier werden dann ganz viele Wirre mögliche Argumente angezeigt, welche man beim cryptsetup verwenden könnte. Allerdings finde ich bei mir keinen Syntaxfehler und wenn ich den Befehl manuell im Terminal ausführe, funktioniert er einwandfrei:

cryptsetup open --key-file /etc/keyfile-cryptSWAP /dev/sda3 cryptSWAP

- wodurch ich mir sicher bin, dass das keyfile per /urandom richtig erstellt wurde und auch luksAddKey richtig ausgeführt wurde. Im keyslot 0 befindet sich mein manuell eingetragenes Passwort, in keyslot 1 das keyfile.

Ohne mich mit diesem Setup zu 100% auszukennen vermute ich trotzdem (wie du auch) dann einen Fehler im Hook. Etwas gekürzt von mir:

prototyp_002 schrieb:

[root@Superuser-Playground hooks]# cat /etc/initcpio/hooks/openswap
run_hook ()
{
...
   mount /dev/mapper/cryptROOT /mnt
   cryptsetup open --key-file /etc/keyfile-cryptSWAP /dev/sda3 cryptSWAP
   umount /mnt
}

Nach meinem Verständnis müßte das cryptsetup so lauten:

...
cryptsetup open --key-file /mnt/etc/keyfile-cryptSWAP /dev/sda3 cryptSWAP
...

da du ja die Root-Partition (auf dessen Dateisystem das Keyfile liegt) zum Aufschließen temporär nach /mnt einhängst und wieder aushängst.

Zu [spoiler] bzw. Formatierungen:
Für Befehlsdarstellung und Befehlsausgaben verwenden wir hier code-Tags, siehe auch die Hilfe unter
https://bbs.archlinux.de/help.php#bbcode

Offline

#3 07.10.2019 17:21:20

frostschutz
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

da du ja die Root-Partition (auf dessen Dateisystem das Keyfile liegt) zum Aufschließen temporär nach /mnt einhängst und wieder aushängst

...und da schläft noch ein anderes Problem, das Root-Dateisystem ist ja noch gemountet beim Suspend, streng genommen darf es vor dem Resume nicht noch einmal gemountet werden.

Der Mount muss mindestens mit dem readonly Flag erfolgen. Besser noch das Swap per Passphrase aufmachen damit es da überhaupt keine Abhängigkeit gibt.

Keyfile auf Rootfs fürs Resume-Swap ist ein Holzweg.

Beitrag geändert von frostschutz (07.10.2019 17:25:23)

Online

#4 07.10.2019 21:37:54

prototyp_002
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

GerBra schrieb:

Hallo und willkommen!

Zu [spoiler] bzw. Formatierungen:
Für Befehlsdarstellung und Befehlsausgaben verwenden wir hier code-Tags, siehe auch die Hilfe unter
https://bbs.archlinux.de/help.php#bbcode

Ja genau, aus der Seite hab ich mir die Fettschrift "besorgt". Ist schon ein wenig her, dass ich in Foren unterwegs war. Hatte mich nur gemeint zu erinnern, dass es in dem ein oder anderen Forum auch eine Variante gab, in dem man so ein Show/Hide Menu per Klick einfügen konnte.


frostschutz schrieb:

...und da schläft noch ein anderes Problem, das Root-Dateisystem ist ja noch gemountet beim Suspend, streng genommen darf es vor dem Resume nicht noch einmal gemountet werden.

Der Mount muss mindestens mit dem readonly Flag erfolgen. Besser noch das Swap per Passphrase aufmachen damit es da überhaupt keine Abhängigkeit gibt.

Keyfile auf Rootfs fürs Resume-Swap ist ein Holzweg.


Ich habe jetzt noch diverse Versuche gestartet, die Befehle leicht abzuändern. Allerdings wirft der mir immer wieder andere Fehlermeldungen raus: kein Mountpoint gefunden, falsche Mountoptionen ausgewählt/nicht verfügbar, Key nicht gefunden.
Nach 3 Tagen hab ich nun keine Lust mehr. Ich werd die Hooks "openswap" und "resume" raus nehmen und mich bei Zeiten mal einlesen, wie ich denn selbst kleine Programme schreiben kann und dann nach dem Bootprozess mit einem Befehl den Swap nachträglich einhänge.

Allerdings würde ich gerne das Problem verstehen: das Problem besteht darin, dass das System anscheinend noch nicht voll funktionsfähig ist? Wenn ich später im Terminal den Swap aufschlüssel, ist das doch auch kein Problem, dass die Root-Partition eingehangen ist.
Müsste ich, damit das klappen würde, ein 4. Partition mit den Schlüsseln anlegen?
Ich hatte mir zuvor dieses Video zum Vorbild genommen:
https://www.youtube.com/watch?v=yMqWrt17Z18
https://drive.google.com/file/d/1-Z5ivk … U1oEF/view <--- hier im Google-Drive eine PDF mit den Befehlen
Hier hatte er aber 2 Partitionen, wobei das Bootverzeichnis mit Root etc auf der 1. Partition verschlüsselt war und der Swap auf der 2. Partition.
Allerdings hat mein System hier auch nicht den keyfile gefunden.


Danke euch beiden für eure Antworten! Ich hatte mir Arch Linux rausgesucht, weil es viel Konfiguration ermöglicht, Verhältnismäßig wenig Leistungs-Balast mitbringt und man sein System durchs Basteln gut kennenlernt.
Ich werd aber erstmal an anderen Baustellen weiter machen.

Offline

#5 07.10.2019 22:40:46

frostschutz
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

prototyp_002 schrieb:

Wenn ich später im Terminal den Swap aufschlüssel, ist das doch auch kein Problem, dass die Root-Partition eingehangen ist.

Da darfst du aber auch kein Resume mehr machen. Wenn du das nicht brauchst, dann brauchst du dich im Initramfs auch nicht mit Swap rumschlagen.

Der Resume ist eben ein Spezialfall. Normalerweise kümmert sich das Initramfs darum, daß die (verschlüsselte oder wie auch immer schwer erreichbare) Rootpartition eingehängt wird. Bei Resume muss das Initramfs stattdessen die Swappartition erreichen und den Resume versuchen, BEVOR überhaupt die Rootpartition angefasst wird.

Machst du einen Resume nachdem das Rootfs verändert wurde hast du ein defektes Dateisystem...

prototyp_002 schrieb:

Müsste ich, damit das klappen würde, ein 4. Partition mit den Schlüsseln anlegen?

Da gibts viele Möglichkeiten. Eigene Partition mit Schlüsseln kann funktionieren, klar warum nicht. (Edit: das mache ich im Prinzip selbst so, jedoch nicht als Partition, sondern als LUKS-Verschlüsselte Schlüsseldatei im Initramfs.)

Alternativ den Schlüssel auf der Swap-Partition oder Root-Partition verstecken. Partitionen können größer sein als Dateisysteme, oder du kannst dir den Sektor merken in dem die Datei liegt, und den Sektor direkt auslesen, ganz ohne irgendwas zu mounten.

Der Ansatz von systemd ist auf Keyfiles ganz zu verzichten, bei mehreren LUKS-Containern die gleiche Passphrase zu setzen und diese einfach wiederzuverwenden. Systemd fragt also einmal nach einem Passwort, schließt damit den Swap auf, macht Resume und wenn kein Resume-Image im Swap war, schließt es das Root-Dateisystem auf (gleiches Passwort, ohne nochmal zu fragen) und bootet normal weiter.

Beitrag geändert von frostschutz (08.10.2019 09:57:15)

Online

#6 08.10.2019 17:18:08

GerBra
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

prototyp_002 schrieb:

Ich habe jetzt noch diverse Versuche gestartet, die Befehle leicht abzuändern. Allerdings wirft der mir immer wieder andere Fehlermeldungen raus: kein Mountpoint gefunden, falsche Mountoptionen ausgewählt/nicht verfügbar, Key nicht gefunden.

Noch ein Hinweis/Tip zum openswap-Hook:
Ich vermute, daß es auch den Einhängepunkt /mnt im initrd-Filesystem zu dem Zeitpunkt nicht gibt. Zumindest bei:

lsinitcpio /boot/initramfs-linux.img |grep mnt

sehe ich nichts. Das würde die o.a. weiteren Fehlermeldungen zu Mount erklären.
Wenn du noch testen willst, dann z.B. das /mnt-Verzeichnis im openswap-Hook noch erstellen bevor du deine Partition mit dem Keyfile temporär nach /mnt mountest. (Das sollte funktionieren, das initrd-Dateisystem ist m.W. - ungetestet - nicht read-only).

Offline

#7 08.10.2019 20:53:22

prototyp_002
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

frostschutz schrieb:
prototyp_002 schrieb:

Müsste ich, damit das klappen würde, ein 4. Partition mit den Schlüsseln anlegen?

Da gibts viele Möglichkeiten. Eigene Partition mit Schlüsseln kann funktionieren, klar warum nicht. (Edit: das mache ich im Prinzip selbst so, jedoch nicht als Partition, sondern als LUKS-Verschlüsselte Schlüsseldatei im Initramfs.)

Also hast du eine unverschlüsselte Boot-Partition, allerdings im initramfs den key als einzelne Datei verschlüsselt?
Wie hieße denn der Pfad zu diesem FS? Habe mich mit dem verschlüsseln einzelner Dateien durch LUKS noch nicht auseinander gesetzt, aber hatte irgendwo gelesen, dass das geht.

frostschutz schrieb:

Alternativ den Schlüssel auf der Swap-Partition oder Root-Partition verstecken. Partitionen können größer sein als Dateisysteme, oder du kannst dir den Sektor merken in dem die Datei liegt, und den Sektor direkt auslesen, ganz ohne irgendwas zu mounten.

Wenn ich außerhalb eines Dateisystems einen Schlüssel verstecke, heißt dass doch, dass es damit keinen zentralen Dateiverweis gibt und der Speicherplatz somit nicht reserviert ist. Da allerdings das Dateisystem diesen Sektorbereich nicht umfasst, wird es auch nicht als "vorhandene Ablagefläche" registriert und einfach in Ruhe gelassen... Würde ich vermuten?
Aber wie macht man das praktisch? Dass man einfach über fdisk oder gdisk irgendwo zwischen den Bytes Platz lässt, leuchtet mir ein, aber zuvor habe ich ja immer der ganzen Partition ein Dateisystem zugeordnet mit:

...
mkfs.ext4 -L BOOT /sda1
...
frostschutz schrieb:

Der Ansatz von systemd ist auf Keyfiles ganz zu verzichten, bei mehreren LUKS-Containern die gleiche Passphrase zu setzen und diese einfach wiederzuverwenden. Systemd fragt also einmal nach einem Passwort, schließt damit den Swap auf, macht Resume und wenn kein Resume-Image im Swap war, schließt es das Root-Dateisystem auf (gleiches Passwort, ohne nochmal zu fragen) und bootet normal weiter.

Würde es dafür reichen, dass ich einfach im /etc/default/grub die UUIDs von GRUB_CMDLINE_LINUX_DEFAULT und GRUB_CMDLINE_LINUX tausche

[root@Superuser-Playground hooks]# cat /etc/default/grub
# GRUB boot loader configuration

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID="UUID vom cryptROOT""
GRUB_CMDLINE_LINUX="cryptdevice=UUID="UUID vom cryptSWAP":cryptSWAP"
GRUB_ENABLE_CRYPTODISK=y

und so die HOOKS anpass(?):

[root@Superuser-Playground hooks]# cat /etc/mkinitcpio.conf
...
HOOKS=(base udev autodetect keymap keyboard modconf block encrypt resume filesystems fsck)
...

Würde er dann im hook encrypt sich auf den SWAP stürzen und automatisch im resume das selbe Passwort für ROOT weiterverwenden?
Dieser Weg ist mir persönlich denke ich der Einfachste und Schnellste.

GerBra schrieb:

Wenn du noch testen willst, dann z.B. das /mnt-Verzeichnis im openswap-Hook noch erstellen bevor du deine Partition mit dem Keyfile temporär nach /mnt mountest. (Das sollte funktionieren, das initrd-Dateisystem ist m.W. - ungetestet - nicht read-only).

Ich hatte jetzt die HOOKS rausgenommen, aber die Codes erstmal im initcpio-Verzeichnis stehen lassen, falls ich doch mal dran weiter basteln will.
Wie oben geschrieben versuch ichs mal mit der Reihenfolge die Frostschutz gerade erwähnt hat: erst SWAP, dann ROOT. Im Prinzip ists ja egal.
Mich würde trotzdem interessieren, wie denn ein solcher Befehl aussehen würde und wo er zu platzieren ist. Vermutlich in den grub-config-Verzeichnissen?

Ich tu mich damit etwas schwer, grundlegendes "Material" zu finden, um Linux zu lernen. Also Dateisysteme, Mounten, systemd. Hier und da gibts Dinge vom CCC online zum nachlesen, allerdings sind die Fertigkeiten, die man mitbringen muss, häufig zu hoch für mich. Und ist ja auch Quatsch, für alles hier nen neuen Threat aufzumachen. Meine Postings sind ohnehin schon lang genug.
Trotzdem vielen Dank!

Offline

#8 08.10.2019 22:00:49

frostschutz
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

prototyp_002 schrieb:
frostschutz schrieb:

Der Ansatz von systemd ist auf Keyfiles ganz zu verzichten, bei mehreren LUKS-Containern die gleiche Passphrase zu setzen und diese einfach wiederzuverwenden. Systemd fragt also einmal nach einem Passwort, schließt damit den Swap auf, macht Resume und wenn kein Resume-Image im Swap war, schließt es das Root-Dateisystem auf (gleiches Passwort, ohne nochmal zu fragen) und bootet normal weiter.

Würde es dafür reichen, dass ich einfach im /etc/default/grub die UUIDs von GRUB_CMDLINE_LINUX_DEFAULT und GRUB_CMDLINE_LINUX tausche

Nein, du müsstest auf den systemd hook und sd-encrypt wechseln. Die anderen Hooks fallen damit weg, das ist eine entweder-oder Geschichte. (systemd schon im initramfs oder nicht) Im Wiki sollte das eigentlich beschrieben sein, wie man die systemd Hooks verwendet... ich habe dieses Setup auch nicht selbst im Einsatz. Wenn du das ausprobierst, sichere deine alte mkinitcpio.conf und das (mehr oder minder) funktionierende initramfs damit du noch irgendwie booten kannst, wenns schiefgeht.

Würde er dann im hook encrypt sich auf den SWAP stürzen und automatisch im resume das selbe Passwort für ROOT weiterverwenden?

Ohne systemd-Hook nur mit dem UUID Tausch würde es wohl bis zum Swap noch kommen aber dann mit Root nicht weitergehen, also wieder eine Sackgasse aus der du nur mit einem eigenen Hook rauskommst.

Online

#9 11.10.2019 12:04:30

prototyp_002
Mitglied

Re: Problem: Entschlüsselung der Swap-Partition (mkinitcpio, hook)

frostschutz schrieb:
prototyp_002 schrieb:
frostschutz schrieb:

Der Ansatz von systemd ist auf Keyfiles ganz zu verzichten, bei mehreren LUKS-Containern die gleiche Passphrase zu setzen und diese einfach wiederzuverwenden. Systemd fragt also einmal nach einem Passwort, schließt damit den Swap auf, macht Resume und wenn kein Resume-Image im Swap war, schließt es das Root-Dateisystem auf (gleiches Passwort, ohne nochmal zu fragen) und bootet normal weiter.

Würde es dafür reichen, dass ich einfach im /etc/default/grub die UUIDs von GRUB_CMDLINE_LINUX_DEFAULT und GRUB_CMDLINE_LINUX tausche

Nein, du müsstest auf den systemd hook und sd-encrypt wechseln. Die anderen Hooks fallen damit weg, das ist eine entweder-oder Geschichte. (systemd schon im initramfs oder nicht) Im Wiki sollte das eigentlich beschrieben sein, wie man die systemd Hooks verwendet... ich habe dieses Setup auch nicht selbst im Einsatz. Wenn du das ausprobierst, sichere deine alte mkinitcpio.conf und das (mehr oder minder) funktionierende initramfs damit du noch irgendwie booten kannst, wenns schiefgeht.

Dann mache ich nun mit der Einrichtung der Snapshots weiter um ein bootfähiges Image zu erstellen und friemel mich dann in den sd-encrypt Hook rein.
Vielen Dank für die Hilfe und Information. Jetzt weiß ich, wo ich suchen muss!

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums