Mouse only usable within single application after mouse click on RHEL 7.6 as a VirtualBox guest
Good morning folks,
I've found this thread at the VirtualBox forum. It discusses an issue that occours when you are running RHEL 7.6 as a VirtualBox guest on a Windows or Linux host system.
The issue is that you could use your mouse only within a single application window after you click in that window. The issue appears not when running RHEL 7.5 as a guest. It appears in RHEL 7.6 whether or not the VBox Guest Additions are installed. It happens with the gnome-shell and the classic gnome desktop.
Because it happens when the Guest Additions are not installed, too. I think this might be an issue with RHEL 7.6 and not entirely related to VirtualBox at all. But I do not know that for sure.
Does anyone of you encounter this issue, too? And does any one encounter this issue even on bare metal?
You could reproduce this issue in RHEL 7.6 as a VBox guest as follows:
- Start RHEL 7.6
- Open a terminal
- Click-drag-select text within window
- Try to move the terminal, click another application, or anything else outside the terminal...it doesn't work.
Would be nice if the two communities could work together on this, to solve it.
Best regards,
Joerg
Responses
Guru
4227 points
Yes, I am seeing the same issue with RHEL 7.6 guests. The /var/log/messages file shows error lines similar to BZ 1594177. I have updated VirtualBox to 5.2.23_126798_el7 (test build) but this did not fix the problem.
Guru
4227 points
Joerg,
I have a couple of notes about the mouse issue.
(1) As someone pointed out in this post in the thread you quoted, the kernel version makes the difference. I updated the kernel of a guest running EL7.5 using the 7.6 kernel (and no other packages updated). The guest now has the same mouse problem. Also, on a 7.6 system showing the issue, I test-installed ELRepo's kernel-ml (4.19.x) and kernel-lt (4.4.x). No problem with either kernel.
(2) On a guest exhibiting the issue, just log out and then log back in. The problem seems to go away.
In either case, the GuestAdditions are not involved.
Active Contributor
208 points
Thanks for the workaround. In my case, I couldn't even reach the logout button, but thankfully I have a terminal that starts up at login. For those that find themselves in a similar situation, the command 'kill -9 -1' may be useful. I should know better than to upgrade VirtualBox when I need to get work done...
Active Contributor
186 points
This exact same behavior also happened to Fedora 28/29 with the introduction of the 4.17.0 kernel, and mysteriously went away with the 4.17.4 kernel. A workaround for Fedora was to simply log out and log back in again, and this [for me] seems to be the case with RHEL 7.6 as well. This is probably a clue for those familiar with the inner workings of relevant packages.
https://www.virtualbox.org/ticket/17827 is the ticket filed against 4.17.0 which I believe is the same underlying issue, with the same workarounds.
Guru
4227 points
Ian,
That is a great hint. By looking through the patches applied to kernel 4.17.4, I think I'm getting close to finding the one that actually fixed the issue. I will post more details, hopefully soon.
Guru
4227 points
I picked up one patch (commit 03ae3a9caf4a59edd32b65c89c375a98ce3ea1ef) as the candidate and applied it to the centosplus kernel (kernel-plus). It is available for testing from:
https://people.centos.org/toracat/kernel/7/plus/bug15570/
It seems to fix the mouse problem according to my brief testing.
Guru
4227 points
Bug reports filed:
CentOS bug 15570 and RHEL bug 1658669 (private)
Please test the patched kernel if you are able. Feedback welcome.
Guru
4227 points
There is no RHEL 7.6 kernel with the patch. However, the centosplus kernel (kernel-plus) is binary compatible with the RHEL kernel. So, could you download kernel-plus-3.10.0-957.1.3.el7.centos.plus.ay1.x86_64.rpm and test-install it? It will not delete any of the existing kernels on the system.
Active Contributor
186 points
@toracat Testing the patched kernel proved to be a few orders of magnitude more difficult than I thought it would be. I finally got there though. The good news is that kernel-plus-3.10.0-957.1.3.el7.centos.plus.ay1.x86_64.rpm did not have the mouse problem, so for me the patch fixes that problem.
The bad news is that despite managing to eventually get the kernel-plus-devel and kernel-plus-headers and all the rest installed, and reinstalling development tools that got shredded when I uninstalled previous versions, and despite it appearing that I could successfully compile the VirtualBox guest additions (from 5.2.23 test build), they don't work correctly, I am stuck with a tiny screen. What I don't understand is that copy/paste between the host and guest does work, so the guest additions are partly working.
Could the patch be interfering with screen resize events?
Active Contributor
186 points
Interestingly, vboxsf driver is working as well, so I can share folders between my CentOS guest and Win7 host. So the only thing not working with the guest additions is the video side of things.
Guru
4227 points
I'm glad to learn that the patch fixed the mouse problem in your testing.
Now, the window issue is something else. It is not due to the patch but rather is related to the kernel-plus itself. Installation of the GuestAdditions involves 3 kernel modules, vboxguest , vboxsf and vboxvideo. What I found so far is that the vboxvideo module does not build under the plus kernel. I am now investigating this.
At least we now know that the proposed patch fixes the mouse issue. When the distro kernel is patched, all should be back to normal.
Guru
4227 points
I now have a new set of the centosplus kernel that does not have the vboxvideo build problem.
https://people.centos.org/toracat/kernel/7/plus/bug15570new/
Download the two rpm packages there and install them (yum localinstall ... ):
kernel-3.10.0-957.1.3.bug15570.plus.el7.x86_64.rpm
kernel-devel-3.10.0-957.1.3.bug15570.plus.el7.x86_64.rpm
(You don't need kernel-header)
Reboot to this kernel. And everything should work now.
Detailed explanation: In VirtuslBox's Makefile for vboxvideo, RHEL 7 kernels were picked up by looking for "el7.x86_64" in the name. The original plus kernel was named ".el7.centos.plus.xxx.x86_64" . As a result, this kernel was not regarded as a "RHEL 7.6 kernel". So in the new version I built the same kernel using "xxxx.plus.el7.x86_64" as the package name. Now Makefile sees this as a RHEL kernel and builds the vboxvideo module.
Guru
4227 points
Bad news. A kernel update has just been released (kernel-3.10.0-957.5.1.el7). However, it did not have the patch.
Guru
4227 points
I have updated the patched plus kernel and made it available from the same location:
https://people.centos.org/toracat/kernel/7/plus/bug15570new/
kernel-3.10.0-957.5.1.bug15570.plus.el7.x86_64.rpm
kernel-devel-3.10.0-957.5.1.bug15570.plus.el7.x86_64.rpm
If you are currently running the plus kernel, please update to this version.
Hi
I was worried about the same problem.
The environment in which the problem occurred.
Host OS - Windows 10 Pro ver 1809 OSbuild 17763.253
Virtualbox 6.0.4
GuestOS - CentOS7 Desktop (use xWindow)
This update fixes the issue.
Thank you for your hard work. :)
Guru
4227 points
Just a note to say no recent progress in the filed RHBZ. But it has a keyword "Z-Stream", so I expect the patch will appear in a future 7.6 kernel.
Active Contributor
186 points
Is there some concern over the patch that is delaying its introduction into the kernel? This issue was pending as a priority for quite a few weeks and failed to make the latest kernel. Seems strange.
Guru
4227 points
This may sound strange but our bug report is being processed faster than the average. I submitted it on 2018-12-12 and the patch was committed on kernel-3.10.0-984.el7 on 2018-12-20. So, it will be in the EL 7.7 kernel. That was "super fast". Then it was added to the "ZStream" on 2019-01-02, meaning the patch will be ported to the EL 7.6 kernel series.
To give you an example for comparison, a kernel bug report with a known patch from kernel.org was submitted on 2018-08-07 (it was EL 7.5 at that time). The patch was committed on kernel-3.10.0-979.el7 on 2018-12-17 (so, will be in EL 7.7). It does not have the keyword "ZStream". Therefore this one may not be fixed in the 7.6 kernel. I would say the progress of this example is rather "typical" for non-critical bug fixes.
Guru
12807 points
Hello Jörg Kastning,
https://access.redhat.com/solutions/3893421 has been created to show the progress of this issue.
Regards,
Jan Gerrit
Guru
34035 points
Hey Jörg, having followed this discussion for some time now ... what about the most easy way to troubleshoot the vbox issues ? Just get rid of ORACLE VirtualBox and Windows - who (still) uses ORACLE/Windows these days ? :D :D - and replace the host with a Linux distro. CentOS, Fedora
or RHEL comes to my mind. Fire up your virtual machines with KVM/QEMU, these tools work as expected. You can use Cockpit to manage, and Virt-Manager to access your machines via a GUI.
Included humoristic points of view are intended !
Cheers :)
Christian
Guru
12807 points
Hi Christian,
For those that are less experienced using KVM/Qemu. Virtualbox or VMWare Workstation all alternatives to run on Windows. The issues are caused by the RHEL 7.6 packaged kernel not by Virtualbox ( :) this time :) ).
Regards,
Jan Gerrit Kootstra
Guru
34035 points
I know Jan Gerrit ... :) What matters is the combination here - I've been using VirtualBox some
years ago too and I realized that I always found bugs and issues - some of them less and some
of them more impacting the user experience in a negative way. After switching to KVM, it was
no longer the case and that's why I recommend it. But of course, the production machine has
to run a Linux system. Those who prefer to run Windows have to stick with vbox or VMware ...
I am running RHEL 7.6 in a KVM virtual machine on a fedora 29 workstation host and all I can
say is that everything works correctly, right as it should be and without any noticeable issues.
Regards,
Christian
Guru
34035 points
Hi Jörg,
Yesterday you asked me to "point your nose" to some good documentation ... well, there's tons of stuff you can find on the
internet. I usually see everything from the customer's point of view and so I thought about the best way to get you started.
Although it would be easy to just point you to the QEMU website, I think it might overwhelm you. Like most users you have
started exploring virtualization with VirtualBox. Moving to KVM will be a bit of a learning curve, but once you've figured out
everything, you will never look back. You get many more configuration options, many more features and on top of that way
better performance. I suggest that you start with virt-manager (a GUI for libvirt/qemu) to explore and try out how all works.
Please follow these instructions - first remove VirtualBox including all configuration files completely and restart the system.
Then install these packages to get the complete virtualization toolset, this is valid for CentOS 7.6, Fedora 29 and RHEL 7.6.
Enable the EPEL repository - in case you haven't done it already - to gain access to dkms (dynamic kernel module support).
To avoid pulling in the wrong dependency kernel-debug-devel, I recommend to install the kernel-devel package beforehand.
sudo yum install kernel-devel
sudo yum install kernel-headers
sudo yum install dkms
sudo yum install libguestfs-tools libvirt qemu virt-install virt-manager
Later on you can install and use Cockpit and the necessary plugins to manage the machines from within a web browser GUI.
Now you have everything you need - reboot the system and start exploring your new environment. Hope I could help you. :)
Regards,
Christian
Guru
34035 points
For your convenience Jörg, here are some additional configuration recommendations. :)
Add yourself (user) to the relevant virtualization groups and configure the ACL settings.
sudo usermod -a <your-user-name> -G libvirt
sudo usermod -a <your-user-name> -G qemu
sudo setfacl -R -m u:<your-user-name>:rwx /path-to-virtual-disks
sudo setfacl -R -m u:qemu:rwx /path-to-virtual-disks
The virtual machines run as qemu user and if you want to launch them with GNOME Boxes,
you need to create a new file in your /home/user/.config/gnome-boxes/sources directory.
sudo vi /home/user/.config/gnome-boxes/sources/'QEMU System' Insert this :
[source]
name=QEMU System
type=libvirt
uri=qemu+unix:///system
save-on-quit=true
Regards,
Christian
Guru
34035 points
And Jörg, if you want to manage your environment via Cockpit ... follow these steps :
sudo yum install cockpit cockpit-machines
sudo systemctl enable --now cockpit.socket
That's all for today, enjoy the new virtualization solution, I wish you a nice weekend. :)
Regards,
Christian
Guru
4227 points
According to a recent post in the referenced VirtualBox forum thread, the RHEL kernel with the fix is scheduled to be released in mid March.
Jörg asked, if someone has this issue on bare metal. I have several identical hosts and on one of them I see this bug every time after rebooting. For me the workaround was switching to a text terminal and back to graphics mode or by restarting the X server. And I have seen it on the other hosts too but very occasionally.
I can confirm it doesn't happen within the vmplayer! But as I said it happens on physical hosts too. And I can confirm that package kernel-3.10.0-957.5.1.bug15570.plus.el7.x86_64.rpm is fixing the problem for them too.
Guru
34035 points
Hi everybody ! :)
There's one thing worth mentioning : All users who install packages from external sources have to be aware that they are about
to loose official support from Red Hat when it comes to issues being related to those software packages - especially the kernel !
The kernel is one of the most important components and, it is definitely recommended to stick with the original Red Hat kernel
on production systems generally, not only in enterprise environments. If one installs external kernels, they are doing it on their
own risk.
Regards,
Christian
Guru
4227 points
I have two notes.
One is that, yes, the bug can be reproduced without VirtualBox. This was confirmed by a Red Hat engineer.
Second is about the external kernels. Right, they are not supported by Red Hat. In this particular case, the plus kernel is offered as a temporary solution until the official RHEL kernel with the patch gets released. Hopefully it will happen very soon.
Guru
4227 points
Big news!
kernel-3.10.0-957.10.1.el7 has just been released. I confirm this version has the patch that fixes the mouse issue.
[EDIT] To be more precise, the source code has been released. Please wait for the announcement for the actual release of the binary packages.
Guru
34035 points
Thank you very much for this "hot" update information, Akemi ! Great news indeed ... Have a nice day ! :)
Regards,
Christian
I did a yum update but after the kernel was still 3.10.0-957.5.1. Is there something additional that needs to be done?
