Unity 7.6

Fr, 1. Juli 2022, Lioh Möller

Der Entwickler Rudra Saraswat hat die Veröffentlichung einer neuen Version der Unity-Desktopumgebung bekannt gegeben. Nach über 6 Jahren nach dem Release der Vorgängerversion, bringt die nun vorliegende Version 7.6 eine Vielzahl an Neuerungen mit sich.

Unity wurde in der Vergangenheit massgeblich durch Canonical, der Firma hinter Ubuntu Linux, entwickelt. Die hauseigene Desktopumgebung war von 2010 bis 2017 der Standard in der offiziellen Ubuntu Variante, bis sich das Projekt entschloss, zurück auf GNOME zu wechseln. Dennoch erfreut sich auch Unity weiterhin bei einigen Anwendern grosser Beliebtheit und seit einiger Zeit steht wieder eine Ubuntu Variante mit dem Unity Desktop zur Verfügung. Nutzer dieser Remix Version, können ihr System mit folgenden Befehlen auf Unity 7.6 aktualisieren:

sudo apt update && sudo apt upgrade

Alternativ lässt sich das Repository wie folgt hinzufügen und eine Installation der Desktopumgebung durchgeführt werden:

wget https://repo.unityx.org/unityx.key
sudo apt-key add unityx.key
echo 'deb https://repo.unityx.org/main testing main' | sudo tee /etc/apt/sources.list.d/unity-x.list
sudo apt-get update && sudo apt-get install -y unity

Es folgt eine Übersicht der Änderungen im Vergleich zur Vorgängerversion:

Quelle: https://unity.ubuntuunity.org/blog/unity-7.6/






Unklare Zukunft für Open Source in Schleswig-Holstein?

Nach LiMux war die Open Source-Strategie von Schleswig-Holstein der nächste große Hoffnungsträger für die FOSS-Community. Nicht zuletzt, weil der bisher zuständige Minister Jan Philipp Albrecht in der Netzgemeinde seit seiner Zeit im Europaparlament wohlgelitten ist. Die Zukunft ist nach Wahl und neuer Koalition aber mal wieder offen.

Ich hatte zu diesem und anderen vergleichbaren Projekten in der Vergangenheit ja sehr kritisch geäußert und bin dafür ziemlich hart angegangen worden. Der Einsatz von Open Source beim Staat ist bei vielen in der FOSS-Community ein unglaublich aufgeladenes und mit irrationalen Hoffnungen verbundenes Thema. Reale Probleme und Herausforderungen spielen da oft weniger eine Rolle als die abstrakte Hoffnung, dass durch den Einstieg des Staates der Gordische Knoten für Linux oder LibeOffice durchschlagen wird.

Wie Heise kürzlich berichtete, ist der neue Koalitionsvertrag zwischen CDU und Grünen deutlich unverbindlicher und die Zuständigkeit wandert vom grünen Umweltministerium in die CDU-Staatskanzlei. Im besten Fall bedeutet das weniger Ankündigungsminister und mehr praktische Arbeit. Im schlimmsten Fall verheddert sich das Projekt im Verwaltungsdickicht. Interessierte können sich die entsprechenden Passagen mal durchlesen. Vor allem im Abschnitt zu „digitaler Souveränität“ sind relevante Aussagen gebündelt. Der Vertrag beinhaltet zwar ein grundsätzliches Bekenntnis zu Open Source und Grundsätzen wie Public Money, Public Code aber lässt mit „Gleichwertigkeit“ von „gewohnter Funktionalität“ einige Hintertüren offen.

Niemand vermutet aktuell einen 180°-Schwenk im Stil von München, aber die Vorhaben und Zeitpläne waren bisher ziemlich ambitioniert. Wer nicht gerade mit eng sitzenden ideologischen Scheuklappen darauf schaute, fragte sich schon länger, wie diese Ziele so schnell erreicht werden sollten. Hier dürfte nun vermutlich etwas mehr Realismus einkehren.

Der Artikel Unklare Zukunft für Open Source in Schleswig-Holstein? erschien zuerst auf [Mer]Curius






Vim 9 erschienen

