Seit ca. einem Jahr tritt Arch Linux immer stärker in meinen Linux-Fokus. Dieser Beitrag beschreibt die Installation von Arch Linux auf einem Notebook. Das neue System soll folgende Merkmale aufweisen:
- Vollverschlüsselung (Betriebssystem + Daten)
- LVM
- systemd-boot (kein GRUB)
Ich gehe davon aus, dass es keine weiteren Betriebssysteme gibt und die gesamte SSD genutzt werden soll. Ich gehe auch davon aus, dass Sie nicht an UEFI Secure Boot interessiert sind. (Bei mir scheidet Secure Boot aus, weil ich auf meinem Notebook auf die NVIDIA-Treiber angewiesen bin.) Falls Sie Secure Boot verwenden wollen, müssen Sie zum Booten GRUB anstelle von systemd-boot verwenden.
Partitionierung
Die Installation beginnt im Live-System des Arch Linux Images (Download, das vorher auf einen USB-Stick übertragen werden muss. Den Umgang mit dem Live System habe ich zuletzt in diesem Blog-Beitrag beschrieben, weswegen ich hier auf Wiederholungen verzichte. Beachten Sie insbesondere die Möglichkeit, im Live-System einen SSH-Server zu starten und die weitere Installation dann auf einem anderen Rechner via SSH durchzuführen.
Die Grundidee der Arch-Linux-Installation besteht darin, dass Sie alle erforderlichen Dateisysteme manuell einrichten und unter /mnt
einbinden. Erst dann startet der eigentliche Installationsprozess.
Die Partitionierung erfolgt mit parted
. Beachten Sie, dass nur zwei Partitionen erforderlich sind:
- Die erste Partition dient gleichzeitig EFI- und Boot-Partition. Sie wird später unter dem Pfad
/boot
genutzt und sowohl die für EFI erforderlichen Dateien (/boot/EFI
) als auch die Boot-Dateien (initramfs-xxx
undvmlinux-xxx
direkt in/boot
) enthalten. Die reservierten 2 GByte sind mehr als großzügig. Aktuell (ein Monat nach der Installation) werden nur 76 MByte genutzt. Aber ein wenig Reserve — gegebenenfalls für die Installation weiterer Distributionen — kann nicht schaden. -
Die zweite Partition dient als LUKS-Container, wird also verschlüsselt.
mkpart ... -1mib
bedeutet, dass die gesamte Disk bis knapp an deren Ende genutzt werden soll.
parted /dev/nvme1n1
(parted) mklabel gpt
(parted) mkpart esp 1mib 2000mib
(parted) mkpart crypt 2001mib -1mib
(parted) set 1 boot on
(parted) set 1 esp on
(parted) unit mib
(parted) print
Modell: Samsung SSD 970 EVO Plus 2TB (nvme)
Festplatte /dev/nvme1n1: 1907729MiB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1,00MiB 2000MiB 1999MiB fat32 esp boot, esp
2 2001MiB 1907629MiB 1905628MiB crypt
Dateisysteme, LUKS und LVM einrichten
Für die erste Partition reicht ein simples FAT32-Dateisystem:
mkfs.fat -F 32 /dev/nvme1n1p1
In der zweiten Partition wird mit cryptsetup luksFormat
ein verschlüsselter Container eingerichtet. cryptsetup luksOpen
aktiviert den Container. Natürlich muss bei beiden Kommandos das gewünschte Passwort angegeben werden:
cryptsetup luksFormat --type luks2 /dev/nvme1n1p2
cryptsetup luksOpen /dev/nvme1n1p2 mycrypt
Der gesamte Container soll als Physical Volume (PV) für LVM verwendet werden:
pvcreate /dev/mapper/mycrypt
Das PV ist vorerst das einzige Element für den LVM-Datenpool, also für die Volume Group (VG):
vgcreate vgcrypt /dev/mapper/mycrypt
Innerhalb der Volume Group habe ich zwei Logical Volumes (LVs) angelegt, eine mit 200 GByte für Arch Linux und eine weitere mit 600 GByte für /home
. In beiden LVs habe ich ein ext4-Dateisystem erstellt.
lvcreate -L 200G -n archroot vgcrypt
lvcreate -L 600G -n archhome vgcrypt
mkfs.ext4 /dev/mapper/vgcrypt-archroot
mkfs.ext4 /dev/mapper/vgcrypt-archhome
Dateisysteme in /mnt einbinden
Bevor die eigentliche Installation losgeht, müssen die neuen Dateisysteme unter /mnt
in den Verzeichnisbaum des Live-Systems integriert werden:
mount /dev/mapper/vgcrypt-archroot /mnt
mkdir /mnt/boot
mkdir /mnt/home
mount /dev/nvme1n1p1 /mnt/boot
mount /dev/mapper/vgcrypt-archhome /mnt/home
Installation und Konfiguration des Minimalsystems
pacstrap
installiert ein Minimalsystem nach /mnt
. genfstab
erzeugt die zum Setup passende Datei /etc/fstab
. arch-chroot
wechselt in das neue Minimalsystem. pacman
installiert einige Basispakete.
pacstrap /mnt base linux linux-firmware
genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mnt
pacman -S lvm2 nano man zile dhclient networkmanager
Ein symbolischer Link kümmert sich um die Einstellung der richtigen Zeitzone:
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime
Ich will englische und deutsche Sprachdateien, die Defaultsprache Deutsch und ein deutsches Tastaturlayout:
cat <<EOF > /etc/locale.gen
de_DE.UTF-8 UTF-8
en_US.UTF-8 UTF-8
EOF
locale-gen
echo "LANG=de_DE.UTF-8" > /etc/locale.conf
echo "KEYMAP=de-latin1" > /etc/vconsole.conf
Einstellung des Hostnamens:
echo "myhostname" > /etc/hostname
cat << EOF > /etc/hosts
127.0.0.1 localhost
::1 localhost
127.0.1.1 myhostname myhostname.fritz.box
EOF
Einstellung des root
-Passworts:
passwd
Boot-Konfiguration
Damit der Boot-Vorgang funktioniert, muss die Initramfs-Datei Treiber für LVM und die Entschlüsselung des LUKS-Containers enthalten. Deswegen muss mit einem Editor die Variable HOOKS
in der Datei /etc/mkinitcpio.conf
angepasst werden. Achtung: Die Reihenfolge der Hooks ist wichtig!
# diese Zeile in der Datei /etc/mkinitcpio.conf anpassen
HOOKS=(base udev autodetect keyboard modconf block encrypt lvm2 filesystems fsck)
Mit mkinitcpio
erzeugen Sie nun die Initramfs-Datei.
mkinitcpio -p linux
bootctl
richtet systemd-boot ein. Das Kommando setzt voraus, dass /boot
die EFI System Partition (ESP) ist. Am Beginn der Installation ist diese Partition mit parted
entsprechend markiert worden (set 1 boot on
und set 1 esp on
).
bootctl --path=/boot/ install
Nun muss noch der Bootloader konfiguriert werden. Dazu ermitteln Sie zuerst mit blkid
den UUID der verschlüsselten Partition:
blkid /dev/nvme1n1p2
/dev/nvme1n1p2: UUID="44fbbcd5-8d8e-4978-9c32-ffcaa646554f" <---
TYPE="crypto_LUKS"
PARTLABEL="crypt"
PARTUUID="798a1e88-2a94-4199-bd1e-ba34d17fbe06"
Das erste cat
-Kommando erzeugt die Datei /boot/loader/loader.conf
. Diese Datei besagt, dass systemd-boot standardmäßig nach 3 Sekunden die Booteinstellungen aus /boot/loader/entries/arch.conf
berücksichtigen soll:
cat << EOF > /boot/loader/loader.conf
timeout 3
editor 0
default arch.conf
EOF
Das zweite cat
-Kommando erzeugt den Menüeintrag für Arch-Linux.
cat << EOF > /boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=UUID=todo:cryptlvm root=/dev/vgcrypt/archroot quiet rw
EOF
In diese Datei müssen Sie nun mit einem Editor die zuvor ermittelte UUID eintragen. In meinem Fall (vergleichen Sie das Ergebnis von blkid
oben) sieht die Datei dann so aus:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=UUID=44fbbcd5-8d8e-4978-9c32-ffcaa646554f:cryptlvm root=/dev/vgcrypt/archroot quiet rw
Zur Kontrolle können Sie bootctl
ohne Parameter ausführen. Das Ergebnis sollte in etwa wie folgt aussehen:
bootctl
System:
Firmware: UEFI 2.60 (Lenovo 0.4992)
Secure Boot: disabled (setup)
TPM2 Support: yes
Boot into FW: active
Current Boot Loader:
Product: systemd-boot 250.3-2-arch
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ Default entry control
✓ One-shot entry control
✓ Support for XBOOTLDR partition
✓ Support for passing random seed to OS
✓ Load drop-in drivers
✗ Boot loader sets ESP information
ESP: n/a
File: └─/EFI/BOOT/BOOTX64.EFI
Random Seed:
Passed to OS: no
System Token: set
Exists: yes
Available Boot Loaders on ESP:
ESP: /boot (/dev/disk/by-partuuid/84bd0fe5-be18-4f5a-991c-b28c2a8899ef)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 250.3-4-arch)
File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 250.3-4-arch)
Boot Loaders Listed in EFI Variables:
...
Boot Loader Entries:
$BOOT: /boot (/dev/disk/by-partuuid/84bd0fe5-be18-4f5a-991c-b28c2a8899ef)
Default Boot Loader Entry:
title: Arch Linux
id: arch.conf
source: /boot/loader/entries/arch.conf
linux: /vmlinuz-linux
initrd: /initramfs-linux.img
options: cryptdevice=UUID=44fbbcd5-8d8e-4978-9c32-ffcaa646554f:cryptlvm root=/dev/vgcrypt...
Reboot, Gnome-Installation
Mit Strg+D verlassen Sie nun die chroot
-Umgebung. reboot
startet den Rechner neu. Wenn alles gut geht, erscheint das minimalistische Boot-Menü von systemd-boot. Wenige Sekunden später landen Sie in einer Textkonsole mit dem ebenso minimalistischen Arch Linux.
Da mein Notebook mit einem Ethernet-Kabel an das lokale Netzwerk verbunden ist, kann die Netzwerkverbindung unkompliziert durch die Aktivierung des NetworkManagers hergestellt werden.
systemctl enable --now NetworkManager
Danach habe ich den SSH-Server installiert:
pacman -Syu openssh
Für einen Verbindungsaufbau als root
mit Passwort muss /etc/ssh/sshd_config
geändert werden (PasswordAuthentication yes
und PermitRootLogin yes
). Danach aktivieren Sie den SSH-Server und können alle weiteren Arbeiten via SSH durchführen.
systemctl enable --now sshd
Im nächsten Schritt ist es zweckmäßig, einen Benutzer (hier kofler
) sowie sudo
einzurichten:
pacman -S sudo
useradd -m kofler
usermod -a -G wheel kofler
passwd kofler
Jetzt ist es an der Zeit, eine grafische Benutzeroberfläche zu installieren. Ich habe mich für Gnome entschieden:
pacman -S xorg gnome
pacman
stellt nun eine Menge Detailfragen. Ich habe alle xorg- und Gnome-Pakete installiert und mich für wireplumber
als Pipewire-Session-Manager entschieden. Das Grafiksystem starten Sie wie folgt:
systemctl enable --now gdm
Überraschend problemlos verläuft die Installation der NVIDIA-Treiber:
pacman -S nvidia
reboot
Aktuell läuft Gnome 41 unter Xorg absolut zufriedenstellend. Mit Gnome 42 werde ich später testen, ob die Kombination aus NVIDIA + Wayland + Gnome mittlerweile praxistauglich ist.
Update 7.4.2022: Getestet mit Gnome 42 und NVIDIA-Treiber (Version 510). Um das Modesetting zu aktivieren, habe ich einen neuen systemd-boot-Loader-Eintrag mit nvidia-drm.modeset=1
erstellt. Das System samt Gnome + Wayland lässt sich problemlos hochfahren, aber der externe Monitor bleibt schwarz. (Der Monitor wird in den Gnome-Einstellungen erkannt, ich kann ihn konfigurieren, aber egal was ich mache: Der Monitor bleibt im Energiesparmodus.) Ich weiß, dass xorg veraltet ist, aber es funktioniert wenigstens :-)
Erfahrungen und Anmerkungen
Die fertige Anleitung liest sich so, als könnte man nicht viel falsch machen. Das täuscht. Ich habe den Prozess zuerst in einer virtuellen Maschine samt EFI »geübt«, und es waren mehrere Versuche notwendig, bis es wirklich funktioniert hat. Natürlich gibt es im Internet Dutzende Arch-Linux-Installationsanleitungen — aber jede bezieht sich auf einen anderen Sonderfall, manche sind veraltet etc. Insofern trifft zu, was ich schon früher geschrieben habe: Arch Linux richtet sich an fortgeschrittene Anwender.
Ich habe mein Glück auch mit archinstall
versucht, bin aber gescheitert. Ich bin mir nicht sicher, ob meine Setup-Wünsche für archinstall
zu spezifisch waren oder ob ich einfach zu blöd bin, um archinstall
korrekt zu verwenden.
Auf grafische Installer (Manjaro etc.) habe ich verzichtet, weil ich ein originales Arch-Linux-System haben wollte.
Meine Arch-Linux-Installation ist ein Experiment mit dem Ziel, Ubuntu als Haupt-Desktop-OS zu verlassen. Ob das glückt, kann ich noch nicht sagen, aber ich werde im Blog weiter darüber berichten. Aktuell habe ich Arch Linux und Ubuntu 21.10 parallel im Betrieb. Ich warte jetzt das Update auf Ubuntu 22.04 ab, aber die Tendenz geht Richtung Arch Linux :-)
Post Scriptum: PCIe-SSDs, LUKS, 4k-Blöcke und Benchmark-Tests
Es gibt im Internet Berichte, wonach LUKS deutlich schneller ist, wenn es 4k-Blöcke verwendet (siehe die Links am Ende des Artikels). Meine SSD, eine Samsung 970 EVO Plus, unterstützt aber nativ keine 4k-Blöcke, sondern meldet wie eine Uraltfestplatte 512-Byte-Blöcke. Manchmal hat man ernsthafte Zweifel am Zustand der IT-Industrie: 512-Byte-Blöcke bei einer SSD mit 2 TByte!
Meine SSD lässt sich, im Gegensatz zu stärker Pro-orientierten SSDs von Samsung, auch nicht mit nvme format
auf 4k-Blöcke umstellen. Es ist aber möglich, mit cryptsetup luksFormat --type luks2 --sector-size 4096
LUKS-intern 4k-Blöcke zu erzwingen. Ich habe vor der eigentlichen Installation einige Stunden lang recherchiert und diverse Benchmark-Tests durchgeführt. Die Ergebnisse waren nicht schlüssig; manche Tests waren mit LUKS-4k schneller als bei einem Standard-LUKS-Setup, andere aber langsamer. (Ideal wäre offensichtlich eine SSD, die 4k-Blöcke nativ unterstützt. Dann verwendet auch LUKS standardmäßig 4k und alles passt zusammen. Mangels passender Hardware kann ich aber nicht sagen, wie viel Performance das gebracht hätte.)
Letztenendes habe ich dieses Nebenthema nicht mehr weiter verfolgt und bin bei den Defaulteinstellungen von cryptsetup
geblieben, somit bei meiner SSD also bei 512-Byte-Blöcken. Sollten Sie vor dem Kauf einer SSD stehen und vor haben, LUKS zu verwenden, lohnt sich aber eine kurze Recherche, ob die SSD 4k-Blöcke unterstützt oder nicht.
Und noch eines: Ja, die Verschlüsselung durch LUKS kostet bei PCIe-SSDs messbar I/O-Performance. Ein ext4-Dateisystem in einer simplen Partition ist bei synthetischen Tests ca. 10 bis 25 % schneller als eines in einem LUKS-Container.
Davon losgelöst ist es selten sinnvoll, sich von synthetischen Benchmark-Tests verrückt machen zu lassen. Diese Tests haben eingeschränkte Relevanz auf den alltäglichen Desktop-Betrieb — selbst wenn man wie ich viel mit virtuellen Maschinen, deren Images sowie mit Docker hantiert. Anders sieht es aus, wenn Sie einen stark I/O-lastigen Server optimieren möchten — aber in diesem Fall werden Sie vermutlich auf die Verschlüsselung ganz verzichten.
Quellen/Links
- https://archlinux.org/download
- https://wiki.archlinux.org/title/installation_guide
- https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system
- https://wiki.archlinux.org/title/Systemd-boot
- https://gist.github.com/OdinsPlasmaRifle/e16700b83624ff44316f87d9cdbb5c94
- https://wiki.archlinux.org/title/PipeWire#Session_manager
- https://wiki.archlinux.org/title/NVIDIA
- https://kofler.info/arch-linux-installieren
- https://kofler.info/arch-linux-und-archinstall
SSD, LUKS und 4k-Blöcke
- https://kopfkrieg.org/2022/01/16/ssds-sektorgrossen-und-das-jahr-2022
- https://www.reddit.com/r/Fedora/comments/rzvhyg/default_luks_encryption_settings_on_fedora_can_be
- https://unix.stackexchange.com/questions/93791
- https://wiki.archlinux.org/title/Advanced_Format
- https://unix.stackexchange.com/questions/93791
archinstall sollte das mittlerweile auch können. Warum nicht einfach das nehmen?
ich hab’s versucht, aber bin gescheitert
Servus Herr Kofler!
Wie kann ich denn bei Arch beim booten weitere LUKS-verschlüsselte Platten entsperren? Reicht es, wenn ich in den Bootloader-Optionen eine weitere Direktive in der Form „cryptdevice=UUID=:cryptdisk2“ angebe? Wenn ich z.B. Ubuntu mit LUKS installiere, erkennt der Installer automatisch weitere LUKS-Devices, die beim booten entsperrt werden. Wenn das Paßwort der LUKS-Geräte identisch ist, muß man es sogar nur einmal eingeben.
Bei Arch muss man offenbar manuell noch etwas nachsteuern. Das Thema ist u.a. auch relevant, wenn man im obigen Beispiel die vgcrypt um eine zusätzliche Platte erweitern oder gar spiegeln möchte.
Schöne Grüße!
Ich habe das selbst noch nie ausprobiert, aber ich hab‘ mir schon vor Wochen ein Bookmark zu dem Thema gemacht. Vielleicht hilft die folgende Seite weiter:
https://unix.stackexchange.com/questions/392284/using-a-single-passphrase-to-unlock-multiple-encrypted-disks-at-boot