AffûtOS

Jusqu'ici, l'installateur recopiait lui-même mes réglages dans le système : configuration du bureau, modèle des nouveaux comptes, règles du système. Ça marchait le jour de l'installation, et plus jamais ensuite : un réglage corrigé n'atteignait pas les machines déjà installées, et aucun ne pouvait être retiré.

Sept paquets, trois règles

Les réglages appartiennent désormais à des paquets affutos-* du dépôt AffûtOS : système, amorçage, GPU AMD, KDE, Firefox, Steam, Decky. Installer un paquet pose ses réglages, le retirer les enlève, le mettre à jour les corrige sur toutes les machines — à une exception près, qu'impose la deuxième règle. La construction de l'image refuse tout réglage copié hors d'un paquet ; l'installateur ne garde que ce qui se joue une fois, comme la sauvegarde restaurée ou l'entrée d'amorçage du firmware.

• Un réglage que KDE lit comme défaut global va dans /etc/xdg : changé pour tous à la mise à jour, toujours surchargeable par le compte ;
• un réglage propre au compte — Steam, Firefox, fichiers que Plasma réécrit — va dans le modèle des nouveaux comptes, /etc/skel, sous forme de fichier possédé par le paquet. Revers de la méthode : un compte existant garde sa copie, que ni mise à jour ni retrait ne touche ;
• un service s'active par un lien livré dans le paquet, pas par une commande : retirer le paquet suffit à le désactiver. Seule exception, Decky : son service porte le nom du compte, que le paquet ne peut pas connaître d'avance ; il l'active pour le premier compte et le désactive à son retrait.

Les moniteurs processeur, mémoire et disque de la barre des tâches passent, eux, par un script de mise à jour de Plasma, joué une fois par compte à l'ouverture de session : ils se placent juste après la liste des tâches, comme sur ma machine principale.

Le coupable était pacman

Le paquet affutos-firefox pose le pack de langue du système à son installation, puis le repose à chaque mise à jour du navigateur. Sur une machine déjà installée, au réseau impeccable, sa réinstallation a échoué au téléchargement : curl: (7) Failed to connect to archive.mozilla.org:443 after 1 ms. Une milliseconde, ce n'est pas un DNS lent : la connexion n'a jamais quitté la machine.

La réponse était dans le manuel de pacman.conf : depuis pacman 7.1, crochets et scripts d'installation des paquets tournent par défaut dans un espace de noms réseau neuf, sans autre interface que la boucle locale. Aucun téléchargement n'y aboutit. C'était la cause des erreurs « impossible de résoudre l'hôte » vues pendant l'installation depuis fin septembre — que j'avais d'abord mises sur le compte du lien DNS mort soupçonné mi-août, puis classées « cause inconnue » le 4 octobre.

Un crochet peut réclamer le réseau (NetworkAccess = allowed), pas un script d'installation de paquet — or le pack se pose aussi quand le paquet s'installe. Le crochet comme le script demandent donc à systemd de lancer un service, qui télécharge en dehors de l'espace isolé : les sockets de systemd sont des fichiers, joignables même sans réseau. Pendant l'installation, où systemd ne tourne pas encore dans le système cible, une étape de post-installation rejoue le téléchargement.

Trois erreurs de moins au journal système

Trois erreurs encombraient le journal système. Deux venaient de la session du mode jeu, qui lance un démon de notifications Steam et une méthode de saisie dont les programmes ne sont pas installés : leurs services sont maintenant sautés tant que leur programme manque. La troisième venait du service qui tient le profil Firefox en mémoire vive : il démarrait aussi pour root, qui n'a pas de profil, et ne tourne plus que pour les comptes ordinaires.

Vérifié dans les deux sens

Sur une machine de test, chaque paquet a été retiré puis réinstallé : ses fichiers et services système disparaissent et reviennent à l'identique. Ensuite, deux installations complètes en machine virtuelle, avec les nouvelles images : aucune des trois erreurs au journal système, et Decky actif dès le premier démarrage.

Un piège au passage : sur une installation neuve, Decky refusait de démarrer, faute d'un dossier que mon compte de test avait déjà. Un service vérifié sur un compte existant ne prouve rien pour un compte neuf : depuis, chaque service se teste aussi sur un compte créé pour l'occasion.

La leçon : tant que la panne ne se produisait que dans l'installateur, je cherchais dans l'installateur. Il a fallu la voir sur une machine ordinaire pour regarder enfin du côté de pacman.

