Arch: LUKS erst mit Login entschlüsseln, systemd mountet trotzdem beim Booten

[Donnerkind]

Hallo Leude,

jetzt muss ich tatsächlich auch mal Linux-Hilfe ersuchen. Ausgangslage: auf meinem Surface Go 1 habe ich Arch Linux drauf, wie auf all meinen anderen Rechnern auch. Der Unterschied ist, dass die SSD nicht komplett geLUKSt ist, sondern nur die Home-Partition. Der Grund: ich möchte im Ernstfall auch ohne die Tastatur das System starten können. Das heißt, ich muss das LUKS-Passwort per Bildschirmtastatur eingeben können, und das geht eben erst ab dem grafischen Anmeldebildschirm.

Das ging auch schonmal. Aber dann habe ich über das Forum zufällig herausgefunden, dass die SSD für die falsche Blockgröße konfiguriert ist und ich wollte das umstellen, denn ich habe immer wieder sehr schlechte I/O-Performance. Dafür musste ich alle Dateien weg sichern und nach der Umstellung wiederherstellen. Ich habe dafür tar in einem Livesystem benutzt, um alle Berechtigungen u.s.w. zu sichern. Die Dateien sind also eigentlich identisch zum Stand von vorher. Dennoch wird seitdem (die Umstellung ist schon mehrere Monate her) die Partition immer schon beim Booten auf der Konsole gemountet. Ich muss mein Benuzterpasswort also aktuell zweimal eingeben: beim Booten und im Anmeldebildschirm.

Ich ging bei der ersten Einrichtung nach der Anleitung im Arch Wiki vor. Ich bin den Artikel eben nochmal durchgegangen und habe meine Configs geprüft. Meine /etc/security/pam_mount.conf.xml enthält wie es sein soll:

<volume user="<mein Username>" fstype="crypt" path="/dev/nvme0n1p3" mountpoint="/home" options="fsck,noatime,allow_discard,fstype=f2fs" />

Die im Artikel fett geschriebenen Zeilen für /etc/pam.d/system-login sind an den korrekten Stellen vorhanden.
Meine /etc/crypttab hat nur Kommentarzeilen und in /etc/fstab gibt es keine Referenz auf /home oder die Partition. Aus irgendeinem Grund will systemd trotzdem die Partition mounten (von nem Foto abgetippt):

[ OK ] Started Rule-based Manager for Device Events and Files.
[ OK ] Found device KBG.... TOSHIBA Linux\x20\x2fhome.
[ OK ] Found device KBG.... TOSHIBA Linux\x20\efi.
       Mounting /boot...
       Starting Cryptography Setup for home...
Please enter passphrase for disk Linux /home (home):

Spoiler: Weitere Daten

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
mmcblk0     179:0    0 366,8G  0 disk 
└─mmcblk0p1 179:1    0 366,8G  0 part  /mnt/data
nvme0n1     259:0    0 119,2G  0 disk 
├─nvme0n1p1 259:1    0   260M  0 part  /boot
├─nvme0n1p2 259:2    0    30G  0 part  /
└─nvme0n1p3 259:3    0    89G  0 part 
  └─home    254:0    0    89G  0 crypt /home

$ cat /proc/cmdline
root=PARTUUID=2c5d9f14-6897-154b-b62e-b83c913c35dd rw add_efi_memmap mitigations=off initrd=/intel-ucode.img initrd=\initramfs-linux.img

$ cat /etc/mkinitcpio.conf
MODULES=(i915 hid hid_sensor_hub i2c_hid hid_generic usbhid hid_multitouch)
BINARIES=()
FILES=()
HOOKS=(base udev keyboard autodetect modconf block filesystems fsck)

Habt Ihr nen Tipp? Danke.

 

[SJAFNWEIF]

Meine /etc/crypttab hat nur Kommentarzeilen

Evtl.

noauto
This device will not be added to cryptsetup.target. This means that it will not be automatically unlocked on boot, unless something else pulls it in. In particular, if the device is used for a mount point, it'll be unlocked automatically during boot, unless the mount point itself is also disabled with noauto.

(https://man.archlinux.org/man/crypttab.5)

 

[Donnerkind]

Das hab ich tatsächlich früher schon probiert, denn der Eintrag steht noch auskommentiert drin:

home /dev/nvme0n1p3 none noauto,discard

Die manpage sagt „if the device is used for a mount point, it'll be unlocked automatically during boot, unless the mount point itself is also disabled“. Ich weiß nicht genau, was mit „device used as mointpoint“ gemeint ist, denn schließlich werden alle Devices an einem Mointpoint eingehängt. Vielleicht, dass noch etwas anders unterhalb gemountet werden soll? Jedenfalls hatte ich auch noch folgende Zeile als Kommentar in fstab:
[/code]
/dev/mapper/home /home f2fs noauto,noatime 0 0
[/code]
Ich habe beide Zeilen reaktiviert, aber es hat nicht geholfen. Ich stieß eben auf einen Post drüben bei Ubuntu, dort hat einer per systemctl list-dependencies rausgefunden, was bei ihm /boot reingeholt hat. Bei mir ist es local-fs.

 

[Uridium]

ich muss das LUKS-Passwort per Bildschirmtastatur eingeben können, und das geht eben erst ab dem grafischen Anmeldebildschirm.

Der grafische Bildschirm könnte aber bereits den /home Ordner benötigen, z.B. /home/${USER}/.config (je nach Displaymanager) oder den Xorg Magic Cookie (.Xauthority) für den Zugriff auf 'Display:0'. Henne/Ei Problem. Oder benutzt Du Wayland? Da ist es vielleicht anders.

home /dev/nvme0n1p3 none noauto,discard

Ich hoffe, Du weißt, was Du da machst. Diese Form des 'discard' ist continuous TRIM und wird nicht so oft empfohlen (insbesondere wegen der von dir geschilderten Symptome = Leistungseinbußen).

 

[Donnerkind]

Der grafische Bildschirm könnte aber bereits den /home Ordner benötigen, z.B. /home/${USER}/.config (je nach Displaymanager) oder den Xorg Magic Cookie (.Xauthority) für den Zugriff auf 'Display:0'. Henne/Ei Problem. Oder benutzt Du Wayland? Da ist es vielleicht anders.

Hm, früher™ ging es ja auch. Auf den Schlag nach der Wiederherstellung der Sicherung ging es nicht mehr. Ich hatte damals pauschal alles gepackt und entpackt, dabei keine Dateien bearbeitet, außer wahrscheinlich UUIDs. Ich habe eben nochmal neu gebootet und vor der Anmeldung ein lsof /home gemacht, was ein leeres Ergebnis brachte. Ich nutze sddm mit X11.

Ich hoffe, Du weißt, was Du da machst. Diese Form des 'discard' ist continuous TRIM und wird nicht so oft empfohlen (insbesondere wegen der von dir geschilderten Symptome = Leistungseinbußen).

Keine Ahnung, warum das da steht, ich habe es sonst auch immer aus und nutze überall einen wöchentlichen fstrim-Cronjob.