- État Nouveau Rouverte
- Pourcentage achevé
- Type Anomalie
- Catégorie Services locaux → VM
- Assignée à Personne
- Système d'exploitation Freebox V9 (Ultra)
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 4.10.2
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par boblaiponge - 18/05/2026
Dernière modification par lduboin - 01/06/2026
FS#41015 - AdGuard - VM - Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
Bonjour,
Ma VM sous AdGuard ne boot plus (je n’ai fait aucun changement) voici message dans logs:
Begin: Running /scripts/init-bottom … done.
[ 3.649729] Kernel panic - not syncing: Attempted to kill init! exitcode=0×00000004 [ 3.651679] CPU: 1 PID: 1 Comm: systemd Not tainted 6.8.0-111-generic #111-Ubuntu
[ 3.653591] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 3.656023] Call trace:
[ 3.656794] dump_backtrace+0xa4/0×150 [ 3.657747] show_stack+0×24/0×50 [ 3.658523] dump_stack_lvl+0×38/0×138 [ 3.659515] dump_stack+0x1c/0×38 [ 3.660449] panic+0x3ac/0×448 [ 3.661255] do_exit+0×408/0×468 [ 3.662235] do_group_exit+0×40/0xa8
[ 3.663100] get_signal+0x8b4/0x8f0
[ 3.664152] do_signal+0×148/0×238 [ 3.665138] do_notify_resume+0×114/0×228 [ 3.666173] el0_undef+0xcc/0×168 [ 3.667257] el0t_64_sync_handler+0×100/0×158 [ 3.668773] el0t_64_sync+0x1b0/0x1b8
[ 3.669718] SMP: stopping secondary CPUs
[ 3.670762] Kernel Offset: 0x488538c10000 from 0xffff800080000000
[ 3.672317] PHYS_OFFSET: 0xfffff91dc0000000
[ 3.673211] CPU features: 0×0,00000011,20020000,0100421b
[ 3.674184] Memory Limit: none
[ 3.674761] —[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0×00000004 ]—
Selon ChatGPT une instruction d’Ubuntu n’est plus expose “el0_undef+0xcc/0×168” peut etre a cause d’une MaJ freebox?
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Ca ressemble plutôt à une Maj du noyau de votre VM qui s'est mal passée.
etrange, je n'ai rien fait de particulier;
j'ai essayé aussi avec une nouvelle VM debian elle a l'air d'etre toujours a 100% alors que je ne fais rien…
Un lien possible avec mon ticket ?
https://https://dev.freebox.fr/bugs/task/41024?string=4.11.1&search_name=&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
Désolé j'étais sur téléphone mobile je n'ai pas tout bien lu
J'ai moi aussi ce matin mes 2 VM qui dysfonctionnent et surtout qui ne veulent plus booter correctement. Je n'arrive plus à les pinguer malgré un stop / démarre.
C'est une Debian Bookworm et Ubuntu.
Est-ce en lien avec la faille récente CIFS (car je monte le disque Raid ? Est-ce qu'un patch a été poussé ?
Autre chose ? C'était stable depuis plusieurs mois… Merci.
Fausse alerte, mais si cela peut servir, mon RAID était plein !!
@boblaiponge
Ne pas prendre ce que dit ChatGPT pour parole d'évangile.
Je suis d'accord avec @loggoi.
La Freebox n'est pas responsable du scheduling des process de votre VM. Si par "toujours à 100%" vous entendez 100% d'utilisation CPU alors le problème vient sûrement de l'OS tournant dans la VM (guest).
Je vous conseillerais de regarder dans les logs de votre VM (journalctl), et de monitorer quel process monopolise le CPU (top).
Bonne semaine