Kurz notiert: Vim hat diese Woche die Veröffentlichung eines neuen Major-Releases angekündigt. Die größte Änderung ist die Einführung von Vim 9 Script.

Bei Vim 9 Script handelt es sich um eine neue Skriptsprache für den bekannten textbaiserten Editor. Als Motivation geben die Entwickler zwei große Ziele an:

Insbesondere die Performanceziele haben den Weg für die Abwärtskompatibilität versperrt. Dabei wurde der Kompromiss gefunden, einerseits Vim 9 Script und andererseits „Legacy-Script“ (sprich: <= Vim 8) parallel zu unterstützen.

Weitere Hinweise zu Vim 9 Script sind unter :help vim9 verfügbar. Darüber hinaus wurden zahlreiche Bugs und Sicherheitslücken gefixt sowie die interne Testabdeckung erhöht. Letzteres soll zur Qualitätssicherung beitragen und die Robustheit erhöhen. Weitere Hinweise zu Neuerungen sind unter :help new-9 zu finden.






Replicant Installation auf dem Samsung Galaxy S III (i9300)

Do, 30. Juni 2022, Lioh Möller

Bei Replicant handelt es sich um eine vollständig Freie Android-Implementierung. Dies bedeutet, dass keinerlei Binary Blobs, also Treiber-Bestandteile, welche nur im Binärcode vorliegen, enthalten sind. Damit einher geht, dass Treiber für Hardware-Komponenten, welche Binary Blobs benötigen, vom Projekt neu implementiert werden müssen. Dieser Vorgang ist aufwändig und zeitintensiv, zahlt sich letztendlich allerdings aus. Neu entwickelte Freie Treiber, sollten dabei möglichst in den Mainline-Kernel aufgenommen werden, um so allen Interessierten zu Gute zu kommen.

Als Referenzplattform hat sich das Replicant Projekt aktuell für das Samsung Galaxy S III (i9300) entschieden. Allerdings wird auch an einer Unterstützung der 4G-Variante mit der Modellnummer i9305 gearbeitet.

Da dem kleinen Entwicklerteam nur bedingt Ressourcen zur Verfügung stehen, werden nur Teile der Hardware unterstützt, wobei das Galaxy S III zu den am weitesten fortgeschrittenen Modellen zählt. Das integrierte 3G-Modem funktioniert beispielsweise, WLAN allerdings nur mit einem externen Adapter. GPS wird aktuell ebenfalls nicht unterstützt.

Sofern man beispielsweise auf einer Online Handelsplattform für Gebrauchtgeräte ein Gerät ergattern konnte, ist die eigentliche Installation in wenigen Schritten auch für motivierte Anfänger durchaus durchführbar.

Voraussetzung sind die Kommandozeilenanwendungen adb und heimdall, welche sich auf einem Debian GNU/Linux System wie folgt installieren lassen:

sudo apt install adb heimdall-flash

Daraufhin können die benötigten Images heruntergeladen werden. Dabei ist darauf zu achten, dass sowohl das Recovery Image als auch das Zip-Systemarchiv zu dem jeweiligen Modell passen. Sicherheitshalber kann die Prüfsumme mit den angebotenen Prüfsummen-Dateien verglichen werden.

Im ersten Schritt wird das Recovery Image mittels Heimdall übertragen. Dazu wird zunächst das Telefon ausgeschaltet und von einer möglichen USB-Verbindung getrennt. Daraufhin startet man das Gerät mit gleichzeitigem Drücken der Leiser- + Einschalt- + Auswahltaste (mittlere Hardwaretaste unter dem Display). Es sollte der Heimdall Download Modus aktiviert werden, welcher eine Bestätigung erfordert.

Erst sobald diese erfolgt ist, kann das Gerät mit dem Computer, auf den zuvor die Images heruntergeladen wurden, verbunden werden.

Nach dem Wechsel in das Verzeichnis, welches das Recovery Image enthält, wird der Flash-Vorgang wie folgt gestartet:

heimdall flash --BOOT recovery-i9300.img --RECOVERY recovery-i9300.img

Sobald dieser erfolgreich war, sollte das Telefon automatisch in den Recovery Modus starten, aus dem die Systeminstallation durchgeführt werden kann.

