Bislang sieht es bei meinem Notebook mit Arch Linux so aus (UEFI und nichts verschlüsselt):
┏━━━━━━━━━━━━━━┓
┃     SSD      ┃  <= Partition 1: /boot   512M   EF00 EFI System
┃ /dev/nvme0n1 ┃  <= Partition 2: /       460G   8304 Linux x86-64 root
┗━━━━━━━━━━━━━━┛
Nun würde ich den persistenten Speicher (in meinem Fall eine SSD, WD Black) gerne verschlüsseln. Allerdings blicke ich nicht mehr so ganz durch, weil es so viele Optionen, Anleitungen und Hinweise gibt... Ich habe gesehen, man kann da was mit dm-crypt machen, allerdings gibt es ziemlich verschiedene Konfigurationen ("LUKS on partition" oder "LVM on LUKS").

Zu dem, wie ich mir das vorstelle im Moment - es sollte so sein, dass der Schlüssel in verschlüsselter Form gespeichert vorliegt. Dieser wird dann mithilfe eines einzugebenden Schlüssels nutzbar gemacht, wobei diese Eingabe gleichzeitig das Login-Passwort bei gdm sein sollte. Man sollte das idealerweise nur einmal eingeben brauchen, es wird dann zum Entsperren des verschlüsselten Speichers und der Anmeldung genutzt. Wichtig ist noch, dass der Bereitschaftsmodus (suspend) weiterhin nutzbar bleiben soll.

Swap hatte ich bislang keinen angelegt, daher sollte das auch in verschlüsselter Form kein Ding sein. Es ist nicht wichtig, dass Partitionen nachträglich noch irgendwie geändert werden könnten bei mir, das wird nur einmal angelegt und danach nie wieder verändert. Hardwareseitige Full Disk Encryption (FDE) wird von der SSD nicht unterstützt. Und gut wäre noch, wenn man die Schlüssel irgendwie sichern könnte (auf Papier oder USB-Stick), um notfalls immernoch an die Daten heranzukommen.

Kann mir vielleicht jemand weiterhelfen, was in diesem Fall relevant ist bzw. was zutrifft?
Eine knapp 500GB Rootpartition in einer SSD unterteilen? Würde ich nicht machen. Daher ist dann auch LVM hinfällig.
Ich kann dir mal beschreiben wie ein verschlüsseltes Arch-Linux ohne LVM installiert wird.
Es wird beim Booten ein Passwort abgefragt. Um automatisch in ein grafisches Desktop zu gelangen, könnte man autologin und starten per xinitrc einrichten. So wird dann nur beim Booten das Passwort abgefragt.
Das Passwort erst mit einem Loginmanager abzufragen, wird nicht gehen, da die verschlüsselte Rootpartition schon entschlüsselt sein müßte. Geht also nicht. Oder besser gesagt, wüßte ich nicht.
Zur Beachtung: Es wird auch der Partition ein Label zugewiesen (pl_arch_crypt) damit man per Label auf die verschlüsselte Partition zugreifen kann. Nach der Entschlüsselung taucht dann das Label p_arch auf. Alternative per /dev/nvmexy oder UUID. 
arch uefi installation:
Es wird eine Bootpartition und eine Rootpartition angelegt.
Abkürzungen:
EFIBOOT Dateisystem-Label für Boot und EFI Partition.
p_arch Dateisystemlabel Rootpartition für Arch-Linux
p_arch_crypt Partitionslabel nach Entschlüsselung /dev/mapper/..
pl_arch_crypt Partitionslabel für verschlüsselte Root Partition. Nicht zu verwechseln mit Dateisystem Label.
p_swap Label für Swappartition falls nötig.

booten mit dem Isoimage
loadkezs de
loadkezs de-latin1
Bootmethode verifizieren:
# ls /sys/firmware/efi/efivars

Auf aktuelle Zeit setzen:
# timedatectl set-ntp true
Status prüfen: timedatectl timesync-status
hwclock -w

lsblk -f
gdisk /dev/sda
Neue Partitionstabelle erzeugen mit
o
neue Partition für efi und boot (EFIBOOT) 256M Fat32 Spezifikation >512MiB ??).
n
Typ ef00
neue Partition für root
n
Typ 8309. PARTLABEL pl_arch_crypt hinzufügen (Taste c in gdisk).

neue Partition für swap
n
Typ 8200
w

modprobe dm-crypt
cryptsetup -c aes-xts-plain64 -y -s 512 luksFormat /dev/sda2 ACHTUNG Passwortvergabe Tastaturbelegung de beachten!!
cryptsetup luksOpen /dev/sda2 p_arch_crypt

Formatieren:
mkfs.fat -F32 -n EFIBOOT /dev/sda1
mkfs.ext4 -L p_arch /dev/mapper/p_arch_crypt

Mounten:
Rootpartition zuerst!!!
mount -L p_arch /mnt
mkdir -p /mnt/boot
mount -L EFIBOOT /mnt/boot
swapon -L p_swap

Falls wlan, wifi-menu

Grundinstallation:
Ab hier wie im Wiki beschrieben
oder Stichwortartig hier weiter
nano /etc/pacman.d/mirrorlist
pacstrap /mnt base linux linux-firmware intel-ucode nano man-pages man-pages-de man-db mlocate netctl dhcpcd usbutils e2fsprogs less lshw mc gptfdisk efibootmgr dmidecode pacman-contrib
genfstab -pL /mnt >> /mnt/etc/fstab

arch-chroot /mnt
echo rechnername > /etc/hostname
nano /etc/hosts
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1	localhost.localdomain	localhost
::1		localhost.localdomain	localhost

echo LANG=de_DE.UTF-8 > /etc/locale.conf
echo KEYMAP=de-latin1 > /etc/vconsole.conf
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

