Changer le kernel d'une VM, et le retour arrière automatique
Épingler une version précise du noyau sur une machine, à chaud ou au prochain démarrage, lire les trois états de la fiche, et savoir ce qui se passe si le nouveau noyau ne démarre pas.
Provisionner8 min de lectureUtilisateur propriétaire de la VM
Ce que vous obtenez : Une machine épinglée sur une version choisie dans le stock, ou revenue au noyau du template, avec le redémarrage que cela implique, connu d'avance.
Avant de commencer
- Un stock de noyaux non vide : la liste déroulante est alimentée par le stock de l'instance. S'il est vide, il ne reste que « Défaut du template ».
- Une décision sur le redémarrage : appliquer tout de suite coupe la machine quelques secondes, reporter évite la coupure mais laisse la machine sur l'ancien noyau.
1.Les trois états de la ligne « Kernel »
La fiche d'une VM affiche une seule ligne « Kernel », et cette ligne dit d'où vient le noyau réellement utilisé. Trois libellés, jamais plus :
| Ce que la ligne affiche | Ce que cela veut dire | Ce qui le déclenche |
|---|---|---|
Kernel épinglé : suivi de la version | La machine démarre sur CE noyau, quoi que déclare le template. | Un épinglage enregistré. Observé : la version 6.12.103, puis 5.15.215, puis 5.10.264. |
Kernel du template : suivi de la version | Aucun noyau épinglé, mais le template courant en déclare un. | Le noyau déclaré par le template. Non observé sur cette plateforme : aucun template proposé n'en déclare. |
Défaut du template | Aucun noyau épinglé et aucun noyau déclaré par le template : la plateforme résout elle-même. | État de départ observé sur site-vitrine, et état retrouvé après un retour au défaut. |
Un badge peut apparaître à droite de la ligne
Quand un noyau est épinglé, la fiche affiche en plus un badge <version> dispo si le stock contient une AUTRE version. Observé : 6.18.44 dispo en face d'une machine épinglée sur 6.12.103, puis sur 5.15.215, puis sur 5.10.264. Le badge disparaît dès que la machine est remise sur Défaut du template : une machine sans noyau épinglé n'affiche jamais ce signal, même si son noyau est ancien.
2.Où l'on change le noyau
- Barre latérale « VMs »
- Cliquer une VM de la liste
- Bloc INFORMATIONS, ligne « KERNEL »
- Bouton « Mettre à jour »
site-vitrine. La liste déroulante est ouverte sur la version 6.12.103 : c'est un choix fait pour la capture, pas un défaut. La case de redémarrage, elle, est cochée par défaut à l'ouverture. (cliquez la capture pour l'agrandir)La modale s'intitule « Mettre à jour le kernel » et ne contient que deux éléments : la liste Kernel et, uniquement si la machine tourne, l'encart de redémarrage. Deux boutons ferment ou appliquent : Annuler et Confirmer. Pendant l'appel, le bouton affiche « Application... ».
3.Épingler une version
La liste contient une entrée par noyau du stock, plus le défaut, rangées du plus récent au plus ancien. Son contenu suit le stock de l'instance : il grandit et se renouvelle, et une version peut en disparaître. Le relevé qui suit est donc DATÉ, pas une liste fixe.
Le relevé du 8 octobre 2026
Ce jour-là, la liste portait onze entrées : le défaut, puis dix versions.
Défaut du template (résolution automatique): la première entrée, valeur vide6.18.54, lignée 6.18, sans date de publication6.18.53, lignée 6.18, sans date de publication6.18.44, lignée 6.18, publié le 9 août 20266.12.111, lignée 6.12, sans date de publication6.12.103, lignée 6.12, publié le 9 août 20266.6.157, lignée 6.6, sans date de publication6.6.151, lignée 6.6, publié le 9 août 20266.1.188, lignée 6.1, sans date de publication6.1.182, lignée 6.1, publié le 7 août 20265.15.221, lignée 5.15, sans date de publication
La forme d'une entrée est `<version>, lignée <lignée>`, et la mention `(publié <date>)` ne s'y ajoute que lorsque le stock connaît cette date : quatre des dix versions relevées la portaient. Rien d'autre n'est affiché : ni taille, ni empreinte, ni machine compatible.
Ce qui n'est pas dit ici : la version de noyau du template de la machine, elle n'est écrite nulle part dans cette modale, et c'est justement l'entrée par défaut qui la représentera. Il n'y a aucun champ de saisie libre : on choisit dans le stock ou on ne choisit pas.
- 1
Choisir la version
Ouvrez la liste et cliquez l'entrée voulue. Les plus récentes sont en haut. La version choisie n'est pas confirmée par un second écran : ce que vous voyez dans la liste est ce qui sera enregistré.
- 2
Décider du redémarrage
La case « Redémarrer maintenant pour appliquer » est cochée par défaut. Laissez-la cochée pour que la machine redémarre immédiatement avec le nouveau noyau ; décochez-la pour ne rien interrompre.
- 3
Confirmer
Cliquez « Confirmer ». La modale reste ouverte le temps de l'appel : le bouton devient « Application... », puis la modale se ferme et la fiche se rafraîchit.
- 4
Lire le résultat sur la fiche
La ligne Kernel passe immédiatement à
Kernel épinglé :suivi de la version : elle décrit le noyau ENREGISTRÉ, pas seulement celui qui tourne. C'est pour cela qu'elle peut afficher une version que la machine n'utilise pas encore.
Kernel épinglé suivi de la version, et le bouton « Mettre à jour » pour changer d'avis. Le badge de version disponible (6.18.44 dispo) accompagne cette ligne. (cliquez la capture pour l'agrandir)4.Appliquer tout de suite, ou au prochain démarrage
L'encart de redémarrage n'apparaît que sur une machine en marche. Il contient une phrase fixe et une case :
- La phrase, toujours affichée : « Le VM sera redémarrée (quelques secondes d'interruption). Vos données ne sont pas touchées. » Elle reste affichée même quand la case est décochée, donc ne la lisez pas comme une confirmation du redémarrage.
- Décochée, une seconde phrase s'ajoute : « Le changement s'appliquera au prochain démarrage de la VM. »
| Case | Ce que l'application a répondu | Effet constaté |
|---|---|---|
| Cochée (défaut) | Message de succès « Kernel mis à jour : VM redémarrée » | Redémarrage réel : l'heure de démarrage de site-vitrine a été repoussée sur deux épinglages successifs. |
| Décochée | Message d'information « Kernel enregistré : appliqué au prochain redémarrage » | Aucune coupure : la machine a continué de tourner sur son noyau précédent, tout en affichant le nouveau noyau épinglé sur la fiche. |
Un changement reporté ne laisse AUCUNE trace visible
Quand vous décochez la case, l'écran ne pose aucun badge « redémarrage requis » : le seul rappel est le toast, qui disparaît. La liste des VMs n'en sait rien, et la fiche affiche le nouveau noyau épinglé comme si le noyau était déjà en service. C'est au prochain démarrage, quelle qu'en soit la cause, que le changement prendra effet.
Ce que la plateforme renvoie, cas par cas
Voici la réponse quand la machine tourne et que le redémarrage est reporté, pour les deux choix possibles, puis le cas du redémarrage immédiat :
// Épinglage d'une version
{"applied_at":"next_restart","kernel":"5.15.215","note":"redémarrage requis","status":"ok"}
// Retour au défaut du template
{"applied_at":"next_restart","kernel":"","note":"redémarrage requis","status":"ok"}
// Redémarrage immédiat, nouveau noyau démarré
{"kernel":"5.15.215","restarted":true,"status":"ok"}applied_at dit quand la valeur prendra effet : next_restart quand la machine tourne et que le redémarrage est reporté, next_start quand elle est arrêtée. kernel renvoie ce qui a été enregistré, et l'interface s'appuie sur ces champs pour choisir son message.
Le troisième cas ne porte aucun `applied_at` : la réponse dit seulement que la machine a redémarré (restarted). La valeur now existe bien dans l'API, mais sur la route des ressources, pas sur celle du noyau.
5.Revenir au noyau par défaut
La première entrée de la liste, Défaut du template (résolution automatique), retire l'épinglage. Son libellé s'adapte : si le template de la machine déclare un noyau, l'entrée affiche le nom de ce noyau ; si le template a été supprimé ou n'en déclare pas, elle retombe sur le libellé générique. Choisissez-la puis Confirmez, exactement comme un épinglage.
Exécuté : après le retour au défaut, la fiche réaffiche Défaut du template, le badge de version disponible disparaît, et la VM n'a plus de noyau enregistré. Le redémarrage, lui, suit la même règle que l'épinglage : immédiat si la case est cochée, au prochain démarrage sinon.
6.Le filet : le retour arrière automatique quand le boot échoue
Un démarrage raté n'est pas un échec, c'est le filet qui fonctionne
Quand vous appliquez un noyau AVEC redémarrage immédiat, la plateforme arrête la machine, l'écrit, la redémarre, puis vérifie que le bon noyau a démarré, en lisant la console pendant 90 secondes.
Si cette vérification échoue, la plateforme réarrête la machine, réécrit l'ancien noyau et la redémarre : votre machine revient d'elle-même sur l'ancien noyau, sans intervention de votre part.
Ce paragraphe n'a PAS été exécuté dans l'application
Aucune manipulation de compte utilisateur ne permet de faire échouer un démarrage : il faudrait qu'un noyau du stock soit cassé. Ce qui suit décrit donc le comportement attendu de la plateforme, et NON une observation : ne le lisez pas comme un comportement constaté.
| Point | Ce que dit la source, avec sa référence |
|---|---|
| Message affiché | Un message d'ERREUR de 8 secondes : « Boot échoué avec le nouveau kernel : ancien kernel restauré (<version>) ». Le message est volontairement alarmant : c'est l'ancien noyau qui tourne, donc le service est debout. |
| Ce qui déclenche le retour | Un vrai échec de démarrage ou un simple doute : au bout de 90 s sans preuve du bon noyau, le retour arrière est déclenché. Une machine lente à démarrer peut donc revenir sur l'ancien noyau sans avoir été en panne. |
| Erreur d'écriture | Le retour n'est pas confirmé dans la réponse : un échec du redémarrage de retour n'est que journalisé. Vérifiez la ligne « Kernel » de la fiche après coup. |
Les pièges, en résumé
La case de redémarrage est cochée par défaut
Elle est cochée à l'ouverture de la modale. Confirmer sans y toucher coupe la machine quelques secondes et redémarre réellement le service qu'elle héberge, comme cela a été observé sur site-vitrine.
La phrase d'avertissement reste affichée même quand la case est décochée
« Le VM sera redémarrée… » reste à l'écran même case décochée. Seule la petite phrase « Le changement s'appliquera au prochain démarrage de la VM. » indique que rien ne redémarrera.
Un changement reporté n'a aucun rappel persistant
Aucun badge « redémarrage requis » n'est posé par ce changement, contrairement aux ressources et au réseau. La fiche affiche le nouveau noyau épinglé alors que la machine tourne encore sur l'ancien.
Le badge de version disponible ne parle que des noyaux épinglés
<version> dispo n'apparaît que si un noyau est explicitement épinglé. Une machine sur Défaut du template peut tourner sur un noyau ancien sans le moindre signal.
Un doute suffit à déclencher le retour arrière
Au-delà de 90 secondes sans trace du bon noyau dans la console, la plateforme restaure l'ancien noyau. Ce comportement n'a pas été observé ici : il est décrit comme attendu, pas comme constaté.
Il n'existe aucun champ de version libre
On choisit dans le stock de l'instance, jamais une version tapée à la main. La liste peut être vide : la seule entrée est alors « Défaut du template ».
Ce guide est-il a jour ?
Chaque affirmation de cette page a ete verifiee sur le produit avant publication, et ce qui n'etait pas verifie n'a pas ete ecrit. Une page peut cependant vieillir avant le produit : si un ecran ne correspond plus a ce que vous voyez, dites-le, la page sera reprise.
Prêt à créer vos premières VMs ?
30 secondes d'inscription. 2 secondes pour la première VM. Zéro engagement.