Le changement de noyau FIPS a emporté les modules Wi-Fi et VPN

Activez fips-updates, redémarrez, et la machine revient sans interface sans fil tandis que le client VPN refuse de démarrer parce que son module de noyau est absent. Rien n'a été désinstallé au sens habituel des paquets, et c'est pourquoi réinstaller le client ne change absolument rien. La machine tourne sur un noyau pour lequel ses pilotes n'ont jamais été compilés. Deux symptômes, une cause, et la cause tient dans une seule commande.

Ce que le redémarrage a réellement changé

Les mises à jour FIPS d'Ubuntu Pro installent une variante certifiée du noyau et en font l'entrée de démarrage par défaut. Cette variante est un vrai noyau : il démarre, il tourne et il lance les services que vous aviez déjà. Ce qu'il ne contient pas, c'est chaque module compilé pour le noyau générique, y compris un pilote sans fil compilé hors de l'arbre et un module de tunnel fourni via DKMS. Le jeu de pilotes suit le noyau, pas le gestionnaire de paquets. Le matériel est donc toujours là et le logiciel qui lui parle ne l'est pas.

Comparez le noyau en cours avec les paquets installés avant d'ouvrir le moindre réglage réseau. La chaîne de version porte un marqueur que le noyau générique n'a pas, et ce seul détail explique les deux pièces manquantes.

Lisez aussi l'entrée de démarrage, car une machine peut avoir le noyau certifié installé sans l'exécuter. Dans ce cas, l'histoire des modules est complètement différente, et les ports et pilotes que vous alliez réinstaller sont en bon état.

Lisez l'état des modules avant la configuration du client

Un module introuvable et un module qui existe mais refuse de se charger sont deux pannes différentes avec deux correctifs différents. modinfo indique laquelle vous avez, et lsmod indique ce qui est chargé en ce moment. Faites les deux avant de toucher à la configuration du client VPN, car l'erreur du client lui-même les distingue rarement.

Le sans-fil demande la même séparation. Une interface qui n'apparaît jamais désigne le pilote, tandis qu'une interface qui existe mais reste bloquée désigne rfkill ou le gestionnaire de réseau. Les deux se ressemblent dans une applet de bureau et ne partagent rien en dessous.

Exécutez les vérifications sur la machine elle-même tant que la panne est encore reproductible. Une sortie collée depuis un autre hôte ne remplace pas celle-ci.

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

Quand modinfo ne trouve pas du tout le module, réinstaller le paquet d'espace utilisateur n'aidera pas, car l'espace utilisateur n'a jamais été la partie manquante. Cette observation économise une heure de manipulations de paquets et pointe droit vers le noyau.

Revenez en arrière dans un ordre qui vous laisse un noyau

Si FIPS a été activé par erreur, le chemin de récupération documenté désactive le service, purge ses paquets puis restaure le noyau générique. L'ordre n'est pas cosmétique. La purge refuse de continuer quand elle ne trouve pas un autre noyau Ubuntu, car retirer le seul laisserait une machine qui ne démarre plus. Cette vérification fait la différence entre un retour arrière et une reconstruction. C'est aussi la raison pour laquelle la séquence échoue quand le noyau générique a déjà été retiré.

Exécutez-la tant que le noyau générique est encore installé, acceptez l'avertissement sur la suppression d'un noyau, puis redémarrez. Confirmez ensuite qu'aucun paquet FIPS ne reste à l'état installé et que le noyau en cours est bien celui que vous attendiez.

Sur un hôte distant, organisez d'abord un accès console ou hors bande. Retirer un noyau par SSH est sans risque jusqu'au redémarrage exact qui ne revient pas.

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

Quand la certification est l'exigence

Revenir en arrière est le mauvais geste quand la certification est contractuelle, car la machine quitte alors la configuration que décrit l'audit. Dans ce cas, l'écart de pilote est une question de choix matériel : prenez un adaptateur sans fil dont le pilote est livré avec le noyau certifié, acceptez une machine filaire uniquement, ou déplacez le tunnel vers un composant que le noyau certifié prend déjà en charge.

Compiler un module hors arbre dans le noyau certifié n'est pas une solution neutre. Cela change ce que le noyau exécute, et c'est précisément la propriété que décrit la certification.

Consignez la décision avec le nom du propriétaire à côté, car la demande de simplement faire fonctionner le Wi-Fi reviendra dans quelques mois avec moins de contexte. Une courte note maintenant évite la même discussion plus tard.

Vérifiez la pile par couches après le changement

Après le retour arrière ou le changement de matériel, vérifiez du bas vers le haut plutôt que du client VPN vers le bas. L'interface doit exister, la liaison doit être active, le résolveur doit fonctionner, et c'est seulement ensuite que le tunnel compte. Chaque couche échoue avec son propre message, et les lire dans l'ordre garde le diagnostic honnête.

Un état DNS résiduel du démarrage précédent est un faux positif courant, alors lisez le résolveur avant de conclure que le tunnel est cassé.

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

Si le tunnel échoue encore une fois le noyau revenu, lisez l'étape qui échoue plutôt que la ligne de résumé du client. Un module qui ne s'est jamais chargé, un certificat que le pair a rejeté et un identifiant que le serveur a refusé sont trois problèmes distincts, et un redémarrage ne les distinguera pas à votre place. Notez le nom de l'étape dans le ticket, et l'ingénieur suivant reprendra là où vous vous êtes arrêté.