12.15 guix system aufrufen

Sobald Sie eine Betriebssystemdeklaration geschrieben haben, wie wir sie in den vorangehenden Abschnitten gesehen haben, kann diese instanziiert werden, indem Sie den Befehl guix system aufrufen. Zusammengefasst:

guix system Optionen… Aktion Datei

Datei muss der Name einer Datei sein, in der eine Betriebssystemdeklaration als operating-system-Objekt steht. Aktion gibt an, wie das Betriebssystem instanziiert wird. Derzeit werden folgende Werte dafür unterstützt:

search

Verfügbare Diensttypendefinitionen anzeigen, die zum angegebenen regulären Ausdruck passen, sortiert nach Relevanz:

$ guix system search console
name: console-fonts
location: gnu/services/base.scm:806:2
extends: shepherd-root
description: Install the given fonts on the specified ttys (fonts are per
+ virtual console on GNU/Linux).  The value of this service is a list of
+ tty/font pairs.  The font can be the name of a font provided by the `kbd'
+ package or any valid argument to `setfont', as in this example:
+
+      '(("tty1" . "LatGrkCyr-8x16")
+        ("tty2" . (file-append
+                      font-tamzen
+                      "/share/kbd/consolefonts/TamzenForPowerline10x20.psf"))
+        ("tty3" . (file-append
+                      font-terminus
+                      "/share/consolefonts/ter-132n"))) ; for HDPI
relevance: 9

name: mingetty
location: gnu/services/base.scm:1190:2
extends: shepherd-root
description: Provide console login using the `mingetty' program.
relevance: 2

name: login
location: gnu/services/base.scm:860:2
extends: pam
description: Provide a console log-in service as specified by its
+ configuration value, a `login-configuration' object.
relevance: 2

…

Wie auch bei guix package --search wird das Ergebnis im recutils-Format geliefert, so dass es leicht ist, die Ausgabe zu filtern (siehe GNU-recutils-Datenbanken in Handbuch von GNU recutils).

edit

Die Definition des angegebenen Dienstes bearbeiten oder anzeigen.

Beispielsweise öffnet folgender Befehl Ihren Editor, der mit der Umgebungsvariablen EDITOR gewählt werden kann, an der Stelle, wo der openssh-Diensttyp definiert ist:

guix system edit openssh

reconfigure

Das in der Datei beschriebene Betriebssystem erstellen, aktivieren und zu ihm wechseln³³.

Anmerkung: Es ist sehr zu empfehlen, guix pull einmal auszuführen, bevor Sie guix system reconfigure zum ersten Mal aufrufen (siehe guix pull aufrufen). Wenn Sie das nicht tun, könnten Sie nach dem Abschluss von reconfigure eine ältere Version von Guix vorfinden, als Sie vorher hatten.

Dieser Befehl setzt die in der Datei festgelegte Konfiguration vollständig um: Benutzerkonten, Systemdienste, die Liste globaler Pakete, setuid-Programme und so weiter. Der Befehl startet die in der Datei angegebenen Systemdienste, die aktuell nicht laufen; bei aktuell laufenden Diensten wird sichergestellt, dass sie aktualisiert werden, sobald sie das nächste Mal angehalten wurden (z.B. durch herd stop X oder herd restart X).

Dieser Befehl erzeugt eine neue Generation, deren Nummer (wie guix system list-generations sie anzeigt) um eins größer als die der aktuellen Generation ist. Wenn die so nummerierte Generation bereits existiert, wird sie überschrieben. Dieses Verhalten entspricht dem von guix package (siehe guix package aufrufen).

Des Weiteren wird für den Bootloader ein Menüeintrag für die neue Betriebssystemkonfiguration hinzugefügt, außer die Befehlszeilenoption --no-bootloader wurde übergeben. Bei GRUB werden Einträge für ältere Konfigurationen in ein Untermenü verschoben, so dass Sie auch eine ältere Systemgeneration beim Booten noch hochfahren können, falls es notwendig wird.

Nach Abschluss wird das neue System unter /run/current-system verfügbar gemacht. Das Verzeichnis enthält Provenienz-Metadaten: Dazu gehören die Liste der Kanäle, die benutzt wurden (siehe Kanäle) und die Datei selbst, wenn sie verfügbar ist. Sie können sie auf diese Weise ansehen:

