Für meine Video Tutorials nutze ich ein Mikrofon. Damit der Sound hier auch gut ist, nutze ich zusätzlich diverse Tools bzw Plugins. Das erste Plugin, das zum Einsatz kommt ist immer ein Denoising Plugin. Das versucht das Umgebungsrauschen raus zu filtern und nur die relevanten Geräusche wie Stimme oder Ähnliches aufzunehmen.

 

In OBS-Studio gibt es zwei verschiedene Plugins dieser Art. Leider kann ich diese aufgrund des Aufnahmeaufbaus nicht benutzen, da Mikrofon und weiterer Sound (Musikproduktion) von einem Rechner zusammengemischt auf einen anderen Rechner geschickt werden, auf dem OBS Studio läuft.

 

Bisher hatte ich mit Easy Effects eine Effekt Kette “RNNoise - Gate - Compressor - Limiter” am Start. Allerdings fiel mir dann auf, dass das RNNoise oder/und das Gate nicht wirklich gut funktionierten. Ich hatte ein leises und leider doch zu sehr hörbares Dauerrauschen.

 

Ich bin dann auf das Tool Real-time Noise Suppression Plugin gestoßen, dass es für Linux, Windows und Mac als VST2, VST3, LV2, LADSPA, AU, AUv3 gibt. Bei der Probe in der DAW gefiel mir das Plugin sofort.

 

Der Autor beschreibt auch gleich noch, wie man das LADSPA Plugin in Pipewire einbindet und somit ein eigenes Noise Suppression Modul erhält. Perfekter geht es nicht, denn das Plugin fungiert sogar noch ein wenig wie ein Gate. Perfekt eingerichtet leite ich per qpwgraph Pipewire Patchbay den Input auf das Noise Suppression Modul, von dort auf Easy Effects, in dem ich nur noch einen Kompressor und einen Limiter habe. Das Rauschen ist jetzt glücklicherweise komplett weg.

 

Hier geht es zum Repository von Real-time Noise Suppression Plugin VST2, VST3, LV2, LADSPA, AU, AUv3  und unter Releases (rechte Seite) gibt es den Download.

 

 

Fr, 11. November 2022, Peter Starfinger

Der Artikel gibt die persönlichen Erfahrungen und Meinungen des Autors wieder.

Meine ersten Erfahrungen mit Linux (damals Knoppix mit KDE 3.5.9) liegen nun schon fast 20 Jahre zurück, und nach einer sechsjährigen Testphase parallel zu Microsoft Windows beschloss ich 2009, mich nur noch auf Linux, genauer Ubuntu, zu stützen. In den Folgejahren probierte ich einige Varianten aus: Kubuntu mit KDE 4, Lubuntu, Ubuntu Mate.

Auch wenn ich meinen Umstieg von Windows auf Linux nie bereut, sondern von Anfang an die Stabilität, Quelloffenheit und die Einladung zur digitalen Selbstbestimmung und Eigenverantwortung geschätzt habe, gab es doch immer auch kleinere oder grössere Anlässe, mich über schlecht oder schlampig programmierte Software zu ärgern.

Mal fehlten wichtige Features, mal stolperte ich über hartnäckige Programmfehler, die auch nach Jahren noch nicht korrigiert waren, mal musste ich enttäuscht feststellen, dass eine bestimmte von mir geschätzte Software gar nicht mehr weiterentwickelt wurde.

Wenn z. B. der Dateimanager eigentlich das Plug & Play voll unterstützt, aber in Wirklichkeit den eingesteckten USB-Stick oft nicht erkennt oder dessen Inhalt unverständlicherweise erst nach Eingeben des Userpassworts anzeigt, kommt Frust auf.

Oder wenn die Task-Leiste instabil ist und manchmal unversehens verschwindet oder plötzlich ihre Einstellungen verliert, sodass man alles wieder neu konfigurieren darf, steigert das die Freude nicht. Natürlich hofft man auf das nächste Upgrade, oft aber auch vergebens. Mich wundert schon, wie beharrlich sich so mancher Bug jahrelang hält.

