Wie man sich sein eigenes Fedora LiveImage baut

Mein zweiter sichtbarerer Beitrag für das Fedoraprojekt ist vor einigen Tagen Live gegangen :

Quick Docs – Creating and Using a live Installation Image

und beim Lesen direkt einen Tippfehler gefunden 🙁 😀 Der nachfolgende Text ist dann auch fast eine 1:1 Übersetzung davon, gespickt mit ein paar Anpassungen. Das ist übrigens auch das gleiche Vorgehen, wie beim Bau des Linux am Dienstag Rescue Images.

Wie man sich sein eigenes Fedora LiveImage baut

Wir verwenden Fedora Release 42 als Beispiel für alle Befehlsbeispiele. Wenn Sie dies für eine andere Version tun müssen, ändern Sie einfach die Versionsnummer entsprechend.

Schritt 1

Um ein Live-Image zu erstellen, werden die Pakete livecd-creator und mock verwendet. Dazu sind Superuser-Rechte erforderlich.

Das Tool livecd-creator ist Teil des Pakets livecd-tools. Wenn es nicht auf Ihrem System installiert ist, fügen Sie es und alle anderen Tools wie mock, lorax, git, pykickstart und einen Texteditor (vim) mit DNF hinzu:

# dnf install livecd-tools mock

Hinweis: Wir erstellen eine Live-CD wie das fedora-live-workstation-Image, das vollständig lokalisiert ist, aber Englisch als Standardsprache hat. Sie müssen keine Lokalisierungsunterstützung selbst installieren. Sie können dies bei Bedarf in der erstellten kickstart.cfg ändern.

Konfigurieren Ihres Systems

Wir müssen Ihren aktuellen Benutzer zur mock-Gruppe hinzufügen, oder Sie müssen alles als Root-Benutzer tun. Ich habe dafür Root genommen, aber das ist echt egal.

# sudo usermod -aG mock $(whoami)

Das $(whoami) fügt Ihren aktuellen Benutzer hinzu, da wir nicht wissen, welchen Benutzernamen Sie derzeit verwenden 😉

Es wäre ratsam, sich erneut anzumelden, damit die Änderung wirksam wird, oder Sie wechseln jetzt zu root.

Erstellen wir die mock-Gruppe:

# newgrp mock

Wenn Sie nun Folgendes eingeben:

# groups

sollte Ihr Benutzername zusammen mit den alten Gruppen und der neuen Gruppe „mock” angezeigt werden. Ist dies nicht der Fall, haben Sie etwas falsch gemacht.

Mock legt uns eine Toolbox  an

Jetzt können wir die Build-Umgebung initialisieren. In diesem Beispiel verwenden wir die wahrscheinlichste Architektur x86_64, aber wenn Sie für ARM oder PowerPC bauen, können Sie einfach eine andere Konfiguration verwenden, indem Sie den ARCH-Typ auf die gewünschte Plattform ändern!

# mock -r /etc/mock/fedora-42_x86_64.cfg –init

Mock erstellt dafür eine leere Toolbox, die wir mit Paketen füllen müssen, die wir später im Prozess zum Erstellen des Images benötigen. Wenn Sie jetzt denken „Warum so kompliziert?“, haben Sie nur teilweise Recht, denn eine Toolbox ist ein einfacher Container, den wir benötigen, um die Arbeit für verschiedene Fedora-Versionen zu trennen. Andernfalls müssten Sie verschiedene Builds selbst überschreiben und mischen.

Stellen Sie sicher, dass Sie über genügend freien Speicherplatz für all diese Dateien und die Dateien verfügen, die der livemedia-creator später herunterladen wird. Wir empfehlen mindestens 10 GB freien Speicherplatz dafür.

# mock -r /etc/mock/fedora-42_x86_64.cfg –install lorax anaconda git pykickstart vim lorax anaconda git pykickstart vim libblockdev-lvm libblockdev-btrfs libblockdev-swap libblockdev-loop libblockdev-crypto libblockdev-dm libblockdev-mdraid libblockdev-part libblockdev-fs libblockdev-nvme libblockdev-mpath

