❌

Normale Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

Mojo: LLVM-Gründer will Python für KI-Anwendung aufbohren

✇Linux-Magazin
Von: Sebastian Grüner ／ Golem.de
09. Mai 2023 um 07:58

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.

Gold-Images für KVM/QEMU erstellen

✇My-IT-Brain
Von: Jörg Kastning
08. Mai 2023 um 05:00

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.

Was ist ein Gold-Image?

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.

Erstellung der Image-Datei

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.

Installation und Partitionierung

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.

Vorwort zur Partitionierung

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.

Primäre Partition /dev/vda1 für /boot

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.

LVM, PV, VG, LV, Dateisysteme und Einhängepunkte

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

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.

Verwendung der Gold-Images

Die Gold-Images werden verwendet, um durch Klonen neue VMs zu erstellen. Ich verwende dazu die Eingangs erwähnte Ansible-Rolle kvm_provision_lab.

Was tun, wenn der Platz knapp wird?

Wird im Laufe des Lebenszyklus einer VM mehr Speicherplatz benötigt, so lässt sich das Vorgehen wie folgt skizzieren:

  1. Neue virtuelle Festplatte mit ausreichend Speicherkapazität der VM hinzufügen.
  2. Eine Partition auf der neuen virtuellen Festplatte erstellen (optional).
  3. Mit pvcreate ein neues Physical Volume erstellen.
  4. Das Physical Volume mit vgextend der Volume Group hinzufügen.
  5. Das Logical Volume mit 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.

Quellen und weiterführende Links

  1. Was ist ein Golden Image? URL: https://www.redhat.com/de/topics/linux/what-is-a-golden-image.
  2. What is a golden image? On opensource.com by Seth Kenlon (Team, Red Hat). URL: https://opensource.com/article/19/7/what-golden-image.
  3. What is a golden image? Definition by Nick Martin on TechTarget. URL: https://www.techtarget.com/searchitoperations/definition/golden-image
  4. Definition Golden Image (auch Master Image oder Goldenes Abbild). ComputerWeekly.de. URL: https://www.computerweekly.com/de/definition/Golden-Image-auch-Master-Image-oder-Goldenes-Abbild
  5. Was ist ein Golden Image? 21.11.2018: Autor / Redakteur: Dipl. Betriebswirt Otto Geißler / Ulrike Ostler. URL: https://www.datacenter-insider.de/was-ist-ein-golden-image-a-775197/
  6. Wikipedia-Artikel zu qcow {EN}
  7. QEMU disk image utility
  8. Wikepdia-Artikel Thin zu provisioning {EN}
  9. Performing a standard RHEL 9 installation; Appendix B. Partitioning reference; URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/performing_a_standard_rhel_9_installation/partitioning-reference_installing-rhel#recommended-partitioning-scheme_partitioning-reference
  10. Debian: Empfohlene Partitionsschemata. URL: https://www.debian.org/releases/bullseye/amd64/apcs03.de.html
  11. Wikipedia-Artikel zu LVM
  12. LVM – Debian Wiki {EN}
  13. Configuring and managing logical volumes. Red Hat Enterprise Linux 9. A guide to the configuration and management of LVM logical volumes. {EN}
  14. Appendix B. Partitioning reference. Performing a standard RHEL 9 installation. {EN}
  15. VMware ESXi: VMDK-Datei einer Gast-VM mit virt-sysprep bereinigen

Python-Compiler verspricht 10- bis 100-fache Leistung

✇Linux-Magazin
Von: Sebastian Grüner ／ Golem.de
21. März 2023 um 08:47

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.

LLVM 15 mit experimentellem DirectX-Support

✇Linux-Magazin
Von: Sebastian Grüner ／ Golem.de
07. September 2022 um 09:34

Mit LLVM können nun auch GPU-Shader für DirectX kompiliert werden. Außerdem unterstützt die Werkzeugsammlung das neue ARMv9.