Die Navigation im Recovery-Modus erfolgt wahlweise über den Touchscreen oder mit den Lauter- / Leiser-Tasten sowie der Power-Taste zur Auswahl.

Zur Vorbereitung der Systeminstallation wählt man Advanced / Wipe system partition. Über den Zurück-Softbutton rechts unter dem Display gelangt man wieder ins Hauptmenü und wählt dort Factory resetWipe data.

Das Systemarchiv kann nun mittels adb sideload vom Computer übertragen werden. Dazu wählt man im Recovery Hauptmenü Apply update / Apply from ADB.

Auf dem Computer kann man sich mittels adb devices anzeigen lassen, ob das Gerät erkannt wurde und ob es sich im Sideloading-Modus befinden. Sollte dies der Fall sein, erfolgt die Übertragung des Zip-Archives wie folgt:

adb sideload replicant-6.0-0004-i9300.zip 

Nachdem diese erfolgreich abgeschlossen wurde, kann das System neu gestartet werden und es begrüsst den freudigen Benutzer eines vollständig befreiten Android-Telefons mit einem roten Roboter. Der erste Systemstart kann dabei etwas mehr Zeit in Anspruch nehmen.

Da WLAN ohne externen Adapter auf dem Gerät aufgrund fehlender Treiber nicht funktionsfähig ist, sollte man eine funktionierende SIM-Karte mit Datenvolumen einlegen, oder die benötigten Anwendungen ebenfalls mittels adb installieren.

Weitere Informationen und Supportkanäle findet man auf der Homepage des Projektes.






Orchid Linux

Mi, 29. Juni 2022, Lioh Möller

Wem die Installation und Konfiguration von Gentoo zu aufwändig oder zu kompliziert ist, der kann einen Blick auf Orchid Linux werfen. Das aus Frankreich stammende Projekt hat sich zum Ziel gesetzt, Gentoo für eine grössere Nutzergruppe zur Verfügung zu stellen. Dennoch richtet sich auch diese Distribution nicht an Einsteiger.

Dabei wird versucht, dem Geiste Gentoos treu zu bleiben und möglichst wenige Modifikationen durchzuführen. Lediglich die Installation wird durch vorcompilierte Paketgruppen beschleunigt, welche beispielsweise als KDE Plasma, Xfce, GNOME oder eine Variante mit dwm angeboten werden.

Darüber hinaus werden Tools bereitgestellt, welche die Arbeit mit dem System vereinfachen sollen und zum Beispiel Systemaktualisierungen ermöglichen.

Die Installation selbst ähnelt hingegen aktuell eher einem klassischen Gentoo Installationsvorgang. Es wird weder ein grafisches noch ein textbasiertes Installationsprogramm angeboten und die erforderlichen Schritte müssen manuell durchgeführt werden. Englischkenntnisse werden dazu zwingend vorausgesetzt. Sofern das System einmal auf die Festplatte gebannt wurde, kann es auf Wunsch mit dem sogenannten Tkg-Kernel ausgestattet werden, der Optimierungen insbesondere für das Gaming- und die Desktop-Nutzung enthält. Mithilfe des Kommandos orchid-nvidia lässt sich bei Bedarf auf einfache Weise NVIDIA Treiber installieren.

Viele der enthaltenen Tools sind lediglich Wrapper in Gentoo enthaltene Standardwerzeuge wie emerge oder eix-sync. Ob es sinnvoller wäre, sich direkt mit der Mutterdistribution auseinanderzusetzen und deren Befehle zu erlernen, oder ob man von den Vereinfachungen des Orchid Linux Projektes profitieren möchte, bleibt letztendlich die Entscheidung des interessierten Anwenders. Mittels orchid-transform lässt sich alternativ auch ein bereits installiertes Gentoo in ein Orchid Linux verwandeln.

Quelle: https://orchid-linux.org/en/index.html






Mozilla veröffentlicht Firefox 102

Mozilla hat Firefox 102 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Weitere Download-Verbesserungen

