Plantage très récurrents de jeedom (OS). Aide pour analyse

[Dreaky]

Bonjour à tous,
Bon ça y est je craque, mon jeedom plante maintenant trop régulièrement pour ne plus les ignorer. Et j’ai besoin de vos lumières

Depuis plusieurs semaines maintenant, mon jeedom ne tient pas plus de 2 jours. J’ai en moyenne 1 à 4 plantages du système (au niveau de l’OS) par jour.
J’en ai eu 4 ce matin entre 5h et 11h, c’est trop…

(je donne en fin de post toute la configuration de mon système).

Il existe plusieurs cas : soit un plantage pur et dur de l’OS, soit un freeze. Les symptômes :

• Sur freeze : d’abord une erreur « bad gateway 502 » sur la page jeedom, avant que cela soit plus du tout accessible (timeout). Pendant cette phase, même le SSH est inaccessible, mais le monitoring proxmox m’affiche toujours une VM en vie avec un plafonnement CPU à 12/13% continu (alors que je suis en général entre 2 et 4%)
• Sur plantage dur : OS full KO, plantage du kernel. Plus rien ne répond (http, ssh etc…)

Ca fait un moment que je tente d’analyser le truc (via du monitoring charge CPU, process etc), mais rien de concluant. Ce matin, sur les 4 plantages, 3 sont des plantages du noyau linux visibles dans les journaux syslog.

Voici l’analyse de ces trois plantages par ChatGPT 4o :

Analyse des logs (résumé technique)

Cas à 08h44 (8h45.txt)

• mariadbd est en lock CPU pendant >22 s → soft lockup
• RCU (Read-Copy Update) détecte un blocage prolongé sur CPU 3
• Appels dans __split_huge_pmd et zap_page_range
• La VM entre dans un état instable (plus de réponse Apache/SSH)

Cas à 09h11 (9h11.txt)

• Blocage du thread khugepaged → tâche du noyau qui gère les pages mémoire énormes >(Transparent Huge Pages)
• Suivi d’un NULL pointer dereference dans le kernel (erreur sérieuse)
• mariadbd et apache2 sont impactés
• Noyau Debian 5.10.0-35 (build récent)

Cas à 07h32 (7h32.txt)

• Redémarrage complet de la VM visible : probablement causé par un crash noyau antérieur ou >un redémarrage forcé

---

Diagnostic

Tu es face à un bug noyau sévère lié à la gestion mémoire dans un environnement virtualisé >KVM/QEMU, impliquant :

• MariaDB comme déclencheur ou aggravant,
• Les appels système madvise, zap_page_range, flush_tlb_mm_range, etc.
• Les Transparent Huge Pages (khugepaged) qui provoquent des corruptions ou blocages.

---

Actions concrètes à engager

1. Désactiver les Transparent Huge Pages (THP)

C’est la priorité immédiate, car khugepaged est impliqué dans les crashs.

Dans /etc/default/grub, ajoute ceci à la ligne GRUB_CMDLINE_LINUX_DEFAULT :

bash

transparent_hugepage=never

Exemple :

bash

GRUB_CMDLINE_LINUX_DEFAULT="quiet transparent_hugepage=never"

Puis applique :

bash

update-grub
reboot

Cela désactive khugepaged, souvent source de crashs avec MariaDB en VM.

---

2. Forcer MariaDB à éviter les mmap / madvise abusifs

Ajoute dans /etc/mysql/mariadb.conf.d/50-server.cnf :

[mysqld]
innodb_use_native_aio=0

Et redémarre MariaDB :

bash

systemctl restart mariadb

---

3. Passer au noyau Debian stable (si ce n’est pas déjà le cas)

Le log indique 5.10.0-35-amd64, soit un backport récent.

Pour améliorer la stabilité, tu peux tenter de revenir au noyau standard (ex. : 5.10.0-28->amd64), ou passer à une version plus récente si stable (6.x via backports). À confirmer selon >ton setup.

---

4. Désactiver THP à chaud (temporaire)

En attendant un reboot, tu peux aussi appliquer :

bash

echo never > /sys/kernel/mm/transparent_hugepage/enabled

et

bash

echo never > /sys/kernel/mm/transparent_hugepage/defrag

---

Recommandation

