Mon serveur headless s’allume mais ne boote pas après un changement de matériel, pourquoi ?

Beaucoup de BIOS/UEFI s’arrêtent sur « Press F1 to resume » après avoir détecté un changement de configuration (nouveau disque, RAM, horloge). Sur une machine avec écran, on tape F1 et ça repart. Sur un serveur headless sans clavier, personne ne tape rien : le BIOS attend indéfiniment, et la machine paraît figée alors qu’elle est simplement en pause avant même de charger le noyau.

Comment envoyer F1 à un BIOS via une console série ?

Reliez un adaptateur USB-UART au header série de la carte, ouvrez la console au débit du BIOS (souvent 9600 ou 115200, 8N1). Quand « Press F1 to resume » s’affiche, envoyez la séquence F1. Sur un terminal VT100/xterm : printf '\033OP' > /dev/ttyUSB0 (ESC O P). En repli VT220 : printf '\033[11~' > /dev/ttyUSB0.

Comment empêcher un BIOS de s’arrêter sur F1 au démarrage ?

Dans le setup BIOS, cherchez une option du type « Wait for F1 if Error », « Halt On » ou « POST Error Pause » et réglez-la sur « No Errors » / « Disabled ». Sur un serveur headless c’est indispensable, sinon le moindre changement matériel — ou une pile CMOS faible qui perd l’heure — bloque le boot sans aucun signe visible sur le réseau.

Une session screen fermée tient encore le port série, comment le libérer ?

screen se détache au lieu de se fermer quand on ferme le terminal : le processus tourne en fond et garde /dev/ttyUSB0 occupé. Trouvez le PID avec fuser /dev/ttyUSB0 et tuez-le par son numéro (kill <pid>). Évitez pkill -f ttyUSB0 : le motif correspondrait aussi à votre propre commande en cours.

NAS headless figé au boot : il attend un appui sur F1

Je viens de remplacer un disque défaillant dans un vieux NAS et de remonter le miroir. Je le rallume : voyants façade allumés, disques qui tournent, châssis qui chauffe. Mais il ne revient jamais sur le réseau. Ni ping, ni SSH. Plusieurs coupures franches de l’alim, même résultat. On dirait un boot figé.

Écarter les vrais suspects

Réflexe : accuser la clé de boot ou les disques. J’ai tout vérifié sur un autre PC :

Le miroir RAID s’assemble proprement ([UU]), les données sont intactes.
La clé USB de boot monte sans erreur, grub.cfg est correct (root=UUID=…, bootdegraded=true), noyau et initrd présents et non corrompus.

Tout est sain. Donc le figeage est avant le chargement du noyau — côté firmware.

Le vrai coupable : « Press F1 to resume »

Beaucoup de BIOS, après avoir détecté un changement de configuration matérielle (ici : un disque différent), s’arrêtent au POST sur :

Press F1 to resume

Sur une machine avec écran et clavier, on tape F1, on n’y pense même plus. Sur un serveur headless, personne ne tape rien : le BIOS attend pour toujours. Aucune trace côté réseau, aucun log — juste une machine allumée, chaude, muette. Ça ressemble à un plantage ; c’est une simple pause.

Le remède : F1 par la console série

Une fois la console série branchée (adaptateur USB-UART sur le header de la carte), on ouvre au débit du BIOS, on rallume et on regarde défiler le POST :

$ screen /dev/ttyUSB0 115200

Au moment où « Press F1 to resume » s’affiche, on envoie la séquence F1. Sur un terminal type VT100/xterm, F1 = ESC O P :

$ printf '\033OP' > /dev/ttyUSB0        # F1
# repli VT220 si besoin :
$ printf '\033[11~' > /dev/ttyUSB0

Le boot repart aussitôt, assemble le RAID, et la machine revient sur le réseau.

⚠️ Piège : screen se détache quand on ferme la fenêtre du terminal — il continue en fond et garde /dev/ttyUSB0 occupé (Périphérique ou ressource occupé). On le libère en tuant le PID exact :

$ kill "$(fuser /dev/ttyUSB0)"

…et surtout pas pkill -f ttyUSB0, dont le motif correspondrait aussi à la commande qu’on est en train de taper.

Le vrai correctif de fond

Une fois dans le setup BIOS, désactiver la pause sur erreur : option « Wait for F1 if Error » / « Halt On » → No Errors / Disabled. Sur un serveur headless, c’est non négociable : sinon le moindre changement matériel — ou une pile CMOS faible qui perd l’heure à chaque coupure — rebloque le boot sans le moindre signe.

Lessons learned

Un boot headless « figé » n’est pas forcément planté. Beaucoup de BIOS attendent F1 après un changement matériel — indéfiniment, sans écran pour le dire.
Vérifier les disques et la clé ailleurs permet d’isoler le problème avant le noyau : si tout est sain, c’est le firmware.
F1 en série = ESC O P (VT100/xterm), repli ESC [ 1 1 ~ (VT220). Bon à connaître pour tout POST headless.
Désactiver « Halt on error / F1 » dès l’install d’un serveur headless évite de ressortir l’adaptateur série à chaque intervention.
screen détaché squatte le port : tuer par PID via fuser, jamais par un pkill -f qui s’auto-viserait.