Mit Firefox 98 hatte Mozilla grundlegende Veränderungen am Download-Verhalten durchgeführt. Basierend auf dem Feedback der Nutzer kam in Firefox 101 eine einfache Möglichkeit via Option zurück, vor jedem Download gefragt zu werden. Mit Firefox 102 folgt die Umsetzung von weiterem Feedback.

So kann über about:config der neue Schalter browser.download.start_downloads_in_tmp_dir per Doppelklick auf true geschaltet werden, damit Firefox wieder das temporäre Download-Verzeichnis nutzt, in welchem diese (auf Nicht-macOS-Plattformen) automatisch gelöscht werden.

Das automatische Öffnen des Download-Panels, immer wenn ein neuer Download startet, kann über eine Rechtsklick-Option auf einen Download-Eintrag in eben jenem Panel abgeschaltet werden. Dies war bereits abschaltbar, bislang jedoch ausschließlich via about:config und nicht über eine sichtbare Option.

Untertitel für Bild-im-Bild-Videos auf weiteren Streaming-Plattformen

Auf Websites, welche den WebVTT-Standard unterstützen, sowie auf den populären Video- und Streaming-Plattformen YouTube, Amazon Prime Video und Netflix, welche stattdessen eine eigene Lösung verwenden, kann Firefox seit Version 100 die Untertitel von Videos auch im Bild-im-Bild-Modus anzeigen.

Firefox 102 bringt eine zusätzliche Untertitel-Unterstützung für HBO Max, Funimation, Dailymotion, Tubi, Disney+ Hotstar sowie SonyLIV.

Mehr Sicherheit für Firefox-Nutzer

Auch in Firefox 102 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 102 daher für alle Nutzer dringend empfohlen.

Das Audio-Dekoding findet nun in einem separaten Prozess mit strengeren Sandboxing-Regeln statt.

Außerdem werden SHA1-Signaturen in Zertifikaten standardmäßig nicht länger unterstützt.

Sonstige Neuerungen von Firefox 102

Firefox 102 entfernt beim Navigieren auf Websites automatisch bestimmte Tracking-Parameter bei Verwendung der strengen Einstellung für den Schutz vor Aktivitätenverfolgung.

Das Panel zum Speichern von Seiten im Mozilla-Dienst Pocket wurde neu gestaltet.

Pocket Firefox 102

In der Drucken-Vorschau gibt es jetzt auch bei PDF-Dateien die Option, die Kopf- und Fußzeilen nicht zu drucken.

Die Leseansicht unterstützt nun auch Markdown-Dateien auf GitHub.

Das Logo der Suchmaschine Ecosia wurde an das neue Design angepasst.

Im Stileditor der Entwicklerwerkzeuge lassen sich sich die geladenen Stylesheets jetzt filtern.

Auch für Entwickler von Websites und Firefox-Erweiterungen gab es wieder Neuerungen, welche in den MDN Web Docs dokumentiert sind.

Neue Basis für Firefox ESR

Firefox 102 löst Firefox 91 als Basis für Firefox ESR, die Unternehmensversion von Firefox mit Langzeitunterstützung, ab. Die Unterschiede zwischen Firefox 102 und Firefox ESR 102 sowie Wissenswertes für System-Administratoren werden in einem gesonderten Artikel behandelt.

Der Beitrag Mozilla veröffentlicht Firefox 102 erschien zuerst auf soeren-hentzschel.at.






Alles Wissenswerte zu Firefox ESR 102 inklusive Unterschiede zu Firefox 102

Mozilla hat Firefox 102 veröffentlicht. Firefox 102 ist gleichzeitig die neue Basis für Firefox ESR, die Firefox-Version mit Langzeitunterstützung. Während Firefox 102 und Firefox ESR 102 grundsätzlich identisch sind, gibt es doch ein paar Unterschiede zwischen beiden Versionen. Auch sonst gibt es einiges Wissenswertes für System-Administratoren.

Mozilla hat Firefox 102 und Firefox ESR 102 veröffentlicht. Nutzer von Firefox ESR 91 haben noch zwölf Wochen Zeit, ehe sie mit Erscheinen von Firefox 105 und Firefox ESR 102.3 am 20. September 2022 automatisch auf Firefox ESR 102 migriert werden. Wie schon Firefox ESR 91 unterscheidet sich auch Firefox ESR 102 in ein paar wenigen Details von seinem Mainstream-Pendant.

