Philou44
Enthusiast
Enthusiast

Erreur "Could not open /dev/vmmon: Aucun fichier ou dossier de ce type. Please make sure that the k"

Bonjour à toutes et tous,

Sous Linux OpenSuse Tumbleweed, j'ai une VMWare Player 16.1.1 ...A l'issue de la dernière mise à jour du Kernel j'ai donc une erreur lors du lancement de la MV.

"Could not open /dev/vmmon: Aucun fichier ou dossier de ce type.
Please make sure that the kernel module `vmmon' is loaded"

Notez que le player se lance bien et que je peux aller jusqu'à sélectionner la MV et c'est lors de l'appuie sur "Run" que ça plante.

J'ai cherché et trouvé une solution qui consiste en Root et en console de lancer la commande suivante :

vmware-modconfig --console --install-all

Cependant c'est labile... C'est a dire qu'a chaque redémarrage de la machine il faut retaper cette commande (logique d'après le message d'erreur...)

1 - Je poste d'une part au cas où ça dépannerait quelqu'un dans le même cas.

2 - Je me pose la question : est ce que c'est juste un bug de mise à jour du Kernel ? auquel cas il est juste urgent d'attendre une mise à jour du Kernel .... Ou bien c'est plus emm... et auquel cas il faut signaler ça ...

A vous lire,

Amicalement

Philippe

Vox Clamentis in Deserto
0 Kudos
13 Replies
Philou44
Enthusiast
Enthusiast

Bonjour,

Un petit update...

Je ne sais pas si je suis le seul car il n'y a pas eu d'autre réponses à ma question...

Ceci dit je viens de voir passer 2 mises à jour du Kernel et nous sommes maintenant en 5.12.0-1-default (alors que le phénomène s'est déclaré après passage en 5.11.xxxx)

Bref, tout ça pour dire que malgré l'upgrade du noyau y a toujours l'erreur.

Et je suis toujours obligé de lancer la commande citée dans mon message précédent pour pouvoir ouvrir une MV...

Avez-vous une idée à qui il faut signaler ce problème ?

A vous lire

Philippe

Vox Clamentis in Deserto
0 Kudos
LucMorizur
Contributor
Contributor

Bonjour ;

si l'anglais ne pose pas de problème, la solution est dans le post suivant :

https://kb.vmware.com/s/article/2146460

En gros, il s'agit d'effectuer les manips permettant au BIOS UEFI d'enregistrer les fichiers vmmon.ko et vmnet.ko, qui ne sont pas téléchargées au cours des mises à jour ou installations, mais compilées, comme étant autorisées à être impliquées dans le démarrage d'un système d'exploitation.

Si la procédure en anglais pose un problème, merci de le signaler, je la traduirai.

Philou44
Enthusiast
Enthusiast

Bonjour Luc,

Merci pour votre message.

L'anglais ne devrait pas me poser de problème, j'ai lu et compris la procédure.

Cependant il n'est pas précisé si la manip devrait être refaite à chaque changement du noyaux Linux et/ou à chaque upgrade de la VMware ... Vous avez essayé ?

J'ai une OpenSuse Tumbleweed et du coup les changements de Kernel sont assez fréquent...

Bon, là je sais ... Je fais un peu "Gaulois râleur" alors que vous apportez une solution...

Je plaisante bien évidemment

Merci en tout cas pour l'aide

Bon dimanche

Philippe

Vox Clamentis in Deserto
0 Kudos
LucMorizur
Contributor
Contributor

Bonjour Philou44 ;

ce qui est certain, c'est qu'il faut refaire la manip à chaque upgrade de VMWare — c'est justement ce qu'il vient de m'arriver ; heureusement pour moi ce coup-ci, je me rappelais mieux ce qu'il fallait faire, du coup là je l'ai bien noté, et puis le fait d'avoir posté les messages ici m'aidera le prochain coup.

Pour ce qui est de l'upgrade du noyau Linux, je ne crois pas avoir déjà eu le cas, mais en toute logique ça ne devrait pas influer, dans la mesure où ce sont les fichiers de démarrage de VMWare qui sont concernés.

Philou44
Enthusiast
Enthusiast

Bonjour LucMorizur,

Bon, j'ai essayé mais ça a pas l'air de fonctionner ...

De ce que j'en ai compris il fallait remplacer dans la première commande le terme "MOK" par vmmon (et vmnet sur une deuxième fois)

ici la commande à fonctionné en répondant : "generating RSA ... writing new private key to 'vmmon.priv' " et pareil pour vmnet.

C'est la commande d'après qui échoue lamentablement ...

/usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./vmmon.priv ./vmmon.der $(modinfo -n vmmon)
-bash: /usr/src/linux-headers-5.16.15-1-default/scripts/sign-file: No such file or directory

J'ai testé pour vmnet et c'est pareil...

J'ai testé en laissant le terme MOK et c'est pareil.

Possiblement sur mon système (Opensuse Tumbleweed) les Headers seraient ils pas situés dans un autre répertoire ?

Je vais poser la question sur le forum dédié de TW

En tout cas merci encore pour l'aide

Amicalement

Philippe

Vox Clamentis in Deserto
0 Kudos
LucMorizur
Contributor
Contributor

Bonjour Philou44 ;


De ce que j'en ai compris il fallait remplacer dans la première commande le terme "MOK" par vmmon (et vmnet sur une deuxième fois)

Non, ce n'est pas ça : il faut donner un nom à la place de MOK, n'importe lequel — en fait MOK conviendrait très bien, ou même vmmon.priv et vmmon.der, pourquoi pas.

Et il y a une autre confusion : il n'y a pas à refaire la première opération pour vmnet.

 

Je reprends la procédure en français :

D'abord

 

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VMware/"

 

(On génère les fichiers MOK.priv et MOK.der)

Ensuite

 

sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)

 

Puis

 

sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmnet)

 

(On signe les modules vmmon et vmnet avec les clés générées auparavant, et selon la version de Linux en cours)

Enfin

 

sudo mokutil --import MOK.der

 

(On inscrit la clé MOK.der sur le système afin que les modules vmmon et vmnet soient acceptés, une fois que l'inscription sera validée — dans la procédure d'origine, le "sudo" a été oublié, il est en fait nécessaire, au moins chez moi)

Au redémarrage suivant, le système demandera confirmation de l'inscription de la clé MOK, en demandant le mot de passe fourni lors de la dernière commande. Une fois l'inscription validée, on peut finir de redémarrer le système et — enfin ! — réutiliser VMWare.

Et comme la signature électronique est fonction de la version de Linux, il faut bien, hélas, refaire l'opération à chaque mise à jour de Linux. Lourd !

Voilà, dites-moi si vous y arrivez maintenant.

Bonne chance !

Philou44
Enthusiast
Enthusiast

Bonsoir Lucmorizur,

Toujours la même erreur, j'arrive bien à générer les fichiers MOK.der et MOK.priv mais c'est la commande d'après qui ne passe pas...

sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)
sudo: /usr/src/linux-headers-5.17.1-1-default/scripts/sign-file: command not found

J'ai cette erreur : command not found.

En fait il ne trouve pas linux-headers-...

J'ai essayé dans le sous répertoire /usr/include et dans /usr/include/linux car lorsque je regarde où pourrait être installé ce fichier il m'oriente ici :

Mais c'est la même erreur...

sudo /usr/include/linux/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)
sudo: /usr/include/linux/linux-headers-5.17.1-1-default/scripts/sign-file: command not found

Je n'ai pas encore eu de réponse sur le forum Opensuse...

Merci en tout cas je vous tiens au courant...

Philippe

Vox Clamentis in Deserto
0 Kudos
LucMorizur
Contributor
Contributor

Bonjour Philou44 ;

désolé, j'ai commis la même erreur qui m'énerve toujours à mon boulot de la part des gens à qui je demande de l'aide : je n'ai pas tout bien lu votre message ; j'ai trouvé un élément sur lequel réagir, et j'ai fait abstraction du reste 🙄😪😕...

Oui en effet dès votre précédent message, on voyait que l'instruction sign-file n'était pas trouvée. Il faut donc la chercher ; que donne la commande :

sudo find / -iname "*sign-file*" -type f

?

 

LucMorizur
Contributor
Contributor

(Pour info je ne connais pas du tout openSUSE (et à peine mieux Ubuntu), les choses peuvent donc être bien différentes.)

Philou44
Enthusiast
Enthusiast

Bonjour,

Mais il n'y a aucun problème !

C'est de l'entraide et on fait tous comme on peut en fonction du temps que l'on a ...

Alors effectivement la commande se trouve ici :

/usr/src/linux-5.17.1-1/scripts/sign-file.c

Je vais tester avec la petite modification...

... et je reviens...

Philippe

Vox Clamentis in Deserto
0 Kudos
Philou44
Enthusiast
Enthusiast

Arghhh...

...

Je passe bien grâce à la modification mais la dernière commande me plante encore une erreur ... Un peu irrémédiable...

FIXE-MAISON:~ # /usr/src/linux-5.17.1-1-obj/x86_64/default/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)
FIXE-MAISON:~ # /usr/src/linux-5.17.1-1-obj/x86_64/default/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmnet)
FIXE-MAISON:~ # mokutil --import MOK.der
EFI variables are not supported on this system
FIXE-MAISON:~ # 

**bleep**...

Bon, j'avoue trouver ça bizarre car le Bios est bien en UEFI ...

Pas trop d'idée pour l'instant... Ceci dit merci encore

Philippe

Vox Clamentis in Deserto
0 Kudos
LucMorizur
Contributor
Contributor

Aïe. Ben là, désolé, je n'essaierai pas de vous aider plus avant, car c'est officiellement au-delà de mes compétences 😕...

En cherchant "EFI variables are not supported on this system" sur un moteur de recherches, on trouve des choses, mais les solutions proposées mettent en œuvre des moyens que je ne maîtrise pas, je préfère ne pas me prononcer. À voir les réponses données sur un forum spécifique openSUSE, sur ce point en particulier.

Une ultime remarque 😉 tout de même :


Bon, j'avoue trouver ça bizarre car le Bios est bien en UEFI ...

Oui, mais sur certains PC, on peut démarrer en "legacy" même si le BIOS est en (U)EFI, attention donc à ce que ce ne soit pas le cas. Si le PC permet d'utiliser les deux modes, il existe des commandes pour vérifier dans quel mode la session actuelle a été démarrée. Je vous laisse là aussi trouver le moyen qui correspondra le mieux à votre système — pour autant qu'il y ait besoin de le faire. (C'est peut-être idiot ce que je dis là, car a priori si le PC est démarré en mode legacy, alors pourquoi VMWare poserait problème au démarrage...)

Désolé, et bonne chance !

Philou44
Enthusiast
Enthusiast

Merci quand même !

En même temps c'est juste inconfortable... Je vais continuer comme je faisais avant.

Amicalement et bonne fin de WE

Philippe

Vox Clamentis in Deserto
0 Kudos