Nächste: guix deploy
aufrufen, Vorige: Bootloader-Konfiguration, Nach oben: Systemkonfiguration [Inhalt][Index]
guix system
aufrufenSobald 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: Installiert die angegebenen Schriftarten auf den festgelegten TTYs + (auf dem Linux-Kernel werden Schriftarten für jede virtuelle Konsole einzeln + festgelegt). Als Wert nimmt dieser Dienst eine Liste von Paaren aus TTY und + Schriftart. Als Schriftart kann der Name einer vom `kbd'-Paket zur Verfügung + gestellten Schriftart oder ein beliebiges gültiges Argument für `setfont' + dienen. Ein Beispiel: + + '(("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 wechseln38.
Anmerkung: Es ist sehr zu empfehlen,
guix pull
einmal auszuführen, bevor Sieguix system reconfigure
zum ersten Mal aufrufen (sieheguix pull
aufrufen). Wenn Sie das nicht tun, könnten Sie nach dem Abschluss vonreconfigure
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,
privilegierten 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.
installer
Run the installer. Usually the installer is built as an iso image, copied to a USB Stick or DVD, and booted from (Installation von USB-Stick oder DVD). If your machine already runs Guix and you still want to run the installer, e.g., for testing purposes, you can skip the step of creating an iso and run for instance:
guix system installer --dry-run
Anmerkung: If you do not use --dry-run then you need to run as root. Be very careful when running the installer as root, it can cause data loss or render your system unbootable!
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.
The --no-graphic option will instruct guix system
to
spawn a headless VM that will use the invoking tty for IO. Among other
things, this enables copy-pasting, and scrollback. Use the ctrl-a
prefix to issue QEMU commands; e.g. ctrl-a h prints a help,
ctrl-a x quits the VM, and ctrl-a c switches between the QEMU
monitor and the 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 mbr-hybrid-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-x86-64)/share/firmware/ovmf_x64.bin
Wenn Sie den Abbildtyp mbr-hybrid-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:
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).
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
).
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).
Liefert den Namen der Ableitungsdatei für das angegebene Betriebssystem, ohne dazu etwas zu erstellen.
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.
Für die Aktion image
wird ein Abbild des angegebenen Typs
erzeugt.
Wird diese Befehlszeilenoption nicht angegeben, so benutzt guix
system
den Abbildtyp mbr-hybrid-raw
.
--image-type=iso9660 erzeugt ein Abbild im Format ISO-9660, was für das Brennen auf CDs und DVDs geeignet ist.
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.
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.
Die Datei zu einer symbolischen Verknüpfung auf das Ergebnis machen und als Müllsammlerwurzel registrieren.
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.
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.
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 Paketgraphviz
.
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.
Diese Aktion (und die dazu ähnlichen Aktionen
switch-generation
und roll-back
) sind nur auf Systemen
nutzbar, auf denen „Guix System“ bereits läuft.
Nächste: guix deploy
aufrufen, Vorige: Bootloader-Konfiguration, Nach oben: Systemkonfiguration [Inhalt][Index]