guix system describe

Diese Informationen sind nützlich, falls Sie später inspizieren möchten, wie diese spezielle Generation erstellt wurde. Falls die Datei eigenständig ist, also keine anderen Dateien zum Funktionieren braucht, dann können Sie tatsächlich die Generation n Ihres Betriebssystems später erneut erstellen mit:

guix time-machine \
  -C /var/guix/profiles/system-n-link/channels.scm -- \
  system reconfigure \
  /var/guix/profiles/system-n-link/configuration.scm

Sie können sich das als eine Art eingebaute Versionskontrolle vorstellen! Ihr System ist nicht nur ein binäres Erzeugnis: Es enthält seinen eigenen Quellcode. Siehe provenance-service-type für mehr Informationen zur Provenienzverfolgung.

Nach Voreinstellung können Sie durch reconfigure Ihr System nicht auf eine ältere Version aktualisieren und somit herabstufen, denn dadurch könnten Sicherheitslücken eingeführt und Probleme mit „zustandsbehafteten“ Diensten wie z.B. Datenbankverwaltungssystemen ausgelöst werden. Sie können das Verhalten ändern, indem Sie --allow-downgrades übergeben.

switch-generation ¶

Zu einer bestehenden Systemgeneration wechseln. Diese Aktion wechselt das Systemprofil atomar auf die angegebene Systemgeneration. Hiermit werden auch die bestehenden Menüeinträge des Bootloaders umgeordnet. Der Menüeintrag für die angegebene Systemgeneration wird voreingestellt und die Einträge der anderen Generationen werden in ein Untermenü verschoben, sofern der verwendete Bootloader dies unterstützt. Das nächste Mal, wenn das System gestartet wird, wird die hier angegebene Systemgeneration hochgefahren.

Der Bootloader selbst wird durch diesen Befehl nicht neu installiert. Es wird also lediglich der bereits installierte Bootloader mit einer neuen Konfigurationsdatei benutzt werden.

Die Zielgeneration kann ausdrücklich über ihre Generationsnummer angegeben werden. Zum Beispiel würde folgender Aufruf einen Wechsel zur Systemgeneration 7 bewirken:

guix system switch-generation 7

Die Zielgeneration kann auch relativ zur aktuellen Generation angegeben werden, in der Form +N oder -N, wobei +3 zum Beispiel „3 Generationen weiter als die aktuelle Generation“ bedeuten würde und -1 „1 Generation vor der aktuellen Generation“ hieße. Wenn Sie einen negativen Wert wie -1 angeben, müssen Sie -- der Befehlszeilenoption voranstellen, damit die negative Zahl nicht selbst als Befehlszeilenoption aufgefasst wird. Zum Beispiel:

guix system switch-generation -- -1

Zurzeit bewirkt ein Aufruf dieser Aktion nur einen Wechsel des Systemprofils auf eine bereits existierende Generation und ein Umordnen der Bootloader-Menüeinträge. Um die Ziel-Systemgeneration aber tatsächlich zu benutzen, müssen Sie Ihr System neu hochfahren, nachdem Sie diese Aktion ausgeführt haben. In einer zukünftigen Version von Guix wird diese Aktion einmal dieselben Dinge tun, wie reconfigure, also etwa Dienste aktivieren und deaktivieren.

Diese Aktion schlägt fehl, wenn die angegebene Generation nicht existiert.

roll-back ¶

Zur vorhergehenden Systemgeneration wechseln. Wenn das System das nächste Mal hochgefahren wird, wird es die vorhergehende Systemgeneration benutzen. Dies ist die Umkehrung von reconfigure und tut genau dasselbe wie switch-generation mit dem Argument -1 aufzurufen.

Wie auch bei switch-generation müssen Sie derzeit, nachdem Sie diese Aktion aufgerufen haben, Ihr System neu starten, um die vorhergehende Systemgeneration auch tatsächlich zu benutzen.

delete-generations ¶

