For me, VMSVGA on VBox 6.1.2 gets a black screen for Manjaro guest. I have to choose VBoxSVGA. By doing so, the VBox setting warns that I am not using the recommended controller. There appears a conflict somewhere.
In my experience, that warning can be safely ignored. It would be nice if upstream would fix the issue (by changing one line of code) but I doubt that will happen.
It is correct there is a warning - for the time being you can ignore it - I think it is a little mysterious why VirtualBox devs insist you should use a VMSVGA.
But yet again Arch and be inheritance Manjaro - has this weird issue - and I think it is because the display driver is included in the kernel.
The kernel includes
vboxvideo (not sure whether it is VBoxVGA or SVGA?) and
From my understanding, this means that VBox uses the built-in kernel drivers and not the ones included in the additions.
VMSVGA works well here, and with VBox 6.1.2 the window resizing issue seems to be fixed too; from changelog:
Linux guest: improve resize and multi-monitor handling for VMs using VMSVGA (known remaining issue: do not disable a monitor "in the middle", causes confusion)
I can't reproduce resizing working with VMSVGA using VBox 6.1.2 on Manjaro testing. I'm guessing this assumes that you're running the official guest extensions.
Yes, that's entirely possible.
Maybe I should check this with a custom kernel without the drivers...
Did you use Manjaro's guest modules, or VBox's guest additions? I had to remove the former and install the latter for shared folders to work. Not sure if that's related to the controller.
You are referring to VBox's guest additions? That's what I am using, but I get a black screen
The screen resize does not work with an Arch guest using VMSVGA.
Running on a Manjaro host.
I'm not sure how that is supposed to help. The in-kernel vboxguest module simply doesn't support resizing. Arch doesn't build VBox's vboxguest module for kernels since 4.16 and relies on the in-kernel module instead.
Will be fixed in Manjaro ISOs 19.x. Mhwd was detecting VMSVGA as Vmware and started the Vmware guest additions instead.
Probably because the in-kernel
vboxguest module is older than the normal Additions' one - and with the Additions' module, resizing doesn't work either here.
Sure did last time I tried it (before implementing video-virtualmachine in mhwd).
Maybe because I'm running this VMSVGA Manjaro guest on a MacOS host?
It's not an issue for me because I normally do not use auto-resize, I was just investigating what could be the cause (kernels 4.19 and 5.4, both with Manjaro modules + guest-utils as well as with VirtualBox' Additions).
In what kernel will the solution for this issue be provided ?
in vmsvga i can choose resolutions i don't want to work with. However in vboxsvga the virtual machine can be resized stiil no icons.
likewise here, on a MacBookPro. VMSVGA Manjaro gets a black screen with VBox's guest addidtions.
If you follow the thread at the Arch bug tracker - it is a generic problem for anything Arch based.
Arch is on linux 5.4.13 and 4.19.97 and it does not yet work on Arch - so your guess is as good as mine.
I do not get a black screen with either - it's only the auto-resize feature that doesn't work.
If you have 3D accel enabled, try disabling it.
FYI - copy & paste of my personal CherryTree notes, on a battle i have been fighting ever since i changed to Manjaro [as Host] in late 2017. I can personally verify that these techniques also work for me in Cleanjaro [Host], & Arch [Host].
Note: The key to me eventually winning this battle was my decision to abandon the MJ Wiki for VirtualBox -- it never ever ever worked for me [wrt Shared Folders].
Shared Folders in Linux Guests.
2019/11/29 - 01:13: For most of the past 10 months ALL my Manjaro & other Arch-based VMs [except KaOS, weirdly] have had NO Shared Folders functionality [from a particular kernel version onwards they all broke (NB - All my non-Archie VMs' SFs continue to work just fine)]. ALL my historical tricks failed me. Essentially for most of this time, though occasionally i still fought, i'd largely just given up altogether. Tonight however, when i was dog-tired & about to head off to bed, i had a flash of inspiration, & decided to test it out.
I did this in my “Cleanjaro KDE” VM. It WORKED -- finally both its SF began working!
- Launch Pamac or terminal in the VM & search for all installed packages containing “virtualbox”. Remove them.
- Reboot VM.
- Load the Oracle Guest Additions CD Image via the VM's Menu's Devices category.
- In either the file-manager or terminal, navigate to this CD directory & then execute
sudo ./VBoxLinuxAdditions.runin terminal.
Reboot VM→ I subsequently discovered i can omit this step.
sudo chmod o+rx /mediain terminal.
- Reboot VM.
- In either the file-manager or terminal, navigate to
- If had previously already added the desired SFs via the VM's Menu's Devices - Shared Folders - Shared Folders Settings option, said SFs should now be visible & accessible. However if not, weirdly just giving them a little tickle seems to make them magically appear. Ie, do Devices - Shared Folders - Shared Folders Settings option again, & change the status of each SF... eg, if Permanently mounted, change to Temporary, or vice versa. Alternatively removing them then re-adding them can also work.
[kdemeoz@cleanjaro-VM ~]$ cd /media [kdemeoz@cleanjaro-VM media]$ ls -la total 20 drwxr-xr-x 4 root root 4096 Nov 29 00:59 . drwxr-xr-x 18 root root 4096 Nov 5 20:34 .. drwxrwx--- 1 root vboxsf 4096 Sep 23 15:25 sf_SHARE_Folder drwxrwx--- 1 root vboxsf 4096 Oct 2 20:33 sf_VM_Share_Folder [kdemeoz@cleanjaro-VM media]$
All the preceding steps have been tried by me over the past months & years in fighting my Manjaro/Arch SFs, except for #1. That seems to be the special sauce. This is deeply ironic given it is a 100% contradiction of the Manjaro Wiki -- doh! The trigger for my late-night inspiration was the sudden thought that maybe the Oracle GA CD & the VM's Manjaro Repo VB packages were fighting each other, thereby bugggering the SFs. Given i've known for yonks that following the Wiki is WRONG wrt SF functionality, it now belatedly seemed logical to try the exact opposite, viz, remove the VM's repo packages, use only the Oracle GA image. Huzzah!!
2019/11/29 - 16:19: My latest Epic Saga of The Quest For The VM Shared Folders.
[per last night's CherryTree notes methodology]
- “Cleanjaro KDE” VM [Testing-branch]: SFs are now GOOD.
$ uname -r 5.3.13-1-CLEANJARO
- "Manjaro KDE+GNOME (now KDE+Cinnamon)" VM [Unstable-branch]:
[kdemeoz@Manjaro18KDEbetaVM ~]$ mhwd-kernel -li Currently running: 5.3.13-1-MANJARO (linux53) The following kernels are installed in your system: * linux419 * linux53 * linux54 [kdemeoz@Manjaro18KDEbetaVM ~]$
With 5.4, SFs still nfg, but boot DMESG shows error "Failure to load kernel modules".
With 5.3, no such DMESG error, & SFs are now GOOD.
- "Manjaro KDE Clone" VM [Testing-branch]: SFs are now GOOD.
$ uname -r 5.3.13-1-MANJARO
- “Manjaro KDE” VM [Stable-branch]: SFs are now GOOD.
$ uname -r 5.3.12-1-MANJARO
- "Manjaro KDE to Cleanjaro KDE" VM [Stable-branch]: SFs are now GOOD.
$ uname -r 5.3.13-1-CLEANJARO
"ArchLabs Plasma" VM: SFs were ALREADY GOOD [no
virtualboxpackages were installed; in fact, i had performed all these steps when i first created this VM].
“Anarchy Linux” VM: SFs are now GOOD.
[kdemeoz@anarchyVM]: ~>$ uname -r 5.3.13-arch1-1 [kdemeoz@anarchyVM]: ~>$
- “EndeavourOS” VM: SFs are now GOOD.
[kdemeoz@EndeavourOS-VM ~]$ uname -r 5.3.13-arch1-1 [kdemeoz@EndeavourOS-VM ~]$
- “Zen-Installer Arch” VM: SFs are now GOOD.
[kdemeoz@zen-revenge-arch-VM ~]$ uname -r 5.3.13-zen1-1-zen [kdemeoz@zen-revenge-arch-VM ~]$
I don't understand the nitty gritty, but afaik there is something fundamentally weird about Manjaro/Cleanjaro kernels & their associated modules that is incompatible with Oracle Shared Folders support. Once all traces of the MJ/CJ VB packages are removed, then the Oracle Guest Additions installed, SFs correctly work.
NB: The MJ VM VB packages alone do NOT allow SFs to work. Only the Oracle GA gets any of my SFs working, but to do so, the MJ packages must first be removed.
Forcing 3D Acceleration & 256 MB VRAM.
2019/12/24 - 20:08
SETUP 3D Acceleration VboxSVGA with 256Mo on VirtualBox 6.1.
Follow the link above for all the explanatory pictures for the following steps.
1/ First checked the 3D inside your VM Name settings, and let whatever graphic controler you want then click OK.
2/ Close the window settings and click as below directly on the name VMSVGA of your VM
3/ Then a little window appears so change it for VboxSVGA and click OK.
4/ Now the VboxSVGA with 3D checked keeps right.
5/ Click on the 128Mo (could another value) then a little window appears
6/ Setup to 256Mo with scroller or button then click ok
7/ Your VM is ready with 3D acceleration on VBoxSVGA 256Mo
My own remarks:
- This trick works well.
- It's my frequent experience that some Linux distro VMs need VMSVGA, whilst others only run with VBoxSVGA, or vice versa.
- Equally, it seems hit & miss / needing trial & error, when 3D Accel can be used or not.
- When inappropriate combos happen per distro, the result is a non-fullscreen black-screen, or a non-fullscreen good screen... either way unusable.
Thank you for sharing
Your notes do match other reports that the Arch modules and the Manjaro modules do not work.
Others have reported that removing the distro modules and running the installer from guest iso fixes issues with both shared folders and dynamic display sizing.
It also matches what is going with the kernel as is linked earlier to Arch bugtracker by @TotallyNotElite.
I must say it is a bumpy road to get VirtualBox functioning - and it appears lot of the trouble stems from Arch upstream and their efforts to make VirtualBox support a kernel thing.
Fwiw, my perception [ie, i have no objective proof of this] is that once VB 6.1 arrived, the VM behaviour wrt SFs & 3DAccel + Display-type, became rather unreliable & unpredictable [even compared to historical] ... for all my Arch & Arch-based distros.