search

outpaddling / desktop-installer

Quickly configure a FreeBSD or NetBSD desktop system
BSD 2-Clause "Simplified" License
54 stars 7 forks source link

VirtualBox - Problem with graphical interface. User member of the wheel group #8

Closed snip3r closed 3 years ago

snip3r commented 3 years ago

I recently set up a FreeBSD-13-Release using the "desktop-installer" (out of curiosity) on a VM in the Virtual Box. I installed the environment with XFCE. When I finished the procedure, I noticed an unusual behavior.

When trying to start the graphical interface, there was a problem and a blank screen is left with just the mouse pointer. I checked the entire environment and realized that the problem only happened with a user who was a member of the wheel group. When removing the user from the wheel group everything worked correctly.

Analyzing the situation better, I realized that the problem was being caused by the package "virtualbox-ose-additions-6.1.18" (services vboxguest_enable="YES" and vboxservice_enable="YES") that was automatically installed during the execution of "desktop-installer ".

When disabling these services, the problem disappeared and the user member of the wheel group can normally access the graphical interface.

Basically, if I activate the vboxguest and vboxservice services and the user is a member of the wheel group, the graphical interface (xfce) does not work.

I thought about reporting the problem to the maintainer of the "virtualbox-ose-additions-6.1.18" package, but I thought it was important to first communicate this to you and ask for your opinion.

To reproduce the problem:

  1. Install FreeBSD-13-Release on Virtual Box
  2. Set up the environment using "desktop-installer"
  3. Add the common user to the wheel group
  4. Restart the VM
  5. Run XDM or
  6. With a common user (member of the wheel group), execute "startxfce4".

The "desktop-installer" is great! It helped me to save a lot of time when setting up the desktop.

Thank's

outpaddling commented 3 years ago

Thanks very much for the PR. I recently became aware of the issue and suspected the guest additions. Are you running a FreeBSD guest on a FreeBSD host? I have seen similar issues with a FreeBSD guest on a FreeBSD host, but a FreeBSD guest on MacOS works fine, as do other guest operating systems on a FreeBSD host.

snip3r commented 3 years ago

Thank you for responding so quickly! I am currently using a FreeBSD guest on a MacOS High Sierra host. The virtualbox I use is in version "6.1.18 r142142 (Qt5.6.3)"

outpaddling commented 3 years ago

I verified that the same problem exists in a FreeBSD guest with Lumina desktop. The symptoms are different, in that the Lumina desktop is rendered at login, but then doesn't respond to keyboard or mouse event. I also confirmed that it only happens for members of the wheel group and with vbox guest/service enabled. That was some nice detective work that should make it relatively easy to track down the issue.

This should be reported via https://www.freebsd.org/support/bugreports/. You want to do the honors? Before opening a new PR, though, let's see if your discovery is related to this one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254458

snip3r commented 3 years ago

Ok, perfect. We will wait for an answer. Thanks!

outpaddling commented 3 years ago

I just did a fresh 12.2 setup under VirtualBox and everything works fine. So this looks like a FreeBSD 13.0 issue.

snip3r commented 3 years ago

I tested a FreeBSD-12 here and the same problem happened. In 12, even removing the user from the group "wheel", the graphical interface does not work, it is left with a blank screen with the mouse pointer. It only worked normally when I turned off the "vboxguest and vboxservice" services.

I tested it twice on two VMs:

  1. I installed FreeBSD-12
  2. I upgraded to the latest version:
  3. freebsd-update fetch
  4. freebsd-update install
  5. run the desktop-installer
  6. chose to install XFCE

In the end, I had to manually install the "xf86-video-vmware" package for the video to work. Without this package, Xorg will not work. I didn't realize before because I always install all the "xf86-video- *" packages, because it is easier for me to test the system in different environments.

outpaddling commented 3 years ago

That's very odd. I tried xf86-video-vmware on my 13.0 guest, and it did not help. It seemed to override the vbox guest additions.

At any rate, we should move this discussion over to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254458 since this is not a desktop-installer bug.

snip3r commented 3 years ago