Download Mozilla Firefox ESR 102

Nur in Firefox ESR 102: Deaktivierbare Signaturpflicht für Add-ons

Zum Schutz seiner Nutzer hat Mozilla eine Signaturpflicht für Add-ons in Firefox eingeführt, welche seit Firefox 43 standardmäßig aktiviert ist. Diese kann nur in Nightly-Builds sowie in der Developer Edition von Firefox deaktiviert werden, nicht in Beta- oder finalen Versionen. Die ESR-Version von Firefox 102 erlaubt auch in der finalen Ausführung die Deaktivierung der Signaturpflicht.

Zur Deaktivierung muss der folgende Schalter über about:config auf false geschaltet werden:

xpinstall.signatures.required

Achtung: Es ist aus Sicherheitsgründen nicht empfohlen, die Signaturpflicht für Erweiterungen zu deaktivieren. Wer seine Erweiterungen ausschließlich über addons.mozilla.org bezieht, findet außerdem in der Regel sowieso ausschließlich signierte Erweiterungen vor.

Nur in Firefox ESR 102: Zusätzliche Unternehmensrichtlinie

Seit Firefox 60 liefert Mozilla die Unterstütztung von Unternehmensrichtlinien aus. Damit ist es für Systemadministratoren möglich, Firefox für die Verteilung im Unternehmen vorzukonfigurieren, wofür bis einschließlich Firefox ESR 52 gerne der sogenannte CCK2 Wizard benutzt worden ist, der allerdings mit Firefox 57 und höher nicht kompatibel ist.

Die SearchEngines-Richtlinie zum Konfigurieren der Suchmaschinen funktioniert ausschließlich in Firefox ESR.

Alle Neuerungen zwischen Firefox ESR 91 und Firefox ESR 102

Natürlich gab es zwischen Firefox ESR 91 und Firefox ESR 102 auch wieder zahlreiche Neuerungen, darunter auch Neuerungen, welche für Unternehmen relevant sein könnten, wie beispielsweise neue Sicherheits- und Datenschutz-Verbesserungen. Für einen Überblick über alle wichtigen Neuerungen zwischen Firefox ESR 91 und Firefox ESR 102 empfiehlt sich die Lektüre der Artikel über die Neuerungen der entsprechenden Major-Releases:

Sonstiges Wissenswertes für Unternehmens-Administratoren

Unternehmensrichtlinien

Firefox lässt sich mittels zahlreicher Unternehmensrichtlinien konfigurieren. Dabei gibt es verschiedene Wege: Plattformübergreifend auf Windows, Apple macOS sowie Linux über eine Datei policies.json, via GPO oder Intune auf Windows oder via .plist-Datei auf Apple macOS.

MSI-Installer für Windows

Um System-Administratoren im Unternehmen das Anpassen und Verteilen von Firefox einfacher zu machen, bietet Mozilla anpassbare MSI-Installer für Firefox ESR auf Windows 7 und höher an.

MSI-Installer erlauben die Anpassung über eine MST-Datei und können über die auf Windows üblichen Deployment-Tools wie Active Directory oder Microsoft System Center Configuration Manager verteilt werden. Mozilla hat eine Dokumentation zu den MSI-Installern veröffentlicht.

Download MSI-Installer von Firefox ESR 102

pkg-Installer für Apple macOS

Ähnlich zu den MSI-Installern für Windows gibt es pkg-Installer für Apple macOS.

Download pkg-Installer von Firefox ESR 102

Dedizierte Profile pro Installation abschalten

Lesezeichen, Chronik, Erweiterungen, Passwörter, Einstellungen – diese und noch weitere Dinge werden in einem sogenannten Profil gespeichert. Verschiedene Firefox-Installationen nutzen bisher standardmäßig immer das gleiche Profil.

Seit Firefox 67 nutzt der Mozilla-Browser dedizierte Profile pro Installation. Das heißt, dass wenn ein Nutzer mehrere Firefox-Installation hat, jede dieser Installationen ein eigenes Profil verwendet und damit standardmäßig nicht länger in allen Installationen automatisch die gleichen Lesezeichen, die gleiche Chronik etc. zur Verfügung stehen.