Systemgenerationen löschen, wodurch diese zu Kandidaten für den Müllsammler werden (siehe guix gc aufrufen für Informationen, wie Sie den „Müllsammler“ laufen lassen).

Es funktioniert auf die gleiche Weise wie ‘guix package --delete-generations’ (siehe --delete-generations). Wenn keine Argumente angegeben werden, werden alle Systemgenerationen außer der aktuellen gelöscht:

guix system delete-generations

Sie können auch eine Auswahl treffen, welche Generationen Sie löschen möchten. Das folgende Beispiel hat die Löschung aller Systemgenerationen zur Folge, die älter als zwei Monate sind:

guix system delete-generations 2m

Wenn Sie diesen Befehl ausführen, wird automatisch der Bootloader mit einer aktualisierten Liste von Menüeinträgen neu erstellt – z.B. werden im Untermenü für die „alten Generationen“ in GRUB die gelöschten Generationen nicht mehr aufgeführt.

build

Die Ableitung des Betriebssystems erstellen, einschließlich aller Konfigurationsdateien und Programme, die zum Booten und Starten benötigt werden. Diese Aktion installiert jedoch nichts davon.

init

In das angegebene Verzeichnis alle Dateien einfügen, um das in der Datei angegebene Betriebssystem starten zu können. Dies ist nützlich bei erstmaligen Installationen von „Guix System“. Zum Beispiel:

guix system init my-os-config.scm /mnt

Hiermit werden alle Store-Objekte nach /mnt kopiert, die von der in my-os-config.scm angegebenen Konfiguration vorausgesetzt werden. Dazu gehören Konfigurationsdateien, Pakete und so weiter. Auch andere essenzielle Dateien, die auf dem System vorhanden sein müssen, damit es richtig funktioniert, werden erzeugt – z.B. die Verzeichnisse /etc, /var und /run und die Datei /bin/sh.

Dieser Befehl installiert auch den Bootloader auf jedem in my-os-config mit targets angegebenen Ziel, außer die Befehlszeilenoption --no-bootloader wurde übergeben.

vm ¶

Eine virtuelle Maschine (VM) erstellen, die das in der Datei deklarierte Betriebssystem enthält, und ein Skript liefern, das diese virtuelle Maschine startet.

Anmerkung: Die Aktion vm sowie solche, die weiter unten genannt werden, können KVM-Unterstützung im Kernel Linux-libre ausnutzen. Insbesondere sollte, wenn die Maschine Hardware-Virtualisierung unterstützt, das entsprechende KVM-Kernelmodul geladen sein und das Gerät /dev/kvm muss dann existieren und dem Benutzer und den Erstellungsbenutzern des Daemons müssen Berechtigungen zum Lesen und Schreiben darauf gegeben werden (siehe Einrichten der Erstellungsumgebung).

An das Skript übergebene Argumente werden an QEMU weitergereicht, wie Sie am folgenden Beispiel sehen können. Damit würde eine Netzwerkverbindung aktiviert und 1 GiB an RAM für die emulierte Maschine angefragt:

$ /gnu/store/…-run-vm.sh -m 1024 -smp 2 -nic user,model=virtio-net-pci

Beide Schritte können zu einem kombiniert werden:

$ $(guix system vm my-config.scm) -m 1024 -smp 2 -nic user,model=virtio-net-pci

Die virtuelle Maschine verwendet denselben Store wie das Wirtssystem.

Vorgegeben ist, für die VM das Wurzeldateisystem als flüchtig („volatile“) einzubinden. Mit der Befehlszeilenoption --persistent werden Änderungen stattdessen dauerhaft. In diesem Fall wird das Disk-Image der VM aus dem Store in das Verzeichnis TMPDIR kopiert, damit Schreibzugriff darauf besteht.

Mit den Befehlszeilenoptionen --share und --expose können weitere Dateisysteme zwischen dem Wirtssystem und der VM geteilt werden: Der erste Befehl gibt ein mit Schreibzugriff zu teilendes Verzeichnis an, während der letzte Befehl nur Lesezugriff auf das gemeinsame Verzeichnis gestattet.