I suspect the problem is "virtualbox-ose-addions-6.1.18". In 12-Release and 13-Release they use the same version "6.1.18" and in both it is enough to deactivate it that everything works. I tested it on 12-Release just to try to help a little more. The problem is not really in the "desktop-installer". Let's wait for some response from the PR. Thank you very much for your help!

grahamperrin commented 3 years ago

https://github.com/outpaddling/desktop-installer/issues/8#issuecomment-825755128

xf86-video-vmware

Almost certainly not required.

If you have not already done so:

  1. stop the guest
  2. set it to use VBoxSVGA

Reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254266#c7

grahamperrin commented 3 years ago

https://github.com/outpaddling/desktop-installer/issues/8#issuecomment-824304110

… MacOS … host. …

https://github.com/outpaddling/desktop-installer/issues/8#issuecomment-825755128

… https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254458 …

My reporting of 254458 was, admittedly, somewhat messy.

Given my experience with a Windows host (non-reproducible), I imagine that it will be similarly non-reproducible with Mac OS X hosts.

grahamperrin commented 3 years ago

@snip3r what's the result for you with VBoxSVGA?

outpaddling commented 3 years ago

Indeed... I see that my 13.0 VM defaulted to VMSVGA while 12.2 defaulted to VBoxVGA. Switching the former for VBoxSVGA solves the display issue for root. Just commented at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255736. Maybe we should patch the port to default to VBoxVGA or VBoxSVGA on all FreeBSD versions until the VMSVGA issue is resolved.

grahamperrin commented 3 years ago

my 13.0 VM defaulted to VMSVGA while 12.2 defaulted to VBoxVGA.

If you create a FreeBSD guest: regardless of version, the default is VMSVGA.

image

… patch the port to default to

Is that possible?

VBoxVGA or VBoxSVGA on all FreeBSD versions

Re: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254266#c7 as far as I can tell, if guest additions will be installed (I should assume so, with desktop environments), and if the host is FreeBSD, then the guest should use VBoxSVGA.

I assume that the same will be true for FreeBSD guests with non-FreeBSD hosts: VBoxSVGA.

until the VMSVGA issue is resolved.

As far as I can tell, there's no issue with VMSVGA. I assume that it works as intended where guest additions are not installed.

outpaddling commented 3 years ago

The default GPU must have changed recently, because I never altered the GPU emulation on any of my VMs. Honestly never considered it until now since I'm not concerned about graphics performance. Regarding the patch, I mean patch the virtualbox-ose port on the host to default to VBoxSVGA for all FreeBSD guests. Once tested, upstream the patches and suggest they be applied to all host platforms. I should have been more clear about this. The issue with VMSVGS is it does not work for members of the wheel group if guest additions are installed. Remove the user from wheel and guest additions work fine. Do you believe this behavior is intentional?

grahamperrin commented 3 years ago

… The issue with VMSVGS is it does not work for members of the wheel group if guest additions are installed. Remove the user from wheel and guest additions work fine. …

Not fine for me.

Windows 10 20H2 host, FreeBSD 13.0-RELEASE guest with sddm and KDE Plasma from latest. Previously working with VBoxSVGA and grahamperrin in wheel.

I removed grahamperrin from wheel, set the guest to use VMSVGA, started the guest, sddm fails to appear:

image

grahamperrin commented 3 years ago

… guest additions work fine …

Including the bi-directional shared clipboard?

outpaddling commented 3 years ago

Maybe because sddm runs as root and uses syscalls that trigger the problem? My test systems were using xdm, which works fine in any case. The problem showed up after logging in as a member of wheel, so something in the desktop-env triggered it for me. Haven't tested the clipboard and won't bother unless there's real interest in fixing vmsvga.

grahamperrin commented 3 years ago

VMSVGA, wheel

For reference only (off-topic, and (at this time) I can't recommend using VMSVGA with virtualbox-ose-additions)

… Remove the user from wheel and guest additions work fine. …

With VMSVGA, and grahamperrin not a member of wheel, SLiM login to LXDE fails:

image

image

outpaddling commented 3 years ago

In summary, the problem is with the virtual VMSVGA device and FreeBSD guests. Using VBoxSVGA appears to be the best choice. Unfortunately, VirtualBox currently defaults to VMSVGA for FreeBSD. This should probably be changed. In any case, this is not a desktop-installer bug.