The fix I used to do isn't working anymore: could not open /dev/vmmon: no such file or directory.

[xphinx]

Hi, every time there's an update in the Ubuntu's kernel I have this problem because of secure boot on Ubuntu 22.04.2.
I'm using: VMware® Workstation 17 Pro. Version: 17.0.0 build-20800274.

I used to do these steps: https://kb.vmware.com/s/article/2146460 and used to work every time but isn't working anymore.

I'm having this issue: could not open /dev/vmmon: no such file or directory. Please make sure that the kernel module 'vmmon' is loaded.

Some errors I see in the logs:

2023-06-29T02:44:07.522Z In(05) vmui VmdbPipeStreamsOvlError Couldn't read: OVL_STATUS_EOF (remote disconnect)
2023-06-29T02:44:07.522Z In(05) vmui VmdbCnxDisconnect: Disconnect: closed pipe for sub cnx '/db/connection/#2c/' (-32)
2023-06-29T02:44:07.524Z In(05) vmui VigorOnlineCnxDemux: VmdbCnx failed: Lost a connection to the running VMX instance.
2023-06-29T02:44:07.524Z In(05)+ vmui Transport (VMDB) error -32: Pipe: Read failed.

2023-06-29T02:44:07.612Z In(05) vmui vm power operation abort, error = Transport (VMDB) error -14: Pipe connection has been broken.

Please help.

[bluefirestorm]

What about the error message(s) in the process of signing the modules/enrolling the keys to the TPM chip?

There is a finite amount of storage in the TPM chip. My best guess is the new .der file is not getting enrolled/stored into the TPM chip.

You would likely have to delete the old .der stored in the TPM chip. If you don't have the previous .der files you can generate them

mokutil --export

It will generate MOK-0001.der through to MOK-00nn.der, however many are stored.

You delete them, for example

mokutil --delete MOK-0028.der

and then reboot to complete the deletion process.

Note that MOK-0001.der is likely a Canonical certificate (not the VMware certificates generated to sign vmmon/vmmnet). You should check the .der file whether it is one from VMware signing process (assuming you put CN=VMware, you can view them from View File by right clicking on the .der file from Nautilus Files and view file) before deleting from the TPM chip using the mokutil.

[xphinx]

Thank you so much for replying.

I don't get any error messages in the process of signing the modules/enrolling the keys to the TPM chip.

I did: sudo mokutil --list-enrolled and I found 14 keys with: Subject: CN=VMware. Including the most recent enrolled keys from yesterday.

So, Do I have to delete all these keys first? if that is the case, should I use: sudo mokutil --revoke-delete

How should I type the name of each key? because when I enrolled them I used the same: MOK-001.der every time and  I don't see the name of the key on the list unless is: [key 3], [key 4] and so on?

After deleting all these keys and restart, should I go on with the process from the link above and generate a new key pair and do the rest of the steps?

All this time I've been going to the Nautilus Files and literally deleting the .priv and .der keys and emptying the trash bin every time, before generating new ones after the kernel update because I was getting errors with the new enrollments if not.

[bluefirestorm]

To delete the certificate from the TPM chip, the generated .der will need to be used. But since you delete them after every enrollment, the way to recover it is use the --export option. As you said you have 14 VMware certs, most likely the output files will be MOK-0001.der to MOK-0015.der (assuming MOK-0001.der is the one from Canonical and 2-15 are the generated .der for VMware) in the directory where you run the mokutil --export.

I haven't tried using --revoke-delete; I simply use the --delete option of mokutil and reboot.

Let's say you deleted MOK-0010.der and MOK-0011.der, next time you --export you should see only up to MOK-0013.der now (although 14 and 15 files will still be there if you don't delete them). Make sure you don't mokutil --delete the Canonical (or any other non-VMware secure boot generated certifcates); this is where the View File from Nautilus File will hep you determine whether you can delete the .der from the TPM.

FWIW, I run Workstation Pro 16.2.5 on Ubuntu 22.04 with kernel 5.19.0-45-generic; secure boot enabled. It works fine and only two der are output (one from Canonical and the other is the current .der signed for the current kernel build).

Have a look at this thread, I try to explain how I maintain the TPM certificates after every kernel updates.
https://communities.vmware.com/t5/VMware-Workstation-Pro/Ubantu-22-04-2-on-Dell-XPS-intel-12th-gen-s...