Wenn Sie einen anderen Texteditor als „vim” verwenden möchten, müssen Sie diesen jetzt installieren, da Sie sonst auf eine nicht besonders gut integrierte Basisinstallation von „vim” angewiesen sind, deren Verwendung etwas unangenehm sein kann. Keine Panik, wir nehmen innerhalb der Toolbox nicht viele Bearbeitungen vor, vim reicht völlig aus 🙂

Nun rufen wir die Toolbox zum ersten Mal auf …​

# mock -r /etc/mock/fedora-42_x86_64.cfg –shell –isolation=simple –enable-network

Dadurch erhalten wir eine Shell und Netzwerkunterstützung, sodass die Skripte in der Toolbox auf das Internet zugreifen und Pakete aus dem Repository installieren können.

Die folgende Ausgabe sieht in etwa so aus:

INFO: mock.py version 6.3 starting (python version = 3.13.7, NVR = mock-6.3-1.fc42), args: /usr/libexec/mock/mock -r fedora-42-x86_64 –shell –isolation=simple –enable-network
Start(bootstrap): init plugins
INFO: selinux enabled
Finish(bootstrap): init plugins
Start: init plugins
INFO: selinux enabled
Finish: init plugins
INFO: Signal handler active
Start: run
Start(bootstrap): chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: Package manager dnf5 detected and used (fallback)
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
INFO: Package manager dnf5 detected and used (direct choice)
Finish: chroot init
Start: shell
<mock-chroot> sh-5.2#

Jetzt müssen wir die Kickstart-Dateien, die in früheren Fedora-Versionen als Paket enthalten waren, von den Fedora-Servern herunterladen:

# git clone https://pagure.io/fedora-kickstarts -b f42

Sie können die Seite mit einem normalen Browser aufrufen, um zu sehen, welche Tags, auch „Branches” genannt, wie „f42” verfügbar sind, falls Sie eine andere Version von Fedora verwenden möchten. Was nun geschieht, ist ein Git-Checkout in das aktuelle Verzeichnis Ihrer Toolbox.

Großer Vorteil: Es besteht keine Gefahr, dass Dateien auf Ihrem Betriebssystem überschrieben werden.

ACHTUNG: Bevor Sie fortfahren, stellen Sie sicher, dass Sie mindestens 10 GB freien Speicherplatz auf Ihrer Systempartition haben, da wir eine Menge RPMs herunterladen und ein Image mit einer Größe von mindestens 2,3 GB erstellen werden. Wenn Sie nicht über genügend Speicherplatz verfügen, können alle weiteren Schritte mit den wildesten Fehlermeldungen fehlschlagen und Sie werden VIEL Zeit damit verschwenden!

Kickstarting für Anfänger

Was wir jetzt brauchen, ist eine Kickstart-Datei. Noch nie davon gehört? Keine Panik 😀

Eine Kickstart-Datei enthält Informationen über die Größe des tmp-Laufwerks im später gestarteten Live-Image, das es mountet, seine Pakete und so weiter. Sie müssen das Rad nicht neu erfinden, keine Sorge. Hier ist ein Beispiel:

%include fedora-live-workstation.ks
%packages
# Packages we want to have
thunderbird
# Package groups excluded from @workstation-product-environment
-@guest-desktop-agents
-@libreoffice
-@multimedia
# Packages excluded from @workstation-product
-rhythmbox
-unoconv
# Packages excluded from @gnome-desktop
-gnome-boxes
-gnome-connections
-gnome-text-editor
-baobab
-cheese
-gnome-clocks
-gnome-logs
-gnome-maps
-gnome-photos
-gnome-remote-desktop
-gnome-weather
-orca
-rygel
-totem
%end

Was Sie sehen, ist ein Teilbereich aller möglichen Optionen, da zuvor mit „git checkout“ ein vollständiger Satz bereits funktionierender Kickstart-Dateien heruntergeladen wurde, die wir zu einer neuen kickstart.cfg-Datei zusammenführen werden.

Die oben genannte Datei entfernt Pakete und Paketgruppen aus dem später erstellten Image im Vergleich zum normalen Fedora-Live-Workstation-Image. Es handelt sich dabei um eine DELTA-Datei, da wir lediglich die Unterschiede zwischen unserem Image und dem ursprünglichen Fedora Live Workstation-Image definieren.