Les crashs sont graves (soft lockup, NULL pointer dereference), donc il est impératif de :

• désactiver les THP,
• forcer MariaDB à éviter certains appels système dangereux,
• et si possible, tester un autre noyau plus stable ou plus récent.

ChatGPT me propose plusieurs solutions, dont notamment désactiver les THP (géré par le processus khugepaged) qui aurait une compatibilité limitée avec mariadb sous environnement virtualisé. Personnellement première fois que j’entends ça.
Il propose ensuite une modif de mariadb pour éviter les mmap / madvise abusifs. Là encore, je crois n’avoir jamais vu ça dans le forum.
Enfin, il propose d’upgrader la version du noyaux linux (actuellement 5.10.0-35-amd64, qui date du 19 mai 2025, donc récente) vers une version « backport », et donc passer sur du 5.19 ou carrément 6.1.

Je ne pense pas avoir d’historisation trop agressive pour pourrait expliquer que mariadb soit à genoux (voir fin de post pour l’analyse de l’historisation)
A noter que j’ai récemment changé le disque (nvme) de mon système proxmox par un neuf (clone disk to disk), pour écarter un problème de secteurs défectueux.
Sinon ma VM tourne sur ce proxmox depuis décembre 2023, et je n’ai ce genre de soucis que depuis quelques semaines.

Mes questions à la communauté :

• A ceux qui hébergent leur jeedom sur une VM proxmox, quelles sont vos versions de noyaux ? Certains ont-ils forcé un update noyau via repot backports ?
• Avez-vous eu des problèmes similaire avec mariadb ? Et effectué une modif de la conf comme proposé par chatgpt ? Car j’ai aussi des doutes sur certains plantage lié à des freezes de mariadb…
• Qu’est-ce que vous préconisez de monitorer pour tenter d’intercepter ce qui fait freeze mariadb ?

Merci d’avance pour votre aide

Ma configuration complète :

• Hardware : ACEMAGICIAN AM06Pro Mini PC (AMD Ryzen 7 5700U 8C/16T, DDR4 32 Go, 1To Nvme)
• VM Jeedom hébergée sous proxmox 8.4.1
• Version du noyau du noeud proxmox : Linux pve 6.8.12-11-pve (2025-05-22T09:39Z) x86_64
• OS : Debian 11, noyau 5.10.0-35-amd64 (build 5.10.237-1, daté du 19 mai 2025)
• Taille d’une sauvegarde jeedom : 190Mo
• Les services Mosquitto et zigbee2mqtt sont hébergés en dehors de la VM jeedom (sur leux propres LXC)
• Config proxmox de la VM :

agent: 1
balloon: 0
boot: order=scsi0;net0
cores: 4
cpu: host
memory: 6144
meta: creation-qemu=8.1.2,ctime=1702054780
name: jeedom
net0: virtio=BC:24:11:74:9F:9F,bridge=vmbr0,firewall=1
onboot: 1
ostype: l26
scsi0: ssdlocal:vm-103-disk-0,iothread=1,size=32G
scsihw: virtio-scsi-single
smbios1: uuid=68e28a3e-42e6-494e-8741-9810288ea162
sockets: 2
startup: order=2
tablet: 0

Analyse archivage :

Durée moyenne d’un archivage : 10sec