Gerade im Unternehmensumfeld kann dies unerwartet sein. Über eine Umgebungsvariable mit beliebigem Wert kann dieses Feature abgeschaltet werden:

MOZ_LEGACY_PROFILES

Wie Umgebungsvariablen angelegt werden, ist der Dokumentation des jeweiligen Betriebssystems zu entnehmen.

Downgrade-Schutz abschalten

Ein anderes Feature seit Firefox 67 ist ein Downgrade-Schutz. Firefox verhindert, dass der Browser mit einem Profil gestartet wird, welches bereits mit einer neueren Firefox-Version genutzt worden ist. Auch dieses Feature kann über eine Umgebungsvariable mit beliebigem Wert abgeschaltet werden:

MOZ_ALLOW_DOWNGRADE

Alternativ dazu kann Firefox mit dem folgenden Kommandozeilen-Argument gestartet werden:

--allow-downgrade

Dokumentation für System-Administratoren

Hier gibt es spezielle Hilfe-Seiten für die Administration von Firefox im Unternehmen.

Der Beitrag Alles Wissenswerte zu Firefox ESR 102 inklusive Unterschiede zu Firefox 102 erschien zuerst auf soeren-hentzschel.at.






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

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.






RPM OSTree GUI

Fr, 24. Juni 2022, Lioh Möller

In Fedora Silverblue ist die Aktualisierung mittels rpm-ostree bereits in GNOME Software integriert. Das KDE Projekt arbeitet ebenfalls seit einer Zeit an einer Integration in Discover, welche allerdings noch nicht abgeschlossen wurde.

Nutzer von Alternativen wie Vauxite bleibt bisher nur ein Griff zur Kommandozeile. Abhilfe schafft das in Python geschriebene Programm RPM OSTree GUI.

Die Installation kann mittels pip3 im Benutzerkontext erfolgen:

pip3 install rpm-ostree-gui

Daraufhin lässt sich die Anwendung über den entsprechenden Eintrag im Startmenü aufrufen.

Aktuell ist es mit dessen Hilfe möglich, zusätzliche Pakete zu installieren, sofern der Paketname bekannt ist. Eine Deinstallation kann ebenfalls ausgelöst werden, sowie eine Suche über die installierten Overlays.

Nützlich ist die integrierte Aktualisierungsfunktion sowie die Möglichkeit, die bisher experimentelle 'Apply live' Funktion aufzurufen, welche eine Aktivierung von neuen Overlays unter bestimmten Umständen ohne Neustart durchführen kann.

Quelle: https://github.com/epiccakeking/rpm-ostree-gui






EPC-QR-Code mittels qrencode erstellen

Vor etlichen Jahren hatte ich mit qrencode ein Werkzeug vorgestellt, um QR-Codes auf der Kommandozeile zu generieren. Neben normalen QR-Code können mit dem Werkzeug auch andere Codes wie EPC-QR-Codes erstellt werden. Dazu muss im ersten Schritt eine Textdatei erzeugt und entsprechend befüllt werden:

BCD
001
1
SCT
BIC12345678
Ada Lovelace
DE07123412341234123412
EUR3.14


Verwendungszweck

Der Wert in der ersten Zeile ist der Service Tag, welcher immer BCD ist und in der nächsten Zeile von einer Versionsnummer ergänzt wird. Anschließend folgt die Zeichenkodierung, in diesem Fall ist es UTF-8. Daraufhin folgt die Identifikation für den SEPA Credit Transfer, anschließend die BIC und der Name des Zahlungsempfängers. Mit dem Zahlungsbeitrag folgen die optionalen Werte, welche bei Bedarf ausgelassen werden dürfen, indem eine Leerzeile genutzt wird.

Der generierte EPC-QR-Code

Anschließend kann aus der Datei der entsprechende QR-Code erstellt werden:

cat epc.txt | qrencode -o epc.png -l M -s 24

Gedacht sind diese Codes, um Überweisung auf mobilen Endgeräten schnell vorzunehmen, indem die entsprechenden Daten über den QR-Code eingelesen werden.