Sie sehen Folgendes in der Datei:

%include fedora-live-workstation.ks

Dies beinhaltet die ursprüngliche Kickstart-Konfiguration (ks) für das ursprüngliche Fedora-Live-Workstation-Image als Basisdatei. Die restlichen Zeilen „überschreiben” die Abschnitte in der Originaldatei. Sie teilen Kickstart also lediglich mit, was Sie im Vergleich zum Fedora-Live-Workstation-Image möchten und was nicht.

Erstellen der Kickstart-Dateien

In diesem Beispiel haben wir einige Gnome-Anwendungen entfernt und erhalten so das sogenannte „Fedora-Minimal-Workstation”-Image. Wenn man statt „-“ einfach den Namen eines Paketes hinschreibt, fügt er das hinzu, z.B. gparted. „gparted“ ist das vielleicht beste grafische Partitionstool für Linux und in unserem Rescue Image unverzichtbar.

Nehmen Sie dieses Beispiel und speichern Sie es in einer Datei, die Sie z. B. „example-START.ks” nennen können. Achten Sie darauf, dass Sie Ihre Datei später als Ausgangspunkt Ihrer Arbeit wiedererkennen können. Denn jetzt werden wir die enthaltenen Dateien zu einer großen kickstart.cfg-Datei „zusammenfügen” bzw. „flatten”, die wir später für livemedia-creator benötigen.

$ ksflatten -c as-you-like-START.ks -o kickstart.cfg

Das Problem, mit dem Sie nun konfrontiert sind, ist, dass es nicht sofort funktioniert, da ksflatten nicht alle benötigten Includes findet. Sie können dies auf zwei Arten lösen:

a) Sie verschieben Ihre ks-Datei in das Verzeichnis „fedora-kickstarts” und wechseln mit cd dorthin, oder

mv as-you-like-START.ks fedora-kickstarts/
cd fedora-kickstarts

b) Sie führen den oben genannten Befehl aus und kopieren alle Dateien, die in der Fehlermeldung genannt werden, von „fedora-kickstarts” nach „.”, bis keine Fehlermeldung mehr angezeigt wird. Das ist mühselig, konterminiert aber das ausgecheckte GIT nicht und wir können die Kickstartfiles vom nächsten Fehler befreien, wenn wir wollten.

Von nun an sollten Sie nur noch die erstellte Datei kickstart.cfg bearbeiten, um Änderungen vorzunehmen, da Sie sonst den nächsten Schritt immer wieder wiederholen müssen.

Behebung des „Mount”-Fehlers

In beiden Fällen erhalten Sie eine fehlerhafte cfg-Datei, da die verwendeten Include-Dateien den Mountpunkt „/“ zweimal definieren, was zu einem Fehler führt. Das lässt sich leicht beheben:

# vim kickstart.cfg

Suchen Sie nach „# Disk partitioning information“ und ändern Sie die beiden Zeilen, die mit „part /“ beginnen, in diese EINE Zeile:

part / –fstype=„ext4“ –size=8576

Ich hab es mit Kevin besprochen: Das wird nicht mehr behoben, da Images bald nur noch mit Kiwi gebaut werden, was aber auch gerade nicht funktioniert 😀

Erstellen der ISO

Nun zu dem Teil, auf den Sie gewartet haben: Erstellen wir das ISO-Image.

# livemedia-creator –ks kickstart.cfg –no-virt –resultdir /var/lmc –project MYPROJECTNAME –make-iso –volid MY_ID –iso-only –iso-name <FILENAME>.iso –releasever 42 –macboot

Bitte ersetzen Sie die folgenden Begriffe:

„MYPROJECTNAME” Das ist Ihr interner Projektname, der in /etc/os-release landet.
MY_ID” Das ist der Name der gemounteten ISO-Datei UND SEHR WICHTIG, wenn Sie in GRUB auf diese ISO verweisen möchten.
<FILENAME>” Das ist der Name der erstellten ISO-Datei unter /var/lmc.

Wenn alles funktioniert, haben Sie in etwa 15 Minuten ein erstelltes <Dateiname>.iso-Image IN IHRER TOOLBOX. Das ist ja ein Container, also hat er es innen liegend gebaut 😉 Um es herauszuholen, geben Sie Folgendes ein …​