Noch etwas stiess mir mehr und mehr auf, nämlich die zunehmende Selbstherrlichkeit der Ubuntu-Entwickler, was einerseits das sang- und klanglose Einmotten geschätzter und andererseits den Einbau überflüssiger, zum Teil nicht gerade ressourcenschonender Software betrifft. Warum verbannt man z. B., angeblich aus Sicherheitsgründen, das bewährte Paket gksu als praktische GUI des Terminalbefehls sudo und verpflichtet den User stattdessen zum Gebrauch des viel umständlicheren Befehls pkexec? Oder warum will man dem User plötzlich die Containersoftware-Ideologie von snap mit all ihren Nachteilen bzgl. Laufzeit, Platzbedarf und Sicherheit aufzwingen?

Vor diesem Hintergrund beschloss ich im Herbst 2019, eine eigene, nur noch auf dem Ubuntu-Kern aufsetzende Distribution, nämlich Starbuntu, zu entwickeln. Einerseits trieb mich die pure Neugier, und die Herausforderung reizte mich. Andererseits wollte ich die angesprochenen Fehlentwicklungen meiden, bei der Auswahl verfügbarer Software möglichst gewissenhaft vorgehen, und dort, wo mich die Software nicht überzeugte oder erst gar nicht vorhanden war, eigene Programme schreiben. Dabei war und ist meine Hauptmotivation durchaus auf mich selbst und nicht auf die Community bezogen: endlich keine faulen Kompromisse mehr machen zu müssen, sondern das, was ich mir von einer guten Desktop-Umgebung wünsche, einfach selbst umzusetzen. Das geht nämlich am besten in der eigenen Werkstatt und nicht am fremden Produkt!

Nach der Einrichtung des X-Window-Systems (damals noch alternativlos) stellte sich das erste Problem: welchen Fenstermanager nehmen? Ich hatte schon viele ausprobiert, konservative wie exotische, ohne oder mit Schnickschnack (z. B. andockbare, wackelnde oder ex- und implodierende Fenster), mehr oder weniger stabil. Schliesslich entschied ich mich für OpenBox, den Weltmeister in den Disziplinen Schlichtheit und Stabilität, denn ich wollte keinen Paradiesvogel, sondern Zuverlässigkeit!

Die nächste Kardinalfrage war die Wahl eines guten Dateimanagers. Ausschlaggebend war hier, welchen Spielraum ich hatte, ihn nach meinen Vorstellungen "aufmotzen" zu können. Nach längerer Suche fiel meine Wahl auf den ROX-Filer, einen wunderbaren leichtgewichtigen, superschnellen und nach eigenem Gusto fast beliebig erweiterbaren Dateimanager, der zwar zunächst viel Konfigurationsaufwand erfordert, diesen aber später doppelt und dreifach zurückzahlt. Die hochgezüchteten Konkurrenten bieten m. E. keine grosse Modulierfähigkeit. Obendrein bringt der ROX-Filer gleich noch eine konfigurierbare Desktopverwaltung mit.

Die meisten Taskleisten (Panels) werden im Verbund mit einer ganzen Desktop-Umgebung angeboten: das MATE-Panel, das LXDE-Panel, das XFCE-Panel usw. Daher kamen sie für mich nicht infrage, denn ich wollte bei der Wahl einer Taskleiste unabhängig sein. Auch hier liess ich mich von den beiden Kriterien Schlichtheit und Stabilität leiten. Natürlich sollte sie auch ansprechend aussehen, allerdings ohne so überflüssige Features wie ein 3D-Design oder auf den Mauszeiger reagierende hüpfende Icons. So entschied ich mich schliesslich für Tint2, eine absolut fehlerfreie und zuverlässige, aber auch ansprechende Leiste, und habe diese Wahl nicht bereut.

Einige Entscheidungen für eine geeignete Software waren nahezu alternativlos, wie z. B. das Libreoffice-Paket oder die Ebook-Verwaltung von Calibre, andere basierten auf persönlichen Erfahrungen oder Vorlieben und sind sicherlich diskutabel. Eine Übersicht über die Standard-Software (GUI) von Starbuntu findet sich hier.

