De la réponse DHCP à l’installation terminée

Amener une machine à accepter une offre de netboot est la partie dont tout le monde parle. Nous en avons parlé aussi, après avoir perdu une semaine sur l’adresse de destination d’une réponse proxy-DHCP.

La partie qui vient après n’est presque jamais couverte, et c’est là que vivent les vraies défaillances. Une machine qui démarre puis reste indéfiniment bloquée sur une question est pire qu’une machine qui n’a jamais démarré, car cela ressemble à un progrès. Voici la seconde moitié : ce qui doit être vrai entre l’arrivée de l’offre et l’apparition d’une invite de connexion, et lesquelles de ces choses échouent en silence.

Les cinq choses qui sont servies

Une fois que le client a une offre et un fichier de démarrage, une installation sans surveillance représente cinq artefacts. Aucun n’est facultatif, et le dernier est celui que les gens oublient.

La colonne intéressante est la dernière. Les éléments 1 à 3 échouent bruyamment, à l’écran, d’une façon que quelqu’un remarquera. Les éléments 4 et 5 échouent sous la forme d’une installation qui a l’air de tourner et qui ne se termine jamais.

Les scripts de démarrage et le problème du marqueur

Le script de démarrage doit nommer des URL absolues, et il ne peut pas les connaître au moment où le profil est écrit : l’adresse de ce qui sert les fichiers dépend du segment sur lequel la machine a démarré.

Le profil contient donc un marqueur qui est substitué au moment de servir. Le nôtre est @@PROVIBR_BASE@@, et sa forme est un choix délibéré plutôt qu’une préférence de style.

La forme évidente serait ${BASE}. C’est exactement l’erreur, car iPXE développe lui-même ${...}. Une substitution qui n’a pas lieu devient une chaîne vide plutôt qu’une erreur, et vous finissez par contempler

chain http:///vmlinuz

en vous demandant ce qui cloche dans votre serveur web. Un délimiteur que le chargeur d’amorçage ne reconnaît pas transforme un échec de substitution silencieux en échec visible.

Les trois lignes de commande de noyau qui comptent, une fois la marque retirée :

# Ubuntu (subiquity)
kernel <kernel> initrd=<initrd> ip=dhcp autoinstall ds=nocloud;s=<dir>/ --- || goto failed

# Debian (preseed)
kernel <kernel> initrd=<initrd> auto=true priority=critical ip=dhcp url=<file> DEBIAN_FRONTEND=text --- quiet || goto failed

# RHEL family (Anaconda)
kernel <kernel> initrd=<initrd> ip=dhcp inst.repo=<tree> inst.ks=<file> inst.text || goto failed

Trois installateurs, trois vocabulaires complètement différents pour la même idée, et l’argument qui porte le fichier de réponses s’écrit différemment dans chacun. ds= prend un répertoire ; url= et inst.ks= prennent un fichier. Confondre les deux vous donne un installateur qui démarre puis pose la première question.

Les quatre clés d’autoinstall qui décident si l’installation se termine

L’autoinstall d’Ubuntu mérite son propre paragraphe, car sur un segment isolé quatre clés séparent une installation qui se termine d’une installation qui ne se termine pas, et aucune ne concerne les disques ou les utilisateurs :

• interactive-sections: [] : sans elle, subiquity s’arrête encore pour demander quelque chose.
• refresh-installer.update: false : sans elle, il part d’abord chercher un installateur plus récent.
• apt.fallback: offline-install : sans elle, il attend l’archive avant d’abandonner.
• drivers.install: false : même classe de problème, même résultat.

La défaillance est chaque fois la même : un écran qui a l’air occupé. Il n’y a pas d’erreur, car du point de vue de l’installateur rien n’a mal tourné.

Il existe un drapeau correspondant pour le support. L’initrd netboot d’Ubuntu décompresse un support d’installation dans un tmpfs et installe depuis celui-ci ; si vous ne lui dites pas où se trouve ce support, il part sur internet en chercher un. Sur un segment sans lien montant, c’est la différence entre fonctionner et quatre minutes de rien suivies d’une invite busybox.

Le rappel que personne n’écrit

L’élément 5 de la liste est une seule ligne dans un script de post-installation qui va chercher une URL, et c’est la pièce la plus souvent manquante dans une installation faite maison.

Sans lui, il n’existe aucun événement qui veut dire terminé. L’installateur redémarre, la machine démarre, et le système qui a lancé l’installation n’en sait rien : il attend donc l’échéance dont il dispose, puis signale un dépassement de délai sur une machine qui s’est installée parfaitement.

Deux détails rendent cela moins pénible qu’il n’y paraît. D’abord, livrez le crochet dans le modèle plutôt que de le documenter, pour que celui qui écrit son propre script de post-installation n’ait pas besoin de savoir qu’il existe. Ensuite, prévoyez un crochet d’échec en plus du crochet de succès : une installation qui échoue à 04:00 et le dit ne donne pas la même expérience de support qu’une installation devenue muette.