nano /etc/locale.gen
de_DE.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE@euro ISO-8859-15
en_US.UTF-8
locale-gen

passwd

nano /etc/mkinitcpio.conf in Hooks einfügen und keyboard keymap vor block encrypt vor filesystem
Komplette Zeile: HOOKS="base udev autodetect modconf keyboard keymap block encrypt filesystems fsck"
mkinitcpio -p linux

systemd Loader installieren 
bootctl install

Datei anlegen:
nano /boot/loader/loader.conf Hinweis: diese Datei wird nur benutzt zum Laden des default Linux.

timeout3
default uefi_arch.conf

Datei anlegen:
nano /boot/loader/entries/uefi_arch.conf

title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=/dev/sda2:p_arch_crypt root=LABEL=p_arch
oder mit Label options cryptdevice=PARTLABEL=pl_arch_crypt:p_arch_crypt root=LABEL=p_arch

Für fallback anlegen:
/boot/loader/entries/uefi_arch_fallback.conf

title Arch Linux fallback
linux /vmlinuz-linux
initrd /initramfs-linux-fallback.img
options cryptdevice=/dev/sda2:p_arch_crypt root=LABEL=p_arch
oder mit Label options cryptdevice=PARTLABEL=pl_arch_crypt:p_arch_crypt root=LABEL=p_arch

Zusätzliche Werkzeuge installieren:
pacman -S gptfdisk efibootmgr lshw mc

efi booteinträge kontollieren:
efibootmgr -v


exit
umount -R /mnt
poweroff
usb stick bzw CD entfernen.
Neu starten
login: root
Passwort: Geheim

useradd -m -g users -s /bin/bash duda
passwd duda

Ab hier grafisches Zeugs installieren.
Viel Glück!!
Gruß aus DN
Greg

Nachtrag: Kleinere Änderungen in der Anleitung.
delta-x8 schrieb Nun würde ich den persistenten Speicher (in meinem Fall eine SSD, WD Black) gerne verschlüsseln. Allerdings blicke ich nicht mehr so ganz durch, weil es so viele Optionen, Anleitungen und Hinweise gibt... Ich habe gesehen, man kann da was mit dm-crypt machen, allerdings gibt es ziemlich verschiedene Konfigurationen ("LUKS on partition" oder "LVM on LUKS").
Wozu möchtest du verschlüsseln? Man wählt die Konfiguration abhängig davon, was man erreichen möchte. Und mir wird nicht klar, was genau du weswegen verschlüsseln möchtest.

Man kann eine Vollverschlüsselung mit oder ohne verschlüsseltes /boot-Verzeichnis einrichten. Du kannst aber auch nur die Daten verschlüsseln, wenn du nicht oft Zugriff darauf brauchst.

Möchtest du nur Vertraulichkeit gewährleisten oder brauchst du auch glaubwürdige Abstreitbarkeit?
Eine Verschlüsselung bietet per se auch keine Integrität.
delta-x8 schrieb Zu dem, wie ich mir das vorstelle im Moment - es sollte so sein, dass der Schlüssel in verschlüsselter Form gespeichert vorliegt. Dieser wird dann mithilfe eines einzugebenden Schlüssels nutzbar gemacht, wobei diese Eingabe gleichzeitig das Login-Passwort bei gdm sein sollte. Man sollte das idealerweise nur einmal eingeben brauchen, es wird dann zum Entsperren des verschlüsselten Speichers und der Anmeldung genutzt. Wichtig ist noch, dass der Bereitschaftsmodus (suspend) weiterhin nutzbar bleiben soll.
Das Login-Passwort (Nutzerpasswort) und die LUKS-Passphrase sind zwei komplett unterschiedliche Passwörter und sollten dementsprechend auch unterschiedliche Passwörter sein. Du kannst zwar für beide Passwörter das "gleiche" (je nach Tastaturlayout) setzen, empfehlen würde ich es aber nicht.

Zum Bereitschaftsmodus kann ich nichts sagen, da ich nie einen nutze.
delta-x8 schrieb Und gut wäre noch, wenn man die Schlüssel irgendwie sichern könnte (auf Papier oder USB-Stick), um notfalls immernoch an die Daten heranzukommen.
USB-Sticks sind meines Wissens nicht unbedingt für lange Lagerung gedacht. Wenn du fürs Entschlüsseln eine Passphrase wählst, dann sollte es kein Hindernis sein, diese auf Papier zu schreiben. Allerdings solltest du dieses Papier dann auch richtig lagern. Papier kann ja nass werden oder brennen oder weggeworfen werden oder von Tieren aufgefressen werden, und und und.

Wenn du von deinen Daten kein Backup hast, dann hast du auch keine wichtigen Daten. Und folglich kann es dir auch komplett egal sein, ob du nicht mehr an die Daten kommst, weil du den Schlüssel nicht mehr weisst/hast.
delta-x8 schrieb Kann mir vielleicht jemand weiterhelfen, was in diesem Fall relevant ist bzw. was zutrifft?
Solange man nicht genau weiss, welche Bedrohungen du mittels Verschlüsselung eigentlich mitigieren willst, kann man auch nur raten.
Gerry_Ghetto schriebSolange man nicht genau weiss, welche Bedrohungen du mittels Verschlüsselung eigentlich mitigieren willst, kann man auch nur raten.
Das ist ein Punkt, ein anderer ist, wie deine Linux Kentnisse sind, d.h. wie du einschätzt, ob du bei Problemen mit einem komplett verschlüsselten System Dir zutraust das zu lösen.
Solche Probleme mögen selten sein, aber bei einem abgebrochenen Update, defektes Dateisystem oder Änderungen beim Update o.ä. möglich.