Nun wäre eine selbst entwickelte Linux-Distribution nicht unbedingt existenzberechtigt, würde sie sich in einer mehr oder weniger willkürlichen Zusammenstellung bekannter Software, vielleicht noch verziert mit nettem Design, erschöpfen. Ihr würde nämlich der eigene Stallgeruch fehlen, das Alleinstellungsmerkmal, das sich nicht nur in einer individuellen Gestaltung (Themes, Hintergrundbilder usw.), sondern vor allem in einer selbstgeschriebenen Lücke füllenden Software findet.

Die Notwendigkeit für eine solche Software zeigte sich mir an vielen Stellen, von denen einige beispielhaft erwähnt seien:

• Der Dateimanager ROX-Filer zeigt andere Festplattenpartitionen wie auch eingesteckte Speichermedien nicht von selbst an. Daher war es nötig, einen Daemon zu schreiben, der die Ports überwacht und anhand eines Hilfsprogramms entsprechende Icons dynamisch auf den Desktop bringt, nach deren Anklicken der Dateimanager den Inhalt des jeweiligen Mediums anzeigt.
• Ebenso bietet der Dateimanager von sich aus keine Möglichkeit an, auf Daten-Images oder entfernte Dateisysteme (ISO-Images, FTP-, SSH- oder WebDAV-Server) zuzugreifen, sodass auch hier Programmierarbeit nötig war.
• Für den ROX-Filer musste ein Papierkorb eingerichtet werden, da er nur endgültiges Löschen anbietet.
• Das Hintergrund-Design für den ROX-Desktop wurde dynamisiert.
• Tint2 bietet kein Applikationsmenü an. Da es in der Linux-Welt kaum unabhängige Standalone-Applikationsmenüs gibt, wurde ein eigenes geschrieben, sowie ein weiteres Programm zur Konfiguration des Applikationsmenüs.
• OpenBox wurde um die Möglichkeit der Positionierung, Zentrierung und Kachelung von Fenstern ergänzt.
• Wie oben schon ausgeführt, war es nötig ein eigenes grafisches Programm für den Benutzerwechsel, meist zum Root, zu schreiben.
• Es wurde eine leistungsfähige Generalapplikation geschrieben, die das deutlich limitierte Standardprogramm xdg-open ersetzt.
• Für diverse Aufgaben wurde ein Verwaltungsprogramm für editierbare und erweiterbare Listen geschrieben, das auch Befehle als Listeneinträge zur Ausführung bringen kann.
• Es wurde ein History-Generator geschrieben, der in verschiedensten eigenen Programmen Anwendung findet.
• Eine browserunabhängige Texteingabebox zur Internet-Recherche mit History für die Suchmaschinen Google, DuckDuckGo oder Startpage wurde geschaffen.
• Es wurde ein Starbuntu-spezifischer Dateityp *.url als Zeiger auf lokale Dateien und Verzeichnisse, Webseiten, FTP-, SSH- und WebDAV-Server, Mailempfänger u. a. kreiert, dessen gespeicherte Zieladresse immer mit der dafür vorgesehenen Anwendung geöffnet wird.
• Eine Starbuntu-eigene Verwaltungssoftware für die benutzerspezifischen Tastenkombinationen mit alphabetischer Label- oder Hotkeysortierung wurde geschaffen.
• Ein Starbuntu-eigener Clipboard-Manager mit getrennter History und Bearbeitungsmöglichkeit für die primäre und die sekundäre Selektion sowie für das Clipboard wurde entwickelt. Dieser Clipboard-Manager erlaubt bis zu drei parallele Zwischenablagen, legt aber nur das ab, was abgelegt werden soll.

Ich denke, erst durch diese und viele weitere Programmierarbeiten ist Starbuntu zu einer Distribution gereift, in der Einfachheit, Klarheit, Übersichtlichkeit, Praxistauglichkeit, aber auch Schönheit realisiert sind.