Depuis deux mois, AffûtOS s'éloigne de CachyOS un correctif après l'autre, chacun avec sa raison écrite en commentaire. Ce que je n'avais jamais fait : installer les deux côte à côte et regarder la différence, fichier par fichier.

Le banc

Deux machines virtuelles sur le même ordinateur, chacune sur son disque, nourries par le même cache de paquets local : CachyOS handheld avec ses réglages par défaut — sauf le système de fichiers et le chargeur, mis en ext4 et systemd-boot comme les miens — et ma version de travail d'AffûtOS. Puis un relevé hors ligne des deux systèmes installés — paquets, fichiers qu'aucun paquet ne possède, services activés — et leurs temps de démarrage.

• Démarrage : 4,56 s contre 6,78 s, alors que ma version de travail lance quelques services de plus — la phase d'initramfs prend 0,07 s avec booster contre 1,65 s ;
• et cinq secondes de menu d'amorçage en plus pour CachyOS, contre aucune pour AffûtOS.

Une explication fausse, en production depuis des semaines

Mi-août, j'avais accusé une étape de l'installateur qui, croyais-je, remplaçait la configuration DNS par un lien mort, et ajouté une étape pour la réparer. En septembre, un pack de langue de Firefox qui refusait de se télécharger pendant l'installation — « impossible de résoudre l'hôte » — avait semblé me donner raison. La comparaison a coulé l'histoire : le live n'a plus ce lien depuis 2022, l'étape recopie un fichier ordinaire identique à celui déjà en place — et CachyOS, sans aucune réparation, finit avec exactement le même fichier.

L'étape de réparation est partie. Le symptôme de Firefox, lui, est réel, et sa cause reste inconnue ; ce qui n'en dépend plus, c'est que les téléchargements hors pacman — pack de langue, Decky, client Steam — se font déjà dans les étapes de post-installation, où le réseau fonctionne.

Mise à jour du 8 octobre : la cause est trouvée — depuis pacman 7.1, les crochets des paquets n'ont, par défaut, pas de réseau. Voir « Chaque réglage dans un paquet ».

Un ménage vérifiable

Chaque différence a ensuite dû se justifier face à l'original. Résultat : 1 224 lignes retirées et 391 ajoutées, en dix commits — des entrées de démarrage réseau que personne n'utilisait, jusqu'à trois minutes d'attente avant l'ouverture de l'installateur pour un classement de miroirs qu'il ne lit qu'au moment d'installer, une copie de mon script que plus rien ne lisait, des estimations de durée dépassées à presque chaque installation. Réinstallée après le ménage, AffûtOS avait les mêmes paquets, les mêmes services, et seulement les écarts de fichiers voulus : même comportement, moins de code.

Au passage, un correctif publié par CachyOS sur sa branche principale — un minuteur de classement des miroirs à neutraliser sur le live — a été repris lui aussi.

La leçon rejoint celle d'août : relire son propre code convainc, le poser à côté de l'original ne ment pas.

Objectif : gagner des secondes entre le bouton d'allumage et le bureau, sur ma machine principale. La première question est venue avant tout changement : comment mesurer. systemd ne voit que ce qui suit le firmware ; pour comparer un chargeur classique et un noyau lancé directement par le firmware, il faut l'horloge du firmware lui-même — une table ACPI note l'instant où il passe la main. Chaque configuration a été démarrée trois à six fois.

• Point de départ, mkinitcpio : 12,83 s de l'allumage au bureau.
• Un mkinitcpio « optimisé » — moins de hooks, modules décompressés, compression maximale : 12,81 s. Rien.
• booster, qui n'embarque que ce dont la machine a besoin (moins de 10 Mo au lieu de 16,7) : 11,52 s, 1,3 s de gagnée. Sur mon autre portable, 2,5 s.
• Une image noyau unifiée lancée par le firmware, sans chargeur du tout : 11,47 s contre 11,45 s. Rien non plus : les 0,3 s du chargeur sont surtout la lecture du noyau sur le disque par le firmware, qu'il doit faire de toute façon.

La seconde qu'on ne voit pas

Le menu de démarrage, réglé à une seconde pour pouvoir encore choisir une entrée, coûtait en fait 1,2 seconde par démarrage ; sur l'autre portable, le chargeur à lui seul prenait jusqu'à 1,8 seconde. Le délai est désormais à zéro, et une touche maintenue fait revenir le menu.