Folgende Stufen gibt es m.M. - Komplexität aufsteigend sortiert:
- keepassxc - Passwortsafe für deine Passwörter
- verschlüsselter Container mit deinen wichtigesten Daten / oder verschlüsselter Unterordner
- verschlüsseltes Home
- verschlüsseltes root
- verschlüsseltes root + boot
Greg schriebIch kann dir mal beschreiben wie ein verschlüsseltes Arch-Linux ohne LVM installiert wird.
Vielen Dank für die ausführliche Anleitung, werde ich ausprobieren! Damit habe ich ja etwas, wo ich anfangen kann.

Gerry_Ghetto schriebWozu möchtest du verschlüsseln?
Weshalb ich an Verschlüsselung denke? - Nun, es geht um ein Notebook. Das hat man auch mal dabei, wenn man das Haus verlässt. Darauf sind allerdings einige Daten gespeichert, auf die nicht jeder zugreifen können sollte. Das ist ja an sich ziemlich gut möglich, man kann beispielsweise von dem Arch-Installationsdatenträger booten, macht ein chroot und ein passwd.

Man kann natürlich darauf hoffen, dass derjenige, der an die Daten ran mag, Angst vor Arch Linux hat und befürchtet, i3 vorzufinden, wenn er sich da Zugang verschafft. Dann wäre allerdings ein Umstieg zu Gentoo Linux ein guter Ansatz. Ich würde eher auf Verschlüsselung setzen, von dem Grad an Verschlüsselung und Aufwand her wäre (denke ich) ein verschlüsseltes /home oder /(root) sinnvoll.
Gerry_Ghetto schriebWenn du von deinen Daten kein Backup hast, dann hast du auch keine wichtigen Daten. Und folglich kann es dir auch komplett egal sein, ob du nicht mehr an die Daten kommst, weil du den Schlüssel nicht mehr weisst/hast.
Thema Datensicherung, ja, das gibt's bei mir! Allerdings ist es dennoch ganz hübsch, wenn man notfalls noch an die Daten herankommt. Es kann ja vorkommen, dass es nach einem Update irgendwo klemmt und da mag man vielleicht nicht gleich alles neu installieren müssen.

Mir ist bekannt, dass Papier und USB-Stick nicht ewig halten. Es kann auch vorkommen, dass ein Meteorit das Haus trifft und tragischerweise dadurch mein auf Papier gesichertes Passwort zerstört wird. Das wäre mir dann allerdings ziemlich egal, weil nach einem ordentlichen Meteoriteneinschlag höchstwahrscheinlich auch das Notebook hinüber wäre :rolleyes: - ich wäre jedenfalls mit Papier zufrieden.
ub4000 schriebDas ist ein Punkt, ein anderer ist, wie deine Linux Kentnisse sind, d.h. wie du einschätzt, ob du bei Problemen mit einem komplett verschlüsselten System Dir zutraust das zu lösen.
Gute Überlegung, das würde ich mir noch zutrauen. /boot würde ich allerdings nicht verschlüsseln, weil da kann es (denke ich mal) echt kompliziert werden.
delta-x8 schrieb...Thema Datensicherung, ja, das gibt's bei mir! Allerdings ist es dennoch ganz hübsch, wenn man notfalls noch an die Daten herankommt....
An einer verschlüsselten Rootpartition kommt man im Notfall auch per Arch Isoimage ran. 
loadkezs de-latin1
modprobe dm_crypt
cryptsetup luksOpen /dev/sda2 p_arch_crypt
mount -L p_arch /mnt
mc
Mit mc hast du einen Dateimanager.
Übrigens, die Installationsanleitung oben ist eben nochmal getestet worden. Ebenso der Notfall um an die Daten heranzukommen.
Gruß aus DN
Greg
delta-x8 schrieb
Gerry_Ghetto schriebWozu möchtest du verschlüsseln?
Weshalb ich an Verschlüsselung denke? - Nun, es geht um ein Notebook. Das hat man auch mal dabei, wenn man das Haus verlässt. Darauf sind allerdings einige Daten gespeichert, auf die nicht jeder zugreifen können sollte. Das ist ja an sich ziemlich gut möglich, man kann beispielsweise von dem Arch-Installationsdatenträger booten, macht ein chroot und ein passwd.

Man kann natürlich darauf hoffen, dass derjenige, der an die Daten ran mag, Angst vor Arch Linux hat und befürchtet, i3 vorzufinden, wenn er sich da Zugang verschafft. Dann wäre allerdings ein Umstieg zu Gentoo Linux ein guter Ansatz. Ich würde eher auf Verschlüsselung setzen, von dem Grad an Verschlüsselung und Aufwand her wäre (denke ich) ein verschlüsseltes /home oder /(root) sinnvoll.
Du denkst da viel zu kompliziert. Wenn die Daten unverschlüsselt sind, dann kann man sie mit einem beliebigen Linux (ginge sogar mit Windows) anschauen. Ein chroot ist nicht nötig.

Und die graphische Oberfläche oder der Umstieg auf Gentoo trägt auch nichts zur Sicherheit bei.
delta-x8 schrieb Thema Datensicherung, ja, das gibt's bei mir! Allerdings ist es dennoch ganz hübsch, wenn man notfalls noch an die Daten herankommt. Es kann ja vorkommen, dass es nach einem Update irgendwo klemmt und da mag man vielleicht nicht gleich alles neu installieren müssen.
Wollte nur sichergehen, dass du dir darüber im Klaren bist.
delta-x8 schrieb
ub4000 schriebDas ist ein Punkt, ein anderer ist, wie deine Linux Kentnisse sind, d.h. wie du einschätzt, ob du bei Problemen mit einem komplett verschlüsselten System Dir zutraust das zu lösen.
Gute Überlegung, das würde ich mir noch zutrauen. /boot würde ich allerdings nicht verschlüsseln, weil da kann es (denke ich mal) echt kompliziert werden.
Wenn du /boot nicht verschlüsselst, musst du daran denken, dass du auf keinen Fall Schlüssel ins initramfs packst.
Greg schriebÜbrigens, die Installationsanleitung oben ist eben nochmal getestet worden. Ebenso der Notfall um an die Daten heranzukommen.
Perfekt und an dich ein sehr großes Dankeschön für die hilfreichen Beiträge!