# exit

und kopieren Sie es an den gewünschten Ort. Beispiel:

# cp /var/lib/mock/fedora-42-x86_64/root/var/lmc/<Dateiname>.iso /home/themasteruser/Downloads/Images/

oder wo auch immer es sonst hin soll. Jetzt können Sie Ihr Image auf verschiedene Arten testen:

Sie können Gnome-Boxen verwenden, um es einfach in Ihrer Desktop-Umgebung auszuführen, was viel einfacher ist als sich eine VM mit QEMU einzurichten, aber auch das geht natürlich. Das Iso kann direkt auf einen USB Stick geschrieben werden.

Herzlichen Glückwunsch: Sie haben Ihr eigenes Live-Image erstellt.

Einige Tipps dazu:

  • Wenn Sie Dienste ausführen müssen, überprüfen Sie kickstart.cfg auf syslive.service.
  • Wenn Sie Konfigurationsdateien für die Dienste einfügen möchten, müssen Sie Ihr eigenes RPM erstellen.
  • Wenn Sie Ihre eigenen Pakete in das Image integrieren möchten, müssen Sie ein benutzerdefiniertes Repo hinzufügen. Siehe „repo” in kickstart.cfg .

Dann macht Euch mal an die Images ran 😉

Ein Recovery System wird geboren

Gestern bei Linux am Dienstag : Recovery ISO Images in Grub einbinden.

Ein Recovery System wird geboren

Gestern Abend konnten wir dank Kanos Hilfe in einem wilden Ritt durch Grub, ein Recovery ISO Image für Fedora in unser Testsystem einbauen, so daß es im GRUB Bootmenü permanent auftaucht, aber nicht auf der Systemplatte hinterlegt ist.

Kommt es zum Bootfail, mal von der totalen Zerstörung der Bootpartition abgesehen, kann über Grub das Recovery ISO Image geladen werden. Ein cleverer Updatemechanismus sorgt dafür, daß es zwar per DNF & RPM installiert werden kann, aber nicht präsent ist, wenn das System läuft. So kann es auch nicht durch unvorsichtige Benutzer oder Software gelöscht werden.

„Wie, nicht auf der Systemplatte hinterlegt?“

Es handelt sich nicht um eine bootbare Partition, das hätte man auch machen können, aber das hat einige Nachteile bei den Updates. Es ist eigentlich nur eine Lagerpartition, auf der das ISO Image draufliegt :

 

nichts besonderes zu sehen, nur ein offener Dateimanager mit dem ISO Image

Dazu gehört ein kleiner Eintrag in der /etc/grub.d:

# cat /etc/grub.d/99_RECOVERY
#!/bin/sh
exec tail -n +3 $0
# Copy into /etc/grub2.d and set chmod +x
menuentry „Fedora-RECOVERY“ –class fedora –class gnu-linux –class gnu –class os {
  insmod ext2
  set isofile=“/RECOVERY.iso
  search -sf $isofile
  loopback loop $isofile
  linux (loop)/boot/x86_64/loader/linux root=live:CDLABEL=Fedora-WS-Live-42 rd.live.image verbose iso-scan/  filename=$isofile quiet rhgb
  initrd (loop)/boot/x86_64/loader/initrd
}

An der Stelle herzlichen Dank an Kano von Kanotix. Er hat die Basis für dieses kleine Script bereitgestellt, der Eintrag selbst ist praktisch mit der LiveBootconfig von der Fedora 42 Livedisk identisch, aber nicht gleich 😉

Dieser GRUB Eintrag durchsucht dank search -sf dateiname alle lesbaren Partitionen nach RECOVERY.iso . Dann wird Grub angewiesen das ISO als Basis zu öffnen und den Kernel daraus nebst initramfs zu benutzen. Das ist ein klein bisschen mehr Aufwand, als wenn die ISO schon auf einem USB Stick ist. Funktioniert aber trotzdem erstaunlich gut.

Hat man das Script eingefügt, muß man es nur noch mit chmod +x  /etc/grub.d/99_RECOVERY ausführbar machen und einmal mit grub2-mkconfig -o /boot/grub2/grub.cfg eine neue Grubconfig gebaut werden.