Die Compiler-Werkzeugsammlung LLVM ist in Version erschienen, wie das Projekt über sein Forum mitteilt. Neu hinzugekommen ist ein Backend für die Grafikschnittstelle DirectX aus Windows, das Microsoft zu dem Open-Source-Projekt hinzufügte. Noch ist die Unterstützung für das sogenannte DirectX-Target jedoch experimentell und wird nicht standardmäßig mit den Binärdateien verteilt, die das LLVM-Projekt selbst erstellt.

Vor mehr als fünf Jahren stellte Microsoft seinen Compiler für die Shader-Sprache HLSL als Open Source zur Verfügung. HLSL sowie der zugehörige Compiler sind Teil der 3D-Grafikbibliothek DirectX. Das freie Analogon in OpenGL heißt GLSL. Mit Hilfe dieser Shader-Sprachen können 3D-Effekte programmiert werden. Zuvor nutzte Microsoft als Shader-Compiler die Eigenentwicklung Fxc. Der neue Shader-Compiler basiert auf LLVM und das neue Backend unterstützt die der DXIL (DirectX Intermediate Language), die wiederum auf der LLVM IR basiert. Die Arbeiten daran hatte Microsoft im Frühjahr dieses Jahres bekannt gegeben.

Neu hinzugekommen ist außerdem die Unterstützung für die neuen ARM-Architektur-Versionen ARMv9-A, ARMv9.1-A und ARMv9.2-A. Diese Architektur hatte der britische Chip-Designer ARM bereits im Frühjahr 2021 vorgestellt (g+) und erweitert damit die ARMv8-Architektur. Neu hinzugekommen sind dabei mehrere Beschleunigereinheiten und die Architektur soll vom Microcontroller- über den Smartphone- bis hin zum Server-CPU-Kern skalieren. Mit LLVM 15 unterstützt wird zudem die Cortex-M85-CPU, die noch auf ARMv8.1 basiert. Änderungen gibt es außerdem an den Backends für RISC-V und x86.

Für das Compiler-Frontend für C-artige Sprachen, Clang, hat das Team mit LLVM 15 außerdem Techniken umgesetzt, die die Sicherheit damit kompilierter Programme erhöhen soll. So gibt es nun die Möglichkeit, auf x86-Chips bestimmte Register zunächst mit Null zu überschreiben, bevor Werte von einer Funktion zurückgegeben werden. Das soll ROP-Angriffe erschweren. Zudem kann das Layout von Strukturen in C nun zufällig erzeugt werden. Damit soll das Erlangen von Informationen aus den Strukturen durch Angreifer erschwert werden.

Der Beitrag LLVM 15 mit experimentellem DirectX-Support erschien zuerst auf Linux-Magazin.

LVM: Logical Volumes (LV) in andere Volume Group (VG) verschieben und andere Arbeiten

✇My-IT-Brain
Von: Jörg Kastning
27. Juni 2022 um 05:00

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.

Ausgangslage

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"

Ziel

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.

Mögliche Vorgehensweisen

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:

  1. Datensicherung
  2. LUKS-Devices umbenennen
  3. LV und Dateisystem der /home-Partition verkleinern
  4. Neue LVs in zweiter VG erstellen
  5. Partitionen mit partclone kopieren
  6. Grub Neukonfigurieren (2x)

Schritt 1: Datensicherung durchführen

Bevor 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.

Schritt 2: LUKS-Devices umbenennen

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

Schritt 3: LV und Dateisystem der /home-Partition verkleinern

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.

Schritt 4: LVs in zweiter VG erstellen

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.

Schritt 5: Partitionen mit partclone kopieren

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

Schritt 6: Grub neukonfigurieren (2x)

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

Ende gut alles gut

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.

Arch Linux mit LVM und Verschlüsselung (LUKS) installieren

✇Koflers Blog
Von: Michael Kofler
06. April 2022 um 07:52

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 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

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
Gnome 41 unter Arch Linux

Ü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

SSD, LUKS und 4k-Blöcke

❌
❌