Opened 5 years ago
Last modified 2 years ago
#19496 assigned defect
Virtualbox 6.1.6 guest screen resize broken
Reported by: | Wheaties | Owned by: | gombara |
---|---|---|---|
Component: | other | Version: | VirtualBox 6.1.6 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Linux |
Description
The virtualbox 6.1.6 update seems to be okay, but if the matching guest additions is applied to the guest, the auto-resize or resize to any resolution is unavailable. I applied guest additions to several hosts before discovering this issue, including Centos-6, Centos-7, Centos-8, kali linux, and OracleLinux-8. Guests that have not gotten the update seem to be working fine.
Matt
Attachments (9)
Change History (85)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
This may be of some help(?) Output from one of the broken guests:
# /usr/sbin/VBoxService --version
6.1.6r137129
# ps -ef | grep VBox
root 587 2 0 08:27 ? 00:00:00 [iprt-VBoxWQueue]
root 588 2 0 08:27 ? 00:00:00 [iprt-VBoxWQueue]
root 2068 1 0 08:28 ? 00:00:00 /usr/sbin/VBoxService --pidfile /var/run /vboxadd-service.sh
mwheat 3004 1 0 08:29 ? 00:00:00 /usr/bin/VBoxClient --clipboard
mwheat 3006 3004 0 08:29 ? 00:00:00 /usr/bin/VBoxClient --clipboard
mwheat 3014 1 0 08:29 ? 00:00:00 /usr/bin/VBoxClient --seamless
mwheat 3015 3014 0 08:29 ? 00:00:00 /usr/bin/VBoxClient --seamless
mwheat 3019 1 0 08:29 ? 00:00:00 /usr/bin/VBoxClient --draganddrop
mwheat 3020 3019 0 08:29 ? 00:00:01 /usr/bin/VBoxClient --draganddrop
root 5623 3963 0 08:34 pts/0 00:00:00 grep VBox
# /usr/bin/VBoxClient --display
VBoxClient: error: unrecognized option '--display'
VBoxClient: info: Try 'VBoxClient --help' for more information
comment:3 by , 5 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:4 by , 4 years ago
This issue is reproducible in most recent KDE Neon distribution.
Screen size issue:
- After guest OS restart it's screen resizes to 1024x768
- If I resize VirtualBox window then guest OS resizes to actual size of window and then immediately resizes back to 1024x768
- If I resize guest OS from KDE monitor settings then it resizes and jumps back to 1024x768
Guest Additions versions:
- Upgraded VirtualBox and Extension Pack from 6.1.4 to 6.1.6
- The issue is not reproducible.
- Upgraded VirtualBox Guest Additions from 6.1.4 to 6.1.6
- The issue is reproducible.
- Downgraded Guest Additions by downloading 6.1.4 from https://download.virtualbox.org/virtualbox/6.1.4/VBoxGuestAdditions_6.1.4.iso
- Issue gone again.
It's obvious that the bug related to guest additions 6.1.6 for linux.
I can fetch any logs from the guest OS. Just tell me which logs do you need.
comment:6 by , 4 years ago
I see a similar problem here with Ubuntu 18.04 guests on Ubuntu 18.04 host.
The screen size is not modifiable from Ubuntu settings or the VBox window View menu when the guest is running with Wayland.
When the guest is running with X11, the screen is black after initial user login. When the screen is resized from the VBox window View menu, the normal desktop appears.
These observations are probably related.
comment:7 by , 4 years ago
Facing a similar problem with Debian 10 Buster running on Windows 10 -VBox version 6.1.6. The screen resolution defaulted to "800x600".
I can confirm that after downgrading to 6.1.4 version of the VBoxGuestAdditions, the screen resolutions started to appear as expected - 1920x1080
comment:8 by , 4 years ago
I can also reproduce this problem with VB 6.1.6 Windows 10 host and RHEL 8.1 guest with GA 6.1.6. The workaround that currently works for me is to downgrade to GA 6.1.2 (6.1.4 has the clipboard bug).
For reference, here are two forum posts describing this problem:
https://forums.virtualbox.org/viewtopic.php?f=3&t=97781
https://forums.virtualbox.org/viewtopic.php?f=3&t=97686
I echo @AndreyVen: Is there a way to subscribe to updates to this bug/ticket?
Thanks for looking into this bug.
comment:9 by , 4 years ago
The workaround that currently works for me is to downgrade to GA 6.1.2 (6.1.4 has the clipboard bug)
@soapydk Thanks for noting this. Now clipboard works for me too :)
comment:10 by , 4 years ago
interestingly I have at least 2 distros which do not show this problem when using the 6.1.6 host/GA combo: 1) Ubuntu 20.04 (Mate edition) guest on a Ubuntu 19.10 host and 2) OpenSuse 15.1 guest on a Ubuntu 18.04.4 host. Both guests where using Xorg.
comment:11 by , 4 years ago
fwiw, I also have a Fedora Rawhide guest running the 5.7-rc1 kernel and the appropriate 6.1.X GA test builds from:
Guest Additions 6.1.x revision 137519
https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_6.1.7-137519.iso
on a Ubuntu 19.10 host with working screen size adjustments.
Using Gnome Classic & Xorg. However it does not work
if I use Gome & Xwayland
by , 4 years ago
Attachment: | VBox-6.1.6-OI-no-resize.log added |
---|
VBox.log of an OpenIndiana that won't resize with 6.1.6 additions
comment:12 by , 4 years ago
The OpenIndiana comment is a bit misleading in the context of this bug, that did not work even before 6.1.6.
comment:13 by , 4 years ago
As discussed on IRC, same problem is seen with OpenIndiana (a Solaris next of kin OS) with MATE, XOrg and 6.1.6 guest additions, on both VMSVGA and VBoxSVGA display adapters - display size does not change by events from hypervisor (window resizing, via menu of Virtual Screen / Resize).
Resizing from inside the VM (its Display preferences) locked up the kbd/mouse inputs the first time I tried, so had to restart X11 via SSH. For the second GUI session (in the same VM uptime) such resizing from the inside did work.
Reverting to additions 6.1.2 and same hypervisor (6.1.6 on Windows) fixes the issue. According to IRC however up till 6.1.2 resizing relied on a "hack" removed in later editions.
comment:14 by , 4 years ago
The OpenIndiana comment is a bit misleading in the context of this bug, that did not work even before 6.1.6.
Not correct, sorry. It did work "like forever", since about the start of post-OpenSolaris era and VirtualBox 3.x? 4.x? For much of the past decade I use OI as a daily workstation, even if the HW system must be a corporate Windows, so I'd notice. And I maintain the vboxsvc for wrapping VMs into SMF instances since before then.
Until VirtualBox 6.x came about, OI users ran directly Oracle-provided binaries for Solaris (hosts and guests). Since 6.0 discrepancies grew to a point that builds from GPL source of releases are made and distributed.
comment:15 by , 4 years ago
I confirm. Host: Windows 7 Pro x64 NVIDIA GeForce GTX 1050 Ti Monitor samsung S32D850T (DisplayPort) The guest: Linux Mint 19.3 Cinnamon
I upgraded from 6.1.4 to 6.1.6 since it fixed the clipboard error. But there was an error resizing the screen, manually resizing the window does not work, or resets to 800x600.
If you downgrade to 6.1.2, the clipboard and dynamic screen resizing work fine.
Tested each version with the corresponding version of GA and EP.
PS. Guys i think it's time to switch to use git!
comment:16 by , 4 years ago
see also:
Bug 1789545 - Can't auto-resize display on Fedora 31 guest VM https://bugzilla.redhat.com/show_bug.cgi?id=1789545
comment:17 by , 4 years ago
Hi, I wish to bring to the table that this might be also happening also in Window guests (at least my combination W10 x64 (1909/815) host and guest. VBOX 6.1.6 +ExtPack and GA 6.1.6)
Simptoms were frozen guest every time IE11 was opened. This happens when I plug to portable an external monitor, then rezising/resolution changes happen automatically. Then, once stabilized, guest frozen as explained. Might not be related to this bug as I started to use the external monitor at the same time as updated to 6.1.6, so, might be this is related to my settings and not to GA. Anyhow, was solved using the workaround (as provided here https://forums.virtualbox.org/viewtopic.php?f=3&t=97686&start=15#p474257)
use VBoxSVGA (without 3D acceleration) as being the display device use Maximum guest size to None in the preferences Do not maximize the guest window but resize it manually (whenever you maximize the display, it appears like it is frozen)
(in my case, I had 3D on and Maximun guest size to auto)
As soon as I find some moments I will try to go back to 6.1.4 in GA with VBOX previous settings and see if this solves.
TIA
Later add: I removed GA616, installed GA614, set maximun guest size to auto, and marked 3d acceleration. Problem come back... so, either it is not the same issue or the issue comes in windows GA before 6.1.4 ...
comment:18 by , 4 years ago
We have been working on a fix and for some desktop environments like cinnamon/KDE the current state is in a better shape than before. For those interested iso image to the update guest additions is here:
https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_6.1.7-137622.iso
as usual all other test build packages from several branches are accessible here.
https://www.virtualbox.org/wiki/Testbuilds
I would appreciate any feedback especially what is not working concerning vmsvga issues on X11 guests.
follow-up: 20 comment:19 by , 4 years ago
@gombara,
Host: 5.6.7-arch1-1 (X11)
Guest: 5.6.7-arch1-1 (LXQt on X11)
virtualbox: 6.1.6-1
Guest additions: 6.1.7-137622 (from the link above)
VMSVGA w/ 3D accel.: not working (View -> Auto-resize Guest Display is grayed-out), but was working with guest additions 6.0.20
VBoxSVGA w/o 3D accel.: working properly
Do you need any additional info/testing done?
comment:20 by , 4 years ago
Nope. I will take a look locally. I will add a comment here if I need something more. Thanks for the feedback.
Replying to Ynov:
@gombara,
Host: 5.6.7-arch1-1 (X11)
Guest: 5.6.7-arch1-1 (LXQt on X11)
virtualbox: 6.1.6-1
Guest additions: 6.1.7-137622 (from the link above)
VMSVGA w/ 3D accel.: not working (View -> Auto-resize Guest Display is grayed-out), but was working with guest additions 6.0.20
VBoxSVGA w/o 3D accel.: working properly
Do you need any additional info/testing done?
comment:21 by , 4 years ago
Add to that:
Host: 5.6.7-arch1-1 (X11)
Guest: Debian 10.3 4.19.0-8-amd64 Debian 4.19.98-1+deb10u1 (GNOME 3.30.2)
virtualbox: 6.1.6-1
Guest additions: 6.1.7-137622 (from the link above)
VMSVGA w/ 3D accel.: working on X11
VMSVGA w/ 3D accel.: not working on Wayland (View -> Auto-resize Guest Display is grayed-out), but again was working with guest additions 6.0.20
VBoxSVGA w/o 3D accel.: working partially - initial resize is working (on gdm3 login), but subsequent window resizes are not applied (View -> Auto-resize Guest Display is not grayed-out), both on X11 and Wayland
follow-up: 24 comment:23 by , 4 years ago
Host = Linux Debian MATE 10.3 (buster)
Guest = Linux Debian MATE 11 (bullseye)
Graphics controller = VMSVGA (with or w/o 3D accel.)
resize to fullscreen at boot is not working: guest screen plain black after boot
6.1.7 behaves just like 6.1.6
BUT ''' when I hit Host-F twice the screen is perfect !
(NB: when I booted my first VM I had no fullscreen either... but that was in 1972 on an IBM 1050 typewriter)
follow-up: 28 comment:24 by , 4 years ago
yeah it is one of the remaining bugs. after reboot the full screen is restored but we get a black picture. guest is alive and all that and going out and coming back to full screen solves the problem. I am still trying to find out what goes wrong there.
comment:25 by , 4 years ago
I can confirm this as well on Arch Linux (host) plus Arch Linux guest.
VBoxClient --display on the guest is never run giving :
VBoxClient: error: unrecognized option '--display' VBoxService --version is : 6.1.6r137129
follow-up: 29 comment:27 by , 4 years ago
The bug is almost completely fixed in the guest additions test builds. So please try the GA isos from https://www.virtualbox.org/wiki/Testbuilds and if something is not working as expected, please describe in detail. Don't forget to attach VBox.log. It contains a lot of details which most users would otherwise forget, making the comment useless.
The problem with most 'remaining' problem descriptions in this ticket is that they're extremely vague, which makes it impossible for us to tell if we see the same issue or something else.
comment:28 by , 4 years ago
Replying to gombara:
guest is alive and all that and going out and coming back to full screen solves the problem. I am still trying to find out what goes wrong there.
Thank you for all your efforts. I think I have the same issue.
I routinely boot and use virtual machines in full-screen (high-DPI 1920x1080) mode on a Windows 10 host, using VMSVGA with 128MB video RAM and a Linux (Xubuntu 19:04) guest. Everything works fine with 6.1.4 and its guest additions and mostly OK with VirtualBox 6.1.6 and the 6.1.4 guest additions.
When booting with VirtualBox 6.1.6.137129 whether using the 6.1.4 or the 6.1.6 guest additions, Xubuntu booted to too small a login screen.
After installing the 6.1.6 guest additions, it again booted to too small a login but then went to a black screen after logging in. After a bit of experimentation I found that I could fix the problem by switching to another Linux terminal (ctl-alt-F2) and then back to the GUI (ctl-alt-F7) and from then on the GUI worked fine indicating that the underlying system appears to work.
by , 4 years ago
Attachment: | VBox 6.1.6 + 6.1.7-137622.log added |
---|
follow-up: 30 comment:29 by , 4 years ago
Still not working.
Windows 10 6.1.6 + Debian 10 gnome 6.1.7-137622.
ps ax | grep wayland 1270 tty2 Ssl+ 0:00 /usr/lib/gdm3/gdm-wayland-session /usr/bin/gnome-session 1328 tty2 Sl+ 0:00 /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6
Replying to klaus:
The bug is almost completely fixed in the guest additions test builds. So please try the GA isos from https://www.virtualbox.org/wiki/Testbuilds and if something is not working as expected, please describe in detail. Don't forget to attach VBox.log. It contains a lot of details which most users would otherwise forget, making the comment useless.
The problem with most 'remaining' problem descriptions in this ticket is that they're extremely vague, which makes it impossible for us to tell if we see the same issue or something else.
follow-up: 31 comment:30 by , 4 years ago
Replying to yuhp:
Still not working.
Windows 10 6.1.6 + Debian 10 gnome 6.1.7-137622.
ps ax | grep wayland 1270 tty2 Ssl+ 0:00 /usr/lib/gdm3/gdm-wayland-session /usr/bin/gnome-session 1328 tty2 Sl+ 0:00 /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6
This cannot work with Xwayland, you have to use an Xorg X11 session in order for screen resizing to work.
comment:31 by , 4 years ago
Replying to fbatschu:
This cannot work with Xwayland, you have to use an Xorg X11 session in order for screen resizing to work.
But 6.1.6 + 6.1.4 work perfect (except broken clipboard).
follow-up: 60 comment:32 by , 4 years ago
Hi, I had the same issue:
- Windows 10 host, VBox 6.1.6 r137129, GA 6.1.6 as shipped with VBox
- Debian 9 client with Xorg Xserver
- VMSVGA with 3D acceleration: log-in screen smaller than normal, then blank screen.
- VBoxVGA without 3D accel: all good
By chance I increased the assigned video memory for the VM from 12 MB to 32 MB. Now -with VMSVGA- all looks quite normal, no blank screen anymore. Well, the automatic resizing doesn't work. That's no surprise as the VBoxClient refuses the --display option. (Btw. why is that?)
comment:33 by , 4 years ago
VBoxGuestAdditions_6.1.7-137891 has fixed the problem in my specific case, at least:
Ubuntu MATE 19.10 x64, kernel 5.4.0-29, mesa 20.0.4, 3D accel OFF.
(Background, in case it's helpful: Was working fine with VB 6.0.12, updated to 6.1.6 a few days ago, changed nothing else, X display needed forcibly refreshing (I used a VT switch rather than Host-F switches) at startup or would only show blank screen. Updated to test GA above, changed nothing else again, all good now at startup on its own).
Thanks.
comment:34 by , 4 years ago
same problem in ubuntu mate 20.04 LTS, kernel 5.4.0-29-generic, OpenGL version string: 4.6 Mesa 20.2.0-devel
follow-up: 41 comment:36 by , 4 years ago
In general this has been fixed in the new release 6.1.8.
However, see also #19590
follow-up: 38 comment:37 by , 4 years ago
Hi!
The Title of that defect should have " and 6.1.8" instead of "6.1.6" in its name. And a claim from 6.1.8 Change log:
Guest Additions: Fixed resizing and multi monitor handling for X11 guests. (6.1.0 regression; bug #19496)
should be removed as soon as possible. This simply is not truth. Guest resizing in Linux with VMSVGA DO NOT WORK.
Even worse, there is a new failure message mentioned above - #19590 And yes it shows in XORG. Looks like every new version of guest additions worsen Linux support.
Host: Windows 10 Ent 64 bit, Guest Slackware64-current + KDE5. Version of VBOX-6.1.2+GA-6.1.2 worked.
comment:38 by , 4 years ago
Replying to zd59:
Hi!
The Title of that defect should have " and 6.1.8" instead of "6.1.6" in its name. And a claim from 6.1.8 Change log:
Guest Additions: Fixed resizing and multi monitor handling for X11 guests. (6.1.0 regression; bug #19496)should be removed as soon as possible. This simply is not truth. Guest resizing in Linux with VMSVGA DO NOT WORK.
Even worse, there is a new failure message mentioned above - #19590 And yes it shows in XORG. Looks like every new version of guest additions worsen Linux support.
Host: Windows 10 Ent 64 bit, Guest Slackware64-current + KDE5. Version of VBOX-6.1.2+GA-6.1.2 worked.
Slackware is so old:
http://www.slackware.com/
that it likely falls under the victims of the new X11 environment check as I shown in #19590
There is absolutely no reason for you to clutter this bug with your rant. Even worse, you picked the wrong bug for your complaint.
Much more helpful would be if you could explain which Slackware version you are using and from what Download location that would be available.
follow-up: 40 comment:39 by , 4 years ago
Hi fbatschu
Sorry if I was not clear. Slackware64-current is one of the most current distributions of Linux. You can find it on ftp://ftp.slackware.com/pub/slackware/slackware64-current/: gcc-9.3.0 xorg-server-1.20.8 On top of it KDE-5 from: https://alien.slackbook.org/ktown/current/latest/ with: KDE 5_20.04 for Slackware, consisting of KDE Frameworks 5.69.0, Plasma 5.18.4 and Applications 20.04.0 on top of Slackware's Qt 5.13.2.
I compiled/installed kernel 5.6.10 So as you can see above, my system is very modern instead "so old" as you mentioned. Again I note, all worked with VBOX and GA 6.1.2 or less and kernels until 5.4.
Please specify what would help to debug (log files, dmesg...). Will append next time.
Regards.
follow-up: 42 comment:40 by , 4 years ago
Replying to zd59:
Hi fbatschu
Sorry if I was not clear. Slackware64-current is one of the most current distributions of Linux. You can find it on ftp://ftp.slackware.com/pub/slackware/slackware64-current/: gcc-9.3.0 xorg-server-1.20.8 On top of it KDE-5 from: https://alien.slackbook.org/ktown/current/latest/ with: KDE 5_20.04 for Slackware, consisting of KDE Frameworks 5.69.0, Plasma 5.18.4 and Applications 20.04.0 on top of Slackware's Qt 5.13.2.
I compiled/installed kernel 5.6.10 So as you can see above, my system is very modern instead "so old" as you mentioned. Again I note, all worked with VBOX and GA 6.1.2 or less and kernels until 5.4.
Please specify what would help to debug (log files, dmesg...). Will append next time.
Regards.
Rather then immediately jumping into the joys of nailing that slackware manually onto my platter, would you perform 3 checks for me please?
1) is that Slackware thingy running systemd at all? 2) if yes, what is the content in your shell from the environment
variable XDG_SESSION_TYPE
3) Are you using Xorg or Xwayland? From your comments I vaguely
take that you are using Xorg indeed, right?
We know this all worked with 6.1.2 and broke with 6.1.4 and 6.1.8 should return the working state for all Xorg use cases modulo regression bug #19590
comment:41 by , 4 years ago
comment:42 by , 4 years ago
Replying to fbatschu:
Rather then immediately jumping into the joys of nailing that slackware manually onto my platter, would you perform 3 checks for me please?
1) is that Slackware thingy running systemd at all? 2) if yes, what is the content in your shell from the environment
variable XDG_SESSION_TYPE
3) Are you using Xorg or Xwayland? From your comments I vaguely
take that you are using Xorg indeed, right?
We know this all worked with 6.1.2 and broke with 6.1.4 and 6.1.8 should return the working state for all Xorg use cases modulo regression bug #19590
1.) Slackware64-current is running system.d
2.) variable XDG_SESSION_TYPE - no sign of it:
[~] # env |grep XDG XDG_CONFIG_DIRS=/etc/xdg:/etc/kde/xdg XDG_CURRENT_DESKTOP=KDE XDG_SESSION_COOKIE=slack.doma-1590050247.597470-689610040 XDG_RUNTIME_DIR=/var/run/user/0 root on slack Thu May 21 10:49 AM
3.) XORG or Xwayland? Yes it's XORG. Take a look a picture I attached: XORG.jpg - Slackware64-current running XORG
And yes, graphics controller is VMSVGA. Auto-resize Guest Display is GRAY - not clickable.
As soon as I replace it with VBoxSVGA the window resize works.
follow-up: 44 comment:43 by , 4 years ago
I also have another Slackware64-current with Xfce on top of XORG.
After VBOX upgrade to 6.1.8 (also Guest Additions)
Xfce-4.12 + VBoxSVGA driver: The parent session seems to be non X11.. Window resize do not work immediately, X11 should be restarted. Auto-resize guest is not gray
Xfce-4.12 + VMSVGA driver: The parent session seems to be non X11.. Window resize do not work, Auto-resize guest is gray.
And another complain: If in a /lib/modules/<kernel_version>/misc are VBOX compiled modules, the installer do not compiles new drivers. And those modules ARE NOT uninstalled with VBOX uninstall program.
follow-up: 45 comment:44 by , 4 years ago
Replying to zd59:
I also have another Slackware64-current with Xfce on top of XORG.
After VBOX upgrade to 6.1.8 (also Guest Additions)
Xfce-4.12 + VBoxSVGA driver: The parent session seems to be non X11.. Window resize do not work immediately, X11 should be restarted. Auto-resize guest is not gray
Xfce-4.12 + VMSVGA driver: The parent session seems to be non X11.. Window resize do not work, Auto-resize guest is gray.
As hinted above, you need to fix for:
#19590: VBoxClient: The parent session seems to be non-X11
follow-up: 46 comment:45 by , 4 years ago
Replying to fbatschu:
Replying to zd59:
I also have another Slackware64-current with Xfce on top of XORG.
After VBOX upgrade to 6.1.8 (also Guest Additions)
Xfce-4.12 + VBoxSVGA driver: The parent session seems to be non X11.. Window resize do not work immediately, X11 should be restarted. Auto-resize guest is not gray
Xfce-4.12 + VMSVGA driver: The parent session seems to be non X11.. Window resize do not work, Auto-resize guest is gray.
As hinted above, you need to fix for:
#19590: VBoxClient: The parent session seems to be non-X11
Sorry fbatschu, but this is NOT truth. I've posted a window screenshot above to prove, X11 is running and NOT Wayland. Slackware-current is not even prepared (compiled) for a Wayland. The statement
The parent session seems to be non-X11
is a prove of a failure of Virtualbox to detect X11 is running. Please accept that as real truth.
The state of XDG_SESSION_TYPE variable can not be the way, VBOX detect X11/Wayland, as on some distributions it is absent.
comment:46 by , 4 years ago
Replying to zd59:
Replying to fbatschu:
Replying to zd59:
I also have another Slackware64-current with Xfce on top of XORG.
After VBOX upgrade to 6.1.8 (also Guest Additions)
Xfce-4.12 + VBoxSVGA driver: The parent session seems to be non X11.. Window resize do not work immediately, X11 should be restarted. Auto-resize guest is not gray
Xfce-4.12 + VMSVGA driver: The parent session seems to be non X11.. Window resize do not work, Auto-resize guest is gray.
As hinted above, you need to fix for:
#19590: VBoxClient: The parent session seems to be non-X11Sorry fbatschu, but this is NOT truth. I've posted a window screenshot above to prove, X11 is running and NOT Wayland. Slackware-current is not even prepared (compiled) for a Wayland. The statement
The parent session seems to be non-X11is a prove of a failure of Virtualbox to detect X11 is running. Please accept that as real truth.
The state of XDG_SESSION_TYPE variable can not be the way, VBOX detect X11/Wayland, as on some distributions it is absent.
Read bug #19590
follow-up: 48 comment:47 by , 4 years ago
fbatschu are you serious?
So stupid X11/Wayland check by VBOX. Reading the forum reveal that XDG_SESSION_TYPE is not a standard env variable!
And now the most simple solution, that solved "no window resize" failure:
file /etc/profile - add here:
export XDG_SESSION_TYPE="x11"
and reboot.
Now "window resize" works.
Sometimes the simplest things are so obvious, that nobody to think about it!
Now both my VBOX Slackware machines have a resizable windows. And best, this solution works for all Linux distributions running X11, not only Slackware.
comment:48 by , 4 years ago
Replying to zd59:
fbatschu are you serious?
So stupid X11/Wayland check by VBOX. Reading the forum reveal that XDG_SESSION_TYPE is not a standard env variable! And now the most simple solution, that solved "no window resize" failure:
file /etc/profile - add here:
export XDG_SESSION_TYPE="x11"and reboot.
Now "window resize" works.
Sometimes the simplest things are so obvious, that nobody to think about it!
Now both my VBOX Slackware machines have a resizable windows. And best, this solution works for all Linux distributions running X11, not only Slackware.
You could have tried reading and understanding bug #19590
and then using the corresponding test builds mentioned in there which contain the fix to this problem.
Of course you can also do whatever you like in your shell and feel positive about it.
comment:49 by , 4 years ago
You are right. But this is a fast and simple solution without any installation. Might help others. I'll wait for a release of a new VBOX version. Thanks for a code that reveal x11 check, so I was able to find that simple solution.
follow-up: 52 comment:50 by , 4 years ago
(In the hope that the devs are still willing to wade through all the ranting in this ticket...)
The fix in 6.1.8 isn't quite there yet, it seems: my Ubuntu 16.04 guest still needs a VT switch, Host-F, or similar "forced refresh" manual trigger to get the initial desktop display to happen.
VMSVGA, 128MB, 3D *dis*abled Mesa 18.0.5, kernel 4.15.0-101-generic
It's an X desktop, with the environment variable VBox is looking for present, so I'm not sure why the initial display isn't happening. If you need further info or would like me to try a potential fix, just let me know.
Thanks.
comment:51 by , 4 years ago
and, OUCH - I windowed the VM to see if the various resolutions were greyed out, out of curiosity. They weren't, but mousing over them caused the VM to lock up, hard. It failed to respond to an ACPI Shutdown sent from the VBox Manager, which then greyed out the "Close" option, and the VM process had to be killed from the host.
There's nothing useful that I can see in the log: just a couple of "got a hint" lines from the Host-F itself, but I've saved a copy of it in case it's helpful. I realise this ticket is about resizing not working, not "even thinking about resizing causes the VM to hard lock" :P, but yeah - it seems there's something very nasty indeed lurking in that code still.
follow-up: 68 comment:52 by , 4 years ago
Replying to arQon:
(In the hope that the devs are still willing to wade through all the ranting in this ticket...)
The fix in 6.1.8 isn't quite there yet, it seems: my Ubuntu 16.04 guest still needs a VT switch, Host-F, or similar "forced refresh" manual trigger to get the initial desktop display to happen.
VMSVGA, 128MB, 3D *dis*abled Mesa 18.0.5, kernel 4.15.0-101-generic
It's an X desktop, with the environment variable VBox is looking for present, so I'm not sure why the initial display isn't happening. If you need further info or would like me to try a potential fix, just let me know.
This bug is about _screen resizing_ what you describe seems to be different problem. Fwiw I've tested 16.04 with 6.1.8 wihtout problems in the follow up bug #19590, https://www.virtualbox.org/ticket/19590#comment:11
So please could you be more verbose what this actually means:
"guest still needs a VT switch, Host-F, or similar "forced refresh" manual trigger to get the initial desktop display to happen."
and if it is not related to resizing the screen while using the VMSVGA adapter, it should probably handled outside the scope of this bug here.
comment:53 by , 4 years ago
As of revision 138395 GA should be able resize virtual monitors on Wayland guests as well. That is when vmsvga graphics adapter is used. The new GAs are available in https://www.virtualbox.org/wiki/Testbuilds.
comment:54 by , 4 years ago
vbox/ga 138395 is not working for openSUSE Tumbleweed guest on Win10 host. It always snaps back to 800x600. The only thing that works for me is GA 6.1.4 so far. Guest is x11, kernel 5.6.14, KDE 5.18.5, VMSVGA no 3D. Host is Win10.
Solution: kill kscreen: "qdbus-qt5 org.kde.kded5 /kded unloadModule kscreen"
Solution: preferred mode: https://bugs.kde.org/show_bug.cgi?id=407058#c24
comment:55 by , 4 years ago
The new Xwayland enabling fixes have been verified on the following platforms so far:
All are now resizing capable running with Gnome/Xwayland:
CentOS 8.1
OpenSuse Tumbleweed
Fedora Rawhide
Fedora 31
Oracle Linux 8.2
Ubuntu 19.04
If it still doesn't work for you, it is very likely because you are using KDE/kscreen where the screen gets resized and kscreen immediately forces it back. Good to talk to the kscreen folks about it.
comment:56 by , 4 years ago
Unfortunately full-screen still doesn't work with X11 guests though. I have a number of Debian 10 guests that run full screen. Up to VirtualBox 6.1.4, the login screen was full screen and once the logon details were entered, the screen was still set to full screen.
Starting with VirtualBox 6.1.6 and continuing with VirtualBox 6.1.8, the logon screen is now 800 x 600 and once the logon details are entered, the desktop goes blank. This is the case with the GA's for 6.1.6, 6.1.8 and the latest test build for GA 6.1.9. If you subsequently, use View -> Full-screen mode (to switch back to windowed), the guests desktop is restored. Using View -> Full-screen mode will then restore the guest desktop to full-screen. However, the next time you reboot the guest, it's broken again. Guests are Debian 10 with the Mate desktop.
comment:57 by , 4 years ago
See: comment:56 and comment:28
Feline and I have identical problems, except that I am using VBox 6.1.10. In our usage, there remains a problem with VBox resizing the screen from 800x600 to full size pre login and with seeing a black screen after login. In my case, the last working version was VBox 6.1.4. Throughout, my guest has been: XUbuntu running on X11.
@gombara: Would you prefer that a new bug report is opened?
follow-up: 61 comment:58 by , 4 years ago
Hi Marvin. I know that loggin into full screen results in a black screen. Going out and in from/to fullscreen mode restores the picture. I am yet to find the cause and fix for this.
comment:59 by , 4 years ago
I've already opened another ticket for this, see https://www.virtualbox.org/ticket/19640
comment:60 by , 4 years ago
Replying to guurpi:
Hi, I had the same issue:
- Windows 10 host, VBox 6.1.6 r137129, GA 6.1.6 as shipped with VBox
- Debian 9 client with Xorg Xserver
- VMSVGA with 3D acceleration: log-in screen smaller than normal, then blank screen.
- VBoxVGA without 3D accel: all good
By chance I increased the assigned video memory for the VM from 12 MB to 32 MB. Now -with VMSVGA- all looks quite normal, no blank screen anymore. Well, the automatic resizing doesn't work. That's no surprise as the VBoxClient refuses the --display option. (Btw. why is that?)
It seems that new VBoxClient doesn't support --display option and doesn't support --vmsvga-x11
root@kali:~# VBoxClient --help Usage: VBoxClient --clipboard|--draganddrop|--checkhostversion|--seamless|--vmsvga[-d|--nodaemon] Starts the VirtualBox DRM/X Window System guest services. Options: --clipboard starts the shared clipboard service --draganddrop starts the drag and drop service --checkhostversion starts the host version notifier service --seamless starts the seamless windows service --vmsvga starts VMSVGA dynamic resizing for x11/Wayland guests -f, --foreground run in the foreground (no daemonizing) -d, --nodaemon continues running as a system service -h, --help shows this help text -v, --verbose increases logging verbosity level -V, --version shows version information root@kali:~# VBoxClient --version 6.1.10_Debianr138449
So after modifying /usr/bin/VBoxClient-all and using --vmsvga instead of --vmsvga-x11 personally i have working resizing again.
comment:61 by , 4 years ago
Replying to gombara:
Hi Marvin. I know that loggin into full screen results in a black screen. Going out and in from/to fullscreen mode restores the picture. I am yet to find the cause and fix for this.
It's already been reported (multiple times/places) that switching between non-fullscreen & back to fullscreen *after* login is completed restores the correct display.
I don't know if this adds any additionally helpful info, but I've used the following method previously with GA 6.1.10 & also verified still working with the latest GA 6.1.12: switching between non-fullscreen & back to fullscreen at the login screen (which is before the switch from 800x600 to full size screen, speculated to be a contributing cause of the black screen) using host-F allows fully correct display (not black) after login.
Mark J Culross KD5RXT
comment:62 by , 4 years ago
With a little more experimentation, I've now found that you can execute the exit/re-enter full screen mode work-around (by hitting the host-F key twice) anytime after the VM is initiated, even as soon as the VBox 6.1 splash screen is displayed & you'll get a fully correct display after login !!
Again, don't know if this adds anything useful, but I thought I'd post it just in case.
Mark J Culross KD5RXT
by , 4 years ago
Attachment: | MXLinux-19.2-on-Ubuntu-20.04-VBox.Log added |
---|
VBox.Log running MXLinux 19.2 32bit VM on top of Ubuntu 20.04
by , 4 years ago
Attachment: | MXLinux-19.2-on-Devuan-Beowulf.log added |
---|
VBox.Log running MXLinux 19.2 32bit VM on top of Devuan Beowulf (debian 10 derivative)
by , 4 years ago
Attachment: | LinuxMint-19.2-on-Devuan-Beowulf_resize-works.log added |
---|
VBox.Log running LinuxMint 19.2 64bit VM on top of Devuan Beowulf. Resizing WORKS here.
comment:63 by , 4 years ago
Can confirm this issue still happens on VirtualBox 6.1.14 new Ubuntu/Debian packages, with some guests, as per VBox log files provided.
A good failure case is to:-
*Create a 'default settings' Linux 32bit Virtual Machine [uses VMSVGA graphics type]
*install MXLinux 32bit in default settings
*Install Guest Additions 6.1.14 using ISO-Image and VBoxLinuxAdditions run file.
*Reboot
*Demonstrate that resizing the virtual machine window, does not resize the guest screensize
Whereas, e.g. Linux Mint 19.2 64bit seems to be okay with resizing as a guest.
A confirmed workaround is to install VBoxGuestAdditions from 6.1.4 GA .iso instead.
Also have experienced the failure on Debian 10 32bit LXDE guest, not just MXLinux/XFCE failure.
I should be able to provide some logs/notes from within the VM, or test config changes, in coming days, if requested.
comment:64 by , 4 years ago
As per helpful suggestion from LocutusOfBorg,
After installing these packages (built from the virtualbox debian source) INSTEAD of vboxguestadditions from iso image:-
virtualbox-guest-dkms_6.1.14-dfsg-2_all.deb virtualbox-guest-source_6.1.14-dfsg-2_all.deb virtualbox-guest-utils_6.1.14-dfsg-2_i386.deb virtualbox-guest-x11_6.1.14-dfsg-2_i386.deb
Then, screen resize WORKS
I have also noted, MXLinux partly includes some virtualbox-guest packages [6.1.2 versions] as provided, that COULD be part of conflict, but I don't *think* these are the issue given other reporters on this bug, and the fact I had the same issue with Debian 10 LXDE as well.
by , 4 years ago
Attachment: | MXLinux-19.2-on-Devuan-Beowulf-with-deb-virtualbox-guest.log added |
---|
VBox.Log running MXLinux 19.2 32bit VM on top of Devuan Beowulf, using deb package guest modules/support, no iso GAs, resize WORKS.
comment:65 by , 4 years ago
+ with above packages still-installed, then install vboxguestadditions from 6.1.14 iso file, and reboot, BREAKS the resize support again ... Clearly something about the iso linux GA installer 'conflicts' somehow with (at least) debian 10's and similar.
comment:66 by , 4 years ago
The latest problems reported on this ticket were about 32 bit guests. I think they are fixed now. Do please update guest additions from iso from the following url: https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_6.1.15-140299.iso Virtualbox installation on the host needs no update. Please update this ticket if this update does not solve resizing problem(s) for you. Thanks enyc for testing etc.
comment:67 by , 4 years ago
Can confirm, this fixes resize on both MXLinux 19.2 32bit (XFCE) and also Debian 10 LXDE 32bit as well.
comment:68 by , 4 years ago
Replying to fbatschu:
Replying to arQon:
(In the hope that the devs are still willing to wade through all the ranting in this ticket...)
The fix in 6.1.8 isn't quite there yet, it seems: my Ubuntu 16.04 guest still needs a VT switch, Host-F, or similar "forced refresh" manual trigger to get the initial desktop display to happen.
This bug is about _screen resizing_ what you describe seems to be different problem. Fwiw I've tested 16.04 with 6.1.8 wihtout problems in the follow up bug #19590, https://www.virtualbox.org/ticket/19590#comment:11So please could you be more verbose what this actually means:
"guest still needs a VT switch, Host-F, or similar "forced refresh" manual trigger to get the initial desktop display to happen."
and if it is not related to resizing the screen while using the VMSVGA adapter, it should probably handled outside the scope of this bug here.
Sorry for this reply being so late...
My understanding is that the failure of the VM to render anything AT ALL (other than the cursor) on the initial switch to X is directly related to this resize bug. Apologies if that's not the case.
I've lost track of the exact starting point of the bug, but I expect it's "every version of 6.1.x". When a Linux guest VM is started (MATE 1604, 1804, 1910, and 2004 at least, all x64) and is (at a minimum including the case of) set to autologin to X, after the switch to X the screen remains completely black, except that the X cursor can be seen (and can be seen changing at times). The only way to get the display to start working is to either toggle away from fullscreen and back, or switch to a different VT and back, or etc: no amount of waiting will cause things to start working correctly on their own.
A comment ?somewhere? (sorry, it was too long ago now) implied that the cause was a failure of some kind in the initial switch and resize to a graphical mode: despite the fact that the switch itself clearly works. To me, it just seems like a failure to trigger the initial paint, but I can see how that could be the result of what appears to VBox to be a failure to actually resize the display correctly in the first place, so I was directed to this ticket.
That was back on 6.1.12, and nothing in the release notes since has suggested that this is fully fixed, but I'll grab the latest builds and re-test just in case in the next few days when I can, and update this (or a different ticket, if this is the wrong place) with the outcome of that.
comment:69 by , 4 years ago
So yeah: the bug (my bug, at least) is still present in 6.1.14. On startup, the log has this:
00:00:22.732628 GUI: UIMachineViewFullscreen::adjustGuestScreenSize: Adjust guest-screen size if necessary. 00:00:22.732636 GUI: UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 1920x1200 if necessary 00:00:22.732647 VMMDev: SetVideoModeHint: Got a video mode hint (1920x1200x32)@(0x0),(1;0) at 0 00:00:22.732696 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 00:00:22.735033 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=800 h=600 bpp=0 cbLine=0x0 flags=0x2 origin=0,0 00:00:26.770265 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cd7f000 w=1920 h=1200 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,000:00:22.732628 GUI: UIMachineViewFullscreen::adjustGuestScreenSize: Adjust guest-screen size if necessary. 00:00:22.732636 GUI: UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 1920x1200 if necessary 00:00:22.732647 VMMDev: SetVideoModeHint: Got a video mode hint (1920x1200x32)@(0x0),(1;0) at 0 00:00:22.732696 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 00:00:22.735033 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=800 h=600 bpp=0 cbLine=0x0 flags=0x2 origin=0,0 00:00:26.770265 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cd7f000 w=1920 h=1200 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0
but doesn't actually render anything (except the cursor) until after this next sequence:
00:00:55.879069 GUI: UIMachineViewNormal::resendSizeHint: Restoring guest size-hint for screen 0 to 1920x1109 00:00:56.185346 GUI: UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 1920x1109 if necessary 00:00:56.190826 VMMDev: SetVideoModeHint: Got a video mode hint (1920x1109x0)@(0x0),(1;0) at 0 00:00:56.219210 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cbaa000 w=1920 h=1109 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0 00:00:56.221423 GUI: UIMachineLogic: Guest-screen count changed 00:00:57.432042 GUI: UIMultiScreenLayout::update: GUI/AutomountGuestScreens is disabled 00:00:57.450848 GUI: UIMachineViewFullscreen::adjustGuestScreenSize: Adjust guest-screen size if necessary. 00:00:57.450875 GUI: UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 1920x1200 if necessary 00:00:57.450897 VMMDev: SetVideoModeHint: Got a video mode hint (1920x1200x32)@(0x0),(1;0) at 0 00:00:57.452888 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=1920 h=1109 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
(in response to Host-F). AFTER that, a second Host-F restores the window to fullscreen and rendering continues to work fine.
Hopefully the logs mean something useful. Cheers.
comment:70 by , 4 years ago
I have this problem with the latest version 6.1.16 and Windows 7 guest machine. Started with VirtualBox 6.0.10 > upgraded to 6.1.16 and everything is fine > installed the new guest additions and now the guest screen won't fill the screen whether in full screen or windowed mode. Clicking the View > Auto-resize Guest Display does nothing. I downloaded and installed the old version and that didn't make a difference until I uninstalled Guest Additions, let it reboot, then reinstalled version 6.0.10 again. Now it works again.
comment:71 by , 4 years ago
I just hit this issue with 6.1.16 and KDE Neon 20.04 guest. Downgrading the guest additions to 6.1.2 restored normal behaviour.
by , 4 years ago
Attachment: | mesg_before_resize.png added |
---|
comment:72 by , 4 years ago
After a few months and releases, this guest fullscreen mode bug is still alive with Linux Debian guests (10.x and sid) on Debian 10.6 host.
Just before the guest screen, initially black, comes on I recorded this Debian Monitor app. message (see image joined).
The problem seems to be there.
Windows guests do not have the same problem.
by , 3 years ago
Attachment: | Vagrantfile added |
---|
Simple light reproductible resize error with guest vmsvga 3d minimal ubuntu-desktop
comment:73 by , 3 years ago
Reproduced with this env. Host:
- Windows 10 2004 "Version 10.0.19041 Build 19041"
- Processor Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2208 Mhz, 6 Core(s), 12 Logical Processor(s)
- Installed Physical Memory (RAM) 16.0 GB
- No dedicated GPU
- Vagrant 2.2.16 (latest)
- vagrant-persistent-storage (0.0.49, global) (latest)
- vagrant-vbguest (0.29.0, global) (latest)
- Virtualbox 6.1.22 (latest)
Guest:
- Ubuntu 20.04 LTS with default ubuntu-desktop package
- Guest Additions 6.1.22
- VMSVGA 3D acceleration enabled
- Any other details in joined this simple and reproductible Vagrantfile https://www.virtualbox.org/attachment/ticket/19496/Vagrantfile
Symptoms:
(1) With VMSVGA and 3D accel, the VM starts and shows me a black screen after a few minutes.
(2) I have to change to vboxsvga and reboot to see the desktop. glxinfo shows direct rendering is true. But the moment I resize, nothing change, it freezes. I can only see the mouse cursor moving but no click possible. However, if I click in "View" "Virtual Screen 1" and resize to any resolution (even 1920x1200), the VM works very well!
(3) Strangely, if I change the Vagrantfile and remove the "--no-install-recommends" for ubuntu-desktop, then with VMSVGA and 3D accel, and with
vagrant destroy && vagrant up
the VM starts and shows me the desktop this time!!! But I have the same issue with resize.
I opened a discussion here https://forums.virtualbox.org/posting.php?mode=reply&f=3&t=102797&sid=d8f3e98a8e7afe0db3d43214c4cb56e4 although that might be a duplicate of this, in which case I might delete the topic.
comment:74 by , 3 years ago
I can add that I tested with Ubuntu bionic and with VboxSVGA, resize works. But with VMSVGA, the display freezes before the login screen.
config.vm.box = "ubuntu/bionic64" config.vm.box_version = "20210501.0.0"
I find Virtualbox support of Linux very bad, and I spent hours on this. I will wait before migrating my Windows VMs to Linux...
comment:75 by , 3 years ago
This is solved for me: see https://bugs.launchpad.net/cloud-images/+bug/1928563. Recommended solution:
- either install missing drivers:
sudo apt install linux-image-generic
- or move from Canonical official Ubuntu boxes to better Bento official boxes (recommended by Vagrant). Eg: https://app.vagrantup.com/bento/boxes/u ... 02012.23.0
comment:76 by , 2 years ago
I experienced this same issue with an Ubuntu 22.04 host running VirtualBox 6.1.34_Ubuntu r150636 and a Ubuntu 20.04 VM running guest services 6.1.38_Ubuntur153438.
I was booting the VM using vagrant based on the bento/ubuntu-20.04 box version 202005.21.0.
Like the others above, my VM presented a black screen that refreshed to show the desktop if I resized the window.
None of the following worked:
- sudo apt install linux-image-generic on the VM
- switching between VMSVGA and VBoxSVGA
- enabling or disabling 3d acceleration
The only thing that worked for me was to ensure vagrant started the VM with the gui rather than headless mode using the following settings:
config.vm.provider "virtualbox" do |v| v.gui = true end
The default used by vagrant is to run virtualbox VMs in headless mode, which produced the black screen when you manually opened the VM window from the main VirtualBox interface. In non-headless mode, the desktop was displayed correctly.
I can reproduce this issue with some Linux vms while some others seem to work as expected. A fix will follow.