KDE ISO 21.1 RC 2 gets stuck on boot (VMWare VM)

[cfinnberg]

The latest KDE ISO 21.1 RC2 (manjaro-kde-21.1-210723-linux513.iso) has a bug where it gets stuck during boot in a MHWD script in a VMWare Virtual Machine (it works fine in a Virtualbox VM)

I know VMWare is an unsupported platform, but just in case it has an easy solution, because RC1 (manjaro-kde-21.1-stable-staging-minimal-210720-linux513.iso) works fine in the same virtual machine.

[philmmanjaro]

We had an issue with VirtualBox config, which hopefully is solved by now. However, we have to see about VMWare once, more, which uses the same config.

[philmmanjaro]

There is a workaround to skip mhwd by adding xdriver=vesa to the kernel cmd line via e + ctrl+x after editing. For some reason the mhwd-script has an issue with installing the driver. So we have to see what blocks it. Tested with vmware-workstation 16.1.2-3 from AUR.

[cfinnberg]

With the xdriver=vesa option, it passes the mhwd script step, but it gets stuck at "Reached target Graphical Interface". I'm testing in VMWare Workstation 16.1.2 on Windows.

[philmmanjaro]

Well it works on the Manjaro host just fine. Also the script mhwd-live calls mhwd correctly. So this issue is odd. Will test with an updated version of that config ...

[cfinnberg]

I tried also in my Manjaro host and I get same result than in Windows. Odd.

I have been using UEFI in my VMs. Tried with BIOS and the only difference is that I get a black screen when it reaches graphical target (Both Linux and Windows hosts)

[philmmanjaro]

I've tested it now with the latest build shipping updated configs for VMWARE. Seems to work now: https://github.com/manjaro-gnome/download/releases/tag/202107241106. Download one of the unstable ISOs. I tested gnome minimal.

[cfinnberg]

Tried manjaro-gnome-21.07-development-unstable-210724-linux510.iso file. Seems to work both in Linux and Windows. One thing I have noticed though is that open-vm-tools is not installed in the liveUSB and doesn't get installed after the installation. In RC1 or RC2, that was not an issue. Maybe that's expected because this ISO has older configs, but just you know.

[philmmanjaro]

I'm currently testing this build. I missed a package so the config was skipped and no driver installed.

[cfinnberg]

This build has the same problem that the RC2. It gets stuck in mhwd script. If I add the xdriver=vesa parameter, then it boots, but still no open-vm-tools in the live system.

[philmmanjaro]

Well if I use xdriver=vesa and modify the script /usr/bin/mhwd-live to not check for the xdriver value it runs thru and the driver got installed. However it simply hangs when you do it on the bootup. Will try now one of the Garuda ISOs, which is using mwhd also.

[philmmanjaro]

same hanging ...

[philmmanjaro]

I might be on something: https://github.com/vmware/photon/blob/master/SPECS/open-vm-tools/vmtoolsd.service#L15 Since multi-user.target is not reached, enabling vmtoolsd might create the block when also trying to start it.

[cfinnberg]

But in this case WantedBy means that when isolating multi-user.target it should start vmtoolsd, but not the other way around, isn't it? If we start vmtoolsd in other target, it should still work AFAIK.

I tested your latest build (unstable) and it's clear that vmtoolsd service is the key (system boots fine, vmtoolsd is enabled but not started). But is it really because of the WantedBy or is it something else?

[philmmanjaro]

Well, latest build works. So it confirms my Theory. Since the mhwd-live.service runs with graphical.target it can't start services with multi-user.wants targets. Let's see how Garuda will solve it.

[philmmanjaro]

seems we start it on our end before a user session gets enabled. So in the end it is tricky, as the timing of the two services is off and therefore the lockdown caused by wanted-by

[philmmanjaro]

let's see if mhwd-db-0.6.5-13 fixes it by passing --no-block ...

[cfinnberg]

I think it should work. My theory is that the After=display-manager.service in vmtoolsd.service is the one that is blocking the whole thing. As display-manager is also scheduled to start (due to the graphical target) vmtoolsd wants to wait for it because of the After=. But as we are starting vmtoolsd in synchronous way, display-manager (or any other unit) can't start before vmtoolsd is started.
I'm confident that --no-block is going to solve the thing, as now even if vmtoolsd waits for display-manager, the boot process don't need to wait for it and can continue starting other units. When display-manager starts, then vmtoolsd will be started too.

[boredland]

closing for being ages old.