AffûtOS

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.