Suivant: Utiliser des clés de sécurité, Précédent: Personnalisation du noyau, Monter: Configuration du système [Table des matières][Index]
Historiquement, le système Guix est centré sur une structure
operating-system. Cette structure contient divers champs qui vont du
chargeur d’amorçage et à la déclaration du noyau aux services à installer.
Les contraintes sur l’image peuvent grandement varier en fonction de la
machine cible : une machine x86_64 standard n’a pas les mêmes
contraintes qu’un petit ordinateur monocarte ARM comme le Pine64. Les
fabricants de matériel imposent donc des formats d’image distincts avec des
tailles et des emplacements de partition variables.
Pour créer des images convenables pour toutes ces machines, une nouvelle
abstraction est nécessaire : c’est le but de l’enregistrement
image. Cet enregistrement contient toutes les informations requises
pour être transformé en une image complète, qui peut être directement
démarrée sur une machine cible.
(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 ;size in bytes as integer
(default 'guess))
(operating-system image-operating-system ;<operating-system>
(default #f))
(partitions image-partitions ;list of <partition>
(default '()))
(compression? image-compression? ;boolean
(default #t))
(volatile-root? image-volatile-root? ;boolean
(default #t))
(substitutable? image-substitutable? ;boolean
(default #t)))
Cet enregistrement contient le système d’exploitation à instancier. Le champ
format défini le type d’image et peut être efi-raw,
qcow2 ou iso9660 par exemple. Plus tard, on prévoit de
l’étendre à docker et aux autres types d’images.
Un nouveau répertoire dans les sources de Guix est dédié aux définitions des images. Pour l’instant il y a quatre fichiers :
Regardons le fichier pine64.scm. Il contient la variable
pine64-barebones-os qui est une définition minimale d’un système
d’exploitation dédié à la carte Pine A64 LTS.
(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")) ; no carrier detect
(baud-rate "115200")
(term "vt100")
(tty "ttyS0")))
%base-services))))
Les champs kernel et bootloader pointent vers les paquets
dédiés à cette carte.
Ci-dessous, la variable pine64-image-type est ainsi définie.
(define pine64-image-type
(image-type
(name 'pine64-raw)
(constructor (cut image-with-os arm64-disk-image <>))))
Elle utilise un enregistrement dont nous n’avons pas encore parlé,
l’enregistrement image-type, défini de cette façon :
(define-record-type* <image-type> image-type make-image-type image-type? (name image-type-name) ;symbol (constructor image-type-constructor)) ;<operating-system> -> <image>
Le but principal de cet enregistrement est d’associer un nom à une procédure
transformant un operating-system en une image. Pour comprendre
pourquoi c’est nécessaire, voyons la commande produisant une image à partir
d’un fichier de configuration de type operating-system :
guix system image my-os.scm
Cette commande demande une configuration de type operating-system
mais comment indiquer que l’on veut cibler une carte Pine64 ? Nous devons
fournir l’information supplémentaire, image-type, en passant le
drapeau --image-type ou -t, de cette manière :
guix system image --image-type=pine64-raw my-os.scm
Ce paramètre image-type pointe vers le pine64-image-type
défini plus haut. Ainsi, la déclaration operating-system dans
my-os.scm se verra appliquée la procédure [cut image-with-os
arm64-disk-image <>) pour la transformer en une image.
L’image qui en résulte ressemble à ceci :
(image
(format 'disk-image)
(target "aarch64-linux-gnu")
(operating-system my-os)
(partitions
(list (partition
(inherit root-partition)
(offset root-offset)))))
qui ajoute l’objet operating-system défini dans my-os.scm à
l’enregistrement arm64-disk-image.
Mais assez de cette folie. Qu’est-ce que cette API pour les images apporte aux utilisateurs et utilisatrices ?
On peut lancer :
mathieu@cervin:~$ guix system --list-image-types Les types d'image disponibles sont : - 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
et en écrivant un fichier de type operating-system basé sur
pine64-barebones-os, vous pouvez personnaliser votre image selon vos
préférences dasn un fichier (my-pine-os.scm) de cette manière :
(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)))))
lancez :
guix system image --image-type=pine64-raw my-pine-os.scm
ou bien,
guix system image --image-type=hurd-raw my-hurd-os.scm
pour récupérer une image que vous pouvez écrire sur un disque dur pour démarrer dessus.
Sans rien changer à my-hurd-os.scm, en appelant :
guix system image --image-type=hurd-qcow2 my-hurd-os.scm
vous aurez une image QEMU pour le Hurd à la place.
Suivant: Utiliser des clés de sécurité, Précédent: Personnalisation du noyau, Monter: Configuration du système [Table des matières][Index]