Im folgenden Beispiel wird eine virtuelle Maschine erzeugt, die auf das Persönliche Verzeichnis des Benutzers nur Lesezugriff hat, wo das Verzeichnis /austausch aber mit Lese- und Schreibzugriff dem Verzeichnis $HOME/tmp auf dem Wirtssystem zugeordnet wurde:

guix system vm my-config.scm \
   --expose=$HOME --share=$HOME/tmp=/austausch

Für GNU/Linux ist das vorgegebene Verhalten, direkt in den Kernel zu booten, wodurch nur ein sehr winziges „Disk-Image“ (eine Datei mit einem Abbild des Plattenspeichers der virtuellen Maschine) für das Wurzeldateisystem nötig wird, weil der Store des Wirtssystems davon eingebunden werden kann.

Mit der Befehlszeilenoption --full-boot wird erzwungen, einen vollständigen Bootvorgang durchzuführen, angefangen mit dem Bootloader. Dadurch wird mehr Plattenplatz verbraucht, weil dazu ein Disk-Image mindestens mit dem Kernel, initrd und Bootloader-Datendateien erzeugt werden muss.

Mit der Befehlszeilenoption --image-size kann die Größe des Disk-Images angegeben werden.

Mit der Befehlszeilenoption --no-graphic wird guix system angewiesen, eine VM ohne Oberfläche anzulegen, bei der die Konsole für Ein-/Ausgabe benutzt wird, über die die VM gestartet wurde. Unter anderem wird damit eine Zwischenablage zum Kopieren und Einfügen und ein Zeilenpuffer (Scrollback) angeboten. Wenn Sie strg-a zuvor drücken, können Sie QEMU-Befehle angeben, z.B. zeigt strg-a h eine Hilfe an und strg-a x beendet die VM; mit strg-a c wechseln Sie zwischen der QEMU-Anzeige und der VM.

image ¶

Mit dem Befehl image können mehrere Abbildtypen erzeugt werden. Der Abbildtyp kann durch die Befehlszeilenoption --image-type ausgewählt werden. Vorgegeben ist efi-raw. Für den Wert iso9660 kann mit der Befehlszeilenoption --label eine Datenträgerkennung („Volume ID“) angegeben werden. Nach Vorgabe wird das Wurzeldateisystem eines Abbilds als nicht-flüchtig eingebunden. Wenn die Befehlszeilenoption --volatile angegeben wird, dann sind Änderungen daran bloß flüchtig. Bei der Verwendung von image wird auf dem erzeugten Abbild derjenige Bootloader installiert, der in der operating-system-Definition angegeben wurde. Das folgende Beispiel zeigt, wie Sie ein Abbild erzeugen, das als Bootloader grub-efi-bootloader benutzt, und es mit QEMU starten:

image=$(guix system image --image-type=qcow2 \
        gnu/system/examples/lightweight-desktop.tmpl)
cp $image /tmp/my-image.qcow2
chmod +w /tmp/my-image.qcow2
qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
                   -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin

Wenn Sie den Abbildtyp efi-raw anfordern, wird ein rohes Disk-Image hergestellt; es kann zum Beispiel auf einen USB-Stick kopiert werden. Angenommen /dev/sdc ist das dem USB-Stick entsprechende Gerät, dann kann das Disk-Image mit dem folgenden Befehls darauf kopiert werden:

# dd if=$(guix system image my-os.scm) of=/dev/sdc status=progress

Durch die Befehlszeilenoption --list-image-types werden alle verfügbaren Abbildtypen aufgelistet.

Wenn Sie den Abbildtypen qcow2 benutzen, wird ein Abbild im qcow2-Format geliefert, das vom QEMU-Emulator effizient benutzt werden kann. Siehe Guix in einer virtuellen Maschine betreiben für weitere Informationen, wie Sie das Abbild in einer virtuellen Maschine ausführen. Als Bootloader wird immer grub-bootloader benutzt, egal was in der als Argument übergebenen operating-system-Datei deklariert wurde. Der Grund dafür ist, dass dieser besser mit QEMU funktioniert, das als BIOS nach Voreinstellung SeaBIOS benutzt, wo erwartet wird, dass ein Bootloader in den Master Boot Record (MBR) installiert wurde.

