Well, a few thing may have changed since the last topic with this name
was closed, but one thing has not: out of the box, the very latest VMware Workstation 17.6.3-24583834 does not work on OpenSuse Leap 15.6.
After an upgrade from 15.5 to 15.6, the old VMware on my laptop (Player 17.5.0) failed to compile its kernel modules due to incompatibilities in the kernel header files. I downloaded and installed the current Workstation instead. This seemed to work in that I could start my virtual machines immediately after the install.
Problem:
After any reboot, however, attempts to start VMware fail - it can’t find /dev/vmmon. Obviously, the VMware kernel modules were not loaded. Loading them manually with modprobe allows VMware to start, but it then crashes when trying to start running a guest OS. I found a partial solution here but manually running vmware-modconfig every time is a bit of a pain - although it may be a viable solution if you really need SecureBoot.
Cause:
I looked around a bit and found that the latest VMware puts it start-up scripts into /etc/init.d instead of doing the right thing and install a service. I consider this a bug (on VMware’s side) since the use of init.d/rc*.d for startup files has been deprecated for well over ten years now. Obviously, Opensuse now ignores them completely.
Workaround:
I copied the files /usr/lib/systemd/system/vmware.service and vmware-USBArbitrator.service from an older installation of VMware into my laptop’s /usr/lib/systemd/system directory and edited the lines with ExecStart= and ExecStop= to point to the actual location of the start scripts so that the /usr/lib/systemd/system/vmware.service file, e.g., now looks like this:
#
# systemd unit file for VMware Workstation kernel modules and virtual
# networking components.
# .
# Copyright (c) 2022 VMware, Inc. All rights reserved.
#
[Unit]
Description=VMware host virtualization and network services for Workstation
Before=multi-user.target
After=network.target
Wants=network.target
[Install]
WantedBy=multi-user.target
[Service]
Type=forking
RemainAfterExit=yes
GuessMainPID=no
IgnoreSIGPIPE=no
ExecStart=/etc/init.d/vmware start
ExecStop=/etc/init.d/vmware stop
After enabling the service (I did it from Yast) and rebooting, VMware now works.
Question:
Is there a better way, or a more “politically correct” way to do this?
Have you installed insserv-compat or systemd-sysvcompat?
zypper if insserv-compat
Loading repository data...
Reading installed packages...
Information for package insserv-compat:
---------------------------------------
Repository : OSS
Name : insserv-compat
Version : 0.1-4.6.1
Arch : noarch
Vendor : SUSE LLC <https://www.suse.com/>
Installed Size : 8,5 KiB
Installed : Yes (automatically)
Status : up-to-date
Source package : insserv-compat-0.1-4.6.1.src
Upstream URL : https://build.opensuse.org/package/show?package=insserv-compat&project=openSUSE%3AFactory
Summary : Simple insserv replacement for systemd only systems
Description :
insserv is used enable System V init scripts. This package only
contains a stub implemenation for use on systemd only systems.
zypper if systemd-sysvcompat
Loading repository data...
Reading installed packages...
Information for package systemd-sysvcompat:
-------------------------------------------
Repository : Update repository with updates from SUSE Linux Enterprise 15
Name : systemd-sysvcompat
Version : 254.24-150600.4.28.1
Arch : x86_64
Vendor : SUSE LLC <https://www.suse.com/>
Installed Size : 72,9 KiB
Installed : Yes
Status : up-to-date
Source package : systemd-254.24-150600.4.28.1.src
Upstream URL : http://www.freedesktop.org/wiki/Software/systemd
Summary : SySV and LSB init script support for systemd (deprecated)
Description :
This package ships the necessary files that enable minimal SysV and LSB init
scripts support in systemd. It also contains the obsolete SysV init tools
telinit(8) and runlevel(8). You should consider using systemctl(1) instead.
Unless you have a 3rd party application installed on your system that still
relies on such scripts, this package should not be needed at all.
Please note that the content of this package is considered as deprecated.
As always, @Sauerland can be relied upon to come up with the correct answer!
Whereas I had been aware of the need for insserv-compat because of this post, I hadn’t realised that there actually is a package providing System V backwards compatibility, i.e. implement the time-honoured runlevels and the /etc/rc.d way of moving between them. (I used to teach this stuff commercially in my Unix System V System Administration course over 35 years ago in the late 1980s!)
Installing systemd-sysvcompat certainly did the trick, and I could remove my hack from /usr/lib/systemd/system/.
One caveat, though: it seems that installing sysvcompat removed the contents of the /etc/init.d/rc?.d directories, including symb-links such as S50vmware that VMware had put there. Needed to re-install VMware to get them back!