Open ErikSchutte opened 1 year ago
@ErikSchutte : thanks for the workaround, it helped me very much.
Since the described command is suddenly broken (–
instead of --
for the command arguments) here the command with working parameters:
kwriteconfig5 --file startkderc --group General --key systemdBoot false
@ErikSchutte : thanks for the workaround, it helped me very much. Since the described command is suddenly broken (
–
instead of--
for the command arguments) here the command with working parameters:kwriteconfig5 --file startkderc --group General --key systemdBoot false
this one workaround worked for me, thanks
Really nice report!
Instead of disabling the systemd boot default KDE Plasma now uses, a better workaround has been found:
https://github.com/vmware/open-vm-tools/issues/568#issuecomment-1577875270
It should work for everyone I think, if not it would be good to know. Fixing the systemd service would be more reliable to contribute as a fix, than the workaround with kwriteconfig5
proposed here.
So just run kwriteconfig5 --file startkderc --group General --key systemdBoot false
in the vm or in the host SO?
So just run
kwriteconfig5 --file startkderc --group General --key systemdBoot false
in the vm or in the host SO?
Inside the VM. Good luck!
@tommdq you should not need to do that if you have systemd v254 (released July 2023, may not be available in non-rolling distros yet) in the VM? (or when you eventually do with an update/upgrade, that workaround shouldn't be necessary)
There are other workarounds available for older systemd versions, you just need to make a small override via drop-in to the systemd service (as referenced by my prior comment).
@tommdq you should not need to do that if you have systemd v254 (released July 2023, may not be available in non-rolling distros yet) in the VM? (or when you eventually do with an update/upgrade, that workaround shouldn't be necessary)
There are other workarounds available for older systemd versions, you just need to make a small override via drop-in to the systemd service (as referenced by my prior comment).
I'm using Parrot OS and have 525.5-2~bpo11+1 systemd. I read your comment but don't quite understand if that's just for Kubuntu or if it also works for Parrot
Thank you in advance for your help!
I'm using Parrot OS and have 525.5-2~bpo11+1 systemd.
v254 was released at the end of July, v525 isn't released yet... so not sure why your OS would already have that, maybe a typo on your end?
I read your comment but don't quite understand if that's just for Kubuntu or if it also works for Parrot
It should be for any distro using systemd. v254 fixes the issue when your OS is using systemd-xdg-autostart-generator
. I only know of KDE Plasma using that, but other DE might as well? 🤷♂️
Just installed KDE on RHEL 9 -- this procedure saved me. Thanks. FWIW -- RHEL9 is running systemd v252
I'm unable to get fully working clipboard in KDE under Wayland. Tried any possible workaround but not possible. Clipboard between host <-> guest works only on Non-KDE native apps, like Firefox.
Clipboard between host <-> guest doesn't work from KDE native apps, like Terminal, Dolphin, Kate, etc. Really frustrating that this bug exists for so many years.
VMware Player 17.5.0 Debian 12 KDE: 5.27.5 Framework 5.103.0 QT: 5.15.8
Opensuse 15.5 - here clipboard even doesn't work from Non-KDE apps. KDE: 5.27.9 Framework 5.103.0 QT: 5.15.8 Kernel: 5.14.21
Describe the bug
Copy and pasting, drag and drop, from host to guest, does not work through shortcuts.
In this scenario you can copy, and go to VMWare > Edit > Paste but cannot use the shortcuts to do so. Though this is not a direct open-vm-tools bug I wanted to post this here as I myself landed here first when googling for a solution.
Figuring out what was going on took me some hours today so hopefully this effort will safe others time.
TLDR; A very very long story short, run “kwriteconfig5 –file startkderc –group General –key systemdBoot false” and reboot your VM.
EDIT: Apologies for the images, they are being cropped when I upload them.
Make sure you have the ‘open-vm-tools’ & ‘open-vm-tools-desktop’ installed on your guest vm and that these services are running!![image](https://user-images.githubusercontent.com/22166523/204785799-59d5d163-7892-4991-bd70-2eb83800aa75.png)
Check that these boxes are checked and greyed-out.
EDIT: command here is "ps -aef | grep vmtoolsd"
“vmtoolsd” is the system service process “vmtoolsd -n vmusr” is the graphical desktop user which vmtoolsd process uses for interactions such as copy and paste or drag and drop. This process was not running in my case -> Read on at 4 on how to address this.
In my case there is a “—blockFd 3” argument which hints at your graphical client being Xorg/X11. If this is “—uinputFd=4” this hints at your graphical client being Wayland. Wayland has lots of issues with copy and paste & drag and drop within VMWare. Consider switching graphical client on the login screen of your vm.
EDIT: images are cropped -> basically on the login screen you'll be able to switch between Xorg/X11 or Wayland.
Reproduction steps
Expected behavior
Running vmware-user to interact with graphical shell and allow copy pasting and dragging and dropping.
Additional context