Hinweis: Die vielen GUI-Dialoge in meinen Programmen hätte ich ohne das hervorragende GTK+-Dialog-Programm yad (yet another dialog) von Victor Ananjevsky nicht realisieren können. Dafür gebührt ihm mein grosser Dank.

Webseite: https://die-starfingers.de/Starbuntu/de/
Download: https://die-starfingers.de/Starbuntu/Starbuntu.iso

Do, 9. November 2022, Martin Brodbeck

Hintergrund: Als ich mir neulich ein neues Notebook gekauft habe, fiel die Wahl auf ein Gerät der Firma Tuxedo, weil ich sichergehen wollte, dass es linuxkompatible Hardwarekomponenten verbaut hat. Letztendlich ist es ein Tuxedo InfinityBook S15 Gen7 geworden.

Als es dann ankam, stellte sich die Frage, welche Linux-Distribution installiert werden soll. Zunächst entschied ich mich für das quasi hauseigene TUXEDO OS. Das ist schnell installiert, enthält bereits die tuxedoeigenen Module und Programme und es verwendet meine derzeit bevorzugte Desktopumgebung KDE Plasma. Und der Ubuntu 22.04 Unterbau garantiert eine gewisse Stabilität. Leider habe ich mich recht schnell dabei ertappt, dass ich mehr und mehr 3rd Party Repositories eingebunden habe, um aktuellere Softwareversionen zu erhalten. Die Version von KDE Plasma war auch noch auf Ubuntu 22.04 Stand (5.24.x) und eine klare Aussage, ob/wann für TUXEDO OS die KDE-Version aktualisiert wird, gab es leider nicht.

Also habe ich dann doch beschlossen, Arch Linux zu installieren, auch wenn es etwas mehr Aufwand bedeutet. Im Folgenden möchte ich also die Installationsprozedur, wie ich sie für mich gewählt habe, beschreiben. Hier führen natürlich viele Wege nach Rom und es gibt kein hartes Richtig oder Falsch. Dies soll also nur als grober Leitfaden dienen, den jede(r) nach eigenen Vorlieben anpassen kann.

Da Arch Linux sehr vielseitige Setups erlaubt, habe ich vorab einige Entscheidungen treffen müssen. Für folgende Eckpunkte habe ich mich entschieden:

• Komplettverschlüsselung der Festplatte (außer /boot)
• Als Dateisystem soll Btrfs verwendet werden
• Verwendung eine Swapdatei (nicht: Swappartition)
• Als Bootloader soll systemd-boot in Einsatz kommen

Selbstverständlich habe ich mich am Installation Guide von Arch Linux orientiert, den ich hier zur Vertiefung wärmstens empfehlen möchte.

Installationsmedium erstellen und Vorarbeiten

Zunächst lädt man sich von der Downloadseite über einen der Spiegelserver ein ISO-Image des Arch Linux Livesystems herunter. Dieses Image wird immer wieder aktualisiert; zum Zeitpunkt meiner Installation war dies archlinux-2022.11.01-x86_64.iso. Mit Tools wie etcher oder usbimager wird damit ein USB-Stick zum bootfähigen Installationsmedium, das auch später noch für Reparaturarbeiten hilfreich sein kann. Hiervon wird also nun gebootet (UEFI) und wir finden uns nun in einer etwas spartanischen Konsolenumgebung wieder.

Die erste Aktion ist nun, mittels loadkeys de-latin1 das Tastaturlayout auf Deutsch umzustellen. Es ist auch kein Fehler, schonmal für eine Internetverbindung zu sorgen. Über den Commandprompt informiert Arch Linux bereits, dass man dafür iwctl verwenden kann, wenn man eine Wi-Fi-Verbindung aufbauen möchte. Nach Eingabe von iwctl befindet man sich in einer Shell, in der man sich mittels station DEVICE connect SSID im WLAN anmelden kann. DEVICE ist der Name des WLAN-Gerätes, etwa wlan0. SSID ist natülich der Name des WLAN-Netzwerks. Ist das gemacht, verlässt man mit exit die iwctl-Shell wieder.

