Fedora Silverblue

Édition de type immutable de Fedora.

Document intéressant sur l'origine de Fedora Silverblue : Team Silverblue - The Origins (voir note : L'origine du nom "Fedora Silverblue").

Ressources :

Journaux liées à cette note :

Convergence vers Bootc #fedora, #linux, #distribution-linux, #gnome

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Support OCI de CoreOS (image pull & updates)".

Colin Walters, le principal développeur de libostree a initié le projet bootc en mars 2021. J'ai découvert le projet bootc en début d'année et lisant des articles liés à systemd.

La vision de bootc est assez simple : rendre la création d'images de système d'exploitation aussi simple que la création d'images de conteneurs d'applications tout en utilisant les mêmes outils. Pour avoir un peu de contexte historique, je conseille l'article lwn de juin 2024 : Making containers bootable for fun and profit

Les images bootc utilisent la même technologie de stockage que les images des container classique : OCI.

D'après ce que j'ai compris, ce type d'image bootc ne porte pas nom officiellle, elles sont nommés aussi bien "bootc image", que "bootable container image" ou "bootable OCI image".

En janvier 2025, Red Hat a transféré le projet bootc à la CNCF. Le but est de permettre à toutes les distributions de l'adopter comme standard, indépendamment de Red Hat.

Parmis les distributions qui ont adopté bootc, trois retiennent mon attention :

Au moment où j'écris ces lignes, je pense migrer d'ici quelques mois ma workstation vers une distribution Desktop bootc, probablement Bluefin, qui est déjà disponible, ou Fedora Silverblue, une fois que son support bootc sera finalisé.

J'aurai donc certainement l'occasion de tester en pratique comment créer des images bootc personnalisées.

Voici diverses ressources que j'ai trouvées concernant le support bootc pour Fedora Silverblue :

Je compte aussi tester bootc et tout particulièrement Bluefin dans le cadre de mon "Projet 26 - "Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora"".

composefs, un filesystem spécialement créé pour les besoins des distributions atomic #CoreOS, #linux, #distribution-linux

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Quelques outils CoreOS : coreos-installer, graphe de migration et zincati".

En 2021, Alexander Larsson a initié composefs, un nouveau filesystem. Pour faire simple, composefs permet de monter un filesystem depuis un checkout libostree.

composefs est un filesystem de type "stacking filesystem" qui combine plusieurs technologies :

  • EROFS : fournit la couche read-only et l'efficacité de stockage
  • overlayfs : gère la superposition de layers
  • fs-verity : assure la vérification d'intégrité des fichiers à la volée

Avec libostree seul (sans composefs), les checkout s'appuient sur des hardlinks vers un store central. Cette approche économise de l'espace disque, mais présente deux limitations :

  1. L'utilisateur root peut modifier les fichiers et corrompre le store partagé
  2. Il n'y a pas de vérification d'intégrité lors de l'accès aux fichiers

Grâce à EROFS, un filesystem read-only, la structure de fichier checkout devient immuable, ces fichiers ne sont plus des hardlink.

composefs a l'avantage de pouvoir utiliser différents filesystèmes comme couche de stockage : ext4, XFS, btrfs, etc.

Comme l'explique Alexander Larsson dans ce post de 2022, le second objectif de composefs est d'adresser une limitation de sécurité d'OSTree identifiée par Lennart Poettering : les fichiers gérés par libostree ne sont vérifiés qu'au moment de leur téléchargement, pas lors de leur utilisation.

Grâce à fs-verity (une fonctionnalité du kernel Linux), composefs permet la vérification cryptographique des fichiers à chaque accès (runtime verification). Cette approche peut détecter toute modification ou corruption au moment de l'utilisation du fichier. Je précise que je maîtrise assez mal cette partie sécurité.

Pour approfondir le sujet composefs, je vous conseille l'article lwn "Composefs for integrity protection and data sharing " de décembre 2022 ou encore tous les billets de Alexander Larsson au sujet de composefs, ainsi que ce "OSTree and composefs tutorial" qui m'a aidé à mieux comprendre par la pratique.

composefs a été intégré dans la version 41 de Fedora CoreOS et la version 42 de Fedora Silverblue. Voici une vérification de la présence de composefs sous CoreOS :

stephane@stephane-coreos:~$ ostree --version
libostree:
Version: '2025.4'
Git: 99a03a7bb8caa774668222a0caace3b7e734042e
Features:
- inode64
- initial-var
- libcurl
- libsoup3
- gpgme
- composefs   <==== ici
- ex-fsverity
- libarchive
- selinux
- openssl
- sign-ed25519
- sign-spki
- libmount
- systemd
- release
- p2p

