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?
(In reply to Li-Wen Hsu from comment #36)
I've downloaded your port. ose-kmod compiles fine but the main app fails with:
invalid application of 'sizeof' to an incomplete type 'struct crypt_data'
size_t const cbCryptData = RT_MAX(sizeof(struct crypt_data) * 2, _256K);
forward declaration of 'crypt_data'
typedef char *(*PFNCRYPTR)(const char *, const char *, struct crypt_data *);
Sorry for not mentioning.
I decided to skip 6.0. 6.1 is imminent.
(In reply to Jung-uk Kim from comment #41)
Not sure if this helps, I was working on cleaning the patches for 6.1:
(In reply to Li-Wen Hsu from comment #42)
Oh, I didn't know. I already have a patch for 6.1.0 RC1.
(In reply to Jung-uk Kim from comment #43)
As far as I remember, 6.1 drop support of i386 hosts...
Created attachment 209925 [details]
VBOX 6.1.0 port
The above is mu attempt to compile VBox 6.1.0 after tweaking the patches.
The VMs start and run OK.
1) with 2 monitors, the 2nd monitor doesn't get the same max resolution as the 1rst.
2) Shutting down the VM freezes the host UI (in my case, kde). Had to alt+F1 to issue a ^C to kill kde.
uname: FreebSD 11.3-STABLE
Created attachment 209927 [details]
Update to 6.1.0
(In reply to Mario Lobo from comment #45)
Thanks but I already have 6.1 patches. Please let me know if I missed anything.
Note the patches are NOT final and you need to update devel/kBuild first.
(In reply to Jung-uk Kim from comment #48)
Could you provide a link for your patches?
To me, this is the version with the best performance I've seen! The VMs are really fast!.
(In reply to Jung-uk Kim from comment #48)
Ok. Found the patches and applied them. I had to make little corrections on a few files but everything ended up compiling and running.
The problems I mentioned on the attempt on my patches remained with yours:
1) with 2 monitors, the 2nd monitor doesn't get the same max resolution as the 1rst. Only after I resize de 2nd monitor, it adjusts to full screen.
2) Shutting down the VM freezes the host UI (in my case, kde). Had to alt+F1 to issue a ^C to kill kde. If I leave the VM on a background workspace, I can terminate the VM without having the host UI frozen. The status on VBox never gets past "stopping", although the logs show that the VM has finished.
Other than that, the VMs run really fast and are fully operational while up.
So, I had been trying these patches as they came about.
The 6.0.x line seemed to work perfectly fine (albeit that I've never been able to get audio to work in the guest, despite the host driver working on the host, but this was a problem for me in the 5.x line too and I don't know when that started happening).
But 6.1.0 seems to be trouble galore. I've had the following issues at one point or another:
* VMs won't start (I would get a pretty generic NS_ERROR_FAILURE 0x80004005 in component SessionMachine, and while others online say it was from starting from a snapshot, I was starting from an offline VM)
* With a dual-monitor Windows 10 VM and using mouse integration, I was getting an issue with the mouse cursor treating the first monitor as if it was both monitors combined (so as I moved right, the cursor position inside the VM itself was going farther right than it should've)
* When I tried to change the display type (which was originally VBoxVGA) to another option, I'd either start getting those generic errors from the first point or it would start fine, but the mouse issue would persist. At one point I switched back to VBoxVGA and ran into an issue where the guest display was some small 640x480 I think with an almost grayscale like 16-color-ish looking display.
* Every time a VM shuts down, it says it aborted instead of being powered off. I see the following in one of the logs:
00:00:05.595427 !!Assertion Failed!!
00:00:05.595427 Expression: <NULL>
00:00:05.595428 Location : /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.0/src/VBox/VMM/VMMR3/MMHeap.cpp(667) void MMR3HeapFree(void *)
00:00:05.595433 Stack :
00:00:05.595453 Invalid heap header! pv=0000000818c3be20, size=0x2d6e492d
* Some of the above issues ended up with the processes of VBoxNetDHCP, VBoxSVC and VBoxXPCOMIPCD still persisting even though no VMs were running (and not even the manager GUI was running). I didn't attempt to stop them because I didn't want to possibly cause a kernel panic.
* After a forced reboot caused by a kernel panic (that wasn't caused by VirtualBox), my Windows 10 VM no longer seems to want to do mouse integration (regardless of if the Guest Additions were installed or not) and wouldn't start if I had my guest audio driver set to Intel HD, getting the following in the log:
00:00:28.109998 !!Assertion Failed!!
00:00:28.109998 Expression: RT_SUCCESS_NP(rc2)
00:00:28.109999 Location : /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.0/src/VBox/Devices/Audio/DevHDA.cpp(1348) VBOXSTRICTRC hdaRegWriteSDCTL(PPDMDEVINS, PHDASTATE, uint32_t, uint32_t)
00:00:28.110020 Stack :
00:00:28.110052 VERR_NOT_SUPPORTED (-37) - Not supported.
I just had another assertion pop up in the Windows 10 VM after it was idle for a bit over half a day:
13:54:39.917997 !!Assertion Failed!!
13:54:39.917998 Expression: pTimer->enmClock == TMCLOCK_VIRTUAL_SYNC ? enmState == TMTIMERSTATE_ACTIVE : enmState == TMTIMERSTATE_PENDING_SCHEDULE || enmState == TMTIMERSTATE_PENDING_STOP_SCHEDULE
13:54:39.917999 Location : /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.0/src/VBox/VMM/include/TMInline.h(39) void tmTimerQueueUnlinkActive(PTMTIMERQUEUE, PTMTIMER)
13:54:39.918016 Stack :
Back to the group. I do not have enough time to work on it.
May be keep 3 different ports:
emulators/virtualbox-ose-52 - old stable
emulators/virtualbox-ose-60 - new, support CPUs without VT-x/AMD-V
emulators/virtualbox-ose-61 - new, support CPUs with VT-x/AMD-V only
So, will be 6.1 landed in port-tree ? or still it is not stable.
(In reply to Hadi from comment #55)
6.1.0 is still unstable. The last stable version I compiled and I use is 6.0.8. The ports version is still 5.x, and VBox is already up to 6.1.4.
I managed to compile version 6.1.0. It runs fine and it is pretty fast, at least in short tests. The problem is that instead of shutting down the machine, it aborts them, no matter what way you used to shut them down. The same happened with Jkim's patch for it.
I wish I had the knowledge to "correct" the code but unfortunately I don't, so I guess I'll just have to wait.