im Grubmenü sieht das dann so aus:

Im Grubbootmenu sieht man den Fedora Recovery Eintrag

Danach bootet einfach das ISO Image normal durch.

Unser Plan für nächste Woche

Da der Boot- und Updatevorgang geklärt ist, Fedorauser können das nämlich bereits im Linux am Dienstag Repo finden, widmen wir uns nächste Woche dann dem Bau des speziellen Liveimages mit all den Tools, die man für ein Recovery so braucht.

ACHTUNG:

Wer das fedora-recovery RPM aus dem Repo testen will, braucht eine min.  3 GB große Partition namens „RECOVERY“. Das richtige Label ist ganz wichtig, weil das RPM darüber die richtige Partition für die Installation findet. Das Filesystem ist dabei in soweit egal, GRUB muß es nur lesen können. Es kommen also min. alle EXT Filesysteme, BTFS und VFAT in Frage.

Selbst wenn Ihr bei der Partition Mist baut, ist das beim Test nicht tragisch, Ihr habt dann einfach nur ein 2,3 GB ISO File unter /usr/share/recovery liegen, das unnötig Platz frisst 😉

Danach bauen wir Scripts um Probleme automatisch zu fixen

In den Wochen danach werden wir versuchen diverse Bootprobleme automatisch zu erkennen und zu fixen.

Am Ende des Projekts könnte ein automatisches Recovery-System stehen, daß normalen Endbenutzern das System wieder herstellt, wenn die es kaputt gemacht haben. Erfahrene Benutzer finden dann dort die Tools, um Ihre etwas heftigeren Probleme selbst zu beheben.

Wo ist jetzt der Vorteil gegenüber einem LIVEImage auf einem USBStick?

Gegenfrage: Wollt Ihr in der Krise erst noch den USB Stick suchen, dann feststellen, daß Ihr gar nicht wisst wo das Bootmenü vom Bios aktiviert wird um dann festzustellen, daß die Tools komplett veraltet sind?

Eher nicht, oder? 🙂 Außerdem wollen wir ja erreichen, daß der Linuxdesktop noch mehr von Normalen Benutzern akzeptiert wird, da muß ein Reparaturtool natürlich auch sehr einfach zu benutzen sein. Damit schlagen wir definitiv ein neues Kapitel im Fedora Desktop auf. Hoffentlich schließen sich da andere Distros mit an.

Übrigens auch für Serverbetreiber wäre das von Vorteil, weil man dann keine „Rescue CDROMS“ mehr in der VM Wechseln müßte, sondern einfach neu booten, ins GRUBMenü gehen und die Rescue starten. Das geht viel einfacher als in der VM erstmal die Bootreihenfolge zu ändern. Denkbar wäre auch eine PXE Bootumgebung, statt einer Partition, dann nimmt der Vorgang weniger Platz weg.

 

Linux – ISO Image brennen

Aus gegebenem Anlass heute das Thema, wie man eine ISO Datei auf einen USB Stick „brennt“.

Die einfache Antwort lautet natürlich: Genau so wie auf eine DVD, aber das ist natürlich nicht hilfreich, daher folgt eine bebilderte Anleitung.

Methode 1

Schritt 1 : Das Laufwerke Tool starten ( aka. Gnome-Disks )

Schritt 2 : Den USB Stick reinstecken und auswählen

Laufwerketool

Schritt 3 : Im Menu ( oben in der Fensterleiste ) „Laufwerksabbild wiederherstellen“ auswählen ( kommt der Kontext oben im Bild )

Schritt 4 : mit dem Dateirequester das ISO Image auswählen

Schritt 5 : Wiederherstellen anklicken

Wirklich brennen?

Schritt 6 : Die Rückfrage beantwortet und abwarten bis der Vorgang beendet ist.

Methode 2

  1. Im Nemo/Nautilus die ISO Datei rechts anklicken.

2. Öffnen mit „Schreiber von Laufwerksabbildern“ ( ganz unten )

Alternative Methode

3. Als Ziel den USB Stick auswählen

4. Wiederherstellung starten und bestätigen

5. Abwarten und Tee trinken gehen!