Gerry_Ghetto schriebUnd die graphische Oberfläche oder der Umstieg auf Gentoo trägt auch nichts zur Sicherheit bei.
Schon klar, war auch mit Humor gemeint 😉. Und ja, du hast recht, es ist ja ein Ext4-Dateisystem, das kann jedes andere Linux auch lesen, nur Windows nicht - hatte ich nicht dran gedacht.
Gerry_Ghetto schriebWenn du /boot nicht verschlüsselst, musst du daran denken, dass du auf keinen Fall Schlüssel ins initramfs packst.
Gut, das heißt ja nur, dass ich aufpassen sollte, wenn es darum geht, etwas in /etc/mkinitcpio.conf einzutragen (also Zeichenfolgen bzw. Dateien, die diese Schlüssel als Klartext enthalten).

Die Partition /boot zu verschlüsseln wäre ja auch eine Option, allerdings ist das vermutlich primär dazu vorgesehen, um zu verhindern, dass jemand etwas an diesen Daten bzw. dem Bootvorgang verändern kann. Das wäre bei mir keine so große Befürchtung, daher bräuchte ich das nicht - trifft die Überlegung soweit zu?
delta-x8 schrieb Und ja, du hast recht, es ist ja ein Ext4-Dateisystem, das kann jedes andere Linux auch lesen, nur Windows nicht - hatte ich nicht dran gedacht.
Wieso sollte Windows die Daten nicht lesen können? Entweder du installierst einen ext4-Treiber für Windows oder das "Windows Subsystem for Linux" oder ein Linux in einer virtuellen Maschine.
delta-x8 schrieb
Gerry_Ghetto schriebWenn du /boot nicht verschlüsselst, musst du daran denken, dass du auf keinen Fall Schlüssel ins initramfs packst.
Gut, das heißt ja nur, dass ich aufpassen sollte, wenn es darum geht, etwas in /etc/mkinitcpio.conf einzutragen (also Zeichenfolgen bzw. Dateien, die diese Schlüssel als Klartext enthalten).
Ja.
delta-x8 schrieb Die Partition /boot zu verschlüsseln wäre ja auch eine Option, allerdings ist das vermutlich primär dazu vorgesehen, um zu verhindern, dass jemand etwas an diesen Daten bzw. dem Bootvorgang verändern kann. Das wäre bei mir keine so große Befürchtung, daher bräuchte ich das nicht - trifft die Überlegung soweit zu?
Eine Verschlüsselung dient primär dem Schutzziel Vertraulichkeit. Die Verschlüsselung ist also dazu da, dass andere deine Daten nicht lesen/verstehen können. Eine Verschlüsselung garantiert im Allgemeinen jedoch keine Integrität oder Authentizität.
Die Daten können beispielsweise mittels dd auf der Festplatte verändert werden. Im besten Fall sind die Dateien zerstört/kaputt/korrupt, im schlechtesten Fall hat ein Angreifer ganz gezielt Dateien zu seinen Gunsten geändert.

Verschlüsselung nützt auch nur dann etwas, wenn die Daten verschlüsselt sind. Im laufenden Betrieb hast du das System ja entschlüsselt. Ein Angreifer, der eine Lücke in Firefox ausnutzt, hat also trotzdem die Möglichkeit, an deine Daten zu kommen.

Um Manipulationen des Bootvorgangs zu erkennen, gäbe es eigentlich Secure Boot bei UEFI, allerdings bietet Arch Linux keine signierten Kernel und Bootloader an (Müsste man alles selbst einrichten, was zwar möglich ist, aber auch sehr viel Wissen erfordert).

Für dich zusammenfassend: Verschlüsselung dient nur der Vertraulichkeit und eine unverschlüsselte /boot ist in deinem Fall sicher genug.
gerry_getto schrieb...und eine unverschlüsselte /boot ist in deinem Fall sicher genug.
Sollte bestimmt heißen:...und ein verschlüsseltes root ist in deinem Fall sicher genug!

