VMware Communities
ekki
Contributor
Contributor
Jump to solution

VMware Worstation Pro 15.5.6 on OpenSuSE Leap 15.2; compiling modules

Hello,

I used VMware Workstation 15.1.0 in leap 15.1 for quite a while. Then I made the system upgrate to leap 15.2 (Kernel Version 5.3.18-lp152.41). But when I tried to start vmware Worstation I got the message "Could not open /dev/vmmon: file or filder not found. Please make sure that the kernel module `vmmon` is loaded.
I though "OK this is the usual pain with new kernels", I only have to get them from https://github.com/mkubecek/vmware-host-modules compile them I can go on.

But this was not the case. The compiling process does not show any problems, except the last lines where the modules are started, Two of them failed. See also the attached output of the modconfig command.
Then I noticed that I didn't use the most recent vmware worstation version. So I updated to the version 15.5.6 and tried the same process again. Certainly with the approptiate module sources from mkubecek. But without success. The error messages are still the same. modconfig installer output still shows no succes in activating two modules and also when starting a virtual machine the error message: "Could not open /dev/vmmon: file or folder not found....." persists.
Are there any others with that problem or ideas where I make a mistake?
Ekki

1 Solution

Accepted Solutions
bluefirestorm
Champion
Champion
Jump to solution

Do you have secure boot enabled on the openSUSE host? The vmmon and vmnet modules needs to be signed and its key enrolled if secure boot is enabled on the host.

My Ubuntu 18.04 host has secure boot enabled and every time new builds are done on the vmmon and vmnet, I have the re-enroll the secure boot keys.

Have a look at the following so something similar needs to be done on your host

https://askubuntu.com/questions/1096052/vmware-15-error-on-ubuntu-18-4-could-not-open-dev-vmmon-no-s...

View solution in original post

13 Replies
bluefirestorm
Champion
Champion
Jump to solution

Do you have secure boot enabled on the openSUSE host? The vmmon and vmnet modules needs to be signed and its key enrolled if secure boot is enabled on the host.

My Ubuntu 18.04 host has secure boot enabled and every time new builds are done on the vmmon and vmnet, I have the re-enroll the secure boot keys.

Have a look at the following so something similar needs to be done on your host

https://askubuntu.com/questions/1096052/vmware-15-error-on-ubuntu-18-4-could-not-open-dev-vmmon-no-s...

ekki
Contributor
Contributor
Jump to solution

Hello bluefirestorn,

thanks for your hint. I indeed had to tailor the commands to the opensuse system a bit but now it runs again.

Thanks very much.

ekki

Reply
0 Kudos
smudgy
Contributor
Contributor
Jump to solution

Ekki

Could you not have included details of your tailoring in your 'thank you for the benefit of other OpenSUSE users in the same situation? Otherwise you are just freeriding on those who do share solutions, even if unintentionally. Very annoying.

The best 'thank you' someone can offer is to observe the convention of detailing their solution, even if only 'tailoring'. Potentially many people just like me are hunting for this solution and might be wondering what on earth you meant by 'tailoring' exactly! 

In the meantime, in the absence of that info I found this VMWare article on this issue which might be useful for anyone also stumbling on this thread looking for the same solution.

<"Cannot open /dev/vmmon: No such file or directory" error when powering on a VM (2146460)

Steps to sign VMware drivers on Linux host with secure boot enabled, so that VMware Workstation can run VMs successfully.>

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

Reply
0 Kudos
smudgy
Contributor
Contributor
Jump to solution

Going round and round in circles here. Installed the C++ development and kernel development packages (and increased the size of my root filesystem) but am stuck at trying to get sign-file to execute. The output is 'command not found'

 

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

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

 

In terms of 'tailoring' I should note OpenSUSE required the absolute path /sbin/modinfo in the previous line to generate the key pair.

but in terms of signing  the modules this is the tailored version to narrow down the errors been thrown

 

sudo  /usr/src/linux-5.3.18-lp152.57/scripts/sign-file sha256 ./vmplayer.priv ./vmplayer.der $(/sbin/modinfo -n vmmon)

# Output = sudo: /usr/src/linux-5.3.18-lp152.57/scripts/sign-file: command not found

 

Trying to use linux-headers-$(uname -r) (or with even worse results 'uname -r') suffixed 'default' in the string passed and reported there was no such file or directory. Calling sign-file through the actual known directory path seems to have at least narrowed it down to not executing the sign-file program. Linux can't find the command but it has located the program file.

 

As you can see I am by no means an experienced or professional tailor and would appreciate if an OpenSUSE user has solved this they could be so kind as to divulge the solution they found!

Reply
0 Kudos
mkubecek
Hot Shot
Hot Shot
Jump to solution

The sign-file binary should be in *-obj dir, in your case

 

/usr/src/linux-5.3.18-lp152.57-obj/default/scripts/sign-file

 

(replace "default" with "preempt" if you are using preempt flavor). A more general and reliable approach would be using

 

/lib/modules/$(uname -r)/build/scripts/sign-file

 

smudgy
Contributor
Contributor
Jump to solution

Worked a treat. Had to check the directory structure for the first method and found default to be nested in x86_64.

 

sudo  /usr/src/linux-5.3.18-lp152.57-obj/x86_64/default/scripts/sign-file sha256 ./vmplayer.priv ./vmplayer.der $(/sbin/modinfo -n vmmon)

 

I still haven't figured out why kernel-headers wasn't working or whether I needed kernel-source etc but that's another matter. Used your second method with vmmon and that worked immediately as is. And has the advantage of being able to be run in a tiny script (sudo) for when the kernel is updated and the modules need to be re-signed. 

 

sudo  /lib/modules/$(uname -r)/build/scripts/sign-file sha256 ./vmplayer.priv ./vmplayer.der $(/sbin/modinfo -n vmnet)

 

