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.

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.

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.