Construire Aurora localement sans GitHub
La plupart de ces conseils ne sont pas propres à Aurora : leurs principes s'appliquent à toute image de conteneur, amorçable ou non.
Nous supposons que vous êtes assez à l'aise avec les outils en ligne de commande utilisés ici, comme git, podman ou un éditeur de texte.
Nous n'expliquerons pas tout ici : il s'agit seulement d'un aperçu général du fonctionnement. Vous devez pouvoir chercher vous-même des informations complémentaires sur les outils mentionnés pour déployer nos images (man, --help ou toute autre forme de documentation).
N'hésitez toutefois pas à nous contacter si vous avez des questions !
Comprendre l'architecture d'Aurora
Les images d'Aurora sont construites à partir de plusieurs dépôts qui fonctionnent ensemble :
- ublue-os/aurora - Dépôt principal des images, qui orchestre le processus de construction et définit les images finales
- get-aurora-dev/common - Configurations d'Aurora, recettes ujust, éléments graphiques et personnalisations reposant sur aurorafin-shared (ujust, MOTD, configuration des outils en ligne de commande, etc.)
- ublue-os/brew - Installation et configuration de Homebrew
- ublue-os/akmods - Paquets liés au noyau partagés par Universal Blue (Nvidia, V4L2, xone)
Préparatifs
Dépendances de construction
Cloner le dépôt principal d'Aurora
git clone https://github.com/ublue-os/aurora
Construire les images
Le Justfile à la racine du dépôt sert à construire les images. Voici quelques exemples :
| Commande | Description |
|---|---|
just build | Utilise par défaut latest et main |
just build --image aurora-dx | Construit Aurora DX |
just build --image aurora-dx --tag testing --flavor nvidia-open | Construit la version testing nvidia-open d'Aurora DX |
just build --tag stable --flavor nvidia-open | Construit la version nvidia-open de la branche stable d'Aurora |
- Images :
aurora,aurora-dx - Étiquettes :
stable,latest,testing - Variantes :
main,nvidia-open
Nous vous recommandons de faire précéder ces commandes de construction par sudo.
Nous utilisons just parce que la construction de nos images est assez complexe : nous ajoutons de nombreux build-arg et label. Cette recette just génère essentiellement une grande commande buildah build et vérifie l'authenticité de nos conteneurs de construction avec cosign.
Tester les modifications locales des couches communes
Si vous souhaitez modifier et tester localement des configurations propres à Aurora (recettes ujust, éléments graphiques, etc.), suivez cette procédure :
Cloner et modifier le dépôt Common
git clone https://github.com/get-aurora-dev/common
cd common
Apportez les modifications souhaitées aux fichiers du dépôt common.
Construire le conteneur Common localement
(sudo) just build
Cela crée une image locale portant l'étiquette localhost/aurora-common:latest.
Modifier le Containerfile d'Aurora
Dans votre dépôt local ublue-os/aurora, vous devez modifier le fichier Containerfile.in pour qu'il référence votre construction locale de common plutôt que celle du dépôt distant.
Dans le fichier Containerfile.in à la racine du dépôt, recherchez la ligne FROM ${COMMON} AS common et modifiez-la pour qu'elle pointe vers votre construction locale :
-FROM ${COMMON} AS common
+FROM localhost/aurora-common AS common
Construire Aurora avec vos modifications locales de Common
Rendez-vous maintenant dans ublue-os/aurora et construisez l'image d'Aurora :
just build
Aurora sera ainsi construit avec votre couche common modifiée localement.
Construire une image dérivée
Vous pouvez bien entendu construire une image dérivée en suivant la procédure classique des conteneurs, plutôt que de construire Aurora « à partir de zéro ».
FROM ghcr.io/ublue-os/aurora:stable
RUN ...
Nous recommandons le modèle image-template.
Tester vos modifications
La méthode dépend fortement de vos modifications, mais l'option la plus sûre consiste à créer une machine virtuelle avec la recette disk-image, puis à la démarrer avec qemu. C'est ce qui se rapproche le plus d'une installation d'Aurora depuis l'ISO d'installation.
Répéter la procédure
Si vous devez apporter d'autres modifications :
- Modifiez les fichiers du dépôt common
- Reconstruisez le conteneur common
- Reconstruisez l'image d'Aurora
- Basculez vers la nouvelle image locale
Proposer vos modifications
Une fois vos modifications testées localement :
- Pour les fonctionnalités propres à Aurora (configurations, éléments graphiques, recettes ujust d'Aurora), ouvrez une pull request dans get-aurora-dev/common
- Pour les fonctionnalités partagées qui concernent Aurora et Bluefin (recettes ujust de base, MOTD, configuration des outils en ligne de commande), contribuez à ublue-os/aurorafin-shared
- Pour les modifications liées à Homebrew, contribuez à ublue-os/brew
- Pour les modifications de l'image d'Aurora elle-même (paquets installés, scripts de construction), contribuez à ublue-os/aurora
Veillez à n'inclure dans vos commits que les modifications réellement souhaitées, à l'aide d'outils comme git add -p.
Basculer vers une image construite localement
Pour que bootc puisse basculer vers la nouvelle image, celle-ci doit être transférée du stockage de conteneurs de l'utilisateur vers celui du compte root.
podman image scp localhost/aurora:latest root@localhost
Vous pouvez aussi ajouter sudo devant les commandes just build : vous n'aurez alors pas besoin de l'étape podman image scp.
sudo bootc switch --transport containers-storage localhost/aurora:latest
Enfin, redémarrez sur la nouvelle image :
systemctl reboot
Tester sans construire d'image
Cette méthode rend /usr accessible en écriture jusqu'au prochain redémarrage, ce qui suffit généralement pour tester des modifications très simples.
overlayfs sur /usr
sudo bootc usr-overlay
Utilisez dnf ou apportez les modifications souhaitées à /usr.
sudo dnf install/swap/remove/downgrade ...
Redémarrez pour annuler toutes les modifications apportées après le montage d'overlayfs sur /usr.
Voici une autre façon de procéder sans redémarrer le système :
sudo rm /run/ostree/deployment-state/*.0/unlocked-development
sudo umount -l /usr
N'oubliez pas que /etc et /var ne sont pas réinitialisés après un redémarrage : vous pouvez donc toujours endommager votre système et y laisser des fichiers résiduels !
Vous pouvez aussi créer une couche de superposition plus persistante :
Cela peut être utile pour revenir à une version antérieure d'un micrologiciel ou pour diagnostiquer des bogues qui ne se produisent qu'à l'arrêt, par exemple.
sudo ostree admin unlock --hotfix
rpm-ostree status
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable
Digest: sha256:4d08e32db51d634eb6fa1cf27e8472de074db783aee5c89849899e00c36c4b59
Version: 42.20250630 (2025-06-30T04:54:48Z)
Unlocked: hotfix
sudo dnf -y downgrade atheros-firmware-20250311-1$(rpm -E %{dist})
Pour supprimer ce déploiement accessible en écriture, vous pouvez simplement effectuer une mise à jour ou attendre la prochaine : il finira par être nettoyé. Vous pouvez aussi démarrer sur le déploiement précédent depuis Grub et exécuter :
rpm-ostree cleanup --pending