@Greg
Ich finde deine Anleitung klasse und werde schauen ob ich das die Tage in der Wicki als Spickzettel herausgeben kann.
Hier schon mal vorab die allgemeine Bitte, den Spickzettel dann doch noch mal durch zu lesen wenn es soweit ist. (Nur nochmal zur Kontrolle, falls ich was übersehen sollte)
Die Einrichtung der Swap-Partition lasse ich aber dabei weg. (Die bliebe ja nach deiner Anleitung nach doch unverschlüsselt was dem "Schutzziel Vertraulichkeit" schaden tut.
Der Fragesteller hier, will ja auch gar keine Swap-Partition, sonst hätte ich hier schon eher was dazu gesagt.
Der neue Spickzettel ist erstellt. Ich hab erstmal einen roten "Achtung neue Anleitung" Balken darüber gestellt falls doch noch irgend etwas daran nicht stimmen sollte. Es wäre sehr sehr nett wenn jemand nochmal gegen ließt.
Hallo tuxnix,
dein Spickzettel ist klasse.
Ich habe mal das Ganze mit qemu durchgespielt.
Dabei gab es Probleme.
In der Zeile 
cryptsetup -c aes-xts-plain64 -y -s 512 luksFormat /dev/x2 ARCH-CRYPT
kommt eine Fehlermeldung 
Failed to open keyfile
Klar, den gibts ja auch nicht.
Macht man ein 
cryptsetup -c aes-xts-plain64 -y -s 512 luksFormat /dev/x2
funktioniert das wunderbar.
Du wolltest dem cryptdevice einen Namen verpassen. Klappt scheinbar nicht. In den manpages habe ich diesbezüglich nichts lesen können.
In der arch-uefi.conf funktioniert der Eintrag 
options cryptdevice=ARCH-CRYPT:ARCH root=LABEL=ARCH rw lang=de init=/usr/lib/systemd/systemd locale=de_DE.UTF-8
dann auch nicht. Zum Testen habe ich dann auch die devnamen eingetragen 
cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de init=/usr/lib/systemd/systemd locale=de_DE.UTF-8
In der mkinitcpio.conf
in der Hook Zeile 
HOOKS="base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck"
Gibt es eine Fehlermeldung 
sd-encrypt ... command not found
Habe ich geändert in 
HOOKS="base systemd autodetect keyboard modconf block encrypt filesystems fsck"
Dann klappts.
Ich habe nur bis hier getestet ob das Basissystem läuft.
Um doch mit Labels arbeiten zu können, kannst du den Partitionen ein Label geben. Siehe Post #2
Besten Dank für deine unermüdliche Arbeit an Arch-Linux Wikis.
Gruß aus DN
Greg
Hallo Greg aus Dänemark,
das ist absolut super klasse, vielen Dank. So weit ich weiß, ist das jetzt die erste Anleitung in der deutschen Wiki für ein verschlüsseltes root ohne auch noch gleichzeitig lvm einzusetzen.
Greg schriebUm doch mit Labels arbeiten zu können, kannst du den Partitionen ein Label geben. Siehe Post #2
Nicht wenn es nicht nötig ist!
Ich hatte dies nur deshalb so vorgesehen weil in der Englischen Wicky steht, dass man in der arch-uefi.conf besser auf die Angabe von LABEL= setzt, da sich die Mount-Reihenfolge ja auch mal ändern kann, wenn man zusätzliche Datenträger anschließt.
Dumm nur, dass ich die Konfiguration von systemd-boot nicht selbst testen kann, weil ich keinen UEFI Rechner habe.

Bei den HOOKS in der mkinitcpio.conf habe ich von udev auf systemd umgestellt. Dies auch nach Englischer Wiki.
Da steht dann extra eine Tabelle die besagt, dass bei der Angabe von systemd statt (udev), sd-vconsole statt (keymmap) und sd-encrypt anstatt (encrypt) zu setzen ist.

Das Problem bei der Englischen Wiki ist, dass beim Thema crypt anscheinend viel überarbeitet werden muss und sie schon einen Sammel-Artikel haben um alle alten Artikel einzusammeln die widersprüchlich sind.
Greg schriebIch habe nur bis hier getestet ob das Basissystem läuft.
Ja, das genügt völllig. Die Spickzettel sind stanadisiert. Der Rest ist Routinekram.

Bei Hook habe ich es jetzt aktull so stehen: HOOKS="base systemd autodetect keyboard keymap modconf block encrypt filesystems fsck"
Das heißt, keymap ist dann auch wieder dabei. Sonst klappt die Passworteingabe ja nicht mit den deutschen Umlauten.

Hattest du bei deinem Test auch Formatiert wie angegeben? Ich hatte anstatt wie bei dir in Post #2 Typ 8309 in Partitionstyp 8300 geändert, weil das Dirk in der Modernen Installatio... auch so gemacht hat.
Zusätzlich habe ich den 'cryptsetup luksOpen ...' Befehl in 'cryptsetup open...' geändert, weil die man page dazu sagt, dass ersteres zwar noch funktioniert aber veraltet ist.

Erstmal viele Dank. Vielleicht schaut ja auch nochmal Gerry_Ghetto oder jemand mit gleich viel Überblick und Erfahrung darüber.
Jedenfalls habt ihr beide hier und delta-x8 schon gute Vorarbeit geleistet.

Mercy

Tuxnix

Gerade schneite es hier.
Muss wohl der April sein.

(Edit)
tuxnix schriebHallo Greg aus Dänemark,
Dänemark scheint ja hier sehr beliebt zu sein. Wenn Ihr so weiter macht muß ich noch nach DK umziehen.
tuxnix schriebBei den HOOKS in der mkinitcpio.conf habe ich von udev auf systemd umgestellt. Dies auch nach Englischer Wiki.
Da steht dann extra eine Tabelle die besagt, dass bei der Angabe von systemd statt (udev), sd-vconsole statt (keymmap) und sd-encrypt anstatt (encrypt) zu setzen ist.
Habe ich nochmal getestet. statt udev systemd hat nicht funktioniert. Qemu bleibt an der Meldung hängen:
Timed out waiting for device /dev/gpt-auto-root.
Kann ich nichts mit anfangen. Er fragt nicht mal nach Passwort zur Entschlüsselung.
Könnte auch eine Eigenart von quemu sein.
Auf jeden Fall klappt das so:
HOOKS="base udev autodetect keyboard keymap modconf block encrypt filesystems fsck"
tuxnix schriebHattest du bei deinem Test auch Formatiert wie angegeben? Ich hatte anstatt wie bei dir in Post #2 Typ 8309 in Partitionstyp 8300 geändert, weil das Dirk in der Modernen Installatio... auch so gemacht hat.
Zusätzlich habe ich den 'cryptsetup luksOpen ...' Befehl in 'cryptsetup open...' geändert, weil die man page dazu sagt, dass ersteres zwar noch funktioniert aber veraltet ist.
Bisher hatte ich immer 8309 als Typ angegeben. Funktioniert aber auch als 8300. Macht keinen Unterschied. Ausser, wenn man ein Partitionstool benutzt wird mit 8309 angegeben, dass es eine verschlüsselte Partition ist.
cryptsetup open funktioniert hier.

In /boot/loader/entries/arch-uefi.conf hast du die Zeile
cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de init=/usr/lib/systemd/systemd locale=de_DE.UTF-8
die mußte ich ändern in
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de init=/usr/lib/systemd/systemd locale=de_DE.UTF-8
was auch funktioniert ist
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw

Auch ein Mercy an dich!!
Gruß aus DN
Greg
Tausend Dank!
Bliebe nur noch das Rätsel zu lösen was DN heißt? Düren vermute ich.
Greg schriebHabe ich nochmal getestet. statt udev systemd hat nicht funktioniert. Qemu bleibt an der Meldung hängen:
Also bleiben wir bei udev! Danke.

Ich habe systemd genommen, weil dort stand, dass dann auch mehrere Partitionen verschlüsselt werden könnten. Aber wenn es in Quemu nicht geht, gibt das dann nur zusätzlichen Frust und Fehleranfragen im Forum. Also lass ich das mal sein. (Das klärt dann auch die Frage, weshalb überhaupt lvm eingesetzt wird. Was aber erst interessant wird wenn eine SWAP Partition bzw. HOME hinzukommt.)
Für diese Konfiguration könnte man aber auch eine Swap-Datei einsetzen falls swap benötigt wird.
...wenn man ein Partitionstool benutzt wird mit 8309 angegeben
Die werden ihren Grund haben, dann machen wir das auch so. Der Hinweis auf gpartet macht es mir jetzt einfach.
(Hier fehlt mir das nötige Hintergrundwissen. Eventuell war 8309 mal für irgend eine bestimmte Formatierung wichtig und bei ext4 ist es egal.)
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de init=/usr/lib/systemd/systemd locale=de_DE.UTF-8
was auch funktioniert ist
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw
Du meinst kürzer wäre besser. Mal überlegen: Wir haben ja ein konfiguriertes System und systemd nimmt diese Einstellung später dann ohnehin aus den Konfigurationsdateien.
Zu diesem Zeitpunkt ist systemd aber noch gar nicht im Spiel. Oder doch? Nimmt systemd-boot hier nicht diese Einstellungen, damit Passwörter auch mit z.B. deutschen Umlauten funktionieren?
Die Hooks-Einträge bewirken ja nur die frühe Fähigkeit des kernels, bestimmen aber alleine nicht welches Tastaturlayout genommen wird.
Also verkürzen wir nur auf:
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de locale=de_DE.UTF-8
Wenn ich mich nicht irre (Karl May)

Dank dir und deinem echt tollen Einsatz kann man jetzt wohl den Roten Balken wieder weg nehmen. Ich tage das gleich nacher alles so ein.

Ganz liebe Grüße
tuxnix
(Matthias aus WI)

Edit: siehe:
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de locale=de_DE.UTF-8
Und jetzt den Link zum fertigen Spickzettel für delta-x8
und ein gutes Gelingen.
tuxnix schriebTausend Dank!
Gerne
tuxnix schriebBliebe nur noch das Rätsel zu lösen was DN heißt? Düren vermute ich.
Genau.
tuxnix schriebHabe ich nochmal getestet. statt udev systemd hat nicht funktioniert. Qemu bleibt an der Meldung hängen:
Also bleiben wir bei udev! Danke.
Ob das jetzt nur an qemu liegt, kann ich nicht sagen. Ich habe sonst keinen PC mit UEFI an dem ich das ausprobieren könnte.
Ich könnte höchstens mal mit Virtualbox probieren wie es da läuft.
tuxnix schriebIch habe systemd genommen, weil dort stand, dass dann auch mehrere Partitionen verschlüsselt werden könnten. Aber wenn es in Quemu nicht geht, gibt das dann nur zusätzlichen Frust und Fehleranfragen im Forum. Also lass ich das mal sein. (Das klärt dann auch die Frage, weshalb überhaupt lvm eingesetzt wird. Was aber erst interessant wird wenn eine SWAP Partition bzw. HOME hinzukommt.)
Für diese Konfiguration könnte man aber auch eine Swap-Datei einsetzen falls swap benötigt wird.
Mehrere Partitionen verschlüsseln ist ja unabhängig von systemd. Müßte eigentlich immer gehen. Ob mit oder ohne LVM. Ohne LVM könnte man eine Rootpartition per Keyboradabfrage entschlüsseln und eine weitere Partition per keyfile in der Rootpartition.
tuxnix schrieb...wenn man ein Partitionstool benutzt wird mit 8309 angegeben
Die werden ihren Grund haben, dann machen wir das auch so. Der Hinweis auf gpartet macht es mir jetzt einfach.
(Hier fehlt mir das nötige Hintergrundwissen. Eventuell war 8309 mal für irgend eine bestimmte Formatierung wichtig und bei ext4 ist es egal.)
Vielleicht mußte man das früher so angeben. Da kenne ich auch zu wenig Hintergrundwissen warum das so ist.
tuxnix schrieboptions cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de init=/usr/lib/systemd/systemd locale=de_DE.UTF-8
was auch funktioniert ist
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw

Du meinst kürzer wäre besser. Mal überlegen: Wir haben ja ein konfiguriertes System und systemd nimmt diese Einstellung später dann ohnehin aus den Konfigurationsdateien.
Zu diesem Zeitpunkt ist systemd aber noch gar nicht im Spiel. Oder doch? Nimmt systemd-boot hier nicht diese Einstellungen, damit Passwörter auch mit z.B. deutschen Umlauten funktionieren?
Die Hooks-Einträge bewirken ja nur die frühe Fähigkeit des kernels, bestimmen aber alleine nicht welches Tastaturlayout genommen wird.
Also verkürzen wir nur auf:
options cryptdevice=/dev/sda2:ARCH root=/dev/mapper/ARCH rw lang=de locale=de_DE.UTF-8
Früher gab es noch das alte Initsystem. Nach der Umstellung mußte man tatsächlich init=/usr/lib/systemd/systemd angeben. Sonst klappte das nicht.
Scheinbar ist der Kernel so konfiguriert, dass der standardmäßig systemd nimmt. Die Umlaute von systemd? Kann ich ja mal ausprobieren mit einem Passwort das Umlaute hat. Also Passwort ßöäü.
tuxnix schriebWenn ich mich nicht irre (Karl May)
Genau.
tuxnix schriebDank dir und deinem echt tollen Einsatz kann man jetzt wohl den Roten Balken wieder weg nehmen. Ich tage das gleich nacher alles so ein.
Naja, in letzter Zeit war ich ja wirklich nicht mehr so aktiv. So konnte ich das wiki Anleitung für Einsteiger (zum Glück) nicht überarbeiten. Zum Glück deshalb, weil du das viel besser gemacht hast als ich es könnte.
Auch ganz viele lieben Grüße nach Wiesbaden aus Dänemark ähh, Düren aus dem Niederrhein.
tuxnix schriebUnd jetzt den Link zum fertigen Spickzettel für delta-x8
und ein gutes Gelingen.
Ebenfalls.

Nachtrag etwas später:

Noch ein Test:
tuxnix schriebInstallation der Basispakete:
pacstrap /mnt base base-devel linux linux-firmware dhcpcd dm-crypt nano
dm-crypt muß raus. Das Paket gibt es nicht.
Vielleicht sollte man noch man-pages man-pages-de man-db hinzufügen.
tuxnix schriebnano /boot/loader/entries/arch-uefi.conf
Und wie folgt anpassen:
...
options cryptdevice=/dev/x2:ARCH root=/dev/mapper/ARCH rw lang=de locale=de_DE.UTF-8
Passwort mit Umlauten funktioniert trotzdem nicht. Könnte daran liegen, dass die keymap nicht definiert ist.
Ob man das auch einstellen kann?? Witzigerweise funktioniert die Entschlüsselung wenn ich per Isoimage boote.
Hallo Greg,

Die HOOKS= ...udev...kann ich auch mal ausprobieren.
Ich bin gerade dabei, das Ganze auf BIOS-Rechner und systemd zu übersetzen und da hab ich tatsächlich noch einen Thinkpad R500 frei, der das mal brauchen könnte.
Erstmal ist es doch gut wenn es funktioniert und udev ist ja auch das was sonst immer genommen wird.
Eine zweite Partition muss auch nicht sein, ŚWAP wird dann halt mittels Swap-Datei gemacht, falls das gebraucht wird.
Greg schrieb Und eine weitere Partition per keyfile in der Rootpartition.
Auch nicht schlecht. Daran hab ich noch gar nicht gedacht. Ich hab dabei immer nur an einen Passwort-Stick gedacht.
Da lass ich mir aber noch etwas Zeit darüber nach zu sinnen, wie und ob ich das in den Spickern zum Einsatz bringe.
Greg schrieb Die Umlaute von systemd? Kann ich ja mal ausprobieren mit einem Passwort das Umlaute hat. Also Passwort ßöäü.
Das wäre natürlich sehr gut es wirklich mal getestet zu haben. Immerhin geht es um die Daten die weg sein könnten wenn da was schief läuft.

Ich frag mich jetzt im Augenblick gerade mal was recht Abwegiges. Bei der Passworteingabe werden die Buchstaben ja nicht auf dem Bildschirm angezeigt.
Wenn man den 'cryptsetup...luksFormat...' Befehl eingibt und damit das Passwort festlegt und in dem Augenblick die US Tastaturbelegung gültig wäre, dann bräuchte man weder bei den Hooks noch bei systemd-boot die frühe Tastaturumstellung zu konfigurieren. Auch darf der user ruhig an sein Passwort mit Umlauten dabei denken. Der Rechner nimmt ohnehin nur die Tastenreihenfolge auf.
Man müsse einfach nur vor diesem Installationsschritt den 'loadkeys us' Befehl ausführen und danach wieder mit 'loadkezs de' umschalten und die ganze Einstellerei wäre unnötig.
Aber wahrscheinlich ist die Idee dann doch etwas zu verrückt um sie in eine offizielle Anleitung zu schreiben. 😉
Und genau an dieser Stelle darf wirklich nichts schief gehen !!!

Danke für's Lob, ich hab halt so die Ader alles (siehe oben) so lange auseinander zu nehmen und wieder anders zusammenzusetzen bis es dann mal passt.
Ursprünglich hab ich mich geärgert, dass jemand eine kleine Anleitung von mir mit ganz langen Erklärungen über gdisk und wie man genau gdisk benutzt überfrachtet hatte.
(Ich habe auch bis heute nur BIOS-Rechner (und ARM) und an gdisk zuvor auch noch nie auch nur einen Gedanken verschwendet)
Dabei ist mir aufgefallen, dass gdisk noch nirgendwo in der Wiki beschrieben war. Der 2. Anstoß war der Moment wo einige die AfE berechtigter Weise löschen wollten. Was auch günstig war, sonst hätte ich mich da wohl nicht dran gewagt. Jedenfalls fiel mir dann auf, dass dort immer wieder aufs neue gdisk und fdisk beschrieben wurde.
Ich denke mir im Nachhinein, dass die Umstellung auf UEFI in der AfE nie konsquent Nachvollzogen wurde. Als ich darauf kam, dass es einfacher wird, wenn man zwischen BIOS-Rechnern und UEFI-Rechnern einen Schnitt macht, war auch in der Anleitung wieder eine Struktur herzustellen. Beim Rest bin ich einfach den Vorschlägen gefolgt die schon lange vorher gemacht wurden. Diese Vorschläge hatten alle Hand und Fuß.

So jetzt Schluss, sonst werden wir ins Cafè verbannt.
Grüße nach DN
tuxnix
Hallo Tuxnix,
siehe noch Nachtrag von mir oben.
tuxnix schrieb Die Umlaute von systemd? Kann ich ja mal ausprobieren mit einem Passwort das Umlaute hat. Also Passwort ßöäü.
Das wäre natürlich sehr gut es wirklich mal getestet zu haben. Immerhin geht es um die Daten die weg sein könnten wenn da was schief läuft.
Habe ich schon ausprobiert. Trotz der lokalen Angaben steht die Tastatur in deutsch zu diesem Zeitpunkt nicht zur Verfügung. Auch suche in den unendlichen Weiten des Internets brachte nichts.
Wer grub benutzt könnte dort auf deutsche Tastatur umstellen.
tuxnix schrieb Ich frag mich jetzt im Augenblick gerade mal was recht Abwegiges. Bei der Passworteingabe werden die Buchstaben ja nicht auf dem Bildschirm angezeigt.
Wenn man den 'cryptsetup...luksFormat...' Befehl eingibt und damit das Passwort festlegt und in dem Augenblick die US Tastaturbelegung gültig wäre, dann bräuchte man weder bei den Hooks noch bei systemd-boot die frühe Tastaturumstellung zu konfigurieren. Auch darf der user ruhig an sein Passwort mit Umlauten dabei denken. Der Rechner nimmt ohnehin nur die Tastenreihenfolge auf.
Man müsse einfach nur vor diesem Installationsschritt den 'loadkeys us' Befehl ausführen und danach wieder mit 'loadkezs de' umschalten und die ganze Einstellerei wäre unnötig.
Aber wahrscheinlich ist die Idee dann doch etwas zu verrückt um sie in eine offizielle Anleitung zu schreiben. 😉
Und genau an dieser Stelle darf wirklich nichts schief gehen !!!
Das funktioniert garantiert. Super Idee. Aber, was machst du wenn du mal so da dran mußt. Mit Isoimage. Denkst du noch daran das Isoimage auf englisch zu lassen um im Notfall an die Daten zu kommen?
tuxnix schrieb...Dabei ist mir aufgefallen, dass gdisk noch nirgendwo in der Wiki beschrieben war. Der 2. Anstoß war der Moment wo einige die AfE berechtigter Weise löschen wollten. Was auch günstig war, sonst hätte ich mich da wohl nicht dran gewagt. Jedenfalls fiel mir dann auf, dass dort immer wieder aufs neue gdisk und fdisk beschrieben wurde.
Doch das war mal unter gpt was heute gdisk ist. Den Artikel kennst du ja. Grins.
tuxnix schriebSo jetzt Schluss, sonst werden wir ins Cafè verbannt.
Grüße nach DN
tuxnix
Ja, ich glaube jetzt sind wir durch.
Maachet joot!!
Gruß nach WI
Greg
Greg schriebDas funktioniert garantiert. Super Idee. Aber, was machst du wenn du mal so da dran mußt. Mit Isoimage. Denkst du noch daran das Isoimage auf englisch zu lassen um im Notfall an die Daten zu kommen?
Das wäre keine Schwierigkeit. Aber ich müsste nochmal gründlich darüber nachdenken, was passiert wenn dann mal eine andere Tastatur angeschlossen wird, ob dann auch wirklich alle Zeichen erlaubt sind.
Aber wie kann das sein, dass die Hooks und system-boot Konfiguration wie wir sie gemacht haben nicht funzt?
In Dirks Anleitung wird auch systemd-boot eingesetzt. In diese Anleitung wird zuerst mit 'loadkeys de-latin1' umgestellt, dann die 'HOOKS=(base udev autodetect modconf block keyboard keymap encrypt lvm2 filesystems fsck shutdown)' und die Zeile von systemd-boot auf 'options cryptdevice=/dev/nvme0n1p2:main root=/dev/mapper/main-root rw lang=de init=/usr/lib/systemd/systemd locale=de_DE.UTF-8' konfiguriert.
Mal angenommen du hast recht und beim Booten wird vor der Passwortabfrage nicht auf Deutsch und deutsche Tastatur gestellt, dann fliegt der erste hier kräftig rein, der ein Passwort mit einem Zeichen nutzt das auf der US-Tastatur auf einer anderen Taste liegt. Und diese Anleitung existiert schon über ein halbes Jahr.
Ich mach mal Pause. Dann kommt oft der richtige Gedanke von allein.

Liebe Grüße
Matthias

Edit #2 Dein Test war wohl verkehrt! Du musst zuerst auf loadkeys de-latin1 einstellen, sonst hast du gar keine Umlaute. Wenn du vorher nur ein 'loadkeys de' gemacht hast sind z.B. 'öä' = '[]' deshalb konnte dein Umlautest auch nicht funzen. 😉
Hallo Greg, schau noch mal den Edit 2# ob meine Vermutung richtig ist.
Greg schriebDoch das war mal unter gpt was heute gdisk ist.
Ja ich hab das etwas verkürzt dargestellt. Das mit den irreführenden Benennungen kommt noch hinzu.
Überall stand etwas von gpt oder ms-dos Tabelle obwohl das aber niemand erklärt hat. Dann hab ich erst einmal Forschung betrieben was das ist und bin nach dem lesen von x Anleitungen bei denen immer wieder inhaltslos die Wichtigkeit von GPT beschworen wurde letztlich darauf gekommen das abzukürzen in: "Bei UEFI immer gdisk nehmen.".

Quintessence, ich geb mir extrem viel Mühe mit der Exaktheit von Namen, Praxisbezogenheit und Struktur bei den Artikeln die ich verfasse. Und bei der Wortwahl bessere ich oft drei mal nach bis ich die treffendste Bezeichnung gefunden habe.

Grüße nach DN