With linux 4.17 and VirtualBox 5.2.12, vboxguest must be blacklisted -> works with 4.17.4

[FredBezies]

I'm using VirtualBox 5.2.12 on my Archlinux host.

I noticed that linux guest distributions - at least Archlinux based ones - with a desktop environment are broken with a kernel 4.17.x.

Mouse focus is not shown and you cannot grab any opened window. I saw this on pure Archlinux with KDE, SwagArch with Xfce.

When moving to 4.14 LTS kernel, everything works back.

I found this thread on virtualbox.org with the same problem: ​https://forums.virtualbox.org/viewtopic.php?f=3&t=88372

I tried to blacklist vboxguest module while running linux 4.17.x, and everything works again.

Looks like vboxguest code is not 100% compatible with linux 4.17.x.

[FredBezies]

Tested with last OpenSuSE Tumbleweed KDE which uses linux 4.17.1 and it is broken. There is really a bug between linux 4.17.x and vboxguest code.

[Socratis]

Did you see the workaround in the forum discussion, the one that you linked? To open a new TTY and switch back? Which (I'm not sure) might prove that this is not actually a kernel issue, but a window manager?

I had a report from another user (over IRC), where they updated an Ubuntu 16.04 guest to kernel 4.17 with no problems at all.

And since the kernel is brand new, I would also try the latest test builds.

[FredBezies]

Replying to socratis:

Did you see the workaround in the forum discussion, the one that you linked? To open a new TTY and switch back? Which (I'm not sure) might prove that this is not actually a kernel issue, but a window manager?

I saw this bug with both xfce and Plasma. Not a windows manager bug. An Xorg 1.20 one, maybe?

I had a report from another user (over IRC), where they updated an Ubuntu 16.04 guest to kernel 4.17 with no problems at all.

Ubuntu 16.04 is an old version. What about 18.04?

And since the kernel is brand new, I would also try the latest test builds.

Will try asap.

[FredBezies]

Well, this bug is also found and reproducible with this build: 5.2.x revision 122890

Only thing that works? Blacklisting vboxguest module. Can reproduce this bug with OpenSuSE Tumbleweed KDE -> linux 4.17.1 and Xorg 1.19.x.

Switching between tty and GUI doesn't change a thing. It stinks like a bug with both xorg 1.19/1.20 and linux 4.17.x.

[FredBezies]

Still broken in build 5.2.x revision 123115. One click on an icon, and focus is lost. Only "fix" with linux 4.17.2 and xorg 1.19/1.20? Blacklist vboxguest module.

[FredBezies]

Still broken in build 5.2.x revision 123149. Annoying. Maybe in next build?

[drankinatty]

I can confirm this behavior. After update on Archlinux to Linux 4.17, libinput-1.11.1 and xorg-server-1.20.0, all left-mouse input to Linux guests broke.

Today on Archlinux, upgrading to libinput-1.11.1-2 and xorg-server-1.20.0-9 does not fix the problem. After upgrading both Arch host and Arch guest, the problem remains.

There is no left-mouse input on virtualbox when accessing arch guests over rdesktop. Moreover, it is like the cursor position doesn't even register anymore. Moving the mouse over the desktop menu brought up by right-mouse click does not even highlight menu entries anymore, and focus-follows-mouse (doesn't).

All guests run on an Archlinux host on my LAN. Guests are started --headless and accessed via rdesktop. All Linux guests no longer respond to left-mouse input. Win7 guests continue to function normally.

Prior to this SNAFU, this setup had worked flawlessly for years.

See: ​https://bugs.archlinux.org/task/59091

[burdi01]

Apropos rdesktop: accessing such a (semi-) frozen VM via VNC does not show the problem. :D

[nixuser]

I can confirm this behavior on Windows 7 and Windows 8.1 hosts and Fedora 28 guests. Latest Fedora updates (to kernel 4.17.2) have killed the mouse in Xfce. Booting the previous kernel 4.16.16 fixes the issue.

[hotjava1231]

I can confirm this, too. Using LXDE as desktop environment.

VirtualBox VM 5.2.13 r123149.

[burdi01]

Kernel 4.17.3: the problem still exists ... :D

[Yaroslav]

Confirming this for Fedora 28 (kernel 4.17.2) and i3-gaps WM with VirtualBox-5.2.13 r123149

[chahuistle]

Can replicate.

• Host OS: Win 10
• Guest OS: Fedora Workstation 28
• Linux Kernel: 4.17.2-200.fc28.x86_64
• VirtualBox: 5.2.12 r122591

[c-xc-c]

I found an alternative workaround to blacklisting the module.

Note, I do not use a login manager - I start X manually.

1. Boot VM
2. Login to user session.
3. StartX
4. Problem with mouse input events occurs
5. Stop X
6. Adjust settings in Devices->Shared Clipboard
7. You can switch to any other option or toggle to a different one and back to the one that it was original set at
8. Start X

The problem with the mouse focus no longer happens.

I am using Archlinux built from the archlinux-2018.06.01-x86-64.iso.

I just installed the base build with xorg-server, xfce4 and virtualbox-guest-utils with kernel modules (not the DKMS option)

[burdi01]

In addition to the other workarounds -- blacklisting vboxguest or Host+F2, Enter, Host+F7 -- I can confirm a simplified version of c-xc-c workaround: 1 through 5, then 8. :D

[Michael Thayer]

Does killing the user processes "VBoxClient --draganddrop" help?

[burdi01]

There is no such user process ...

rescue:~# ps -ef | grep -i vbox
root      4615  4577  0 14:56 pts/0   00:00:00 grep -i vbox
rescue:~#

See the ISO I provided for ​https://forums.virtualbox.org/viewtopic.php?f=3&t=88372 :D

[Michael Thayer]

Could you try reproducing it with a fresh Fedora 28 installation and give precise instructions?

[burdi01]

I am a Slackware and Xubuntu user, not a Fedora one. But I am willing to have a try. With the "fresh Fedora 28 installation" do you mean a host or a guest installation? :D

[Michael Thayer]

Sorry, guest of course. I also have an Ubuntu 18.04 guest handy if that helps. Obviously I could download and install something else, but that raises the bar and lowers the chance I will get to having a look.

[Michael Thayer]

(And I have to download and install an openSUSE 15 for other things, so that would do too.)

[burdi01]

Ok, I will go for a Ubuntu 18.04 guest then. :D

[Michael Thayer]

Remembered though that one doesn't have a 4.17 kernel by default.

[burdi01]

I installed a Ubuntu 18.04 VM using all defaults.
The kernel version was 4.15.0-20-generic.
Rather soon updates were proposed: I accepted. The new kernel was 4.15.23-generic.
I then installed the 4.17.3 kernel -- see ​https://wiki.ubuntu.com/Kernel/MainlineBuilds . After a reboot I started a Terminal and was able to close it via the URH "X".
Then I started the Files file manager and was *not* able to close it via the URH "X". The mouse was dead in this window.
I then started the Terminal again: The mouse was still dead in the Files window.
After closing the Terminal window via the URH "X" the mouse was alive in the Files window again.

In my Slackware-based VM the mouse is dead in the Terminal as well as the File Manager window. First after one of the workarounds the mouse is alive again.
:D

[Michael Thayer]

I wonder if there are any reports of that happening on physical hardware. I will take a look though.

[mduncan]

I am running Fedora 28 on both physical hardware and as a guest under VirtualBox. My VM guest is the only one having this issue.

[Michael Thayer]

I'm sorry to say this, but re-reading comment:24 I have seen issues very much like this on physical hardware. This was when I was using Ubuntu 17.04 (with the then default kernel). I also eventually worked out that a virtual terminal switch made them go away again, after many many retrospectively unneeded reboots. I don't think I bothered to report it, as there were other, even more annoying problems there, and I have not seen it much if at all with Ubuntu 18.04 (still physical hardware here). I put it down to some problem with xwayland, but if it is the same, and people are reporting it with xorg then clearly not.

Edit: I meant 17.10 above, not 17.04.

[Michael Thayer]

@burdi01 Did you install the Guest Additions from VirtualBox into Ubuntu or just use the ones there? This is not so that I can start arguing, I just want to know.

[Michael Thayer]

A couple of random links from searches on everybody's favourite Q and A site (don't know about the Ubuntu 9.10 one, but see some of the answers):