[2025-06-11 14:35:20][SCENARIO] -- Début : Scenario lance manuellement.
[2025-06-11 14:35:20][SCENARIO] - Exécution du sous-élément de type [action] : code
[2025-06-11 14:35:20][SCENARIO] Exécution d'un bloc code
[2025-06-11 14:35:20][SCENARIO] ┌──────────── Logs bloc code - version du 31/10/2024 07:00
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:20][SCENARIO] | -------- PARAMETRES
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:20][SCENARIO] |     Seuil alerte 24h           : 50
[2025-06-11 14:35:20][SCENARIO] |     Seuil nb lignes archivées  : 50 000
[2025-06-11 14:35:20][SCENARIO] |     Seuil taille table         : 200 MB
[2025-06-11 14:35:20][SCENARIO] |     Seuil nb lignes table      : 2 000 000
[2025-06-11 14:35:20][SCENARIO] |     Nb de commandes récupérées : 5
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:20][SCENARIO] | -------- TACHE D'ARCHIVAGE
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:20][SCENARIO] |     Actif    : 1
[2025-06-11 14:35:20][SCENARIO] |     Statut   : stop
[2025-06-11 14:35:20][SCENARIO] |     Last run : 2025-06-11 05:00:01
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:20][SCENARIO] | -------- RESUME
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:20][SCENARIO] |     Table historyArch : Taille -> 240MB , nb lignes -> 5 830 441
[2025-06-11 14:35:20][SCENARIO] | /!\ Table Anormalement grosse, taille superieure au seuil (240MB)
[2025-06-11 14:35:20][SCENARIO] | /!\ Table Anormalement grosse, Nb de lignes superieur au seuil (5 830 441 lignes)
[2025-06-11 14:35:20][SCENARIO] |     Table history : Taille -> 17MB , nb lignes -> 271 635
[2025-06-11 14:35:20][SCENARIO] |     Table conso_teleinfo : Taille -> 8MB , nb lignes -> 49 850
[2025-06-11 14:35:20][SCENARIO] |     Table event : Taille -> 8MB , nb lignes -> 249
[2025-06-11 14:35:20][SCENARIO] |     Table cmd : Taille -> 2MB , nb lignes -> 3 531
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:20][SCENARIO] | -------- COMMANDES AVEC DONNEES VOLUMINEUSES
[2025-06-11 14:35:20][SCENARIO] |
[2025-06-11 14:35:21][SCENARIO] | virtual -> #[Maison][Résumé élec][Conso totale]# (id : 6718)
[2025-06-11 14:35:21][SCENARIO] | /!\ PB DE PARAMETRAGE, nb de valeur archivéess trop importantes (663 055), superieur à 50 000
[2025-06-11 14:35:21][SCENARIO] |     Configuration : historisé -> 1 , lissage -> avg , purge -> -2 years
[2025-06-11 14:35:21][SCENARIO] |     Historique    : 2006 valeurs (estimation sur 24h : 5021)
[2025-06-11 14:35:21][SCENARIO] |     Archives      : 663055 valeurs depuis 389 jours (1705 valeurs par jour en moyenne)
[2025-06-11 14:35:21][SCENARIO] |
[2025-06-11 14:35:21][SCENARIO] | virtual -> #[Maison][Résumé élec][Import edf]# (id : 6719)
[2025-06-11 14:35:21][SCENARIO] | /!\ PB DE PARAMETRAGE, nb de valeur archivéess trop importantes (638 949), superieur à 50 000
[2025-06-11 14:35:21][SCENARIO] |     Configuration : historisé -> 1 , lissage -> avg , purge -> -2 years
[2025-06-11 14:35:21][SCENARIO] |     Historique    : 2012 valeurs (estimation sur 24h : 5036)
[2025-06-11 14:35:21][SCENARIO] |     Archives      : 638949 valeurs depuis 389 jours (1643 valeurs par jour en moyenne)
[2025-06-11 14:35:21][SCENARIO] |
[2025-06-11 14:35:21][SCENARIO] | virtual -> #[Maison][Résumé élec][Injection]# (id : 6721)
[2025-06-11 14:35:21][SCENARIO] | /!\ PB DE PARAMETRAGE, nb de valeur archivéess trop importantes (638 935), superieur à 50 000
[2025-06-11 14:35:21][SCENARIO] |     Configuration : historisé -> 1 , lissage -> avg , purge -> -2 years
[2025-06-11 14:35:21][SCENARIO] |     Historique    : 2010 valeurs (estimation sur 24h : 5031)
[2025-06-11 14:35:21][SCENARIO] |     Archives      : 638935 valeurs depuis 389 jours (1643 valeurs par jour en moyenne)
[2025-06-11 14:35:21][SCENARIO] |
[2025-06-11 14:35:21][SCENARIO] | teleinfo -> #[Maison][Téléinfo][BBRHCJB]# (id : 6168)
[2025-06-11 14:35:21][SCENARIO] | /!\ PB DE PARAMETRAGE, nb de valeur archivéess trop importantes (408 357), superieur à 50 000
[2025-06-11 14:35:21][SCENARIO] |     Configuration : historisé -> 1 , lissage -> aucun , purge -> -1 year
[2025-06-11 14:35:21][SCENARIO] |     Historique    : 2007 valeurs (estimation sur 24h : 5023)
[2025-06-11 14:35:21][SCENARIO] |     Archives      : 408357 valeurs depuis 365 jours (1119 valeurs par jour en moyenne)
[2025-06-11 14:35:21][SCENARIO] |
[2025-06-11 14:35:21][SCENARIO] | teleinfo -> #[Maison][Téléinfo][BBRHPJB]# (id : 6169)
[2025-06-11 14:35:21][SCENARIO] | /!\ PB DE PARAMETRAGE, nb de valeur archivéess trop importantes (408 354), superieur à 50 000
[2025-06-11 14:35:21][SCENARIO] |     Configuration : historisé -> 1 , lissage -> aucun , purge -> -1 year
[2025-06-11 14:35:21][SCENARIO] |     Historique    : 2007 valeurs (estimation sur 24h : 5023)
[2025-06-11 14:35:21][SCENARIO] |     Archives      : 408354 valeurs depuis 365 jours (1119 valeurs par jour en moyenne)
[2025-06-11 14:35:21][SCENARIO] |
[2025-06-11 14:35:21][SCENARIO] | -------- COMMANDES AVEC DONNEES ALPHANUMERIQUES
[2025-06-11 14:35:21][SCENARIO] |
[2025-06-11 14:35:23][SCENARIO] | teleinfo -> #[Maison][Téléinfo][PTEC]# (id : 1389)
[2025-06-11 14:35:23][SCENARIO] |     Configuration : historisé -> 1 , lissage -> aucun , purge -> -1 year
[2025-06-11 14:35:23][SCENARIO] |     Historique    : 8028 caractères (estimation sur 24h : 20092)
[2025-06-11 14:35:23][SCENARIO] |     Archives      : 4348 caractères depuis 365 jours (12 caractères par jour en moyenne)
[2025-06-11 14:35:23][SCENARIO] |
[2025-06-11 14:35:23][SCENARIO] | mode -> #[Maison][Modes][Mode]# (id : 756)
[2025-06-11 14:35:23][SCENARIO] |     Configuration : historisé -> 1 , lissage -> aucun , purge -> aucun
[2025-06-11 14:35:23][SCENARIO] |     Historique    : 0 caractères (estimation sur 24h : 0)
[2025-06-11 14:35:23][SCENARIO] |     Archives      : 674 caractères depuis 760 jours (1 caractères par jour en moyenne)
[2025-06-11 14:35:23][SCENARIO] |
[2025-06-11 14:35:23][SCENARIO] | teleinfo -> #[Maison][Téléinfo][DEMAIN]# (id : 6174)
[2025-06-11 14:35:23][SCENARIO] | /!\ PB DE PARAMETRAGE, nb de valeur par 24h important (20 092) et aucun lissage ni aucune purge paramétrés
[2025-06-11 14:35:23][SCENARIO] |     Configuration : historisé -> 1 , lissage -> aucun , purge -> aucun
[2025-06-11 14:35:23][SCENARIO] |     Historique    : 8028 caractères (estimation sur 24h : 20092)
[2025-06-11 14:35:23][SCENARIO] |     Archives      : 516 caractères depuis 411 jours (1 caractères par jour en moyenne)
[2025-06-11 14:35:23][SCENARIO] |
[2025-06-11 14:35:23][SCENARIO] | virtual -> #[Maison][Chauffage][etat]# (id : 1963)
[2025-06-11 14:35:23][SCENARIO] |     Configuration : historisé -> 1 , lissage -> aucun , purge -> -3 month
[2025-06-11 14:35:23][SCENARIO] |     Historique    : 0 caractères (estimation sur 24h : 0)
[2025-06-11 14:35:23][SCENARIO] |     Archives      : 395 caractères depuis 92 jours (4 caractères par jour en moyenne)
[2025-06-11 14:35:23][SCENARIO] |
[2025-06-11 14:35:23][SCENARIO] | teleinfo -> #[Maison][Téléinfo][HHPHC]# (id : 1425)
[2025-06-11 14:35:23][SCENARIO] |     Configuration : historisé -> 1 , lissage -> aucun , purge -> -1 year
[2025-06-11 14:35:23][SCENARIO] |     Historique    : 2007 caractères (estimation sur 24h : 5023)
[2025-06-11 14:35:23][SCENARIO] |     Archives      : 362 caractères depuis 365 jours (1 caractères par jour en moyenne)