Deux pièges

• L'option strip de booster, qui allège les modules, leur retire aussi leur signature : le noyau se déclare alors souillé. Elle reste désactivée — l'écart de taille est sous le mégaoctet.
• Créer ou supprimer une entrée d'amorçage UEFI fait refaire au firmware de ma machine une initialisation complète au démarrage suivant : 7,3 s au lieu de 4,4. Toute mesure prise juste après avoir touché aux entrées est fausse ; il faut d'abord un démarrage de chauffe.

Où ne plus chercher

L'échantillonnage du reste du démarrage a montré que l'écran de connexion, à 6,8 s, est retenu par deux pilotes : celui du GPU AMD, qui ne commence sa détection qu'à 5,75 s, et celui du Wi-Fi, qui applique sa réglementation radio. Ce qui reste du côté de systemd vaut 0,2 s environ. Les mesures disent où arrêter de creuser autant qu'où creuser.

Une analyse du code avait désigné un coupable idéal : les paquets préchargés au démarrage n'atterrissaient pas là où l'installateur les cherchait, et seraient donc retéléchargés. Deux minutes à récupérer, sur le papier.

Le correctif était une régression

Il l'était doublement. Le programme d'installation n'appelle pas pacman --root mais pacman --sysroot — et cette option fait lire la configuration et le cache dans le système en cours d'installation, pas sur le live. Le code d'origine visait donc déjà le bon endroit. Ma « correction » détournait 746 Mo vers un cache que personne ne lit, sous des noms de fichiers que l'installateur ne cherche jamais.

Douze paquets tirés au hasard parmi les préchargés : douze retéléchargés. Le cache du live n'avait pas grossi d'un octet pendant toute l'installation. Seule l'exécution réelle l'a montré — la lecture du code, elle, avait convaincu deux analyses successives.

Le vrai gain était ailleurs, et il est énorme

Un cache de paquets sur le réseau local, lui, change tout. Mesuré sur la machine de salon, installation complète :

• 5 minutes au lieu de 12, pour 1271 paquets installés ;
• 341 Mo tirés d'Internet au lieu de 4,2 Go ;
• 3347 fichiers servis par le cache local contre 177 allés chercher dehors, soit 95 % des requêtes.

La leçon tient en une ligne : une hypothèse sur un cache se vérifie à la date des fichiers après coup, jamais à la lecture des options.

Jusqu'ici, préparer l'installateur voulait dire le retoucher à chaud : plus de mille lignes de substitutions appliquées à son fichier de configuration, à chaque démarrage du live. Ça marchait, et c'était intenable — impossible de dire ce qui différait de l'amont sans dérouler le script à la main.

La configuration vit désormais dans l'image, en clair, sous forme d'une surcouche que l'installateur lit avant la sienne. Elle se relit, se compare, se versionne. Le lanceur contrôle dans le journal quelle configuration a réellement été ouverte et s'arrête si ce n'est pas la bonne : un repli silencieux installerait la distribution d'origine sans prévenir.

Dans la foulée, la post-installation a quitté son script en arrière-plan pour devenir une étape appelée par l'installateur. Et une relecture complète a fait tomber 925 lignes : des groupes de paquets qu'une édition console ne peut pas afficher, un chargeur d'amorçage que rien ne savait configurer, des fichiers de démarrage que rien ne lisait.

Un détail mesuré au passage : sans réglage explicite, l'outil de noyau reconstruisait un initramfs et une entrée de démarrage déjà produits par l'étape précédente — 64 Mo abandonnés sur une partition d'amorçage de 196 Mo.

Le démarrage réseau d'AffûtOS s'est mis à refuser l'image système : checksum error. Réflexe habituel : régénérer la somme de contrôle. Ç'aurait été la pire décision possible.

Le disque disait vrai, la mémoire mentait

En comparant l'image publiée avec celle du répertoire de travail, un seul octet différait sur 2 823 114 752 — et il ne différait que d'un bit : 0xA2 était devenu 0xAA. Le reste de l'image, noyau et initramfs compris, était identique au bit près.

La chronologie situait l'accident dans une fenêtre d'une seconde et demie, pendant la recopie de l'image vers le fichier ISO. Le fichier source sur le disque, relu plus tard en contournant le cache mémoire, était parfaitement sain.