stephane@stephane-coreos:~$ mount | grep -i composefs
composefs on / type overlay (ro,relatime,seclabel,lowerdir+=/run/ostree/.private/cfsroot-lower,datadir+=/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on)

Note suivante : "L'utilisation de OSTree par Flatpak".

Quelques outils CoreOS : coreos-installer, graphe de migration et zincati #CoreOS, #fedora, #linux, #admin-sys, #DevOps, #Kubernetes

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Fusion de CoreOS et Atomic Project en 2018".

coreos-installer

L'outil coreos-installer est un composant essentiel de Fedora CoreOS. Il propose différentes méthodes pour installer Fedora CoreOS.

La commande coreos-installer download permet de télécharger tout type de version de CoreOS, sous différents formats, par exemple iso, raw, qemu, cloud image, etc (toutes celles présentes dans la page download).

Ensuite, la commande coreos-installer install permet d'installer la version téléchargée vers un disque. Cette commande est par exemple disponible à la fin du boot d'une image ISO. Contrairement à Fedora Silverblue qui propose d'installer la distribution avec Anaconda, l'installation de CoreOS s'effectue en cli via coreos-installer install.

Ensuite, la commande coreos-installer install permet d'installer la version téléchargée sur un disque. Cette commande est notamment accessible après le démarrage d'une image ISO. Contrairement à Fedora Silverblue qui utilise l'installateur graphique Anaconda, CoreOS s'installe exclusivement en cli via coreos-installer install.

Toutefois, coreos-installer permet de préparer une installation automatique. La commande coreos-installer iso customize modifie une image ISO existante pour y intégrer directement une configuration ignition, rendant l'installation entièrement automatisée au démarrage.

Voici un exemple dans mon playground : atomic-os-playground/create-coreos-custom-iso.sh.

coreos-installer pxe permet aussi d'effectuer une configuration automatique par réseau, via PXE, mais je ne l'ai pas testé.

Graphe de migration de versions

Lors de mes tests d'upgrade de CoreOS à partir d'une ancienne release (environ n-10), j'ai constaté que la transition vers la dernière version ne se faisait pas directement mais nécessitait le passage par des versions intermédiaires.

J'ai découvert que CoreOS maintient un graphe qui définit le parcours d'upgrade requis. Certaines versions intermédiaires doivent être installées pour gérer des breaking changes, comme la migration de configurations.

zincati

Un autre composant important de Fedora CoreOS est zincati, le service responsable de l'exécution des mises à jour automatiques.

zincati décide d'effectuer les mises à jour en fonction du seuil de prudence de déploiement (rollout_wariness) et de la stratégie de mise à jour : immediate ou periodic (plage horaire définie dans la semaine).

CoreOS utilisant par défaut la stratégie immediate, zincati détecte automatiquement les nouvelles releases dès le premier démarrage et lance immédiatement leur téléchargement, suivi d'un redémarrage.

Le téléchargement par deltas rend l'upgrade vers la dernière release très rapide.

zincati permet également de coordonner les mises à jour de plusieurs serveurs, fonctionnalité particulièrement utile dans le contexte d'un cluster Kubernetes. Je n'ai pas encore testé cette fonctionnalité.

Note suivante : "composefs, un filesystem spécialement créé pour les besoins des distributions atomic".

Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows #MacOS, #CoreOS, #linux, #windows, #distribution-linux

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Ajout de packages dans des distributions atomiques".

Chrome OS et Android implémentent la stratégie de double partition A/B (seamless) system updates.
Cette technologie offre des mises à jour complètement transparentes en arrière-plan et un redémarrage immédiat.
En revanche, contrairement à la solution CoreOS (méthode détaillée dans cette note), cette méthode a pour inconvénient de consommer deux fois plus d'espace de stockage.

MacOS s'appuie sur les snapshots de son filesystem APFS (fonctionnalité qu'offre aussi btrfs). Cela garantit un retour en arrière rapide vers la version antérieure si des problèmes surviennent.
En revanche, l'upgrade se termine durant le reboot, pouvant prendre de 2 à 5 minutes, alors que le redémarrage reste instantané avec Chrome OS, Android, CoreOS ou Fedora Silverblue.