Partitionierung und Verschlüsselung

Ich bevorzuge eine übersichtliche Einteilung der Festplatte mit nur wenigen Partitionen. Tatsächlich erstellen wir hier lediglich zwei: Eine kleine EFI-Partition, ohne die ein UEFI-System nicht auskommt und eine große Partition, die im nächsten Schritt verschlüsselt wird und auf der das eigentliche System installiert wird. Am einfachsten geht die Partitionierung mit dem guten alten fdisk von der Hand. Da ich die Installation in einer virtuellen Maschine nochmal nachvollzogen habe, verwende ich hier der Einfachheit halber das Device /dev/vda. Ein aktuelles Notebook dürfte aber eher eine M.2 NVMe enthalten. Ein Devicename von /dev/nvme0n1 o. ä. dürfte also wahrscheinlicher sein. Hier, exemplarisch, die Prozedur mit fdisk:

root@archiso ~ # fdisk /dev/vda
Welcome to fdisk (util-linux 2.38.1)
[…]

Command (m for help): g
Created a new GPT disklabel (GUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

Command (m for help): n
Patition number (1-128, default 1):
First sector (2048-41943006. default 2048):
Last sector, […]: +512M
[…]

Command (m for help): t
Selected partition 1
Partition type or alias (type L to list all): 1
Changed type of partition 'Linux filesystem' to 'EFI System'.

Command (m for help): n
Patition number (2-128, default 2):
First sector (1050624-41943006, default 1050624):
Last sector, […]: 
[…]

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Die EFI-Partition formatieren wir gleich mit FAT32:

root@archiso ~ # mkfs.fat -F32 /dev/vda1

Jetzt muss die zweite, große Partition mit cryptsetup verschlüsselt werden:

root@archiso ~ # cryptsetup luksFormat /dev/vda2

WARNING!
========
This will overwrite data on /dev/vda2 irrevocably.

Are you sure? (Type 'yes' in calital letters): YES
Enter passphrase for /dev/vda2: 
Verify passphrase:
[…]

luksFormat bietet mannigfaltige Optionen, mit denen man den Verschlüsselungsalgorithmus und anderes anpassen kann. Doch kann man auch einfach, wie hier gezeigt, die Standardeinstellungen verwenden.

Btrfs

Jetzt kommt das Dateisystem Btrfs zum Einsatz. Dank Subvolumes kann man eine Partition praktisch einteilen, ohne eine feste Größe wie bei "echten" Partitionen angeben zu müssen. Außerdem kann man von den Subvolumes später Snapshots erstellen und davon dann wiederum konsistente Backups durchführen. Auch hier möchte ich es übersichtlich halten und nur folgende Subvolumes erstellen:

• @ (für das System, also /)
• @home (für die Homeverzeichnisse, also /home)
• @swap (für die Swapdatei, dazu später mehr)

Zunächst aber muss die verschlüsselte Partition geöffnet werden, damit wir das Dateisystem darauf erstellen können. Anschließend wird das Btrfs-System gemountet, damit darin die Subvolumes erstellt werden können.

Los geht's:

root@archiso ~ # cryptsetup open /dev/vda2 dm-0
Enter passphrase for /dev/vda2:
root@archiso ~ # mkfs.btrfs /dev/mapper/dm-0
btrfs-progs v6.0
[…]

root@archiso ~ # mount /dev/mapper/dm-0 /mnt
root@archiso ~ # btrfs subvolume create /mnt/@
Create subvolume '/mnt/@'
root@archiso ~ # btrfs subvolume create /mnt/@home
Create subvolume '/mnt/@home'
root@archiso ~ # btrfs subvolume create /mnt/@swap
Create subvolume '/mnt/@swap'
root@archiso ~ # umount /mnt

Jetzt können die Subvolumes (und die EFI-Partition) entsprechend ihrer Verwendung gemountet werden:

root@archiso ~ # mount -o compress=zstd,subvol=@ /dev/mapper/dm-0 /mnt
root@archiso ~ # mount --mkdir -o compress=zstd,subvol=@home /dev/mapper/dm-0 /mnt/home
root@archiso ~ # mount --mkdir /dev/vda1 /mnt/boot

Installation essenzieller Pakete

Jetzt wird es langsam spannend, denn nun können wir die ersten Arch Linux Pakete nach /mnt installieren. Hier dürfen die btrfs-progs nicht vergessen werden. Auch kann man gleich einen Netzwerkmanager und einen Editor installieren. Bei mir sieht das Kommando hierfür so aus:

pacstrap -K /mnt base linux linux-firmware btrfs-progs networkmanager vim man-db man-pages

Konfiguration des Arch Systems

Wenn die Pakete installiert wurden, ist es Zeit, das System, das sich nun unter /mnt befindet, einzurichten. Zunächst erstellen wir dort eine /etc/fstab, basierend auf den aktuellen Mountpunkten:

root@archiso ~ # genfstab -U /mnt >> /mnt/etc/fstab

Jetzt wechseln wir in das neue System, in eine chroot-Umgebung, damit wir direkt dort die restlichen Einstellungen vornehmen können:

root@archiso ~ # arch-chroot /mnt

Zeitzone

Zunächst ein paar Zeit-Einstellungen:

[root@archiso /]# ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime
[root@archiso /]# hwclock --systohc

Lokalisation

In /etc/locale.gen entfernen wir bei en_US.UTF-8 UTF-8 und de_DE.UTF-8 UTF-8 die Kommentarzeichen und erstellen die locales:

[root@archiso /]# locale-gen

Dann erstellen wir die Datei /etc/locale.conf mit dem Inhalt LANG=de_DE.UTF-8. Außerdem erstellen wir die Datei /etc/vconsole.conf mit dem Inhalt KEYMAP=de-latin1.

Netzwerkkonfiguration

Schließlich tragen wir in die Datei /etc/hostname noch den Namen des Rechners ein, z. B. myhostname. Außerdem ist da noch /etc/hosts:

Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1       localhost.localdomain   localhost
::1             localhost.localdomain   localhost
127.0.0.1       myhostname.localdomain  myhostname

Bootloader

Als Bootloader verwende ich nicht grub, sondern systemd-boot, da hier die Konfiguration einfacher von der Hand geht und der Bootloader eh mit systemd mitkommt. Zunächst muss er installiert werden:

[root@archiso /]# bootctl install

Das erstellt einige Verzeichnisse und Dateien unter /boot/EFI sowie unter /boot/loader.

In /boot/loader/loader.conf habe ich folgende Einträge gemacht, damit etwa arch.conf standardmäßig vorausgewählt ist und nach 3 Sekunden automatisch gebootet wird:

default arch.conf
timeout 3
console-mode max
editor no

Und in /boot/loader/entries werden noch zwei Dateien, also Einträge für das Bootloadermenü, erstellt:

arch.conf:

title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options rd.luks.name=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx=dm-0 root=/dev/mapper/dm-0 rootflags=subvol=@ rw quiet

arch-fallback.conf:

title   Arch Linux (fallback initramfs)
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux-fallback.img
options rd.luks.name=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx=dm-0 root=/dev/mapper/dm-0 rootflags=subvol=@ rw quiet

In beiden Fällen entspricht xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx der UUID der verschlüsselten Partition, welche mittels blkid ermittelt werden kann.

initrd /intel-ucode.img bindet die Microcode Updates für die CPU ein – in diesem Fall Intel. Dazu muss das Paket intel-ucode installiert werden:

[root@archiso /]# pacman -S intel-ucode

Für AMD-CPUs steht das Paket amd-ucode zur Verfügung.

Initramfs

Das Initramfs ist ein komprimiertes Archiv, das für den Systemstart benötigte Dateien enthält. Hier müssen wir aufpassen! In /etc/mkinitcpio.conf müssen einige Anpassungen gemacht werden, damit die verschlüsselte Partition eingebunden werden kann.

Die MODULES-Zeile sollte so aussehen: MODULES=(btrfs).

Die HOOKS-Zeile habe ich für die systemd-Variante angepasst (näheres siehe Arch Linux-Wiki): HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck)

