Mouse do not work in the workstation after the update of today.
It is broken in live and persistent mode for both user and sysmaint. In the gateway VM it works
The Whonix VirtualBox version is functional.
I am not a maintainer of Whonix KVM and not testing that.
New kloak version was in testers repository for 2 weeks or longer. Seems like we don’t have any KVM testers (using testers repository).
About this KVM Page
Contributor maintained wiki page.
Support Status: stable
Difficulty: medium
Contributor: @HulaHoop
Support: Community support only!
Should we downgrade Whonix KVM support status to unsupported? @HulaHoop
Are you able to get logs from kloak? Try booting into sysmaint mode, then press Ctrl+Alt+T, then run sudo systemctl stop kloak.service - does this give you control of your mouse again? Then run sudo journalctl --boot -u kloak.service and share the output here.
1 Like
My mouse is broken in persistent mode for the Workstation but works in persistent sysmaint. The issues started after updating workstation.
Running sudo journalctl --boot -u kloak.service produces:
systemd[1]: Starting kloak.service - kloak anti keystroke deanonymization tool
systemd[1]: Started kloak.service - kloak anti keystroke deanonymization tool
systemd[1]: Stopping kloak.service - kloak anti keystroke deanonymization tool
systemd[1]: kloak.service: Deactivated successfully
systemd[1]: Stopped kloak.service - kloak anti keystroke deanonymization tool
The issue still persists.
1 Like
It do not work in persistent/live sysmaint/user for me. kloak is not the issue. I disabled it and the issue persists.
Mouse and keyboard work at the login screen. The mouse, keyboard and “Send Key” breaks after a successful or wrong login.
KVM getting unsupported sounds like a very sad decision
I can’t start terminal after login and look for errors. When I login without GUI everything works. It breaks once I start the desktop interface
Lack of contributors.
OK, log in to a sysmaint session without GUI and try sudo journalctl --boot=-0 -u kloak.service and type any error messages you see here. (Type them verbatim if possible, since that makes it easier to debug.)
1 Like
Actually it is greetd hanging, not the desktop. Disabling kloak has no effect as mentioned by @skh. It blocks all input devices including the keyboard. The workaround is to enable auto-login. If you enable autologin and logout, greetd will immediately hang. The log comes from this case. So greetd hangs when:
- Logging in successfully
- Logging in unsuccessfully
- Logging out after autologin
Here is the journalctl log. Note that it is not stopped, because no console can be reached via Ctrl+Alt+Fn and the system does not react to ACPI signals (shutdown/reset) for regular shutdown, however, the system keeps running after successful logins, since notifications (resize) are still shown.
Apr 03 23:00:16 host systemd[1]: greetd.service - Greeter daemon was skipped because of an unmet condition check (ConditionPathExists=!/run/rads/rads-block-display-manger-startup.status).
Apr 03 23:00:17 host systemd[1]: Started greetd.service - Greeter daemon.
Apr 03 23:00:17 host greetd[1623]: pam_unix(greetd:session): session opened for user user(uid=1000) by user(uid=0)
Apr 03 23:00:17 host greetd[1623]: pam_succeed_if(greetd:session): requirement "uid eq 0" not met by user "user"
Apr 03 23:00:17 host greetd[1623]: pam_succeed_if(greetd:session): requirement "uid ne 0" was met by user "user"
2 Likes
I am also experiencing this issue on virtualbox. The workstation completely hangs and I have to force quit the machine.
2 Likes
Yes, I have also just finished the Virtualbox setup and reproduced it there as well. Can confirm the issue on both virtualization types.
2 Likes
Found a significant difference between the VM images. Gateway does work in KVM/Virtualbox as mentioned, but Workstation is broken.
When restarting greetd the active session can not be found according to spice-vdagentd.service. This might be related to the loss of input, although vdagent should not be keyboard related, but maybe the VM loses focus or similar. I could not find any configuration difference unfortunately.
Here is the log:
Apr 04 11:19:54 host systemd[1]: Starting spice-vdagentd.service - Agent daemon for Spice guests...
â–‘â–‘ Subject: A start job for unit spice-vdagentd.service has begun execution
â–‘â–‘ Defined-By: systemd
â–‘â–‘ Support: https://www.debian.org/support
â–‘â–‘
â–‘â–‘ A start job for unit spice-vdagentd.service has begun execution.
â–‘â–‘
â–‘â–‘ The job identifier is 254.
Apr 04 11:19:54 host (vdagentd)[1259]: spice-vdagentd.service: Referenced but unset environment variable evaluates to an empty string: SPICE_VDAGENTD_EXTRA_ARGS
Apr 04 11:19:54 host systemd[1]: Started spice-vdagentd.service - Agent daemon for Spice guests.
â–‘â–‘ Subject: A start job for unit spice-vdagentd.service has finished successfully
â–‘â–‘ Defined-By: systemd
â–‘â–‘ Support: https://www.debian.org/support
â–‘â–‘
â–‘â–‘ A start job for unit spice-vdagentd.service has finished successfully.
â–‘â–‘
â–‘â–‘ The job identifier is 254.
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:48 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:49 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:28:49 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:31:45 host spice-vdagentd[1289]: Error getting active session: No data available
Apr 04 11:31:45 host spice-vdagentd[1289]: Error getting active session: No data available
2 Likes
Nailed it down. Took a lot of hit and miss. It is the autologin! I had it disabled on both the gateway and the workstation. Gateway runs fine. Workstation did not. I run them with the split sysmaint disabled. When I reinstalled the workstation, I left it alone. Ran the updates, verified it ran correctly. It did. Then changed password, still ran correctly. Next, I disabled autologin. BAM! Loads the machine but nothing is selectable. Rebooted back to the sysmaint, enabled autologin, rebooted, and works fine. Hope this helps!
2 Likes
Ahhh, now that you say that I know exactly why that happens. Kloak is starting while the login screen is visible, and attaches to the login screen’s Wayland compositor. When you log in, a new Wayland compositor is started, and Kloak isn’t attached to it, and so all your keyboard and mouse input silently fails. If that happens, you can press Right Shift + Escape to restart Kloak; it will then attach to the running session’s compositor and everything should work again.
This is something we should fix, I will see if I can make a fix for it (probably we need to restart Kloak as part of the login procedure).
1 Like
Confirmed this works!
3 Likes
The actual fix ended up being to restart Kloak if the Wayland compositor dies. This way if Kloak connects to the compositor that presents the login screen, it restarts when the login screen exits and the session starts. I also fixed some other issues and documentation while I was there. Fix submitted:
1 Like
sudo systemctl disable kloak.service doesn’t fully work to disable Kloak, at least not in the sysmaint session, because sysmaint-boot.service contains the line Wants=kloak.service. So this is most likely Kloak’s fault, even if it happens after having “disabled” it.
1 Like
This is not isolated to KVM, as I am running VirtualBox. I neglected to mention that in my initial post.
3 Likes
You are of course right. Kloak still starts. As a temporary test I disabled x permission for /usr/bin/kloak and it works. But since you already have a fix, this should fix it for both KVM and Virtualbox, because both were affected as already mentioned.
2 Likes