Wenn Sie den Abbildtyp docker anfordern, wird ein Abbild für Docker hergestellt. Guix erstellt das Abbild von Grund auf und nicht aus einem vorerstellten Docker-Basisabbild heraus, daher enthält es exakt das, was Sie in der Konfigurationsdatei für das Betriebssystem angegeben haben. Sie können das Abbild dann wie folgt laden und einen Docker-Container damit erzeugen:

image_id="$(docker load < guix-system-docker-image.tar.gz)"
container_id="$(docker create $image_id)"
docker start $container_id

Dieser Befehl startet einen neuen Docker-Container aus dem angegebenen Abbild. Damit wird das Guix-System auf die normale Weise hochgefahren, d.h. zunächst werden alle Dienste gestartet, die Sie in der Konfiguration des Betriebssystems angegeben haben. Sie können eine interaktive Shell in dieser isolierten Umgebung bekommen, indem Sie docker exec benutzen:

docker exec -ti $container_id /run/current-system/profile/bin/bash --login

Je nachdem, was Sie im Docker-Container ausführen, kann es nötig sein, dass Sie ihn mit weitergehenden Berechtigungen ausstatten. Wenn Sie zum Beispiel Software mit Guix innerhalb des Docker-Containers erstellen wollen, müssen Sie an docker create die Befehlszeilenoption --privileged übergeben.

Zuletzt bewirkt die Befehlszeilenoption --network, dass durch guix system docker-image ein Abbild erzeugt wird, was sein Netzwerk mit dem Wirtssystem teilt und daher auf Dienste wie nscd oder NetworkManager verzichten sollte.

container

Liefert ein Skript, um das in der Datei deklarierte Betriebssystem in einem Container auszuführen. Mit Container wird hier eine Reihe ressourcenschonender Isolierungsmechanismen im Kernel Linux-libre bezeichnet. Container beanspruchen wesentlich weniger Ressourcen als vollumfängliche virtuelle Maschinen, weil der Kernel, Bibliotheken in gemeinsam nutzbaren Objektdateien („Shared Objects“) sowie andere Ressourcen mit dem Wirtssystem geteilt werden können. Damit ist also eine „dünnere“ Isolierung möglich.

Zurzeit muss das Skript als Administratornutzer „root“ ausgeführt werden, damit darin mehr als nur ein einzelner Benutzer und eine Benutzergruppe unterstützt wird. Der Container teilt seinen Store mit dem Wirtssystem.

Wie bei der Aktion vm (siehe guix system vm) können zusätzlich weitere Dateisysteme zwischen Wirt und Container geteilt werden, indem man die Befehlszeilenoptionen --share und --expose verwendet:

guix system container my-config.scm \
   --expose=$HOME --share=$HOME/tmp=/austausch

Die Befehlszeilenoptionen --share und --expose können Sie auch an das erzeugte Skript übergeben, um weitere Verzeichnisse im Container als Verzeichniseinbindung („bind mount“) verfügbar zu machen.

Anmerkung: Diese Befehlszeilenoption funktioniert nur mit Linux-libre 3.19 oder neuer.

Unter den Optionen können beliebige gemeinsame Erstellungsoptionen aufgeführt werden (siehe Gemeinsame Erstellungsoptionen). Des Weiteren kann als Optionen Folgendes angegeben werden:

--expression=Ausdruck

-e Ausdruck

Als Konfiguration des Betriebssystems das operating-system-Objekt betrachten, zu dem der Ausdruck ausgewertet wird. Dies ist eine Alternative dazu, die Konfiguration in einer Datei festzulegen. Hiermit wird auch das Installationsabbild des Guix-Systems erstellt, siehe Ein Abbild zur Installation erstellen).

--system=System

-s System

Versuchen, für das angegebene System statt für denselben Systemtyp wie auf dem Wirtssystem zu erstellen. Dies funktioniert wie bei guix build (siehe Aufruf von guix build).

--target=Tripel

Lässt für das angegebene Tripel cross-erstellen, dieses muss ein gültiges GNU-Tripel wie z.B. "aarch64-linux-gnu" sein (siehe GNU-Tripel für configure in Autoconf).

--derivation