[Dreaky]

Voilà que j’écris à peine le message, qu’un nouveau plantage intervient :

On voit sur proxmox que ça fait seulement 3h18 que la VM tourne.
Proxmox voit la VM en vie, avec un plafonnement CPU à 13% typique :

Le ping est KO, SSH aussi (même depuis la console proxmox).
Seul moyen de récupérer la VM => forcer un stop.

Rien de suspect niveau des IO et de la mémoire :

Analyse de chatgpt :

Le log 14h54.txt confirme à nouveau un plantage noyau grave, causé par un processus utilisateur (mariadbd) impliqué dans la gestion mémoire.

Détail de l’erreur
Erreur détectée : BUG: kernel NULL pointer dereference, address: 0000000000000001

Processus fautif : mariadbd (PID 679)

Pile noyau (stack trace) : implique zap_page_range, madvise_vma, do_madvise, etc.

Conséquence : arrêt brutal du processus et déstabilisation de la VM.

Diagnostic confirmé
C’est la quatrième fois que le noyau plante sur un appel mémoire (zap_page_range, madvise, split_huge_pmd) initié par MariaDB, avec en cause probable :

l’usage des Transparent Huge Pages (THP) activés par défaut,

et un bug connu affectant certaines versions de noyaux 5.10 avec MariaDB ou MySQL intensifs.

