Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par ajacss (26-09-2019 11:55:53)
Hors ligne
j'ai l'impression que se sont les mêmes "kernel panic"
J'ai plutôt l'impression du contraire. Sur la première image, on lit "PANIC: double fault" et sur l'autre "Attempted to kill init".
Dans l'architecture x86, une "double fault (anglais)" résulte d'un problème pendant le traitement d'une interruption ou d'une exception. C'est une erreur interne du noyau qui peut être causée par la corruption de la table de description des interruptions (IDT).
"Attempted to kill init" est un erreur plus courante qui se produit quand quelque chose provoque l'arrêt du processus "init". Ce processus qui a le PID 1 est le premier lancé par le noyau, il est le parent (PPID) ou l'ancêtre de tous les autres processus et ne doit jamais être arrêté. Cela peut être provoqué par un plantage du processus lui-même à cause d'une erreur mémoire par exemple.
Le point commun pourrait être un bug qui provoque une corruption de la mémoire.
- booter sur l'ISO netinstall.
Mais rien n'y fait, même symptôme, après le grub Kernel Panic...
Lors du démarrage de l'installateur ou du démarrage du système installé ?
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par ajacss (22-09-2019 13:54:08)
Hors ligne
C'est lors du boot de l'installeur. Juste après le GRUB de l'installeur (boot sur L'ISO)
En mode BIOS, l'installateur Debian ne démarre pas avec GRUB mais avec ISOLinux.
c'est une installation 64bit (non x86)
La version du noyau visible sur les images indique qu'il s'agit de l'architecture amd64, donc x86 64 bits.
Entre l'image 1 et l'image 2 j'ai désactivé l'accélération materielle
Sur la même machine ? Comment était-on censé le deviner ? Comme il était fait mention de deux machines, je pensais naturellement que chaque image correspondait à une machine différente.
Il vaut mieux montrer que raconter.
Hors ligne
ajacss a écrit :c'est une installation 64bit (non x86)
La version du noyau visible sur les images indique qu'il s'agit de l'architecture amd64, donc x86 64 bits.
Oula, la fatigue, je voulais marqué "c'est en effet une installation 64bit (non 32bit)"
En tout cas merci pour votre aide ! Dite moi ce que je peux faire pour aider au diagnostic
Dernière modification par ajacss (22-09-2019 15:21:07)
Hors ligne
Dernière modification par ajacss (23-09-2019 12:01:45)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
pour ta V.M. :
quel systeme virtualise tu ?
nom du systeme ?
version du systeme ?
kernel (version) ?
Hors ligne
Dernière modification par melissa6969 (24-09-2019 17:55:27)
Quamdiu est spes est, Est vitae.
Fiet in posterum melius
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Debian Alain (25-09-2019 09:00:40)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
En quoi est-ce moins important si c'est une VM ?
Je sais pas, attends au hasard comme ça, peut-être parce que la VM qui dysfonctionne est hébergée sur ton système hôte qui lui fonctionne très bien, donc à quoi bon se prendre la tête 20 plombes pour une pauvre VM qu'on peut recréer à l'infini sans péter notre système hôte.?? (je réponds comme une idiote de service parce que ta question n'a tout simplement aucun sens/intérêt)
Mais c'est vrai que c'est mieux de faire ultra complexe quand c'est d'une simplicité enfantine, c'est bien connu, la simplicité c'est has been de nos jours.
@debian_alain
Et sur le système hôte on a des données importantes qu'on veut pas perdre, alors que la V.M on en a rien à carrer, elle plante bah OSEF on la réinstalle et on se pas chier 30 plombes avec une connerie
Mais bon les VM c'est la vie apparemment les gens s'inquiètent + de leur VM que de leur système hôte, et pollue les topics de screens inutiles (un simple copier coller des messages d'erreur de la VM à l'hôte serait + économique en terme de ressources 
oui parce que le copy paste de la VM à l'hôte existe, innovation du XXIe siècle utile pour une fois, mais faut encore avoir l'envie d'y faire 
Dernière modification par melissa6969 (25-09-2019 11:29:28)
Quamdiu est spes est, Est vitae.
Fiet in posterum melius
Hors ligne
pour ta V.M. :
quel systeme virtualise tu ?
nom du systeme ?
version du systeme ?
kernel (version) ?
Tout est dans le 1er post du thread. Debian 10.1 kernel 4.19
une V.M. , si çà coince , tu peux tout casser , tout recommencer ....
sur une machine physique , c'est déjà moins évident .
En effet, je plussoie mais en quoi ca m'aide ? Je n'essai pas de réparer un systeme de VM, J'essay de comprendre pourquoi je n'arrive pas à l'installer / la démarrer
En quoi est-ce moins important si c'est une VM ?
EN effet, quand on travail en production (et oui c'est pas pour jouer à la maison dans mon cas), ce n'est pas moins important
Mais bon les VM c'est la vie apparemment les gens s'inquiètent + de leur VM que de leur système hôte, et pollue les topics de screens inutiles (un simple copier coller des messages d'erreur de la VM à l'hôte serait + économique en terme de ressources acid.gif
oui parce que le copy paste de la VM à l'hôte existe, innovation du XXIe siècle utile pour une fois, mais faut encore avoir l'envie d'y faire big_smile
Oula tu crois vraiment que je me serait fait autant chier à poster des captures d'écrans si j'avais pus faire un simple copier/coller de ma console ESX ?
Sort un peu de ta grotte, on travaille pas tous sur des jouet à la maison. En production, on à pas toujours les dernières versions des Hotes et on ne peut pas toujours réinstaller / tout péter au niveau du système Hote juste parce qu’une console ne permet pas de faire un copier coller...
Dernière modification par ajacss (26-09-2019 09:04:20)
Hors ligne
Je n'ai aucun moyen de mettre à jour l'OS des systèmes Hôtes car ils ne m'appartiennent pas.
arf !!! très embêtant çà . j'avais cru lire que c'était l'une des rares solutions .
Hors ligne
melissa6969 a écrit :
Mais bon les VM c'est la vie apparemment les gens s'inquiètent + de leur VM que de leur système hôte, et pollue les topics de screens inutiles (un simple copier coller des messages d'erreur de la VM à l'hôte serait + économique en terme de ressources acid.gif
oui parce que le copy paste de la VM à l'hôte existe, innovation du XXIe siècle utile pour une fois, mais faut encore avoir l'envie d'y faire big_smile
Oula tu crois vraiment que je me serait fait autant chier à poster des captures d'écrans si j'avais pus faire un simple copier/coller de ma console ESX ?
Sort un peu de ta grotte, on travaille pas tous sur des jouet à la maison. En production, on à pas toujours les dernières versions des Hotes et on ne peut pas toujours réinstaller / tout péter au niveau du système Hote juste parce qu’une console ne permet pas de faire un copier coller...
C'est pour le taf et tu sais pas installer une VM fonctionnelle, t'es en train de nous dire.??
Qui t'as dis de péter le système hôte.?? J'ai dis ça à quel moment.?? Quand je t'ai dis de toucher à ton système hôte.??
Je te parle de ta VM, on s'en cogne de ton système hôte, c'est pas lui le soucis il me semble.
J'en reviens à dire que je comprends pas pourquoi tu te fais chier avec cette VM, elle marche pas, bah vires la et réinstalles-la, y a quoi de compliqué à faire ça.??
Tu fais des screens, donc t'as un accès physique à VMware, dans ma grotte, c'est la 1ere chose que j'aurais fais, plusieurs tests avec VMware avec plusieurs isos de Debian, si le problème est reproductible à chaque fois, alors oui y a un soucis, pourtant j'ai pas bac +50 et je suis pas sys admin, mais juste un peu logique et pas envie de perdre encore + de temps, mais chacun voit midi à sa porte
Quamdiu est spes est, Est vitae.
Fiet in posterum melius
Hors ligne
Hors ligne
ajacss a écrit :Je n'ai aucun moyen de mettre à jour l'OS des systèmes Hôtes car ils ne m'appartiennent pas.
arf !!! très embêtant çà . j'avais cru lire que c'était l'une des rares solutions .
Oui en effet. La personne a qui appartient ces serveurs a trouvé le problème:
Mon Serveur est un HP Gen10, et ESX5.5 ne connais pas le CPU utilisé. Quand tu utilises un Kernel trop récent qui détecte le CPU et éssaie d'en exploiter le maximum des ressources, ESX ne comprend pas les instructions, il ne les connait pas.
En migrant tes VM sur un autre serveur du Vcenter, ça fonctionne.
En solution, je vais passer l'infra ESX en version 6.
Dans un premier temps, j'installe un Vcenter 6.0 pour pouvoir faire cohabiter du 5.5 et du 6.0. Je vais passer les hotes de tes VMs en 6.0, ce qui résoudra ton problème.
Dans un second temps, je passerai tout en 6.7, qui est beaucoup plus stable (le client doit accepter le devis des licences ESX et Acronis pour cette migration)
Dans tous les cas, le passage en 6.0 de tes hotes sera fait aujourd'hui ou demain au plus tard.
Dernière modification par ajacss (26-09-2019 11:53:43)
Hors ligne