-d

Liefert den Namen der Ableitungsdatei für das angegebene Betriebssystem, ohne dazu etwas zu erstellen.

--save-provenance

Wie zuvor erläutert, speichern guix system init und guix system reconfigure Provenienzinformationen immer über einen dedizierten Dienst (siehe provenance-service-type). Andere Befehle tun das nach Voreinstellung jedoch nicht. Wenn Sie zum Beispiel ein Abbild für eine virtuelle Maschine mitsamt Provenienzinformationen erzeugen möchten, können Sie dies ausführen:

guix system image -t qcow2 --save-provenance config.scm

Auf diese Weise wird im erzeugten Abbild im Prinzip „sein eigener Quellcode eingebettet“, in Form von Metadaten in /run/current-system. Mit diesen Informationen kann man das Abbild neu erzeugen, um sicherzugehen, dass es tatsächlich das enthält, was davon behauptet wird. Man könnte damit auch eine Abwandlung des Abbilds erzeugen.

--image-type=Typ

-t Typ

Für die Aktion image wird ein Abbild des angegebenen Typs erzeugt.

Wird diese Befehlszeilenoption nicht angegeben, so benutzt guix system den Abbildtyp efi-raw.

--image-type=iso9660 erzeugt ein Abbild im Format ISO-9660, was für das Brennen auf CDs und DVDs geeignet ist.

--image-size=Größe

Für die Aktion image wird hiermit festgelegt, dass ein Abbild der angegebenen Größe erstellt werden soll. Die Größe kann als Zahl die Anzahl Bytes angeben oder mit einer Einheit als Suffix versehen werden (siehe Größenangaben in GNU Coreutils).

Wird keine solche Befehlszeilenoption angegeben, berechnet guix system eine Schätzung der Abbildgröße anhand der Größe des in der Datei deklarierten Systems.

--network

-N

Für die Aktion container dürfen isolierte Umgebungen (auch bekannt als „Container“) auf das Wirtsnetzwerk zugreifen, d.h. es wird kein Netzwerknamensraum für sie erzeugt.

--root=Datei

-r Datei

Die Datei zu einer symbolischen Verknüpfung auf das Ergebnis machen und als Müllsammlerwurzel registrieren.

--skip-checks

Die Konfiguration nicht vor der Installation zur Sicherheit auf Fehler prüfen.

Das vorgegebene Verhalten von guix system init und guix system reconfigure sieht vor, die Konfiguration zur Sicherheit auf Fehler hin zu überprüfen, die ihr Autor übersehen haben könnte: Es wird sichergestellt, dass die in der operating-system-Deklaration erwähnten Dateisysteme tatsächlich existieren (siehe Dateisysteme) und dass alle Linux-Kernelmodule, die beim Booten benötigt werden könnten, auch im initrd-modules-Feld aufgeführt sind (siehe Initiale RAM-Disk). Mit dieser Befehlszeilenoption werden diese Tests allesamt übersprungen.

--allow-downgrades

An guix system reconfigure die Anweisung erteilen, Systemherabstufungen zuzulassen.

Nach Voreinstellung können Sie mit reconfigure Ihr System nicht auf eine ältere Version aktualisieren und somit herabstufen. Dazu werden die Provenienzinformationen Ihres Systems herangezogen (wie sie auch von guix system describe angezeigt werden) und mit denen aus Ihrem guix-Befehl verglichen (wie sie guix describe anzeigt). Wenn die Commits von guix nicht Nachfolger derer Ihres Systems sind, dann bricht guix system reconfigure mit einer Fehlermeldung ab. Wenn Sie --allow-downgrades übergeben, können Sie diese Sicherheitsüberprüfungen umgehen.

Anmerkung: Sie sollten verstehen, was es für die Sicherheit Ihres Rechners bedeutet, ehe Sie --allow-downgrades benutzen.

--on-error=Strategie

Beim Auftreten eines Fehlers beim Einlesen der Datei die angegebene Strategie verfolgen. Als Strategie dient eine der Folgenden:

nothing-special

Nichts besonderes; der Fehler wird kurz gemeldet und der Vorgang abgebrochen. Dies ist die vorgegebene Strategie.