ChatGPT re propose en premier de désactiver le THP (Transparent Huge Pages), de modifier la config mariadb pour limiter les appels systèmes à risque (innodb_use_native_aio = 0) et de mettre à jour la version du noyau debian vers une 6.1 depuis les depots backports.

En parallèle, j’ai aussi vu un plantage kernel du noeud proxmox une minute avant le plantage de la VM jeedom. Voici l’analyse de chatgpt :

Oui, cette erreur du noyau sur le nœud Proxmox (pve) est clairement liée et extrêmement sérieuse. Voici les points clés :

---

Ce qui se passe sur le nœud Proxmox

Erreur : invalid opcode dans srso_safe_ret+0x16/0x20

• Cela correspond à un bogue dans le code d’atténuation matérielle des vulnérabilités CPU (ici SRSO : Speculative Return Stack Overflow).
• Le thread fautif est : CPU 5/KVM, ce qui désigne un cœur exécutant du code de machine virtuelle via KVM.
• L’erreur se produit dans le contexte du module kvm_amd, donc ta machine physique utilise un CPU AMD.

---

Conséquences :

• Le processus kvm plante dans le noyau → impact direct sur une ou plusieurs VMs en exécution.
• Très probablement, c’est ta VM Jeedom qui tournait sur ce cœur.
• Ce crash du noyau hôte précède ton plantage VM d’une minute, ce qui est suffisant pour expliquer la perte d’I/O dans la VM et les freezes associés.

---

Synthèse du problème

Tu as deux couches qui posent problème indépendamment ET combinées :

Niveau	Problème
VM	MariaDB provoque des corruptions mémoire (THP, madvise, etc.)
Hôte (pve)	Le noyau Proxmox 6.8.12-11 (très récent) plante dans KVM avec AMD + srso mitigations

---

Ce que tu dois faire maintenant

1. Mettre à jour (ou rétrograder) le noyau Proxmox du nœud

Tu utilises actuellement :

6.8.12-11-pve

Cette version est très récente, encore instable pour certains CPUs AMD, et introduit des correctifs SRSO non testés partout.

Solution :

• Revenir à une version stable comme 6.5.13-3-pve :

bash

apt install pve-kernel-6.5.13-3-pve

• Ou sinon, installer un noyau plus stable compatible 6.1.x (backport de Debian 12).

Et reboot sur ce noyau :

bash

reboot

Ensuite, pour démarrer automatiquement sur cette version :

bash

proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin <version>

---

2. Désactiver les atténuations SRSO pour tester

En ajoutant dans /etc/default/grub sur le nœud Proxmox :

bash

GRUB_CMDLINE_LINUX_DEFAULT="quiet mitigations=off"

Puis :

bash

update-grub
reboot

À n’utiliser que temporairement pour confirmer la cause, car cela désactive certaines protections CPU.

---

3. Appliquer en parallèle les correctifs côté VM

