Does the server have a physical graphic card (GPU) (or CPU built-in GPU)? To debug, run on the host operating system:
It’s very conceivable that the server has no GPU to safe costs because most server workflows I suppose are over SSH and then no graphics on the server are needed, never any monitor connected (maybe a serial console but that doesn’t need a graphics card either).
If the server does not have a GPU, that might cause some issues. I don’t know if VirtualBox can emulate a virtual graphic card while the host operating system has no real GPU. Even if VirtualBox can do this, this might cause some issues. All speculation based.
- Does the host operating system have a functional graphical desktop environment such as Xfce?
How could you even test that? Not trivial. A VNC server is not really the same. A VNC server can be run without a GPU. (Running a VNC client without X - Server Fault) Using framebuffer. But that’s not really the same as having a real GPU and setting in front of it. Meaning, there could be issues in corner cases.
Using framebuffer it might be the case that applications using hardware acceleration (which likely includes browsers) will fail. → linux - How can OpenGL graphics be displayed remotely using VNC? - Server Fault
Getting all packages for a functional desktop environment (including xserver) is non-trivial. A functional shortcut could be installing
kicksecure-xfce-host on the host operating system. (instructions: Install Kicksecure ™ inside Debian)
Getting to the stage of a functional graphical desktop environment such as Xfce on the host operating system might require a local physical testing system (to get the package selection right).
- Does the host operating system run xserver? If it does not have xserver, that might also confuse VirtualBox and in turn Tor Browser.
- The VNC server software.
Even if the host operating system already has a functional A) physical GPU, B) xserver and C) desktop environment (such as Xfce), and D) VNC server applications using hardware acceleration such as browser might still fail.
I am using
x11vnc on a remote computer that has A, B, C and D and can confirm that browsers are functional on both, on the host operating system and inside (Kicksecure / Whonix) VMs.
tightvnc might not work for this purpose.
To test VNC, a computer you have physical access to (such as in LAN) might be handy.
For commands to set up
x11vnc, start the server and connect the client to, ask me. I can look that up. (Although I never manged to make it fully non-interactive when logging into a VNC session but then I would have a reason to look into that again.)
Also don’t know if
x11vnc would be compatible with the way WATS is currently expecting the VNC to function.
- Try running WATS on the host operating system. This is to figure out if this is a VM specific issue or already happening on the host operating system. The idea is, if it fails on the host operating system, there’s a good chance it will fail within the VM.
- Maybe not start with a complex GUI application such as Tor Browser first? Maybe it’s unspecific to Tor Browser?
Try some simpler GUI application such as
xfce4-terminal first. Just open an close using WATS. Let’s see if that works.
Then try Chromium.
Then try Firefox.
- Is there any way to do a video recording of the host operating system?
- Qubes uses openQA for automated GUI testing. I don’t know how Qubes / openQA handles (hardware accelerated) graphical tests. Are we re-inventing openQA?
- If Tor Browser (or all hardware accelerated graphical tests), all of this is getting too complex to fix, just skip it for now.