VBoxClient: Failed to set graphics capability, rc=VERR_NOT_SUPPORTED

[Crenel]

Host is Windows 7 Pro 64-bit; guest is openSUSE 13.2 32-bit. Previously functioning correctly with this host and this VM. VM display is no longer using custom dimensions, but preset 4:3-aspect dimensions seem to work. Upon logging in to account in guest OS, I receive the following two errors:

• vBoxClient: Failed to set graphics capability, rc=VERR_NOT_SUPPORTED
• vBoxClient: Initialising service: VERR_NOT_SUPPORTED

The background on this is that I was running VirtualBox 4.3.20 (I think) until this morning. After being prompted about a new version (4.3.24) I decided to upgrade, including updating the Guest Additions. (Oops.) If I remember right, this problem appeared on the first boot after the Guest Additions upgrade. I then tried 4.3.25 (not seeing that .26 was already available), with the matching(?) Guest Additions, and the behavior was the same. I then installed 4.3.26 and the matching Guest Additions, and the behavior is still the same.

While I can use preset sizes, they are all 4:3 and are either significantly smaller than what I want to use or are too large vertically, imposing scrolling (not ideal).

I'm assuming the 'component' is 'guest additions' but I'm not sure that's correct.

[Crenel]

Correction/clarification: Hours after filing this bug report I realized that it actually would allow me to resize the window, even though it lost my earlier size settings. I tried rebooting and it kept the new custom size, although it still shows the same two errors when I log in. This seems to merit a downgrade in the priority of resolving this defect.

[Michael Thayer]

Would you be able to attach a log file from the virtual machine, just in case?

[Michael Thayer]

If you feel adventurous you could also edit the file /usr/src/vboxguest-*/vboxguest/Makefile in the guest, add "-DLOG_ENABLED" to the end of the MOD_DEFS section, re-run "sudo /etc/init.d/vboxadd setup" and re-start the guest. After that there should be a lot more information in the log file.

[RobbySherwood]

same problem for me. Host: Win7 guest: OpenSuSE 13.2 -- i think, it still worked with 4.3.26 and older Guest Additions (4.3.22 or 4.3.24?)

[RobbySherwood]

host log file

[RobbySherwood]

one line repeats very often:

00:04:56.931979 Guest Log: VBoxGuestCommonIOCtl: Unknown request iFunction=0xc0085621 stripped size=0xc0005621

i think also in the clients /var/log/messages

[Frank Mehnert]

RobbySherwood, you are mixing the OpenSUSE 4.3.18 Guest Additions kernel modules and Guest Additions userland tools from a more recent version (newer than 4.3.20). Both (the kernel modules and the userland tools) must fit together. Therefore please uninstall the VirtualBox Guest Additions kernel modules provided by OpenSUSE. I guess you need to uninstall all 'virtualbox-guest-*' packages. After that, execute /etc/init.d/vboxadd setup' and reboot the guest.

[RobbySherwood]

Yeah! :-)

i did

zypper search virtualbox

and removed the 2 foun packets

sudo zypper remove virtualbox-guest-kmp-desktop virtualbox-guest-x11

Then i needed to reinstall the guest additions and IT WORKS AGAIN!

THX!

[Crenel]

I never got around to figuring out what log I should attach, but I was motivated to look at this again after the latest VirtualBox update, because the originally-reported problem of losing custom screen sizes became persistent. After reviewing the other comments about manually removing all virtualbox-guest-* packages and then reinstalling, I tried that and it worked.

I've upgraded VirtualBox many times before and did not start having this problem until I created this ticket earlier this year. My guess: Previously the installation process cleanly removed older versions, but this is no longer happening. That would imply that something changed to cause the clean removal to stop working, but I have no clue where or what that something would be.

[Crenel]

After running through this process on a second virtual machine, I see that it also had a remnant from 4.3.18, like RobbySherwood, so maybe there was something specifically with that version that prevented it from being removed cleanly...?

[Michael Thayer]

If your previous 4.3.18 installation is part of the distribution you are running in the virtual machine then you have to remove it using the native tools (e.g. zypper in OpenSUSE). Our installer does not understand native installations.