Schlussendlich erstellen wir die Initramfs noch:

[root@archiso /]# mkinitcpio -P

Passwort

Damit wir uns nachher am System einloggen können, müssen wir noch das Passwort für root setzen. Das machen wir mit dem Kommando passwd.

Reboot!

Jetzt ist es geschafft! Wir verlassen die chroot-Umgebung mit exit und unmounten /mnt mit umount -R /mnt. Mit reboot wird das System neu gestartet. Zu Beginn des Bootprozesses wird das Passwort für die Entschüsselung der Festplatte abgefragt. Anschließend sehen wir das Login-Prompt und wir können uns als root anmelden.

Als Allererstes stellen wir wieder eine Internetverbindung her. Da wir den Network Manager installiert haben, aktivieren wir diesen nun:

[root@myhostname ~]# systemctl enable --now NetworkManager

Die eigentliche Internetverbindung können wir nun recht bequem mit nmtui herstellen.

Damit sich bei neuen systemd-Versionen der Bootloader automatisch aktualisiert, müssen wir noch den entsprechenden Dienst aktivieren:

[root@myhostname ~]# systemctl enable --now systemd-boot-update

Swap

Der Einfachheit halber habe ich bisher das Erstellen des Swapfiles verschwiegen, weil wir es jetzt, da das System problemlos läuft, in Ruhe nachholen können. In /etc/fstab fügen wir folgende Einträge noch ein (natürlich auch hier die eigentliche UUID verwenden):

