Neue Incus-Version verbessert Konfiguration von Cluster Groups
Incus jongliert Container und virtuelle Maschinen. Die neue Version kann einen Sub-Pfad eines Volumes als Disk verwenden und isolierte OVN-Netzwerke erzeugen.
Incus jongliert Container und virtuelle Maschinen. Die neue Version kann einen Sub-Pfad eines Volumes als Disk verwenden und isolierte OVN-Netzwerke erzeugen.
Die Firma Cyberus Technologies hat VirtualBox die Zusammenarbeit mit KVM beigebracht.
Die in Dresden ansässige Firma Cyberus hat VirtualBox die Zusammenarbeit mit KVM beigebracht. Dies wiederum bietet zahlreiche Vorteile.
Die in Dresden ansässige Firma Cyberus hat VirtualBox die Zusammenarbeit mit KVM beigebracht. Dies wiederum bietet zahlreiche Vorteile.
Oracles VirtualBox erhält von der Firma Cyberus aus Dresden ein KVM-Backend. Das in Linux integrierte KVM bringt einige Vorteile gegenüber Oracles Kernel-Treiber.
Die Entwickler von ScummVM haben Version 2.8 veröffentlicht. Der Slogan für ScummVM 2.8.0 lautet Mysterien, Mammuts und Muppets. Das Team hat laut eigenen Angaben fleißig an neuen Engines gearbeitet und bestehende verbessert. Die Liste der unterstützten Spiele ist damit deutlich gewachsen. Insgesamt werden nun unter anderem diese zusätzlichen 27 Spiele unterstützt: In der offiziellen Ankündigung kannst Du nachlesen, dass insgesamt 50 neue Spiele unterstützt werden und es gibt fünf neue Engines. Neue Plattformen und schnellere Grafiken Das Team gibt an, […]
Der Beitrag ScummVM 2.8 unterstützt 50 neue Spiele ist von bitblokes.de.
NixOS, die Distribution rund um den Paketmanager Nix
Chris Lattner hat LLVM begründet und Swift erfunden. Die Sprache Mojo soll Vorteile von Python und C vereinen.
Die neue Programmiersprache Mojo soll allen KI-Programmierern eine Heimat bieten und dabei die Einfachheit von Python mit der Geschwindigkeit von C kombinieren. Das zumindest verspricht das KI-Startup Modular, das von LLVM-Gründer Chris Lattner mitbegründet worden ist und von diesem derzeit als CEO geführt wird.
Mojo baut dabei direkt auf Python auf, das als Grundlage der aktuellen KI-Forschung gilt und für zahlreiche Frameworks wie etwa Tensorflow oder Pytorch genutzt wird. Die neue Sprache soll offenbar eine Art Übermenge für Python selbst sein und den Zugriff auf das komplette Python-Ökosystem bieten. Modular zählt hier vor allem die für Berechnungen wichtigen Bibliotheken Numpy und Pandas auf.
Erreicht werden sollen die Geschwindigkeitsverbesserungen von Mojo vor allem dank einer Laufzeitumgebung, die Modular selbst erstellt, sowie der Compilertechnik MLIR. Bei dieser handelt es sich um eine neue Art der Intermediate Representation (IR), die Lattner selbst gemeinsam mit weiteren Forscher bereits vor mehr als drei Jahren vorstellte.
Statt diese Art der Compiler-Zwischenschicht je Sprache selbst zu erstellen oder auch für bestimmte Hardware zu optimieren, soll MLIR durch einen Mehrschichtansatz (Multi-Level) eben verschiedene Probleme lösen, diese aber letztlich in einem Projekt zusammenführen.
Für Mojo ergebe sich dank MLIR ein Zugriff auf die Beschleunigereinheiten von KI-Hardware. So sollen Threads ebenso genutzt werden können wie Low-Level-Funktionen, etwa Tensor-Cores oder die AMX-Erweiterungen. Bei spezifischen numerischen Berechnungen soll Mojo so bis zu 35.000-fach schneller sein als Python und damit auch schneller als üblicher C++-Code.
Noch befinde sich Mojo in der Entwicklung. Modular bietet aber eine Art Spielwiese auf Grundlage von Jupyter-Hub, um die Sprache bereits auszuprobieren. Dazu ist allerdings noch eine Anmeldung notwendig.
Der Beitrag Mojo: LLVM-Gründer will Python für KI-Anwendung aufbohren erschien zuerst auf Linux-Magazin.
Nachdem ich bereits beschrieben habe, wie ich Labor-Umgebungen mit Ansible in KVM erstelle, beschreibe ich in diesem Artikel, wie ich die dort verwendeten Gold-Images erstelle.
Ich erkläre kurz, was ein Gold-Image ist und wofür man es verwendet. Anschließend zeige ich, wie man mit dem Programm qemu-img
eine Image-Datei auf der Kommandozeile erzeugt und diese im Installationsprozess für die Partitionierung und Erzeugung des LVM nutzt. Im Anschluss daran dokumentiere ich, welche Laufwerke und Dateisysteme ich für welchen Zweck erstelle und warum ich mich so entschieden habe. Der Text endet mit einer Sammlung von Quellen und weiterführenden Links zum Thema.
Der Text soll mir helfen, in Zukunft nachvollziehen zu können, warum ich mich so entschieden habe. Für euch mag er als Information dienen, wie ich im Unterschied zu euch an das Thema herangehe. Wer noch nie etwas von Gold-Images gehört hat, findet in diesem Text eine Erklärung und passende Quellen dazu.
Ein Gold-Image, auch Golden Image oder Baseline-Image genannt, bezeichnet eine Vorlage (engl. template) in virtuellen Umgebungen, woraus sich virtuelle Maschinen (VMs) klonen lassen (siehe [1-5]).
In ein Gold-Image werden all die Softwarekomponenten, Anwendungen und Konfigurationsoptionen aufgenommen, welche Bestandteil aller davon abgeleiteten VMs sein sollen. Klonen ermöglicht die schnelle Bereitstellung neuer Systeme. Dies ist besonders dann nützlich, wenn sich die VMs sehr ähnlich sind und man nur eine geringe Anzahl von Gold-Images pflegen muss.
Ich nutze Gold-Images, um für die von mir verwendeten Linux-Distributionen jeweils eine Installation manuell durchzuführen, welche die minimal erforderlichen Pakete enthält, um die abgeleiteten Klone mit Ansible fertig konfigurieren zu können. Wie ich dabei vorgehe, beschreibe ich in den folgenden Abschnitten.
Im ersten Schritt erstelle ich Image-Dateien im qcow2-Format. Bei diesem Format handelt es sich um das heute gebräuchliche Format in KVM-/QEMU-Umgebungen. Zur Erstellung verwende ich das QEMU disk image utility qemu-img.
Die allgemeine Form des Befehls lautet (Details siehe Manpage qemu-img(1)):
qemu-img create -f FORMAT DATEINAME GRÖßE
Der folgende Befehl erstellt eine Image-Datei im qcow2-Format, mit 20 Gigabyte Größe und dem Dateinamen debian11-template.qcow2 im Pfad /var/lib/libvirt/images/:
$ qemu-img create -f qcow2 /var/lib/libvirt/images/debian11-template.qcow2 20G
Formatting '/var/lib/libvirt/images/debian11-template.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=21474836480 lazy_refcounts=off refcount_bits=16
Dabei werden die 20 GB nicht sofort alloziert. Zu Beginn belegt die Datei lediglich einige Kilobyte und kann je nach Nutzung auf die maximale Größe von 20 GB anwachsen. Diese Bereitstellungsform ist auch als Thin provisioning bekannt.
ls -sh /var/lib/libvirt/images/debian11-template.qcow2
193K /var/lib/libvirt/images/debian11-template.qcow2
Es lässt sich auf diese Weise mehr Speicherplatz provisionieren, als tatsächlich im System zur Verfügung steht. Dabei gilt jedoch zu beachten, dass sich die Physik nicht betrügen lässt. Man ist gut beraten, den realen Speicherverbrauch zu überwachen, um volllaufende Dateisysteme zu vermeiden.
Bei der Installation des Gold-Images für Labor-Umgebungen mache ich es mir relativ einfach. Ich erstelle z.B. im virt-manager oder cockpit eine VM, die ich von einem Installations-ISO-Image der jeweiligen Distribution installiere.
Bei Debian installiere ich für gewöhnlich ein System ohne grafische Oberfläche, welches zusätzlich zur Basis-Installation lediglich die Paketgruppen SSH-Server und System-Werkzeuge umfasst. Bei Fedora oder RHEL führe ich die Minimal-Installation durch.
Ob bzw. welches Passwort für den Benutzer root vergeben wird, ist an dieser Stelle nicht wichtig, da dies beim Klonen in eine neue VM durch die Ansible-Rolle kvm_provision_lab geändert wird.
Der Installer erkennt eine Festplatte, die in diesem Text exemplarisch als /dev/vda bezeichnet wird. Diese wird nun wie folgt konfiguriert.
Das optimale Partitionslayout hängt vom konkreten Anwendungsfall ab und kann sich je nach Umgebung stark unterscheiden. Das von mir verwendete Layout passt aktuell am besten zu meinen Anforderungen. Es mag in Zukunft völlig anders aussehen.
Ich beschreibe, welche Partitionen ich erstelle und erläutere, warum ich mich zum Zeitpunkt der Erstellung dieses Textes dafür entschieden habe. Bitte übernehmt dieses Layout nicht stumpf, sondern überlegt, ob es zu euren Anforderungen passt.
In dieser Partition werden die Kernel und das initramfs abgelegt. Nach meiner Erfahrung reicht eine Größe von 1 GiB aus, um auch einige ältere Kernel vorzuhalten. Formatiert habe ich diese Partition mit dem Dateisystem ext4.
Ich bevorzuge ext4 gegenüber XFS, da es sich im Gegensatz zu letzterem auch verkleinern lässt. Zugegeben, dass dies notwendig ist, ist mir in 20 Jahren nur einmal untergekommen. Doch in diesem einen Moment war ich froh, dass es möglich war.
Der Logical Volume Manager (LVM) (siehe [11-13]) bietet die Möglichkeit, Partitionen (genaugenommen Logical Volumes) für weitere Einhängepunkte zu erstellen, welche sich später noch flexibel in der Größe anpassen lassen (Vergrößern und Verkleinern). Und dies, ohne die verwendeten Dateisysteme aushängen zu müssen.
Wer mit den für LVM relevanten Begriffen Physical Volume, Volume Group und Logical Volume nicht vertraut ist, findet weiterführende Hinweise in [12] für Debian bzw. [13] für RHEL. Ich werde die Erstellung hier nicht im Detail beschreiben.
Ich erstelle eine zweite primäre Partition /dev/vda2 mit Typ LVM, welcher ich die verbleibende Speicherkapazität von 19 GiB zuweise. Mein fertiges Partitionslayout sieht wie folgt aus:
lsblk -o +FSTYPE
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT FSTYPE
sr0 11:0 1 1024M 0 rom
vda 254:0 0 20G 0 disk
├─vda1 254:1 0 953M 0 part /boot ext4
└─vda2 254:2 0 19.1G 0 part LVM2_member
├─vg_system-root 253:0 0 9.3G 0 lvm / ext4
├─vg_system-var_log 253:1 0 4.7G 0 lvm /var/log ext4
└─vg_system-home 253:2 0 1.9G 0 lvm /home ext4
Vorstehendem Code-Block ist zu entnehmen, dass ich drei Logical Volumes für die Einhängepunkte /, /var/log und /home verwende. Ich verwende auch hier durchgängig das ext4-Dateisystem.
Log-Dateien und unkontrolliert wachsende Daten in HOME-Verzeichnissen führen schnell dazu, dass das Root-Dateisystem (/) vollläuft. Dies lässt sich mit der Verwendung separater Einhängepunkte sicher verhindern.
Eurem aufmerksamen Auge ist sicher aufgefallen, dass ich keine Swap-Partition verwende. Da ich sie für die meist kurzlebigen Labor-VMs nicht benötige, lasse ich diese in der Regel weg. Für Systeme, die ich für langfristigen Betrieb installiere, füge ich diese nachträglich hinzu. Dank LVM ist dies kein Problem.
Darüber, ob man eine Swap-Partition braucht und wie groß diese sein sollte, werden teils esoterische Diskussionen geführt. Ich selbst orientiere mich an Table B.1. Recommended system swap space aus [14].
Damit habe ich ein Gold-Image erstellt, welches mir als Vorlage für weitere VMs dient und dabei nur wenig Platz auf der Festplatte des Hypervisor belegt:
ls -sh /var/lib/libvirt/images/debian11-template.qcow2
2.3G /var/lib/libvirt/images/debian11-template.qcow2
Sysprep ist ursprünglich ein Programm von Microsoft, mit welchem Gold-Images für die automatische Verteilung von Microsoft Windows vorbereitet werden. Heute taucht dieser Begriff in den Programmbezeichnungen weiterer Projekte auf und beschreibt gleichzeitig die Tätigkeit, ein Gold-Image für die weitere Verwendung vorzubereiten. Ich selbst verwende das Programm virt-sysprep von Richard W.M. Jones (Red Hat) und Wanglong Gao (Fujitsu Ltd.).
Virt-sysprep entfernt Einstellungen, User, Host-spezifische Dateien und leert Protokolldateien in dem erzeugten Image. Damit soll sichergestellt werden, dass die von dem Gold-Image abgeleiteten VMs keine Eigenschaften besitzen, die spezifisch für das Original sind, wie z.B. der Hostname, MAC-Adressen oder die SSH-Host-Keys, um nur drei Beispiele zu nennen. Die Anwendung ist daher dringend empfohlen.
Mit dem Befehl virt-sysprep --list-operations
kann man sich die Aktionen anzeigen lassen, die virt-sysprep ausführen kann. Die Standard-Aktionen sind in der Ausgabe mit einem ‚*‘ markiert. Unter RHEL 9 sieht die Ausgabe wie folgt aus:
$ virt-sysprep --list-operations
abrt-data * Remove the crash data generated by ABRT
backup-files * Remove editor backup files from the guest
bash-history * Remove the bash history in the guest
blkid-tab * Remove blkid tab in the guest
ca-certificates Remove CA certificates in the guest
crash-data * Remove the crash data generated by kexec-tools
cron-spool * Remove user at-jobs and cron-jobs
customize * Customize the guest
dhcp-client-state * Remove DHCP client leases
dhcp-server-state * Remove DHCP server leases
dovecot-data * Remove Dovecot (mail server) data
firewall-rules Remove the firewall rules
flag-reconfiguration Flag the system for reconfiguration
fs-uuids Change filesystem UUIDs
ipa-client * Remove the IPA files
kerberos-data Remove Kerberos data in the guest
kerberos-hostkeytab * Remove the Kerberos host keytab file in the guest
logfiles * Remove many log files from the guest
lvm-system-devices * Remove LVM2 system.devices file
lvm-uuids * Change LVM2 PV and VG UUIDs
machine-id * Remove the local machine ID
mail-spool * Remove email from the local mail spool directory
net-hostname * Remove HOSTNAME and DHCP_HOSTNAME in network interface configuration
net-hwaddr * Remove HWADDR (hard-coded MAC address) configuration
net-nmconn * Remove system-local NetworkManager connection profiles (keyfiles)
pacct-log * Remove the process accounting log files
package-manager-cache * Remove package manager cache
pam-data * Remove the PAM data in the guest
passwd-backups * Remove /etc/passwd- and similar backup files
puppet-data-log * Remove the data and log files of puppet
rh-subscription-manager * Remove the RH subscription manager files
rhn-systemid * Remove the RHN system ID
rpm-db * Remove host-specific RPM database files
samba-db-log * Remove the database and log files of Samba
script * Run arbitrary scripts against the guest
smolt-uuid * Remove the Smolt hardware UUID
ssh-hostkeys * Remove the SSH host keys in the guest
ssh-userdir * Remove ".ssh" directories in the guest
sssd-db-log * Remove the database and log files of sssd
tmp-files * Remove temporary files
udev-persistent-net * Remove udev persistent net rules
user-account Remove the user accounts in the guest
utmp * Remove the utmp file
yum-uuid * Remove the yum UUID
customize * Customize the guest
dhcp-client-state * Remove DHCP client leases
dhcp-server-state * Remove DHCP server leases
dovecot-data * Remove Dovecot (mail server) data
firewall-rules Remove the firewall rules
flag-reconfiguration Flag the system for reconfiguration
fs-uuids Change filesystem UUIDs
ipa-client * Remove the IPA files
kerberos-data Remove Kerberos data in the guest
kerberos-hostkeytab * Remove the Kerberos host keytab file in the guest
logfiles * Remove many log files from the guest
lvm-system-devices * Remove LVM2 system.devices file
lvm-uuids * Change LVM2 PV and VG UUIDs
machine-id * Remove the local machine ID
mail-spool * Remove email from the local mail spool directory
net-hostname * Remove HOSTNAME and DHCP_HOSTNAME in network interface configuration
net-hwaddr * Remove HWADDR (hard-coded MAC address) configuration
net-nmconn * Remove system-local NetworkManager connection profiles (keyfiles)
pacct-log * Remove the process accounting log files
package-manager-cache * Remove package manager cache
pam-data * Remove the PAM data in the guest
passwd-backups * Remove /etc/passwd- and similar backup files
puppet-data-log * Remove the data and log files of puppet
rh-subscription-manager * Remove the RH subscription manager files
rhn-systemid * Remove the RHN system ID
rpm-db * Remove host-specific RPM database files
samba-db-log * Remove the database and log files of Samba
script * Run arbitrary scripts against the guest
smolt-uuid * Remove the Smolt hardware UUID
ssh-hostkeys * Remove the SSH host keys in the guest
ssh-userdir * Remove ".ssh" directories in the guest
sssd-db-log * Remove the database and log files of sssd
tmp-files * Remove temporary files
udev-persistent-net * Remove udev persistent net rules
user-account Remove the user accounts in the guest
utmp * Remove the utmp file
yum-uuid * Remove the yum UUID
Selbstverständlich gibt es mit virt-sysprep(1) auch eine Manpage, welche die Nutzung des Programms und sämtliche Optionen erläutert.
Es ist sehr wichtig, dass die zu behandelnde Domain (VM) ausgeschaltet ist, bevor virt-sysprep gestartet wird, um eine Korruption der Image-Datei zu vermeiden.
Der nun folgende Code-Block zeigt die Anwendung von virt-sysprep auf die qcow2-Datei meines debian11-templates. Die dabei verwendeten Option --operations defaults,-ssh-userdir
sorgt dafür, dass alle Standard-Operationen mit der Ausnahme durchgeführt werden, dass die .ssh
-Verzeichnisse der User erhalten bleiben. Die Option --firstboot-command 'dpkg-reconfigure openssh-server'
stellt sicher, dass beim ersten Start des Klons neue SSH-Hostkeys generiert werden. Andernfalls kann der SSH-Dienst nicht starten und ich wäre nicht in der Lage mich via SSH anzumelden. Anschließend ist das Image bereit, um geklont bzw. kopiert zu werden.
$ virt-sysprep -a /var/lib/libvirt/images/debian11-template.qcow2 --operations defaults,-ssh-userdir --firstboot-command 'dpkg-reconfigure openssh-server'
[ 0.0] Examining the guest ...
[ 2.0] Performing "abrt-data" ...
[ 2.0] Performing "backup-files" ...
[ 2.1] Performing "bash-history" ...
[ 2.1] Performing "blkid-tab" ...
[ 2.1] Performing "crash-data" ...
[ 2.1] Performing "cron-spool" ...
[ 2.1] Performing "dhcp-client-state" ...
[ 2.1] Performing "dhcp-server-state" ...
[ 2.1] Performing "dovecot-data" ...
[ 2.1] Performing "ipa-client" ...
[ 2.1] Performing "kerberos-hostkeytab" ...
[ 2.2] Performing "logfiles" ...
[ 2.2] Performing "lvm-system-devices" ...
[ 2.2] Performing "machine-id" ...
[ 2.2] Performing "mail-spool" ...
[ 2.2] Performing "net-hostname" ...
[ 2.2] Performing "net-hwaddr" ...
[ 2.3] Performing "net-nmconn" ...
[ 2.3] Performing "pacct-log" ...
[ 2.3] Performing "package-manager-cache" ...
[ 2.3] Performing "pam-data" ...
[ 2.3] Performing "passwd-backups" ...
[ 2.3] Performing "puppet-data-log" ...
[ 2.3] Performing "rh-subscription-manager" ...
[ 2.3] Performing "rhn-systemid" ...
[ 2.4] Performing "rpm-db" ...
[ 2.4] Performing "samba-db-log" ...
[ 2.4] Performing "script" ...
[ 2.4] Performing "smolt-uuid" ...
[ 2.4] Performing "ssh-hostkeys" ...
[ 2.4] Performing "sssd-db-log" ...
[ 2.4] Performing "tmp-files" ...
[ 2.4] Performing "udev-persistent-net" ...
[ 2.4] Performing "utmp" ...
[ 2.4] Performing "yum-uuid" ...
[ 2.4] Performing "customize" ...
[ 2.4] Setting a random seed
[ 2.5] Setting the machine ID in /etc/machine-id
[ 2.5] Installing firstboot command: dpkg-reconfigure openssh-server
[ 2.5] SELinux relabelling
[ 2.5] Performing "lvm-uuids" ...
Das Programm ist nicht auf qcow2-Images beschränkt. Einen weiteren Anwendungsfall habe ich bereits hier im Blog beschrieben: VMware ESXi: VMDK-Datei einer Gast-VM mit virt-sysprep bereinigen.
Die Gold-Images werden verwendet, um durch Klonen neue VMs zu erstellen. Ich verwende dazu die Eingangs erwähnte Ansible-Rolle kvm_provision_lab.
Wird im Laufe des Lebenszyklus einer VM mehr Speicherplatz benötigt, so lässt sich das Vorgehen wie folgt skizzieren:
pvcreate
ein neues Physical Volume erstellen.vgextend
der Volume Group hinzufügen.lvextend
vergrößern.Die Schritte 3-5 werden ausführlich in der RHEL-9-Dokumentation in Chapter 5. Modifying the size of a logical volume beschrieben. Dort wird auch beschrieben, wie ein Logical Volume verkleinert werden kann.
Falls ihr euch hierzu ein Tutorial wünscht, lasst es mich bitte in den Kommentaren wissen. Dann liefere ich ein entsprechendes Beispiel nach.
Eine native Kompilierung von Python soll eine Programmgeschwindigkeit wie bei C und C++ ermöglichen.
Die Programmiersprache Python gilt zwar als vergleichsweise einfach zu erlernen und wird auch deshalb viel verwendet, die Nutzung des Interpreters in der Standardimplementierung hat aber Nachteile bei der Geschwindigkeit. Mit dem Codon-Projekt versucht ein Team des MIT (Massachusetts Institute of Technology) einen nativen Compiler für Python zu erstellen, um die Sprache deutlich zu beschleunigen.
In der Ankündigung des MIT sagt der Hauptautor von Codon zu der Umsetzung: “Der Benutzer schreibt einfach Python, so wie er es gewohnt ist, ohne sich um Datentypen oder Leistung kümmern zu müssen, was wir automatisch erledigen – und das Ergebnis ist, dass sein Code 10 bis 100 Mal schneller läuft als normales Python. Codon wird bereits kommerziell in Bereichen wie quantitative Finanzen, Bioinformatik und Deep Learning eingesetzt.”
Der neue Python-Compiler Codon basiere auf der LLVM-Compiler-Infrastruktur, biete natives Multithreading und die Geschwindigkeit damit erzeugter Programme reiche gar an C oder C++ heran, schreiben die Beteiligten auf Github. Das Multithreading und die Nebenläufigkeit werden in der Standardimplementierung von Python derzeit effektiv vom sogenannten Global Interpreter Lock (GIL) verhindert, der aber entfernt werden soll.
In einem Vortrag beschreibt das Team Codon als “einen domänenerweiterbaren Compiler und DSL-Framework (Domain Specific Language) für leistungsstarke DSLs mit der Syntax und Semantik von Python.” Neu sei dabei vor allem eine Intermediate Representation die Optimierungen und Analysen erleichtere.
Zwar unterstützte Codon fast die gesamte Python-Syntax, ein kompletter Ersatz für die Standardimplementierung sei das Projekt aber nicht, heißt es. So werden einige Python-Module noch nicht unterstützt und die Nutzung einiger dynamischer Funktionen von Python ist schlicht nicht erlaubt, so dass bestehende Programme teils zur Nutzung mit Codon angepasst werden müssen.
Der Beitrag Python-Compiler verspricht 10- bis 100-fache Leistung erschien zuerst auf Linux-Magazin.
Kürzlich bin ich beim Klonen von virtuellen Maschinen mit AlmaLinux 9 unter KVM/libvirt als Virtualisierungs-Host auf Netzwerk-Probleme gestoßen: Obwohl ich sämtlichen VMs per Script Netzwerkadapter mit eigenen MACs, IPv4- und IPv6-Adressen zugewiesen haben, traten IPv6-Netzwerkkonflikte auf — und zwar nicht für die reguläre Adressen, sondern für die Link-Local-Unicast-Adressen (fe80-xxx).
Eine kurze Google-Suche führt zur Ursache des Problems: Der NetworkManager wertet offenbar /etc/machine-id
aus, um »eindeutige« fe80-Adressen zu generieren. Bei den geklonten VMs war /etc/machine-id
aber immer identisch. Die resultierenden IPv6-fe80-Adressen waren daher ebenfalls identisch und führten zu Adresskonflikten (IPv6 Duplicate Address Detected) und letztlich zur Deaktivierung des betreffenden Netzwerkadapters.
Abhilfe ist zum Glück einfach: /etc/machine-id
muss gelöscht und neu erzeugt werden:
rm /etc/machine-id
systemd-machine-id-setup
In meinen Setup gibt es ein Script, das beim ersten Start in jeder VM ausgeführt wird. Es führt zuerst die statische Konfiguration der Netzwerkschnittstellen durch, dann die beiden obigen Kommandos und zuletzt einen reboot
. Damit gelingt der Parallelbetrieb diverser geklonter VMs wieder problemlos.
Ja, der Titel ist eine Ansage. Mit der neuen Version kannst Du Deine Spiele mit wesentlich verbesserter visueller Genauigkeit spielen. Das Team erinnert an das warme Leuchten der Röhrenmonitore. Dank der Einführung von shaderbasierten Skalierern gibt es das Erlebnis wieder. ScummVM 2.7.0 wird bereits mit einer Reihe von Shadern ausgeliefert, die sorgfältig aus der Shader-Sammlung von LibRetro ausgewählt wurden. Ein umfangreicheres Set ist als zusätzlicher Download in der Anwendung selbst verfügbar. Dank neuer Engines ist die Anzahl der verfügbaren Spiele […]
Der Beitrag ScummVM 2.7.0: The Real Slim Shader ist von bitblokes.de.
Der folgende Text dient mir als Dokumentation. Ich halte darin fest, wie ich LVs von einer VG in eine andere VG verschiebe und die Partitionstabelle der Festplatte mit der Quell-VG bearbeite. Der Verschiebe-Vorgang setzt sich dabei aus den zwei Vorgängen Kopieren und Löschen zusammen.
Der Text mag euch unterhalten und ggf. könnt ihr darauf zurückgreifen, wenn ihr ähnliche Arbeiten an euren Linux-Dateisystemen plant. Euch erwartet jedoch kein Tutorial, das in einzelne Themen oder Programme einführt. Falls ihr von hieran weiterlest, wünsche ich euch viel Spaß mit dem Text.
Es geht um meinen Desktop-PC. Dieser besitzt neben einer Geschichte auch einige Altlasten. Nun ist mir meine /boot-Partition zu klein. Da der Platz hinter der Partition jedoch von einer LUKS-verschlüsselten Partition mit LVM belegt ist, muss ich hier erst Platz schaffen, um die /boot-Partition vergrößern zu können.
Folgender Code-Block gibt einen Überblick über die Block-Geräte meines PCs, die darauf befindlichen Partitionen sowie deren Einhängepunkte in /etc/fstab
und /etc/crypttab
. Identifizierende Merkmale wie UUIDs wurden gekürzt, verändert oder Platzhalter an ihrer Stelle verwendet.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
└─sdb_crypt 253:4 0 931,5G 0 crypt
└─tower--pc--vg2-lv--images 253:5 0 360G 0 lvm /var/lib/libvirt/images
sdb 8:16 0 238,5G 0 disk
├─sdb1 8:17 0 243M 0 part /boot
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 238,2G 0 part
└─sda5_crypt 253:0 0 238,2G 0 crypt
├─tower--pc--vg-root 253:1 0 27,9G 0 lvm /
├─tower--pc--vg-swap_1 253:2 0 4G 0 lvm [SWAP]
└─tower--pc--vg-home 253:3 0 204,3G 0 lvm /home
sr0
$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/tower--pc--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=a3809eb1-fc3d191e2ae9 /boot ext2 defaults 0 2
/dev/mapper/tower--pc--vg-home /home ext4 defaults 0 2
/dev/mapper/tower--pc--vg-swap_1 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
# 1 TB SSD SANDisk
/dev/mapper/tower--pc--vg2-lv--images /var/lib/libvirt/images ext4 defaults 0 0
$ cat /etc/crypttab
sda5_crypt UUID=07f0d6c5-257591190166 none luks,discard
sdb_crypt UUID="e605980c-307daf28b717" none luks,discard
$ sudo blkid
/dev/sdb1: UUID="a3809eb1-fc3d191e2ae9" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="6ee39e6a-01"
/dev/sdb5: UUID="07f0d6c5-257591190166" TYPE="crypto_LUKS" PARTUUID="6ee39e6a-05"
/dev/sda: UUID="e605980c-307daf28b717" TYPE="crypto_LUKS"
/dev/mapper/sda5_crypt: UUID="AZKTuQ-rVeB5S" TYPE="LVM2_member"
/dev/mapper/tower--pc--vg-root: UUID="be0ff8fd-7aee7ce75f3b" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/tower--pc--vg-swap_1: UUID="90823267-b6828aeca9b9" TYPE="swap"
/dev/mapper/tower--pc--vg-home: UUID="d410241d-04214b690522" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/sdb_crypt: UUID="Ff4Lt0-RKJrGd" TYPE="LVM2_member"
/dev/mapper/tower--pc--vg2-lv--images: UUID="3af3b461-cdd7b2bc9710" BLOCK_SIZE="4096" TYPE="ext4"
Mein Ziel ist, die /boot-Partition auf 2 GB zu vergrößern, ohne das System neuinstallieren zu müssen oder die Daten in den vorhandenen Partitionen zu verlieren.
Bei meiner Internet-Recherche bin ich auf folgende Lösungsmöglichkeiten gestoßen:
Wenn man diese Diskussionen und den Wiki-Artikel liest, erkennt man, dass es mehrere Wege zum Ziel gibt. Ich habe mich für folgendes Vorgehen entschieden, da es auf mich den Eindruck macht, unkompliziert zu sein und nur ein geringes Risiko für Datenverlust birgt:
partclone
kopierenBevor ich irgendwelche Änderungen an der Partitionstabelle von /dev/sdb
durchführe, erstelle ich eine Datensicherung. Dazu verwende ich die freie Software Clonezilla, um die Partitionen von /dev/sdb
in eine Image-Datei auf einer externen Festplatte zu sichern.
Das Programm ist einfach in der Bedienung und ermöglicht mir im Fehlerfall, die Partitionen der zu bearbeitenden Festplatte wiederherzustellen.
Im IST-Zustand befindet sich das LUKS-Device sdb_crypt
auf dem Gerät /dev/sda
, während sich sda5_crypt
auf dev/sdb5
befindet. Dies ist unschön und lässt sich wie folgt ändern:
root:~# dmsetup rename sda5_crypt sd_temp
root:~# dmsetup rename sdb_crypt sda5_crypt
root:~# dmsetup rename sd_temp sdb_crypt
Nun wird die Datei /etc/crypttab
entsprechend angepasst (vgl. mit IST-Zustand):
root:~# cat /etc/crypttab
sdb_crypt UUID=07f0d6c5-257591190166 none luks,discard
sda5_crypt UUID="e605980c-307daf28b717" none luks,discard
Damit die Partitionen beim Start des Rechners korrekt entschlüsselt und eingebunden werden, wird abschließend initramfs
aktualisiert:
root:~# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-15-amd64
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
Nach einem Neustart ergibt sich das gewünschte Bild:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
└─sda5_crypt 253:4 0 931,5G 0 crypt
└─tower--pc--vg2-lv--images 253:5 0 360G 0 lvm /var/lib/libvirt/images
sdb 8:16 0 238,5G 0 disk
├─sdb1 8:17 0 243M 0 part /boot
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 238,2G 0 part
└─sdb_crypt 253:0 0 238,2G 0 crypt
├─tower--pc--vg-root 253:1 0 27,9G 0 lvm /
├─tower--pc--vg-swap_1 253:2 0 4G 0 lvm [SWAP]
└─tower--pc--vg-home 253:3 0 204,3G 0 lvm /home
Meine /home-Partition ist mir mit 204 GB etwas groß geraten. Daher möchte ich sie um 100 GB verkleinern. Um das Dateisystem verkleinern zu können, darf die Partition nicht eingehängt sein. Um die folgenden Schritte durchzuführen, nutze ich diesmal das Linux-System System Rescue. Dabei handelt es sich um ein Live-System, mit jeder Menge Werkzeugen, um einen (beschädigten) Rechner zu bearbeiten.
Der folgende Code-Block zeigt, wie zuerst das verschlüsselte LUKS-Device geöffnet und anschließend das LV der /home-Partition verkleinert wird. Der dabei verwendete Befehl führt die Verkleinerung des Dateisystems und des LV in einem Schritt aus:
# LUKS-Device öffnen
# cryptsetup open <device> <name> --type <device_type> see cryptsetup(8)
root@sysrescue ~]# cryptsetup open /dev/sda5 crypt_disk --type luks2
Enter passphrase for /dev/sda5:
[root@sysrescue ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 647.7M 1 loop /run/archiso/sfs/airootfs
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 243M 0 part
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 238.2G 0 part
└─crypt_disk 254:0 0 238.2G 0 crypt
├─tower--pc--vg-root 254:1 0 27.9G 0 lvm
├─tower--pc--vg-swap_1 254:2 0 4G 0 lvm
└─tower--pc--vg-home 254:3 0 204.3G 0 lvm
sdb 8:16 0 931.5G 0 disk
# Dateisystem und LV in einem Schritt verkleinern
# Aufgrund der gewählten Größe dauert dieser Vorgang einige Minuten
# lvresize --size [+|-]Size[m|UNIT] --resizefs <lv name> see lvresize(8)
[root@sysrescue ~]# lvresize --size -100G --resizefs /dev/tower-pc-vg/home
fsck from util-linux 2.38
/dev/mapper/tower--pc--vg-home: Inode 393223 extent tree (at level 1) could be narrower. IGNORED.
/dev/mapper/tower--pc--vg-home: Inode 12847282 extent tree (at level 1) could be narrower. IGNORED.
/dev/mapper/tower--pc--vg-home: 20959/13393920 files (1.2% non-contiguous), 14367863/53551104 blocks
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/mapper/tower--pc--vg-home to 27336704 (4k) blocks.
The filesystem on /dev/mapper/tower--pc--vg-home is now 27336704 (4k) blocks long.
Size of logical volume tower-pc-vg/home changed from 204.28 GiB (52296 extents) to 104.28 GiB (26696 extents).
Logical volume tower-pc-vg/home successfully resized.
[root@sysrescue ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 647.7M 1 loop /run/archiso/sfs/airootfs
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 243M 0 part
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 238.2G 0 part
└─crypt_disk 254:0 0 238.2G 0 crypt
├─tower--pc--vg-root 254:1 0 27.9G 0 lvm
├─tower--pc--vg-swap_1 254:2 0 4G 0 lvm
└─tower--pc--vg-home 254:3 0 104.3G 0 lvm
sdb 8:16 0 931.5G 0 disk
Zur Sicherheit führe ich noch eine Dateisystemüberprüfung aus:
[root@sysrescue ~]# fsck -t ext4 /dev/mapper/tower--pc--vg-home
fsck from util-linux 2.38
e2fsck 1.46.5 (30-Dec-2021)
/dev/mapper/tower--pc--vg-home: clean, 20959/6840320 files, 13956503/27336704 blocks
Da alles in Ordnung ist, fahre ich mit dem nächsten Schritt fort. Dazu nutze ich weiterhin die System Rescue Umgebung.
Da ich für die folgenden Vorgänge Zugriff auf die zweite VG benötige, öffne ich zuerst das LUKS-Device, in dem sich diese befindet:
[root@sysrescue ~]# cryptsetup open /dev/sdb crypt_disk2 --type luks2
Nun erstelle ich drei neue LVs, welche den Inhalt der existierenden LVs root
, swap_1
und home
aufnehmen sollen. Die Ziel-LVs müssen dazu mindestens gleich groß oder größer als die Quell-LVs sein. Um die erforderliche Größe zu ermitteln, lasse ich mir die Größe der Quell-LVs in Byte anzeigen. Ich wähle bewusst die Einheit Byte, da die Ausgabe bei größeren Einheiten auf zwei Nachkommastellen gerundet wird und ich mir keine Probleme durch die Rundung einhandeln möchte.
# Es werden nur die relevanten Informationen wiedergegeben
root:~# lvdisplay --unit b
LV Path /dev/tower-pc-vg/root
LV Name root
VG Name tower-pc-vg
...
LV Size 29997662208 B
-----
LV Path /dev/tower-pc-vg/swap_1
LV Name swap_1
VG Name tower-pc-vg
...
LV Size 4290772992 B
-----
LV Path /dev/tower-pc-vg/home
LV Name home
VG Name tower-pc-vg
...
LV Size 111971139584 B
Mit diesen Informationen erstelle ich die neuen LVs in der zweiten VG:
:~# lvcreate --size 29997662208B /dev/tower-pc-vg2 --name root
Logical volume "root" created.
:~# lvcreate --size 4290772992B /dev/tower-pc-vg2 --name swap_1
Logical volume "swap_1" created.
:~# lvcreate --size 111971139584B /dev/tower-pc-vg2 --name home
Logical volume "home" created.
Für diesen Schritt nutze ich die freie Anwendung Partclone. Da meine LVs weiterhin ausgehängt sind, muss ich mir um Schreib-Zugriffe anderer Prozesse während des Kopiervorgangs keine Sorgen machen:
# Manpage partclone(8)
# partclone.<fs_type> --dev-to-dev --source <Quelle> --output <Ziel>
[root@sysrescue ~]# partclone.ext4 --dev-to-dev --source /dev/tower-pc-vg/root --output /dev/tower-pc-vg2/root
Partclone v0.3.20 http://partclone.org
Starting to back up device(/dev/tower-pc-vg/root) to device(/dev/tower-pc-vg2/root)
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%
Total Time: 00:00:01, 100.00% completed!
done!
File system: EXTFS
Device size: 30.0 GB = 7323648 Blocks
Space in use: 20.8 GB = 5078551 Blocks
Free Space: 9.2 GB = 2245097 Blocks
Block size: 4096 Byte
Elapsed: 00:03:16, Remaining: 00:00:00, Completed: 100.00%, Rate: 6.37GB/min,
current block: 7323648, total block: 7323648, Complete: 100.00%
Total Time: 00:03:16, Ave. Rate: 6.4GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/tower-pc-vg/root) to the device (/dev/tower-pc-vg2/root)
Cloned successfully.
[root@sysrescue ~]# partclone.ext4 --dev-to-dev --source /dev/tower-pc-vg/home --output /dev/tower-pc-vg2/home
Partclone v0.3.20 http://partclone.org
Starting to back up device(/dev/tower-pc-vg/home) to device(/dev/tower-pc-vg2/home)
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%
Total Time: 00:00:01, 100.00% completed!
done!
File system: EXTFS
Device size: 112.0 GB = 27336704 Blocks
Space in use: 57.2 GB = 13956503 Blocks
Free Space: 54.8 GB = 13380201 Blocks
Block size: 4096 Byte
Elapsed: 00:12:22, Remaining: 00:00:00, Completed: 100.00%, Rate: 4.62GB/min,
current block: 27336704, total block: 27336704, Complete: 100.00%
Total Time: 00:12:22, Ave. Rate: 4.6GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/tower-pc-vg/home) to the device (/dev/tower-pc-vg2/home)
Cloned successfully.
Die SWAP-Partition enthält keine Daten, die kopiert werden müssen. Hier formatiere ich das neue LV einfach als SWAP-Partition:
[root@sysrescue ~]# mkswap /dev/tower-pc-vg2/swap_1
Setting up swapspace version 1, size = 4 GiB (4290768896 bytes)
no label, UUID=f9181521-a06da5b8ade5
An diesem Punkt habe ich meinen Rechner normal gestartet, um zu überprüfen, dass er wie gewohnt hochfährt. Die gute Nachricht lautet: „Er ist wie gewohnt gestartet.“
Nun verfüge ich über ein Clonezilla-Image der ersten Festplatte, dessen Wiederherstellbarkeit ich noch nicht durch Restore validiert habe und über die Kopien meiner Partitionen in der zweiten VG. Starten tut mein Rechner jedoch immer noch von den altbekannten Partitionen, da ich der Grub-Konfiguration noch nicht mitgeteilt habe, dass ein Wurzeldateisystem aus einer anderen Partition zu verwenden ist.
Leider habe ich es versäumt, mir während der Nutzung der System-Rescue-Umgebung Notizen zu machen. Daher kann ich die verwendeten Befehle an dieser Stelle nur unvollständig wiedergeben. Es ist mir jedoch gelungen, vom Wurzeldateisystem in /dev/tower-pc-vg2/root
zu starten. Dies sieht man z.B. in der Ausgabe von lsblk
:
:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
└─sda5_crypt 253:0 0 931,5G 0 crypt
├─tower--pc--vg2-lv--images 253:1 0 360G 0 lvm /var/lib/libvirt/images
├─tower--pc--vg2-root 253:2 0 27,9G 0 lvm /
├─tower--pc--vg2-swap_1 253:3 0 4G 0 lvm [SWAP]
└─tower--pc--vg2-home 253:4 0 104,3G 0 lvm /home
sdb 8:16 0 238,5G 0 disk
├─sdb1 8:17 0 2G 0 part /boot
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 234,2G 0 part
└─sdb_crypt 253:5 0 234,2G 0 crypt
├─tower--pc--vg-root 253:6 0 27,9G 0 lvm
├─tower--pc--vg-swap_1 253:7 0 4G 0 lvm
└─tower--pc--vg-home 253:8 0 104,3G 0 lvm
sr0
Wer den Code-Block genau studiert hat, wird festgestellt haben, dass meine /boot-Partition gegenüber dem Eingangs erwähnten IST-Zustand auf 2 GB angewachsen ist. Ich habe die Partitionstabelle zwischenzeitlich mit GParted bearbeitet, welches in der System-Rescue-Umgebung enthalten ist.
Damit habe ich mein Ziel erreicht. Der Artikel könnte an dieser Stelle enden. Ich möchte jedoch zukünftig wieder die Partitionen von /dev/sdb
verwenden. Dazu muss ich nochmals Grub neukonfigurieren, welches ich diesmal in folgendem Code-Block zeige:
root@tower-pc:~# mount /dev/tower-pc-vg/root /mnt
# Die separate /boot-Partition muss ebenfalls mit eingehängt werden
root@tower-pc:~# mount /dev/sdb1 /mnt/boot
root@tower-pc:~# for DEVICE in /dev /dev/pts /proc /sys; do mount --bind $DEVICE /mnt$DEVICE; done
root@tower-pc:~# mount /dev/tower-pc-vg2/lv-images /mnt/var/lib/libvirt/images
# ID der Partition mit dem Wurzeldateisystem ermitteln
root@tower-pc:~# ls -l /dev/tower-pc-vg/root
lrwxrwxrwx 1 root root 7 18. Jun 20:13 /dev/tower-pc-vg/root -> ../dm-6
root@tower-pc:~# ls -l /dev/disk/by-id/ | grep dm-6
lrwxrwxrwx 1 root root 10 18. Jun 20:13 dm-name-tower--pc--vg-root -> ../../dm-6
# In eine chroot-Umgebung wechseln
root@tower-pc:~# chroot /mnt
root@tower-pc:/# pwd
/
In der chroot
-Umgebung wird die Datei /etc/default/grub
mit einem Editor geöffnet und die Zeile GRUB_CMDLINE_LINUX_DEFAULT=
bearbeitet. Dort trage ich die ID der Partition meines Wurzeldateisystems ein. Die Zeile sieht anschließend wie folgt aus:
GRUB_CMDLINE_LINUX_DEFAULT="root=/dev/disk/by-id/dm-name-tower--pc--vg-root iommu='soft' quiet"
Der folgende Code-Block stellt die Befehle dar, mit denen Grub neukonfiguriert und installiert sowie initramfs
aktualisiert wird.
root@tower-pc:/# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-15-amd64
Found initrd image: /boot/initrd.img-5.10.0-15-amd64
Found linux image: /boot/vmlinuz-5.10.0-13-amd64
Found initrd image: /boot/initrd.img-5.10.0-13-amd64
Found Debian GNU/Linux 11 (bullseye) on /dev/mapper/tower--pc--vg2-root
done
root@tower-pc:/# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-15-amd64
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
root@tower-pc:/# exit
exit
root@tower-pc:~# reboot NOW
Nach dem Neustart habe ich noch überprüft, dass der Rechner wirklich die ursprünglichen Partitionen eingehängt hat:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
└─sda5_crypt 253:4 0 931,5G 0 crypt
├─tower--pc--vg2-lv--images 253:5 0 360G 0 lvm /var/lib/libvirt/images
├─tower--pc--vg2-root 253:6 0 27,9G 0 lvm
├─tower--pc--vg2-swap_1 253:7 0 4G 0 lvm
└─tower--pc--vg2-home 253:8 0 104,3G 0 lvm
sdb 8:16 0 238,5G 0 disk
├─sdb1 8:17 0 2G 0 part /boot
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 234,2G 0 part
└─sdb_crypt 253:0 0 234,2G 0 crypt
├─tower--pc--vg-root 253:1 0 27,9G 0 lvm /
├─tower--pc--vg-swap_1 253:2 0 4G 0 lvm [SWAP]
└─tower--pc--vg-home 253:3 0 104,3G 0 lvm /home
sr0 11:0 1 1024M 0 rom
Operation gelungen. Patient rechnet noch.
Mein Ziel habe ich erreicht und als Bonus Grub so konfiguriert, dass wieder meine ursprünglichen Partitionen verwendet werden. Die LVs in VG2 behalte ich vorerst. Sie stören nicht und ich kann die dortige Installation ebenfalls booten. Diese kann ich evtl. noch für zukünftige Experimente hernehmen.
Mir gefällt, dass ich frei verfügbare Informationen und Werkzeuge benutzen konnte, um alle notwendigen Aufgaben zu erledigen. So habe ich wieder einiges dazugelernt. Dies ist einer der Gründe, weshalb mir Freie Software und Open Source so gut gefallen.
Nun werde ich diesen Text noch verschlagworten, damit ich ihn in einer fernen Zukunft auch wiederfinde.
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:
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.
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:
/boot
genutzt und sowohl die für EFI erforderlichen Dateien (/boot/EFI
) als auch die Boot-Dateien (initramfs-xxx
und vmlinux-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
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
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
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
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...
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 :-)
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 :-)
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.
SSD, LUKS und 4k-Blöcke