So, I’m running Fedora with Gnome. When I fire up Windows 10 in Virtualbox, the VB menu tabs appear at the bottom of the virtual machine, covering up the tray. Of I attempt to minimize it, it leaves the Windows window. When I reclick on it, the tabs are still there. If I try to close it, it freezes the host. I can switch workspaces, and windows, but I can’t do anything within them; clicking on links, or new tabs within a browser instance, does nothing. The cursor remains an arrow regardless of its location. The only way to fix it (that I’ve found so far) is to reboot, which is a PETA, because a lot of stuff has to be autoloaded each time.
Any ideas for troubleshooting?
[Saturday-afternoon update]
OK, I have discovered that I can unfreeze the host without having to reboot, by killing the VM process. So that will help. But it’s still not switching properly between full-screen and scaled modes. And I still have to modprobe the driver every time I reboot, or the machine won’t start.
Try putting the cursor/focus into the root window for the Win10 guest and enter RIGHT_CTRL-f. See if that restores a normal window with the menu items along the top. You should be able to size and manipulate that window out of our Linux task bar area as well. I only use the full window on a dual monitor set-up where the full window is on the screen w/o a task bar.
It’s important to use RIGHT_CTRL not LEFT_CTRL as the former is treated differently by VBox as the “Host” key. So what you are entering is ID’d by VBOX as HOST-F.
Hope this helps.
On my VBox (v 7.0.6) there is a ‘pin’ icon on that full screen menu at the bottom at the extreme left. If I un-check that (click on it once), and move the mouse away, it makes it drop down to a single line that you can get to pop-up again if you mouse down into it. At least that’s the way it works when Win-10 is hosting Ubuntu.
This is another option if you don’t want to do the Host-f trick above and your Linux tray icons are big enough you can mouse into them without going into the line.
This is another option if you don’t want to do the Host-f trick above and your
LinuxWindows tray icons are big enough you can mouse into them without going into the line.In addition to David’s comments, I have a few suggestions. This may be more a Gnome problem than a VB problem. In my Ubuntu (Jammy-Jellyfish) machine as host and Win10 as client, the VB machine shows up with a title bar at the top, and below that is a menu bar (File Machine View Input Devices Help). Then you get the Win10 machine, including its taskbar at the bottom. Below that is a gray bar where the VB icons appear, indicating disk use, CD tray, sound, etc. The Dock is outside of all this on the left side of the screen. The locations of things in the host window will be controlled by Gnome, so your Gnome settings and/or any Gnome extensions you have will control those (locations of menus, actions when clicking, etc.).
I’ve found that I get the fewest headaches when I run the VB machine maximised, with the Win10 machine set up to never turn off the screen. Linux and VB client screensavers don’t play well together and Win10 can get confused when resized in a VB machine. If I need to do something separately in Ubuntu, I just switch to another workspace, whereupon the normal screensave function operates and the Win10 machine is none the wiser.
I’m trying to figure out if the two issues (inability to get rid of the VB tabs at the bottom of Windows, and the freezing up of the host) are related.
I’m not sure I know what you mean about “VB tabs at the bottom of Windows”. Do you mean the icons that are part of the hosting machine window (not part of Win10)? I don’t know why you’d want to get rid of them as they are useful in controlling the virtual machine. Are you changing some setting in VB? How are you “getting rid of them”?
Yes, that’s what I mean. They’re covering up the Windows tray. I don’t want to see them in Windows. I try getting rid of them by minimizing it, but that minimizes the Windows window as well. When I reclick on it, the VB tabs are still there.
Sorry Rand, I’m running a set-up which is the cannonical-opposite of what you are doing (i.e. a Windows host running a Linux guest) so perhaps I’m not seeing the exact same behavior you are. In my setup the little VB icons are part of the Window-10 windows border and do not impede the Linux task bar (Gnome).
Here’s another thing you can try. In the Machine Drop down menu select Settings, in the pop up select User Interface. In the dialog un-check the box at the bottom which shows all the VB icons. That should make them disappear from the Linux window border so hopefully they no longer obstruct your Windows task bar.
The other thing you can do is move your Windows taskbar elsewhere. Right click in the Windows taskbar and select ‘Taskbar Settings’. In the pop-up go down to the ‘Taskbar location on screen’ selection box and pick something other than ‘Bottom’. Not ideal granted.
In order to be able to do that, I’d have to activate Windows…
Yes I definitely have the screen saver turned off in the Linux guest. That has caused trouble in the past.
I was thinking of doing a dual-boot build for my next computer but you’re really making me unsure about Linux. ^_^”
None of this is really dual-boot. Typically that means two separate operating systems on a disk, with separate boot mechanics and disk partitions that can’t see each other and are formatted to the native OS. They cannot run concurrently. It’s one or the other.
Under VirtualBox you have the ‘host machine’ always running. And ‘guest machines’ which are just separate OSes that can be booted and can run concurrently on the same machine as the host, but in a window on the host machine. You can even share files between the host and guest ‘machines’, network resources, devices, sound, etc. As long as both OSes support them. Guest machines can be booted and shutdown at will without affecting the host. And you can have >1 guest machine running if you have the hardware horsepower to support that.
It really has very little to do with Linux either. Except maybe in Rand’s case the Linux implementation of VirtualBox isn’t quite handling Gnome window borders like it should. Or perhaps it’s a limitation of Gnome. That’s not Linux per-se either, it’s just one of many window managers for Linux. Gnome and KDE are two of the more popular ones. Gnome comes out-of-the-box with Fedora I believe.
This time…
…lol. Fedora: Sometimes Alpha, but Forever Beta…
Also I sorta focused in on the tray/icons issue rather than the freeze.
I would discourage you from using the X to close the guest root window (and presumably shutdown the guest). I don’t do this typically. What I do instead is go to the power-on/off icon in the upper right corner (just below the window X), and click on it to do a power-off/logout and select power off. Alternatively you can also shutdown from the VirtualBox Manager window, by right clicking on the running machine and pick one of the stop options from the pop-up menu.
I always shut down the Win10 virtual session using the power off feature in the Win10 start button menu. Once that completes, the Win10 window closes. Closing the machine using a windows close (X) feature is equivalent to turning off your Win10 desktop by pushing the power button or unplugging the machine. Unexpected things tend to happen.
I agree completely. Yes use the Windows shutdown feature! I should’ve said that from the get go.
Last comment. Sometime I don’t get the full root window when I start the guest machine in a normal window. Often times it’s completely missing the task bar. Resizing it to anything different straightens it out again.
Also it’s best to make sure you have the guest additions add-on that matches your VB release.
And I still have to modprobe the driver every time I reboot, or the machine won’t start.
You can fix this using systemd. See if you have the text file /etc/modules in your distro. If so edit it and add the line “vboxdrv” and save it. Upon reboot you shouldn’t have to do the modprobe anymore. ‘lsmod’ will tell you if it’s loaded.
If you don’t have /etc/modules but there is an /etc/modules.d see this link. Replace the substring “rt2800usb” with “vboxdrv” in the example and again if successful the ‘lsmod’ should show it.
But it’s still not switching properly between full-screen and scaled modes.
Well without seeing a screen shot of this, it’s hard for me to guess what is happening here. If none of my prior suggestions helped, then I’m left with the idea that I’d get very bad behavior when either 1) the guest additions were not installed or 2) the guest additions did not match up with the version of VirtualBox I was running.
You might want to double check your guest additions and perhaps re-install. Check your VirtualBox release. One clue that this is the problem is if in your scaled window you get horizontal and vertical scroll bars in the Gnome window that allow you to move around the Win-10 window to see different parts of it. If that’s the case, you need to update your guest additions.
Of I attempt to minimize it, it leaves the Windows window.
That also sounds like a guest additions problem.
I’m also wondering why you need to modprobe to begin with? This sounds like a broken install to me.
Did all this behavior start after a Fedora update? If so, you might want to un-install and re-install your Virtual Box program completely. But before doing, that check with the VirtualBox forums for any known issues with the version of Fedora you are running.
I don’t know if I’ve said this once already before, so I’ll say it now.
If you really, really want to run Fedora, I’d run it as a guest machine under a different, more stable Linux host, like Debian or Ubuntu LTS (Long Term Support) or even RHEL* 6/7 if you want to shell out some cash for it.
Then if you always take a snapshot of the Fedora guest (very fast for Ubuntu for me takes only about 10-15 seconds to do) before doing any Fedora updates, any hiccups can be rolled back with a simple mouse click to reboot the snapshot. You aren’t using the host for anything other than running the guest OSes and that because of that there is little to no need to update the host OS and over the long term that should work just fine. If you insist on running Fedora I can’t think of a safer, more robust way of doing it than this. All your Fedora apps, etc. should run just fine on the guest machine. To minimize your downtime, I’d suggest bringing all this up on a new machine before retiring your existing set-up.
*RHEL == Red Hat Enterprise Linux (aka IBM).