• ​https://unix.stackexchange.com/questions/33980/mouse-clicks-stop-working-after-random-time-using-awesome-wm-gnome
• ​https://askubuntu.com/questions/420646/mouse-clicks-suddenly-stops-working
• ​https://superuser.com/questions/72112/mouse-clicks-suddenly-stopped-working-in-ubuntu

[burdi01]

@michael: I did not install the Guest Additions at all. The vboxvideo and vboxguest kernel modules come with the 4.17 kernel.
:D

[burdi01]

@michael: I doubt whether or not the ancient Q&A's have any bearing on the issue at hand.
:D

[Michael Thayer]

One theory about what this could be, though it might be completely wrong: some X11 client grabbing the mouse button. There seems to be a bug in the X server which I have run into occasionally which makes the button grab release fail. I have seen it (on host systems) because we do button grabs in VirtualBox, but I have also seen Unity cause it when Unity was still in use. Terminating the grabbing client releases the grab. If this theory is correct then the grabbing client will be the one still getting clicks.

[burdi01]

@michael: If your theory would be right the grabbing client would be calling into the vboxguest kernel driver -- as blacklisting vboxguest "resolves" the problem.
:D

[Michael Thayer]

Or changes the timing.

[mibh]

opensuse tumbelweed moved from 4.16 to 4.17 a few days ago and my mouse stopped tracking.

the VboxLinux.run shell script no longer builds correctly -- there are compile errors in vboxvideo.

i am dead in the water, desktop-wise. now using "ssh -X" to get in from elsewhere in order to run KMail.

[nixuser]

Latest Fedora kernel update to 4.17.3-200.fc28.x86_64 has not fixed the problem. Ctl+Alt+Fx and jumping back didn't fix things for me.

[hery88]