La preuve, quelques heures plus tard

Le même jour, un paquet du cache s'est mis à échouer sa vérification de signature. Lu normalement — donc depuis la mémoire — sa signature était invalide. Lu directement depuis le disque, elle était parfaite. Et le bit fautif était le même que celui de l'image : le bit 3.

La machine a une mémoire sans correction d'erreurs, quatre barrettes poussées au-delà des fréquences validées par le constructeur. Elle n'a aucun moyen de détecter, et encore moins de corriger, ce genre d'accident.

Ce que j'en ai tiré

• Une somme de contrôle qui échoue est une bonne nouvelle : elle a fait son travail. La régénérer revient à certifier officiellement une donnée corrompue.
• Une vérification qui relit un fichier juste après l'avoir écrit ne vérifie que la mémoire. Il faut vider le cache avant de relire, sinon on valide la copie suspecte avec elle-même.
• Rien n'est publié désormais sans une relecture disque de tous les fichiers, et pas seulement du plus gros.

Le versant serveur de cet incident

Objectif : associer le Wi-Fi depuis l'initramfs, avant que le système n'existe, pour installer une machine sans câble réseau. Le script était écrit, injecté dans l'image, et ne s'exécutait pas. Aucun message. Aucune erreur. Rien.

Tout était correct, sauf une chose

Le fichier était bien présent dans l'image — vérifié. Sa syntaxe était valide — vérifiée avec l'interpréteur exact de l'initramfs. Son chargement définissait bien la fonction attendue — vérifié. Il figurait dans la liste des scripts à exécuter — vérifié. Et pourtant il ne tournait jamais.

La réponse était dans le code du système d'amorçage, une seule ligne :

[ -x "/hooks/$hook" ] || continue

Un script non exécutable est ignoré, sans le moindre message. C'est même le mécanisme officiel de désactivation : la fonction prévue pour désactiver un script se contente de lui retirer son bit d'exécution.

En reconstruisant l'image à la main, j'avais recréé le fichier en 0644 au lieu de 0755. J'avais désactivé mon propre script sans le savoir, à chaque tentative.

Deux leçons de méthode

• J'ai ajouté un numéro de version affiché à l'écran par le script. Sans lui, impossible de savoir quelle version tournait réellement — j'ai passé une heure à tester des correctifs qui n'étaient pas chargés.
• La console de l'initramfs n'affiche pas les caractères accentués : tous mes messages de diagnostic en français apparaissaient comme des symboles illisibles. Ils étaient là depuis le début, je ne pouvais simplement pas les lire.

Je voulais que trois réglages du mode jeu soient appliqués dès l'installation, sans intervention : ne jamais réduire la luminosité sur secteur, ne jamais se mettre en veille, et afficher le pourcentage de batterie. Les noms de clés semblaient évidents. Ils ne fonctionnaient pas.

La bonne clé au mauvais endroit

Le fichier de configuration contient deux blocs portant le même nom. Le logiciel n'en lit qu'un : le plus profond. J'écrivais dans l'autre. La clé était juste, la valeur était juste, l'emplacement était faux — donc rien ne se passait, sans le moindre avertissement.

Même piège pour le pourcentage de batterie, quelques heures plus tard : la clé devait vivre dans un sous-bloc précis, aux côtés de trois clés sœurs écrites par le même composant. À la racine, elle restait lettre morte.

La méthode qui a marché

Deux approches complémentaires. D'abord l'empirique : prendre une photo des fichiers, modifier le réglage à la main dans l'interface, comparer. Le fichier avoue alors exactement ce qu'il faut écrire, et où.

Ensuite la lecture des sources. L'interface de Steam n'est plus une bibliothèque compilée mais du JavaScript minifié : une centaine de mégaoctets de code illisible, mais parfaitement consultable. On y retrouve le nom exact de la clé, la fonction qui l'écrit, et celle qui la relit au démarrage — donc la certitude qu'une valeur posée d'avance sera bien reprise.

Un piège à éviter absolument

Une astuce circule pour désactiver l'assistant de premier démarrage : créer un certain fichier de configuration avec une ligne magique. Le lanceur, quand il rencontre cette ligne, exécute un rm -rf sur tout le dossier de l'application — à chaque démarrage. La solution correcte utilise un fichier d'amorçage prévu par l'éditeur, que personne ne semble utiliser.