Et gardez deux horloges, pas une. La commande qui lance une installation doit se terminer dès que les services d’écoute sont en place et que la session est acceptée, pas quand l’installation est finie ; la nôtre dispose de 90 secondes pour cela, contre un budget d’installation d’une heure imposé des deux côtés. Une seule échéance pour les deux donne soit une tâche qui reste une heure dans l’interface sans rien faire, soit une installation tuée parce qu’elle prend le temps que prennent les installations.

Quels éditeurs publient une somme de contrôle, mesuré

Si la machine va chercher un noyau et un initrd en HTTP sur un miroir, quelque chose doit vérifier ce qui revient. La façon de le faire est d’épingler un sha256 dans le profil et de le vérifier après le téléchargement, à l’endroit qui effectue la récupération.

Cela ne marche que si l’éditeur en publie une. Nous avions supposé que la réponse était « la plupart du temps non », nous l’avions écrit, et cela s’est révélé faux dans trois cas sur quatre. Ce qui est réellement publié, mesuré le 2026-09-02 :

Le coût de cette hypothèse erronée n’a pas été une panne ; il a été pire, à sa manière discrète. Des ressources qui auraient pu être épinglées restaient marquées comme invérifiables, et des profils se déclaraient non installables alors que l’éditeur publiait la réponse au grand jour. Quatre artefacts sur cinq pour les deux premiers profils.

Le comportement à adopter quand une somme de contrôle n’existe véritablement pas mérite d’être conçu exprès. Le nôtre laisse l’épingle vide, marque la ressource comme en attente, et le profil se déclare non installable jusqu’à ce qu’un administrateur colle une empreinte. C’est délibérément plus bruyant que de la télécharger quand même. Un noyau non vérifié récupéré en HTTP depuis un miroir est l’endroit le plus rentable à attaquer dans un système de provisionnement, et « nous n’avons pas pu le vérifier, donc nous l’avons fait quand même » n’est pas une politique.

Ce que « maintenu » a le droit de vouloir dire

Nous livrons dix profils de base : Ubuntu Server 24.04 et 26.04, Debian 12 et 13, Rocky Linux 9 et 10, AlmaLinux 9 et 10, CentOS Stream 10, Fedora Server 44.

Le statut de support attaché à chacun est calculé, pas saisi. Un profil ne peut se dire maintenu que s’il a une exécution vérifiée sur les deux chemins de micrologiciel, BIOS et UEFI. Un seul des deux donne « aperçu ». Aucun des deux ne donne « non maintenu ».

En faire une règle plutôt qu’un champ vaut le peu de code que cela demande. Une étiquette saisie à la main vaut exactement le soin de celui qui l’a saisie, et c’est une étiquette sur la foi de laquelle un client met une machine.

Ce qui oblige à dire clairement où cela nous laisse aujourd’hui. Ubuntu Server 26.04 et Debian 13 se sont installés entièrement sans surveillance sur un segment isolé, sur une machine BIOS. Le chemin UEFI a été réparé dans la même ronde, et le réparer n’est pas la même chose que l’exécuter. Aucun profil livré n’est donc maintained à l’heure où nous écrivons, et les profils de la famille RHEL n’ont pas du tout été exécutés sur une machine réelle : ils ont été écrits d’après la documentation de l’éditeur et mesurés contre de vrais fichiers sources, ce qui est une affirmation plus faible qu’elle n’en a l’air vue de l’extérieur.

Par ailleurs, proposer le netboot comme moyen de créer une nouvelle machine est désactivé par défaut dans notre plateforme, en attendant exactement une chose : une machine réelle qui s’installe ainsi, sur du micrologiciel réel. Le chemin qui existe et qui est utilisé est la réinstallation par-dessus une machine existante. Un drapeau de fonctionnalité activé parce que le code est écrit, plutôt que parce que la chose a été observée en train de fonctionner, produit un bouton de commande qui laisse le premier vrai client en plan à mi-chemin.

Petites choses qui coûtent chacune un après-midi

• Validez les chemins des fichiers servis. Pas de barre oblique initiale, pas de .., pas de barres obliques inverses, une seule classe de caractères. Ce qui sert les fichiers se trouve à l’intérieur du réseau de quelqu’un, avec un système de fichiers derrière.
• Expurgez la ligne d’audit. Enregistrez quel fichier a été servi et s’il portait un secret, jamais le contenu. Qui a besoin du contenu peut refaire le rendu du profil.
• Ne laissez pas le fichier de réponses devenir une seconde source de vérité sur le support. L’argument du noyau et le fichier de réponses nomment tous deux la provenance des paquets ; les dériver d’un seul réglage est la seule façon de les garder égaux.
• Supposez que personne ne regarde la console. Chaque choix ci-dessus concerne ce qui se passe quand l’installation en est à la sixième minute sur huit et qu’il n’y a personne dans la pièce.

Ceci est la seconde partie du texte sur les raisons pour lesquelles le netboot UEFI échoue là où le BIOS fonctionne, et cela vient de la construction de l’installation par le réseau dans Provibr. Les détails sont dans la documentation netboot.