Comme vu précédemment :

• Désactivation des Transparent Huge Pages
• Ajout de innodb_use_native_aio = 0 dans MariaDB
• (Éventuellement) mise à jour du noyau de la VM elle-même (kernel 6.x)

---

Conclusion

Oui, le crash à 14h46 sur le nœud est très probablement la cause directe du freeze à 14h47 de ta VM.
Tu es victime d’une double instabilité :

• sur MariaDB / mémoire dans la VM
• sur le noyau kvm_amd dans Proxmox, amplifiée par le noyau 6.8.x

Sur quel version de proxmox tournez-vous ?

Mes plantages récents (d’il y a quelques semaines donc) font peut être suite à un upgrade de mon PVE (que je fais régulièrement, à défaut peut être…)

[Jeandhom]

@Dreaky

Sur quel version de proxmox tournez-vous ?

Virtual Environment 8.4.1

[Dreaky]

Merci !

Et quelle version du noyau ?

[Jeandhom]

Linux 6.8.12-10-pve (2025-04-18T07:39Z)

Je n’ai pas encore fait la dernière MàJ.

[ngrataloup]

Je ne me casserai pas trop la tête à analyse un truc qui n’est pas analysable, puisque j’imagine que le plantage ne laisse aucun log. C’et sun peu frustrant, mais il faut des fois faire le constat de notre ignorance pour gagner du temps.
Bref, tu es sur proxmox, donc install d’un nouvel environnement via ce post : Installation d'un jeedom neuf sous proxmox en moins de 10min

et en 15minutes, tu es reparti sur un environnement sains.

Norbert

[echo]

Bonjour

Souvent le point faible sous Proxmox ce sont les SSD, vous pouvez déjà vérifier dans pve2 → disques que le wearout est à 0%. A 1 % j’avais des plantés inexplicables de plus en plus rapprochés.

Après, avez vous fait les optimisations sur jeedom : historiques , etc…

[Dreaky]

Merci pour ton aide.

Alors oui j’avais déjà lu que proxmox est un bouffeur de SSD. C’est pour ça que j’ai désactivé quasiment dès le début les services qui gèrent la clusterisation (que je n’utilise pas) : pve-ha-crm et pve-ha-lrm, qui sont réputés pour lire/écrire à vitesse grand V sur le disque (et qui sont donc à eux seuls les principaux fautifs de l’usure prématurée des disques).

Et sinon, mon wearout SMART est à 0%, puisque comme écrit dans mon premier (long, je l’avoue) post, j’ai mentionné avoir changé le SSD en première intention, car j’avais justement très peur d’un disque avec secteurs defecteux.

@Dreaky

A noter que j’ai récemment changé le disque (nvme) de mon système proxmox par un neuf (clone disk to disk), pour écarter un problème de secteurs défectueux.

[Dreaky]

Je réponds à moi même : J’ai downgrade le kernel pve à la version 6.5.13-6 (datée de juillet 20024), et je n’ai plus eu de plantage depuis 4 jours, donc je pense que c’était bel et bien le problème et que chatgpt avait vu juste :

Donc pour ceux qui possèdent un mini PC sur processeur AMD, font tourner du proxmox et qui rencontrent régulièrement du kernel panic => downgrader la version du kernel proxmox (ça se fait très facilement et sans risque aucun).

[Jeandhom]

@Dreaky

downgrader la version du kernel proxmox (ça se fait très facilement et sans risque aucun)

Dommage de ne pas indiquer la méthode que tu as employée.
Cela évitera de chercher.

[Dreaky]

Effectivement.

Voici :

Pour afficher la liste des kernels déjà dispo sur la machine :

proxmox-boot-tool kernel list

Pour appliquer un kernel disponible :

proxmox-boot-tool kernel pin 6.5.13-6-pve

Puis rebooter, et on vérifie que la version a bien été appliquée avec la commande uname -r

Pour installer une version spécifique d’un kernel (pas dispo sur la machine) :
apt install pve-kernel-6.5.13-3-pve

[Jeandhom]

J’ajoute le retour en arrière du downgrade du noyau.
Dé-fixer le noyau et revenir au fonctionnement normal ==> proxmox-boot-tool kernel unpin

Merci à Mips pour la réouverture de ce sujet.