VirtualBox

Ticket #17827 (closed defect: invalid)

Opened 5 weeks ago

Last modified 12 days ago

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

Reported by: FredBezies Owned by:
Priority: major Component: guest additions/x11/graphics
Version: VirtualBox 5.2.12 Keywords:
Cc: Guest type: Linux
Host type: Linux

Description

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.

Attachments

VBox.log Download (249.9 KB) - added by hotjava1231 4 weeks ago.

Change History

comment:1 Changed 5 weeks ago by 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.

comment:2 follow-up: ↓ 3 Changed 5 weeks ago by 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.

comment:3 in reply to: ↑ 2 Changed 5 weeks ago by 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.

comment:4 Changed 5 weeks ago by FredBezies

Well, it looks like this bug is found 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.

Version 0, edited 5 weeks ago by FredBezies (next)

comment:5 Changed 5 weeks ago by 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.

comment:6 Changed 4 weeks ago by FredBezies

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

comment:7 Changed 4 weeks ago by 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

comment:8 Changed 4 weeks ago by burdi01

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

comment:9 Changed 4 weeks ago by 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.

comment:10 Changed 4 weeks ago by hotjava1231

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

VirtualBox VM 5.2.13 r123149.

comment:11 Changed 4 weeks ago by burdi01

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

comment:12 Changed 4 weeks ago by Yaroslav

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

Last edited 4 weeks ago by Yaroslav (previous) (diff)

comment:13 Changed 4 weeks ago by 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

Changed 4 weeks ago by hotjava1231

comment:14 Changed 4 weeks ago by 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)

comment:15 Changed 4 weeks ago by 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

comment:16 Changed 4 weeks ago by michael

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

comment:17 Changed 4 weeks ago by 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

comment:18 Changed 4 weeks ago by michael

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

comment:19 Changed 3 weeks ago by 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

comment:20 Changed 3 weeks ago by michael

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.

comment:21 Changed 3 weeks ago by michael

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

comment:22 Changed 3 weeks ago by burdi01

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

comment:23 Changed 3 weeks ago by michael

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

comment:24 Changed 3 weeks ago by 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

Last edited 3 weeks ago by burdi01 (previous) (diff)

comment:25 Changed 3 weeks ago by michael

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

comment:26 Changed 3 weeks ago by 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.

Last edited 3 weeks ago by mduncan (previous) (diff)

comment:27 Changed 3 weeks ago by michael

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.

Last edited 3 weeks ago by michael (previous) (diff)

comment:28 Changed 3 weeks ago by michael

@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.

comment:30 Changed 3 weeks ago by burdi01

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

Last edited 3 weeks ago by burdi01 (previous) (diff)

comment:31 Changed 3 weeks ago by burdi01

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

comment:32 Changed 3 weeks ago by michael

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.

comment:33 Changed 3 weeks ago by 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

comment:34 Changed 3 weeks ago by michael

Or changes the timing.

comment:35 Changed 3 weeks ago by 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.

comment:36 Changed 3 weeks ago by 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.

comment:37 Changed 3 weeks ago by 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.

comment:38 Changed 3 weeks ago by nixuser

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

comment:39 Changed 3 weeks ago by mduncan

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

comment:40 Changed 3 weeks ago by 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.

comment:41 Changed 3 weeks ago by 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.

comment:42 Changed 3 weeks ago by melanopsis

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

comment:43 Changed 3 weeks ago by burdi01

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

comment:44 Changed 3 weeks ago by 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.

comment:45 Changed 3 weeks ago by michael

  • Status changed from new to closed
  • Resolution set to invalid
  • Summary changed from With linux 4.17 and VirtualBox 5.2.12, vboxguest must be blacklisted. to With linux 4.17 and VirtualBox 5.2.12, vboxguest must be blacklisted -> works with 4.17.4

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?

comment:46 Changed 3 weeks ago by 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.

comment:47 Changed 3 weeks ago by michael

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.

comment:48 Changed 3 weeks ago by 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

comment:49 Changed 2 weeks ago by 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.

comment:50 Changed 12 days ago by 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.

comment:51 Changed 12 days ago by 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

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use