I'm using VirtualBox 5.2.12 with ArchLinux with both XFCE desktop environment and i3 installed, choosing between the two of them on login with LightDM login screen. I can reproduce the problem on both XFCE and i3.

I have another workaround: Simply logout and re-login back. It will make the problem disappear until the next reboot. It does not matter whether I logout and login again to the same desktop environment or not.

[nixuser]

@hery88: The logout/login trick seems to work for me on Fedora 28 with 4.17.3-200.fc28.x86_64 and Xfce.

[mduncan]

I can report that the workaround by hery88 (in comment #37) works for me.

[AlW]

I have been running Fedora 27 as a host, and have a Fedora 28 LXDE and Fedora 28 KDE guest systems. Virtual Box 5.2.12. The problem appeared on both guests as described with the update to kernel 4.17.3. Booting an older kernel (for the guest) solved the problem. Trying to rebuild the guest additions failed. Today I upgraded the host to fedora 28 kernel 4.17.3, and also upgraded to Virtual Box 5.2.14 with new guest extensions. Same problem. Logging out and back in solves the problem as suggested by @hery88 and others. And as an aside, my Windows 7 guest had no problems.

[FredBezies]

Linux 4.17.4 seems to fix this.

​https://lkml.org/lkml/2018/7/3/435

"Wenwen Wang (1):

virt: vbox: Only copy_from_user the request-header once"

Tried with an Archlinux based distribution (SwagArch Linux) and linux 4.17.4 and it worked. No need to blacklist vboxguest anymore.

Just waiting now to see if other persons in this thread can confirm that linux 4.17.4 is OK.

[melanopsis]

I can confirm that 4.17.4 has fixed this issue for me.

[burdi01]

Confirming the 4.17.4 kernel to resolve the problem for my slackware-based live ISO ...
:D

[oberger]

FWIW, on Fedora28 ws with current kernel (4.17.3-200.fc28.x86_64), I added module_blacklist=vboxguest to the kernel parameters in /boot/grub2/grub.cfg and rebooted, but that doesn't solve the issues : erratic mouse moves, no access to the full (virtual) desktop surface (XFCE4)... not fixed.

I guess it needs 4.17.4, or 4.16.3-301.fc28.x86_64 which was the one installed from the Fedora 28 iso, before I applied updates through dnf.

[Michael Thayer]

I have trouble seeing what the commit referenced above would change here, but glad the problem is solved. Since it does not actually involve software in the virtual machine which we provide (and I am still very doubtful that it is in vboxguest at all, my guess is still a timing problem which happened to show up in that combination), can we consider this closed?

[oberger]

IMHO, it would be interesting to be able to track to Fedora issues (and other distro bugtrackers), even if this is closed since the problem lies in the Kernel side. That'd help people spot when the issue can be fixed for end users.

[Michael Thayer]

You can still comment on closed tickets. I am also happy to change the ticket description to include links to other bug trackers if people consider that helpful. The fact that logging in and out makes the problem go away does not really point to a kernel problem though. Perhaps the point in time during the boot sequence when the desktop loads plays a role. And what burdi01 described on comment:24 sounded like what I have seen on physical hardware (but may not be what other people are seeing), which in my case only seemed to affect X11 clients, not pure Wayland ones.

[oberger]

I can confirm that it's solved on Fedora 28 guests running kernel 4.17.4, with VB guest extensions 5.2.14 recompiled. See the packer environment of boxcutter I've used to regenerate the guest base boxes for Vagrant + VirtualBox, committed at: ​https://github.com/olberger/fedora/commits/fedora-28

[nixuser]

On Fedora 28 you can now do it the easy way:

sudo dnf --enablerepo=updates-testing update kernel*

sudo dnf --enablerepo=updates-testing update virtualbox-guest-additions

Will bring you up to 4.17.4 with working vbox drivers. Still no folder sharing though.

[r2p2]

I've had the same issue and updated my arch today. Then I restarted the X server without rebooting and the issue was gone. As far as I know, the new kernel was not active yet, meaning that the kernel has nothing todo with the solution itself.

This is a list of all updated packages. ​https://gist.github.com/r2p2/85cbeb201616e4e111a7a5049e6700db

I am curious what the actual root cause was and how it was fixed. Maybe someone smarter than me knows which of those packages were actually loaded after the update but before rebooting the machine and could have resolved the isse. Then it would be possible to check the commits between the given versions.

I hope that makes sense.

[burdi01]

@r2p2: You replaced the faulty vboxguest kernel module by a corrected one.

Originally that kernel module came from the Guest Additions or was included in a distribution package. Since kernel 4.17 that kernel module comes with the kernel too.
:D

[nixuser]

This problem is back again, but on an older (major version number wise) kernel in latest RHEL 7.6 (and presumably CentOS 7.6 also) releases.

RHEL Kernel 3.10.0-957.1.3.el7.x86_64 Red Hat Enterprise Linux Server release 7.6 (Maipo)

Symptoms are as described here, and so far the workaround trick suggested by hery88 seems to work (logging out and back in again).

[Michael Thayer]

See: ​https://forums.virtualbox.org/viewtopic.php?f=3&t=90267