Nächste: Sicherheitsschlüssel verwenden, Vorige: Den Kernel anpassen, Nach oben: Systemkonfiguration [Inhalt][Index]
In der Vergangenheit drehte sich in Guix System alles um eine
operating-system-Struktur. So eine Struktur enthält vielerlei Felder
vom Bootloader und der Deklaration des Kernels bis hin zu den Diensten, die
installiert werden sollen.
Aber je nach Zielmaschine – diese kann alles von einer normalen
x86_64-Maschine sein bis zu einem kleinen ARM-Einplatinenrechner wie
dem Pine64 –, können die für ein Abbild geltenden Einschränkungen sehr
unterschiedlich sein. Die Hardwarehersteller ordnen verschiedene
Abbildformate an mit unterschiedlich versetzten unterschiedlich großen
Partitionen.
Um für jede dieser Arten von Maschinen geeignete Abbilder zu erzeugen,
brauchen wir eine neue Abstraktion. Dieses Ziel verfolgen wir mit dem
image-Verbund. Ein Verbundsobjekt enthält alle nötigen Informationen,
um daraus ein eigenständiges Abbild auf die Zielmaschine zu bringen. Es ist
direkt startfähig von jeder solchen Zielmaschine.
(define-record-type* <image>
image make-image
image?
(name image-name ;Symbol
(default #f))
(format image-format) ;Symbol
(target image-target
(default #f))
(size image-size ;Größe in Bytes als ganze Zahl
(default 'guess)) ;Vorgabe: automatisch bestimmen
(operating-system image-operating-system ;<operating-system>
(default #f))
(partitions image-partitions ;Liste von <partition>
(default '()))
(compression? image-compression? ;Boolescher Ausdruck
(default #t))
(volatile-root? image-volatile-root? ;Boolescher Ausdruck
(default #t))
(substitutable? image-substitutable? ;Boolescher Ausdruck
(default #t)))
In einem Verbundsobjekt davon steht auch das zu instanziierende
Betriebssystem (in operating-system). Im Feld format steht,
was der Abbildtyp („image type“) ist, zum Beispiel efi-raw,
qcow2 oder iso9660. In Zukunft könnten die Möglichkeiten auf
docker oder andere Abbildtypen erweitert werden.
Ein neues Verzeichnis im Guix-Quellbaum wurde Abbilddefinitionen gewidmet. Zurzeit gibt es vier Dateien darin:
Schauen wir uns pine64.scm an. Es enthält die Variable
pine64-barebones-os, bei der es sich um eine minimale Definition
eines Betriebssystems handelt, die auf Platinen der Art Pine A64 LTS
ausgerichtet ist.
(define pine64-barebones-os
(operating-system
(host-name "vignemale")
(timezone "Europe/Paris")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-pine64-lts-bootloader)
(targets '("/dev/vda"))))
(initrd-modules '())
(kernel linux-libre-arm64-generic)
(file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(services (cons (service agetty-service-type
(agetty-configuration
(extra-options '("-L")) ;kein Carrier Detect
(baud-rate "115200")
(term "vt100")
(tty "ttyS0")))
%base-services))))
Die Felder kernel und bootloader verweisen auf
platinenspezifische Pakete.
Direkt darunter wird auch die Variable pine64-image-type definiert.
(define pine64-image-type
(image-type
(name 'pine64-raw)
(constructor (cut image-with-os arm64-disk-image <>))))
Sie benutzt einen Verbundstyp, über den wir noch nicht gesprochen haben, den
image-type-Verbund. Er ist wie folgt definiert:
(define-record-type* <image-type> image-type make-image-type image-type? (name image-type-name) ;Symbol (constructor image-type-constructor)) ;<operating-system> -> <image>
Der Hauptzweck dieses Verbunds ist, einer Prozedur, die ein
operating-system in ein image-Abbild umwandelt, einen Namen zu
geben. Um den Bedarf dafür nachzuvollziehen, schauen wir uns den Befehl an,
mit dem ein Abbild aus einer operating-system-Konfigurationsdatei
erzeugt wird:
guix system image my-os.scm
Dieser Befehl erwartet eine operating-system-Konfiguration, doch wie
geben wir an, dass wir ein Abbild für einen Pine64-Rechner möchten? Wir
müssen zusätzliche Informationen mitgeben, nämlich den Abbildtyp,
image-type, indem wir die Befehlszeilenoption --image-type
oder -t übergeben, und zwar so:
guix system image --image-type=pine64-raw my-os.scm
Der Parameter image-type verweist auf den oben definierten
pine64-image-type. Dadurch wird die Prozedur (cut image-with-os
arm64-disk-image <>) auf das in my-os.scm deklarierte
operating-system angewandt und macht es zu einem image-Abbild.
Es ergibt sich ein Abbild wie dieses:
(image
(format 'disk-image)
(target "aarch64-linux-gnu")
(operating-system my-os)
(partitions
(list (partition
(inherit root-partition)
(offset root-offset)))))
Das ist das Aggregat aus dem in my-os.scm definierten
operating-system und dem arm64-disk-image-Verbundsobjekt.
Aber genug vom Scheme-Wahnsinn. Was nützt die Image-Schnittstelle dem Nutzer von Guix?
Sie können das ausführen:
mathieu@cervin:~$ guix system --list-image-types Die verfügbaren Abbildtypen sind: - unmatched-raw - rock64-raw - pinebook-pro-raw - pine64-raw - novena-raw - hurd-raw - hurd-qcow2 - qcow2 - iso9660 - uncompressed-iso9660 - tarball - efi-raw - mbr-raw - docker - wsl2 - raw-with-offset - efi32-raw
und indem Sie eine Betriebssystemkonfigurationsdatei mit einem auf
pine64-barebones-os aufbauenden operating-system schreiben,
können Sie Ihr Abbild nach Ihren Wünschen anpassen in einer Datei, sagen wir
my-pine-os.scm:
(use-modules (gnu services linux) (gnu system images pine64)) (let ((base-os pine64-barebones-os)) (operating-system (inherit base-os) (timezone "America/Indiana/Indianapolis") (services (cons (service earlyoom-service-type (earlyoom-configuration (prefer-regexp "icecat|chromium"))) (operating-system-user-services base-os)))))
Führen Sie aus:
guix system image --image-type=pine64-raw my-pine-os.scm
oder
guix system image --image-type=hurd-raw my-hurd-os.scm
und Sie bekommen ein Abbild, das Sie direkt auf eine Festplatte kopieren und starten können.
Ohne irgendetwas an my-hurd-os.scm zu ändern, bewirkt ein Aufruf
guix system image --image-type=hurd-qcow2 my-hurd-os.scm
dass stattdessen ein Hurd-Abbild für QEMU erzeugt wird.
Nächste: Sicherheitsschlüssel verwenden, Vorige: Den Kernel anpassen, Nach oben: Systemkonfiguration [Inhalt][Index]