backtrace

Ebenso, aber zusätzlich wird eine Rückverfolgung des Fehlers (ein „Backtrace“) angezeigt.

debug

Nach dem Melden des Fehlers wird der Debugger von Guile zur Fehlersuche gestartet. Von dort können Sie Befehle ausführen, zum Beispiel können Sie sich mit ,bt eine Rückverfolgung („Backtrace“) anzeigen lassen und mit ,locals die Werte lokaler Variabler anzeigen lassen. Im Allgemeinen können Sie mit Befehlen den Zustand des Programms inspizieren. Siehe Debug Commands in Referenzhandbuch zu GNU Guile für eine Liste verfügbarer Befehle zur Fehlersuche.

Sobald Sie Ihre Guix-Installation erstellt, konfiguriert, neu konfiguriert und nochmals neu konfiguriert haben, finden Sie es vielleicht hilfreich, sich die auf der Platte verfügbaren – und im Bootmenü des Bootloaders auswählbaren – Systemgenerationen auflisten zu lassen:

describe

Die laufende Systemgeneration beschreiben: ihren Dateinamen, den Kernel und den benutzten Bootloader etc. sowie Provenienzinformationen, falls verfügbar.

Die Befehlszeilenoption --list-installed hat dieselbe Syntax wie bei guix package --list-installed (siehe guix package aufrufen). Wenn die Befehlszeilenoption angegeben wird, wird in der Beschreibung eine Liste der Pakete angezeigt, die aktuell im Systemprofil installiert sind. Optional kann die Liste mit einem regulären Ausdruck gefiltert werden.

Anmerkung: Mit der laufenden Systemgeneration – die, auf die /run/current-system verweist – ist nicht unbedingt die aktuelle Systemgeneration gemeint, auf die /var/guix/profiles/system verweist: Sie unterscheiden sich, wenn Sie zum Beispiel im Bootloader-Menü eine ältere Generation starten lassen.

Auch die gebootete Systemgeneration – auf die /run/booted-system verweist – ist vielleicht eine andere, etwa wenn Sie das System in der Zwischenzeit rekonfiguriert haben.

list-generations

Eine für Menschen verständliche Zusammenfassung jeder auf der Platte verfügbaren Generation des Betriebssystems ausgeben. Dies ähnelt der Befehlszeilenoption --list-generations von guix package (siehe guix package aufrufen).

Optional kann ein Muster angegeben werden, was dieselbe Syntax wie guix package --list-generations benutzt, um damit die Liste anzuzeigender Generationen einzuschränken. Zum Beispiel zeigt der folgende Befehl Generationen an, die bis zu 10 Tage alt sind:

$ guix system list-generations 10d

Sie können als Befehlszeilenoption --list-installed angeben mit derselben Syntax wie in guix package --list-installed. Das kann nützlich sein, wenn Sie herausfinden möchten, wann ein bestimmtes Paket zum System hinzukam.

Der Befehl guix system hat sogar noch mehr zu bieten! Mit folgenden Unterbefehlen wird Ihnen visualisiert, wie Ihre Systemdienste voneinander abhängen:

extension-graph

Auf die Standardausgabe den Diensterweiterungsgraphen des in der Datei definierten Betriebssystems ausgeben (siehe Dienstkompositionen für mehr Informationen zu Diensterweiterungen). Vorgegeben ist, ihn im Dot-/Graphviz-Format auszugeben, aber Sie können ein anderes Format mit --graph-backend auswählen, genau wie bei guix graph (siehe --backend):

Der Befehl:

$ guix system extension-graph Datei | xdot -

zeigt die Erweiterungsrelation unter Diensten an.

Anmerkung: Sie finden das Programm dot im Paket graphviz.

shepherd-graph

Auf die Standardausgabe den Abhängigkeitsgraphen der Shepherd-Dienste des in der Datei definierten Betriebssystems ausgeben. Siehe Shepherd-Dienste für mehr Informationen sowie einen Beispielgraphen.

Auch hier wird nach Vorgabe die Ausgabe im Dot-/Graphviz-Format sein, aber Sie können ein anderes Format mit --graph-backend auswählen.