Comme d'habitude, je n'arrive pas à trouver des informations précises sur le fonctionnement interne de MS Windows 😔. D'après Claude Sonnet 4, le système de mise à jour de Windows 10 et Windows 11, baptisé Unified Update Platform (UUP), semble plutôt daté : pas d'A/B (seamless) system updates, absence d'atomicité, installation longue lors du reboot (10 à 30 minutes), possibilité d'échec en cours de processus, rollback complexe, aucun système de snapshot comparable à MacOS. J'ai du mal à croire ce bilan tellement catastrophique, ce qui m'amène à questionner sur l'exactitude des informations rapportées par Claude Sonnet 4.

D'après cette documentation particulièrement riche et mes recherches complémentaires, je pense que la stack libostree + composefs (avec zstd:chunked ) tel qu'implémenté dans Fedora CoreOS est probablement la technologie de mise à jour la plus avancée actuellement disponible.

Avant de présenter le fonctionnement du système de mise à jour de Fedora CoreOS en 2025, je vais retracer l'évolution technique de cette solution.

Note suivante : "CoreOS de 2013 à 2018".

Peu à peu depuis 2015, le terme immutable est remplacé par atomic #CoreOS, #linux, #distribution-linux, #fedora

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "En 2016, j'ai testé Fedora Atomic Host, une expérience pénible".

Après avoir étudié et testé CoreOS pendant une semaine, je réalise que la plupart des informations que j'avais entendues sur cette distribution, et plus généralement sur les immutables ou atomiques, étaient approximatives et m'ont conduit à des erreurs de compréhension.

Quelques exemples de propos que j'ai entendus de la part d'amis sur ce sujet.

En 2025 :

« Une distribution readonly ça empêchait pas mal de choses. Je n'ai pas creusé, je n'y connais rien, mais j'ai vu beaucoup de gens se plaindre. »

ou encore 2024 :

Les distributions immuables (comme feu CoreOS) garantissent une cohérence ultime. Pas de gestion de paquets, donc ni ajout ni suppression ni mises à jour possibles. Tout est gravé dans le marbre. Pour protéger le marbre, la partition racine est montée en lecture seule. Note suivante : "Ajout de packages dans des distributions atomiques". Le choix est extrême, mais l’idée est de servir de socle pour une abstraction de plus haut niveau. Imaginé pour les conteneurs, ils peuvent aussi gérer des machines virtuelles.

Pour mettre à jour, il suffit de redémarrer sur une nouvelle version. Techniquement, il y a deux partitions bootables, la courante, en lecture seule, la version suivante sur laquelle on a appliqué des patchs, soit n et n+1. Si le redémarrage de mise à jour se passe mal, rembobinage sur la dernière version connue comme stable.

Ma première erreur consistait à penser que distribution atomic et distribution immutable désignaient la même chose.

Les distributions immutables ont les caractéristiques suivantes :

  • Système de fichiers racine en lecture seule
  • Protection contre les modifications accidentelles
  • Peut ou non avoir des mises à jour transactionnelles

Les distributions atomics ont les caractéristiques suivantes :

  • Toujours immutable (par nature)
  • Mises à jour transactionnelles (tout ou rien)
  • Capacité de rollback complet
  • Basé sur des images système versionnées (généralement OSTree)

Les distributions atomic modernes, telles que Fedora CoreOS, Fedora Silverblue permettent en plus :

  • La modification de l'image de manière transactionnelle, par exemple d'installer des packages supplémentaires via rpm-ostree
  • Personnalisation tout en gardant les bénéfices de l'approche atomic

En 2016, lors de ma première utilisation de Fedora Atomic Host, j'avais compris que cette distribution était immutable comme CoreOS, sans réaliser qu'elle était aussi atomic. Contrairement à CoreOS qui interdisait tout ajout de packages système, Fedora Atomic Host permettait déjà via rpm-ostree d'installer des packages de manière transactionnelle (package layering), tout en conservant les bénéfices des mises à jour atomiques et du rollback.

À l'époque, CoreOS mettait l'accent sur son approche "100% conteneurs" et son immutabilité stricte, ce qui m'avait fait passer à côté de cette différence importante.

D'après ce que j'ai compris, la terminologie autour des distributions immutables et atomic a évolué au fil du temps. Si les concepts techniques sont bien définis (immutabilité du système, mises à jour transactionnelles), leur usage dans la communication a varié selon les projets et les époques. J'ai l'impression que cette ambiguïté persiste aujourd'hui.

Note suivante : "Ajout de packages dans des distributions atomiques".

J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈 #distribution-linux, #CoreOS