👍👍👍  a better method, as you said

Have been testing out the vm programs and VMWare is easily the best imo, but signing the modules (on top of running the installation script itself) would put most untutored OpenSUSE users off, which is a shame I reckon. So I hope this thread helps for anyone finding problems implementing for OpenSUSE the solution described generally in https://kb.vmware.com/s/article/2146460 

Just to round it off and import the key for enrolling at the next secure boot

 

sudo mokutil --import vmplayer.der

 

No errors and I assume the reboot will proceed as expected as per the KB article.

I haven't yet said thanks a million mkubecek so you have it   😀

 

Reply
0 Kudos
smudgy
Contributor
Contributor
Jump to solution

Thanks for this. Using your tips I can get the sign-file binary to run and the process of stepping through the commands goes without error. I began from fresh with a new key vmware.der etc as follows

 

sudo openssl req -new -x509 -newkey rsa:2048 -keyout vmware.priv -outform DER -out vmware.der -nodes -days 36500 -subj "/CN=VMware/"
sudo  /lib/modules/$(uname -r)/build/scripts/sign-file sha256 ./vmware.priv ./vmware.der $(/sbin/modinfo -n vmmon)
sudo  /lib/modules/$(uname -r)/build/scripts/sign-file sha256 ./vmware.priv ./vmware.der $(/sbin/modinfo -n vmnet)
sudo mokutil --import vmware.der

 

 

When I rebooted I enrolled the hash using the first option if I recall and also inspected the key. There were options to enroll from a file but I don't know where the file is and the first option has worked before.

However on completing the reboot nothing had changed and the modules were not loaded. Am wondering if I should have turned off secure boot before running all the commands? Or what else could be missing. Feel I'm nearly there as your instructions worked fine for locating and executing sign-file binary.

Reply
0 Kudos
mkubecek
Hot Shot
Hot Shot
Jump to solution

This could be caused by a recent change which requires the key used to sign kernel and modules to have code signing extended key usage, see e.g. https://bugzilla.suse.com/show_bug.cgi?id=1178813

smudgy
Contributor
Contributor
Jump to solution

Worked a treat (for some reason my replies are disappearing unless I add them twice) so thanks again! 

The bugzilla post essentially specified appending -addext "extendedKeyUsage=codeSigning" so I generated (another) key with a new 

 

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

 

 Then passed the new name with the correct code as above

 

sudo  /lib/modules/$(uname -r)/build/scripts/sign-file sha256 ./vmware.priv ./vmware.der $(/sbin/modinfo -n vmmon)
sudo  /lib/modules/$(uname -r)/build/scripts/sign-file sha256 ./vmware.priv ./vmware.der $(/sbin/modinfo -n vmnet)
sudo mokutil --import vmware.der

 

 

And that was it. 👍

(Deleting the redundant mok keys is not so apparent, maybe only one deletion per boot is allowed, but either way this is a great result and I even managed to sync my treasured Palm Pilot in the VM 😀)

Thanks again

smudgy
Contributor
Contributor
Jump to solution

AFTER A KERNEL UPDATE >>> ReSigning the Modules VMMON and VMNET

Updated successfully after the kernel was updated. But not without a hitch which can be eliminated as follows:

For an easy error-free update VMWare Player or Workstation must be started before attempting to resign the modules for the new kernel. The program automatically detects that the modules VMMON and VMNET have to be rebuilt for the updated kernel and then does so.

(In my case this happened despite generating errors saying it had failed and directing me to a tmp logfile  /tmp/vmware-*/vmware-24004.log

However sudo modinfo -n vmmon confirmed the modules had to the contrary been successfully rebuilt. This time running the command sequence for resigning and generating the mok was error free).

Rebooted and successfully enrolled key. VMWare started and loaded guest OS immediately

NB: To get the kernel-headers on OpenSUSE you don't need all the kernel-source which is a very large file. linux-glibc-devel supplies kernel-headers in a much smaller file.

https://pkgs.org/download/kernel-headers 

Reply
0 Kudos
mkubecek
Hot Shot
Hot Shot
Jump to solution

linux-glibc-devel is a package with kernel related headers for building userspace applications. To build out of tree kernel modules, you should install kernel-devel and kernel-default-devel (or kernel-preempt-devel, depending on which flavor you are using).

JoeSalmeri
Contributor
Contributor
Jump to solution

Those steps no longer work with VMWorkstation Player 17.0.0 and Linux kernel 6.2.1 on Tumbleweed.

Creating the keys, signing vmmon and vmnet, importing the der file, rebooting, and enrolling key all work fine, however, after you reboot the modules still cannot be loaded.

localhost:~ # modprobe vmmon
modprobe: ERROR: could not insert 'vmmon': Operation not permitted
localhost:~ # modprobe vmnet
modprobe: ERROR: could not insert 'vmnet': Operation not permitted

journalctl

Mar 08 11:18:11 localhost.localdomain kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
Mar 08 11:18:14 localhost.localdomain kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7

So the kernel is complaining that the modules are not signed but modinfo on vmmon and vmnet shows that they are signed by the key generated.

Any thoughts on how to resolve this now ?

 

 

 

Reply
0 Kudos
gschu
Contributor
Contributor
Jump to solution

This is a new phenomen on TW. With kernel 6.2.1 they have build in a kernel lockdown patchset. And sadly in a way that MOK (user) keys are not used anymore to verify the signed modules. 


This has been discussed  the last few days in the openSUSE mailing list and ob openSUSE bugzilla.  Sorry from here where I write this I do not have the links available. So you have to search yourself.

 

If I read it all right the current plan is to revert this lockdown patch and go back to the signature validation procedure as before. This should happen with the next TW kernel update.

 

Reply
0 Kudos