# swap
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx       /swap           btrfs           rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@swap    0 0
/swap/swapfile                                   none           swap            defaults 0 0

Außerdem mounten wir das Ganze nach /swap und erstellen darin ein Swapfile, nachdem wir das Verzeichnis mit dem NO_COW-Flag versehen haben:

[root@myhostname ~]# mkdir /swap && mount /swap
[root@myhostname ~]# chattr +C /swap
[root@myhostname ~]# dd if=/dev/zero of=/swap/swapfile bs=1M count=4096 status=progress

Jetzt müssen wir noch die Permissions anpassen und die Datei für Swap formatieren. Schließlich aktivieren wir das Swapfile:

[root@myhostname ~]# chmod 0600 /swap/swapfile
[root@myhostname ~]# mkswap -U clear /swap/swapfile
[root@myhostname ~]# swapon /swap/swapfile

Schluss

Noch ein Wort zum Tuxedo Notebook: Im AUR, dem Arch User Repository, gibt es die Pakete tuxedo-control-center-bin und tuxedo-keyboard-dkms. Mit ersterem kann man u. a. die Performance- und Lüftereinstellungen komfortabel festlegen. Letzteres installiert die Treiber für die Tastatur. Damit funktionieren dann auch die Tastenkombinationen, um etwa die LED-Beleuchtung zu justieren. Hier bitte nicht vergessen, vorab die linux-headers zu installieren. Wie Pakete aus dem AUR installiert werden, ist übrigens auch sehr gut beschrieben. Damit ist die minimale Einrichtung des Notebooks abgeschlossen. Nun haben wir ein Notebook mit aktuellem Linux und aktuellen Softwarepakten. Und Hardware, die komplett mit Linux funktioniert.

Es gäbe jetzt noch viele Möglichkeiten, um das System einzurichten und zu verfeinern. Viele Pakete wollen noch installiert werden. Eine grafische Benutzeroberfläche wie etwa KDE Plasma möchte man sicherlich auch haben. An dieser Stelle verweise ich jedoch nochmals auf das hervorragende Wiki von Arch Linux. Hier findet man wirklich zu jedem Anliegen die passende Beschreibung. Insbesondere beim Setup eines Systems wie dem unseren hier, also die Kombination aus Verschlüsselung, Btrfs und systemd-boot, findet man manchmal in der Dokumentation den Wald vor lauter Bäumen nicht. Ich hoffe, dass die Anleitung hier als kleiner Leitfaden dienen kann, um es selbst einmal mit Arch Linux zu versuchen.