Le 22 septembre, j'ai commencé à explorer CoreOS, sans me douter que j'allais tomber dans un tel rabbit hole 🙈.
J'ai commencé une note qui dépasse maintenant 4000 mots, et après plus de 3 semaines, je ne l'ai toujours pas publiée.

Ce soir, je reviens à la méthode itérative qui me permet de garder la motivation. J'ai décidé de découper cette note en plusieurs petites notes, accessibles depuis cette note qui fait office de sommaire.

Liste en vrac des technologies mentionnées dans ces notes : CoreOS, libostree, rpm-ostree, butane, ignition, zincati, coreos-installer, composefs, OCI, Fedora Silverblue, Atomic OS, bootc, Universal Blue, Flatpak.

Sommaire des notes en lien avec CoreOS :

L'origine du nom "Fedora Silverblue" #fedora, #distribution-linux, #histoire

La lecture du document "Team Silverblue - The Origins " m'a appris de nombreuses choses sur les origines de la distribution Fedora Silverblue.

Avant 2018, le prédécesseur de Fedora Silverblue s'appelait "Fedora Atomic Workstation", défini comme : "image-mode container-based Fedora Workstation based on rpm-ostree".

À ses débuts, Fedora Atomic Workstation était un side project, développé et utilisé par quelques membres seulement de l'équipe Project Atomic (version du site de 2017).

Durant la conférence DevConf.CZ de janvier 2018, des participants ont présenté leur projet "Atomic Desktop". Suite à cette présentation, Owen Taylor, Sanja Bonic et Matthias Clasen ont créé un Special interest group (SIG) dédié à ce sujet dans la communauté Fedora : https://fedoraproject.org/wiki/SIGs/AtomicDesktops.

Voici comment le nom "Team Silverblue" a été choisi 2018 par Matthias Clasen et Sanja Bonic :

Couldn’t you come up with a better name?

No.

And in more detail: Matthias and Sanja have vetted over 150 words and word combination for something suitable, starting with tree names and going to atoms, physics, nature, landscapes.

Several other people have been asked to contribute. The entire process lasted for roughly 2 months, culminating in an open discussion of naming in the SIG meeting on April 16.

On April 19, Matthias and Sanja decided for the name Team Silverblue, because it was :

  • available on Twitter, GitHub, and as a .org domain
  • makes sense and sounds nice within the Fedora realm (color alignment)
  • opens up fun and entertaining ways to have swag (silver-blue wigs, sports jerseys with the logo on it, phrasing like “Go, Team Silverblue!”, “Want to join the Team and improve Silverblue?”)
  • works as Fedora Silverblue or Team Silverblue without losing branding investment

source

"Team Silverblue" a ensuite donné le nom Fedora Silverblue.

Le document indique que Red Hat a acquis CoreOS juste quelques jours après le lancement de cette idée de projet par les développeurs. S'agit-il d'une coïncidence heureuse 🤔 ? Le document ne le précise pas.

Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora #projet, #desktop, #linux-desktop, #hardware

J'envisage de proposer à ma mère et à ma compagne de se prêter à une expérimentation : une transition en douceur vers des portables sous GNU/Linux, avec mon assistance complète durant tout le processus.

Leur situation actuelle :

Choix de la distribution Linux : une Fedora version n-1 (voir la note 2024-01-29 pour plus d'informations sur ce choix).

Plus précisément, j'envisage d'utiliser l'édition Fedora Silverblue, une variante immutable (ou « atomic ») de Fedora Workstation qui propose l'environnement de bureau GNOME.

Je souhaite configurer et rendre très facilement accessibles les applications Signal et RustDesk :

  • Signal pour facilement échanger avec moi en cas de difficulté ;
  • RustDesk pour me permettre de prendre directement le contrôle du desktop à distance, pour les aider.

Pour ma maman, je souhaite lui faire tester Libre Office. Pour éviter de la perturber avec les formats de fichier, je souhaite configurer Libre Office pour qu'il enregistre par défaut au format de Microsoft Word et Microsoft Excel.

Je souhaite installer quelques extensions GNOME pour que l'environnement Linux ressemble au maximum à MS Windows, par exemple :

Je souhaite leur proposer un laptop qui répond aux caractéristiques suivantes :

  • si possible à moins de 1000 € ;
  • entre 14 et 15 pouces, avec une résolution verticale de 1200 pixels minimum ;
  • 16Go de RAM ;
  • un trackpad et un châssis avec un maximum de qualité ;
  • idéalement convertible en 2 en 1 ou 3 en 1 ;
  • silencieux ;
  • support GNU/Linux parfait ;

Pour le moment, j'ai identifié les modèles suivants :