Please update to 6.0
Please don't update it till www/phpvirtualbox add support of 6.0 branch.
Created attachment 201612 [details]
Update to 6.0.4.
Please!!! Make 2 separate ports or wait phpvirtualbox 6.0: https://github.com/phpvirtualbox/phpvirtualbox/issues/154
Initial support already commited, but not released yet:
(In reply to VVD from comment #3)
Don't worry, I heard you. :-)
(In reply to Jung-uk Kim from comment #4)
> Please also use version 5.2 if you still need support for 32-bit hosts, as this has been discontinued in 6.0.
Is it mean impossibility to build VirtualBox 6 on 32bit at all, or just Oracle stop make binary packages for 32bit hosts?
(In reply to VVD from comment #5)
> Is it mean impossibility to build VirtualBox 6 on 32bit at all, or just Oracle stop make binary packages for 32bit hosts?
It builds fine for now.
But how long are we going to wait for a 3rd party add-on for this port?
At some point 2 ports have to been made if one is hold hostage by phpvirtualbox imo.
(In reply to Jung-uk Kim from comment #4)
We can update phpvirtualbox right now, 6.0 support already commited.
They can not do make release for a long time.
(In reply to Jung-uk Kim from comment #2)
I applied your patch against revision 491653 and compilation went fine on 12.0-RELEASE-amd64.
• Starting a VM graphically gets stuck at a 0% progress bar
• Using vboxmanage is not better: Waiting for VM "Win7" to power on...
While waiting, CPU usage stays close to zero.
I am now rebuilding with DEBUG on...
(In reply to Jung-uk Kim from comment #2)
With DEBUG on, I got an error at compilation:
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.4/src/VBox/VMM/VMMR3/APIC.cpp:1336:43: error: comparison between
pointer and integer ('void *' and 'RTR0PTR' (aka 'unsigned long'))
Assert(pApicCpu->pvApicPageR3 == NIL_RTR0PTR);
Created attachment 204171 [details]
Update to 6.0.6.
(In reply to Jung-uk Kim from comment #11)
Thank you for your effort and the time you dedicate to this. It is much appreciated.
Created attachment 204412 [details]
Update to 6.0.8.
Created attachment 204430 [details]
Update to 6.0.8 (rebased)
Testing that latest patch, I can still reproduce the problems reported in comment #9 - starting a VM (via GUI, via VBoxManage, headless or with GUI - doesn't matter, it's all the same) waits "forever" (I gave up after ~10min latest) without anything relevant happening (when starting the VM via GUI, a progress bar appears after some time (15s? 30s?) but stays stuck at 0%). That affects old VMs carried over from a 5.2 installation, but also newly created VMs.
(In reply to Christoph Moench-Tegeder from comment #15)
I only tested on 12.0-RELEASE.
Did you test on CURRENT ? If you did not and if Jung-uk Kim can not reproduce on CURRENT, then we kind of know what is going on.
(In reply to Samy Mahmoudi from comment #16)
This is 12.0-RELEASE-p4 - basically, the same setup/problem as you have (had?). It's not clear whether we have a solution for that (have we? did I miss it?).
(In reply to Christoph Moench-Tegeder from comment #17)
We may have something if Jung-uk Kim can not reproduce our freezes on CURRENT.
This would mean our problem is not only related to the port but also to the base system we both use. This would not be a solution though, only a starting point to investigate.
(In reply to Jung-uk Kim from comment #14)
Did you test launching a VM on FreeBSD-CURRENT ?
(In reply to Samy Mahmoudi from comment #19)
> Did you test launching a VM on FreeBSD-CURRENT ?
Yes, of course. Does it only happen with Windows guests? Did you turn on 2D/3D acceleration for the guests?
Created attachment 204727 [details]
Update to 6.0.8
Never mind. Please try this.
(In reply to Jung-uk Kim from comment #21)
Yay! Progress! Thanks!
With aforementioned setup (and a Linux guest) the VM starts and seems to be ok.
Only one glitch: "VBoxManage startvm --type headless" fails with:
: cmt@elch:~$ VBoxManage startvm host1 --type headless
: Waiting for VM "host1" to power on...
: VBoxManage: error: Unable to load R3 module /usr/local/lib/virtualbox/VBoxDD.so (VBoxDD): /usr/local/lib/virtualbox/VBoxDD.so: Undefined symbol "glXMakeCurrent" (VERR_FILE_NOT_FOUND)
: VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole
This only happens with startvm in headless mode - other VBoxManage operations (like showinfo or controlvm) or even "start" without "--type headless" work just fine.
Created attachment 204742 [details]
Update to 6.0.8 (fixed OpenGL issue)
This patch should fix the OpenGL issue. Please try this.
(In reply to Jung-uk Kim from comment #23)
This looks good - my VMs start (with and without GUI), new guest additions are working, shared folders ok... great!
Will the 6,0 update get committed any time soon?
Considering that this 3rd party add-on added support
for vbox 6 with this commit a few months ago (April 2019)
Can we please move forwards on this and get virtual box updated?
I don't see the logic behind requiring the normal users of
virtualbox that don't rely on a web interface from being able to
run the modern version of virtualbox without needing to venture
in to manually compiling this.
There is absolutely no need to wait for phpvirtualbox. There is a (to my opinion) much better alternative, which already supports Virtualbox version 6 on freebsd since January this year.
So please update to Virtualbox v6 asap.
I am working with it since beginning 2018 and it is working flawlessly, though installation was a bit complicated.
It would make sense that we rename virtualbox-ose and friends to virtualbox-ose5 and add this as virtualbox-ose6. There are many examples of this in the tree such as xpdf and many others.
(In reply to Cy Schubert from comment #28)
Agree - make separate ports with 5 and 6.
VB 6 have stability problems on FreeBSD - already fixed?
RemoteBox isn't web application (but phpvirtualbox is) - it's stand-alone rich client on GTK.
(In reply to VVD from comment #29)
Why should it be mandatory to be a web app? I can work very well with virtualbox on remotebox on my remote server. The only difference is that you must install remotebox on every computer that needs access to virtualbox.
I really don't see what is the problem? For me it is about the functionality and I prefer to be able to work with vbox 6 and install remotebox on more machines instead of waiting forever on phpvirtualbox
(In reply to BonHomme from comment #30)
> Why should it be mandatory to be a web app?
Are you serious?
> The only difference is that you must install remotebox on every computer that needs access to virtualbox.
> I really don't see what is the problem?
You must install software on every computer, as you said before, and this is the problem!
How to use it on non-supported platforms, for example?
It's classical problem with all stand-alone rich clients compared to web applications.
> For me it is about the functionality and I prefer to be able to work with vbox 6 and install remotebox on more machines instead of waiting forever on phpvirtualbox
You can do it self now if you need - patch is here.
Are stability issues of VB 6 on FreeBSD fixed already?
(In reply to VVD from comment #31)
Come on. Be a little bit practical please.
How many people really need to reach Virtualbox from more than one or two machines? Beside that, once you installed Remotebox on the client and Freebsd, installing the next client is just a matter of a few minutes.
Using phpvirtualbox or remotebox is just a matter of choice and what is most important to you as the Virtualbox funtionality in both solutions is the same. Only the access method is different. And for people that work with an unsupported platform nothing changes. They have to wait for phpvirtualbox anyway.
So as remotebox is an excellent, very well working and very well maintained alternative to phpvirtualbox (remotebox supports V6 already since January 6 2019) I really don't understand why everybody using virtualbox must wait (more than 8 months) for phpvirtualbox to be ready.
And as far as using an (untested?) and unsupported patch for Vbox 6: Are yóu serious?
> How many people really need to reach Virtualbox from more than one or two machines?
At least 10 people in our company use it from different devices.
And we regularly use it from arbitrary computers in the office.
> Beside that, once you installed Remotebox on the client and Freebsd, installing the next client is just a matter of a few minutes.
Please stop this stupid dispute "rich client vs web application"! Web application is zero-cost support on client side and "true" cross-platform. Rich client isn't.
> And as far as using an (untested?) and unsupported patch for Vbox 6: Are yóu serious?
And you think that this patch will become tested after the maintainer updates the port? "Are yóu serious?"
Just make separate port for VB 6 and keep VB 5 as more stable version. And you can be happy to be beta-tester for this patch.
But better get this patch included in the upstream.
Can we keep this civil and on-topic? Thank you.
To summarize, the questions are:
- Are there any outstanding issues with VirtualBox 6? (It works for me, but sometimes I'm one of the lucky ones...)
- If there are any ports which cannot be updated to work with VirtualBox 6, is there anything preventing a repocopy and having both virtualbox 5 and 6 in the tree? (I don't mind the naming, let it be "virtualbox" and "virtualbox6" or "virtualbox5" and "virtualbox", or some variation thereof).
Is that the state of things right now?
I too would like the VirtualBox ports upgraded (the current latest from upstream is 6.0.10) -- at least, the ose-guest-additions, because that's all I use.
The one point, that all of the virtualbox ports have omitted so far is adding -DPAE to the compiler command lines building kernel modules. I'm trying to deal with this myself currently with things like this:
but I'm never certain, if they have the proper effect every time or if my vboxguest.ko is subtly miscompiled :(
This may be less important to the server port, as VM-hosting servers these days tend to be 64bit anyway, but it is perfectly normal for a guest VM to be 32-bit -- using PAE to have more than 4GB of total memory, while limiting each process to 4GB.
I'm not sure, if PAE should be a "flavor" or an option... Given that it only affects kernel-modules (both for the host- and the guest- ports), maybe, the vboxguest.ko needs a port of its own (like the already-existing virtualbox-ose-kmod).
My WIP for 6.0.12 is here: https://github.com/lwhsu/freebsd-ports-virtualbox-ose
(In reply to Li-Wen Hsu from comment #36)
That 6.0.12 works fine for what I'm doing (FreeBSD host, guests are mostly Linux).
One small nitpick: when downloading the Guest Additions ISO image, right when the download is at 100%, an error message pops up: "The network operation failed with the following error: During network request: Unknown reason." (that's really neither specific nor helpful...). Downloading the image manually into the right place works fine.
Created attachment 207660 [details]
When loading the vboxguest (built from 6.0.12) after booting a PAE guest (11.3-STABLE), I usually get the kernel panic attached. It takes multiple reboots to get the module to load, after which the machine seems usable.
Is there something we need to patch in the guest code?