Bug 234878

Summary: emulators/virtualbox-ose: Update to 6.1
Product: Ports & Packages Reporter: kunda <chitty_cloud>
Component: Individual Port(s)Assignee: Virtualbox Team (Nobody) <vbox>
Status: Closed FIXED    
Severity: Affects Only Me CC: adridg, cmt, cy, cyberbotx, daniel, darin, dereks, didier.castellacci, dnelson_1901, dutchman01, emaste, grahamperrin, ilavsky.martin, imb, jkim, jwb, lapo, lobo, ludacrisvp, lwhsu, madpilot, mgamsjager, mi, n.ospam, osidorkin, pauamma, philipp, pi, pub1q4wf7u, rezaee.hadi, ronald-lists, samy.mahmoudi, sdalu, sepotvin, sghctoma, sharky, spam123, swills, trueos, vbox, vvd
Priority: --- Keywords: feature, needs-patch, needs-qa
Version: LatestFlags: tobik: maintainer-feedback? (vbox)
Hardware: Any   
OS: Any   
URL: https://reviews.freebsd.org/D28871
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242637
Attachments:
Description Flags
Update to 6.0.4.
none
Update to 6.0.6.
none
Update to 6.0.8.
none
Update to 6.0.8 (rebased)
none
Update to 6.0.8
none
Update to 6.0.8 (fixed OpenGL issue)
none
Kernel panic
none
VBOX 6.1.0 port
none
Update to 6.1.0
none
VBOX 6.1.6 port
none
Port of VitualBox 5.2.42
none
VBox 6.1.10 port files
none
VBox 6.1.10 kmod port files
none
VirtualBox 6.1.16 port files
none
14.0-CURRENT failed build of emulators/virtualbox6-ose-kmod from freebsd/freebsd-ports-kde
none
distinfo for virtualbox6-ose-6.1.18
none
distinfo for virtualbox6-ose-kmod-6.1.18
none
6.1.18 in lieu of 6.1.16
none
distinfo for virtualbox6-ose-6.1.18
none
VirtualBox 6.1.16 port
none
Screenshot of the application
none
VirtualBox 6.1.18 revised patch
none
VirtualBox 6.1.18 revised patch
none
Kernel modules, pacakges, services
none
6.1.18 port files archive none

Comment 1 VVD 2019-01-28 12:16:43 UTC
Please don't update it till www/phpvirtualbox add support of 6.0 branch.
Comment 2 Jung-uk Kim freebsd_committer 2019-02-01 18:29:24 UTC
Created attachment 201612 [details]
Update to 6.0.4.
Comment 3 VVD 2019-02-01 22:54:07 UTC
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:
https://github.com/phpvirtualbox/phpvirtualbox/commit/3a5a1ce787515183788fb2e63ae83c1b00f71ffc
Comment 4 Jung-uk Kim freebsd_committer 2019-02-01 23:49:09 UTC
(In reply to VVD from comment #3)
Don't worry, I heard you. :-)
Comment 5 VVD 2019-02-03 13:51:57 UTC
(In reply to Jung-uk Kim from comment #4)
Thanks! [-:

BTW:
> Please also use version 5.2 if you still need support for 32-bit hosts, as this has been discontinued in 6.0.
https://www.virtualbox.org/wiki/Downloads
Is it mean impossibility to build VirtualBox 6 on 32bit at all, or just Oracle stop make binary packages for 32bit hosts?
Comment 6 Jung-uk Kim freebsd_committer 2019-02-04 18:24:26 UTC
(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.
Comment 7 Matthias Gamsjager 2019-04-17 14:48:21 UTC
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.
Comment 8 rozhuk.im 2019-04-17 19:19:32 UTC
(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.
Comment 9 Samy Mahmoudi 2019-04-24 16:37:18 UTC
(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...
Comment 10 Samy Mahmoudi 2019-04-24 21:36:22 UTC
(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);
Comment 11 Jung-uk Kim freebsd_committer 2019-05-02 20:36:59 UTC
Created attachment 204171 [details]
Update to 6.0.6.
Comment 12 Samy Mahmoudi 2019-05-11 23:40:31 UTC
(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.
Comment 13 Jung-uk Kim freebsd_committer 2019-05-17 01:10:15 UTC
Created attachment 204412 [details]
Update to 6.0.8.
Comment 14 Jung-uk Kim freebsd_committer 2019-05-17 14:52:17 UTC
Created attachment 204430 [details]
Update to 6.0.8 (rebased)
Comment 15 Christoph Moench-Tegeder freebsd_committer 2019-05-27 10:49:33 UTC
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.
Comment 16 Samy Mahmoudi 2019-05-27 11:49:06 UTC
(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.
Comment 17 Christoph Moench-Tegeder freebsd_committer 2019-05-27 12:39:01 UTC
(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?).
Comment 18 Samy Mahmoudi 2019-05-27 21:38:02 UTC
(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.
Comment 19 Samy Mahmoudi 2019-05-27 21:40:00 UTC
(In reply to Jung-uk Kim from comment #14)
Hi again,

Did you test launching a VM on FreeBSD-CURRENT ?
Comment 20 Jung-uk Kim freebsd_committer 2019-05-30 18:07:08 UTC
(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?
Comment 21 Jung-uk Kim freebsd_committer 2019-05-30 22:29:14 UTC
Created attachment 204727 [details]
Update to 6.0.8

Never mind.  Please try this.
Comment 22 Christoph Moench-Tegeder freebsd_committer 2019-05-31 10:14:08 UTC
(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.
Comment 23 Jung-uk Kim freebsd_committer 2019-05-31 14:40:34 UTC
Created attachment 204742 [details]
Update to 6.0.8 (fixed OpenGL issue)

This patch should fix the OpenGL issue.  Please try this.
Comment 24 Christoph Moench-Tegeder freebsd_committer 2019-06-02 13:41:40 UTC
(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!
Comment 25 Yuri Victorovich freebsd_committer 2019-06-12 05:55:11 UTC
Will the 6,0 update get committed any time soon?
Comment 26 eweiman 2019-08-08 15:32:05 UTC
Considering that this 3rd party add-on added support 
for vbox 6 with this commit a few months ago (April 2019)

https://github.com/pasha1st/phpvirtualbox-6/commit/bbdc56de41533e1ee420dafd620e96d0f8803ba9

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.
Comment 27 BonHomme 2019-08-18 11:34:47 UTC
Hello,

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.

https://sourceforge.net/projects/remotebox/
http://remotebox.knobgoblin.org.uk/
https://wiki.archlinux.org/index.php/RemoteBox

I am working with it since beginning 2018 and it is working flawlessly, though installation was a bit complicated.
Comment 28 Cy Schubert freebsd_committer 2019-08-18 12:52:27 UTC
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.
Comment 29 VVD 2019-08-18 12:59:24 UTC
(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.
Comment 30 BonHomme 2019-08-18 13:16:59 UTC
(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
Comment 31 VVD 2019-08-18 14:18:31 UTC
(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.
YES!

> 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?
Comment 32 BonHomme 2019-08-18 15:08:42 UTC
(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?
Comment 33 VVD 2019-08-18 19:50:04 UTC
> 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.
Comment 34 Christoph Moench-Tegeder freebsd_committer 2019-08-18 20:49:23 UTC
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?
Comment 35 Mikhail Teterin freebsd_committer 2019-08-27 14:45:54 UTC
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:

.if ${.CURDIR:M*/ports/*virtualbox-ose*}
CFLAGS+=        -DPAE
COPTFLAGS+=     -DPAE
CXXFLAGS+=      -DPAE
.endif

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).
Comment 36 Li-Wen Hsu freebsd_committer 2019-09-14 00:23:28 UTC
My WIP for 6.0.12 is here: https://github.com/lwhsu/freebsd-ports-virtualbox-ose
Comment 37 Christoph Moench-Tegeder freebsd_committer 2019-09-15 20:29:48 UTC
(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.
Comment 38 Mikhail Teterin freebsd_committer 2019-09-20 16:55:11 UTC
Created attachment 207660 [details]
Kernel panic

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?
Comment 39 Mario Lobo 2019-10-17 19:44:31 UTC
(In reply to Li-Wen Hsu from comment #36)

I've downloaded your port. ose-kmod compiles fine but the main app fails with:


ports/emulators/virtualbox-ose/work/VirtualBox-6.0.12/src/VBox/Runtime/r3/posix/process-creation-posix.cpp:368:49: error:
      invalid application of 'sizeof' to an incomplete type 'struct crypt_data'
        size_t const       cbCryptData = RT_MAX(sizeof(struct crypt_data) * 2, _256K);
                                                                          ^     ~~~~~~~~~~~~~~~~~~~

ports/emulators/virtualbox-ose/work/VirtualBox-6.0.12/src/VBox/Runtime/r3/posix/process-creation-posix.cpp:190:63: note:
      forward declaration of 'crypt_data'
typedef char *(*PFNCRYPTR)(const char *, const char *, struct crypt_data *);
Comment 40 Mario Lobo 2019-10-17 19:46:08 UTC
Sorry for not mentioning.

FreeBSD 11.3-STABLE
Comment 41 Jung-uk Kim freebsd_committer 2019-12-04 20:49:17 UTC
I decided to skip 6.0.  6.1 is imminent.
Comment 42 Li-Wen Hsu freebsd_committer 2019-12-04 21:01:23 UTC
(In reply to Jung-uk Kim from comment #41)
Not sure if this helps, I was working on cleaning the patches for 6.1:
https://github.com/lwhsu/freebsd-ports-virtualbox-ose/pull/1
Comment 43 Jung-uk Kim freebsd_committer 2019-12-04 21:10:45 UTC
(In reply to Li-Wen Hsu from comment #42)
Oh, I didn't know.  I already have a patch for 6.1.0 RC1.
Comment 44 VVD 2019-12-05 00:45:17 UTC
(In reply to Jung-uk Kim from comment #43)
As far as I remember, 6.1 drop support of i386 hosts...
Comment 45 Mario Lobo 2019-12-13 22:32:29 UTC
Created attachment 209925 [details]
VBOX 6.1.0 port
Comment 46 Mario Lobo 2019-12-13 22:38:12 UTC
The above is mu attempt to compile VBox 6.1.0 after tweaking the patches.

The VMs start and run OK.

Problems:

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
Comment 47 Jung-uk Kim freebsd_committer 2019-12-13 22:50:12 UTC
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.
Comment 48 Jung-uk Kim freebsd_committer 2019-12-13 22:53:18 UTC
Note the patches are NOT final and you need to update devel/kBuild first.
Comment 49 Mario Lobo 2019-12-13 23:38:30 UTC
(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!.
Comment 50 Mario Lobo 2019-12-16 14:05:16 UTC
(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.
Comment 51 Naram Qashat 2019-12-19 01:04:44 UTC
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.595434 00000008014439a7
00:00:05.595434 
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.110021 00000008014439a7
00:00:28.110022 
00:00:28.110052 VERR_NOT_SUPPORTED (-37) - Not supported.
Comment 52 Naram Qashat 2019-12-19 14:39:35 UTC
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     :
13:54:39.918016 00000008014439a7
Comment 53 Jung-uk Kim freebsd_committer 2019-12-26 06:57:45 UTC
Back to the group.  I do not have enough time to work on it.
Comment 54 VVD 2019-12-27 14:05:22 UTC
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
Comment 55 Hadi 2020-02-25 13:49:03 UTC
So, will be 6.1 landed in port-tree ? or still it is not stable.
Comment 56 Mario Lobo 2020-03-06 20:54:56 UTC
(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.
Comment 57 Mario Lobo 2020-04-17 14:31:56 UTC
I managed to compile VBox 6.1.6 yesterday without errors.

The GUI comes up OK with everything working (settings, preferences, media manager, etc..).

When I start a VM, the initial console window shows up for about 10 secs but the "PRESS F12 .." never shows. The window closes and a box with a "NS_ERROR_FAILURE 0x80004005" shows. Bellow are the ending log lines in chronological time of file creation:

- VBoxSVC.log

00:00:01.980290 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Windows/Win10/Win10.vbox" with version "1.17-freebsd"
00:00:01.981326 nspr-2   VirtualBox: object created
00:00:07.032477 main     VirtualBox: object deletion starts
00:00:07.033816 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Snow.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.035501 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Debian.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.036172 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Windows7Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.036208 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Windows72Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.036780 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Novell-5.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.037423 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win98-Novell.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.037943 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Praieira_Server.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.038466 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Praieira_Client.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.038992 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win8Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.039022 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win82Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.039690 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/OPNsense.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.040260 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/xuDBServer.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.081253 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Harbour.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.082321 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win764.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.082947 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win7.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.082978 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win72.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.083561 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Klinx.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.084079 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win10.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:07.086053 main     HostDnsMonitor: shutting down ...
00:00:07.086062 main     HostDnsMonitor: shut down
00:00:07.086328 main     {000000080546ca40} HostPowerServiceLinux::~HostPowerServiceLinux: RTThreadWait() for 5000 ms failed with VERR_INVALID_HANDLE
00:00:07.087070 Watcher  ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={d0a0163f-e254-4e5b-a1f2-011cf991c38d} aComponent={VirtualBoxWrap} aText={The object is not ready}, preserve=false aResultDetail=0
00:00:07.087746 main     VirtualBox: object deleted


- VBox.log (VM log)

00:00:04.417050 VD: VDInit finished with VINF_SUCCESS
00:00:04.417156 VD: Opening the disk took 175900 ns
00:00:04.417188 AHCI: LUN#0: disk, PCHS=16383/16/63, total number of sectors 102400000
00:00:04.417459 DrvVD: Flushes will be ignored
00:00:04.417462 DrvVD: Async flushes will be passed to the disk
00:00:04.420181 VD: Opening the disk took 96492 ns
00:00:04.420206 AHCI: LUN#1: disk, PCHS=16383/16/63, total number of sectors 81920000
00:00:04.420653 AHCI#0: Reset the HBA
00:00:04.420657 VD#0: Cancelling all active requests
00:00:04.420661 VD#1: Cancelling all active requests


- selectorwindow.log

00:00:09.318041 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated: Screen 0 work area is actually resized to: 0x0 x 1920x1080
00:00:09.328396 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated: Screen 1 work area is actually resized to: 1920x0 x 1920x1080
00:00:09.347424 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:01:15.203925 ERROR [COM]: aRC=NS_ERROR_UNEXPECTED (0x8000ffff) aIID={c0447716-ff5a-4795-b57a-ecd5fffa18a4} aComponent={SessionWrap} aText={The session is not locked (session state: Unlocked)}, preserve=false aResultDetail=0
00:08:08.517376 ERROR [COM]: aRC=NS_ERROR_UNEXPECTED (0x8000ffff) aIID={c0447716-ff5a-4795-b57a-ecd5fffa18a4} aComponent={SessionWrap} aText={The session is not locked (session state: Unlocked)}, preserve=false aResultDetail=0
Comment 58 Mario Lobo 2020-04-17 14:53:44 UTC
Created attachment 213495 [details]
VBOX 6.1.6 port

My specs:

FreeBSD 11.3-STABLE #1 r350287M
qt 5.10.1
kde 4.14.3
xorg-7.7_3

I reverted back to VBox 6.0.8 which works perfectly.

Attached is the 6.1.6 port in case anyone wants to try it.
Comment 59 Darin Luckie 2020-04-24 18:48:17 UTC
I'm running 12.1-STABLE r359734

I need 6.1 for GNS3 as I am preparing for my CCIE labs and last I tried, VMware was a non-starter.

I took a look at the Makefile and and the PR for LLVM8 7>8 issues (PR#236616), so I got it working after removing the clang6 requirement and patches because they failed to apply.

The ONLY change I made waas simply to change llvm=60 to llvm=70 since I am trying to keep python2 out of all my systems :)

211c211
< VBOX_LLVM_VER?=       70
---
> VBOX_LLVM_VER?=       60

THANK YOU SO MUCH FOR THIS!!!

I will be on my way now.

Cheers,

-D
Comment 60 Mario Lobo 2020-04-26 17:14:57 UTC
(In reply to Darin Luckie from comment #59)

Did you use the port I attached (6.1.6) or made your own?
Comment 61 Darin Luckie 2020-04-26 19:44:10 UTC
I used your patch, and it loaded the modules, but once it booted the VM, DHCP went beserk and the VBoxNetDHCP process wouldn't die (had to SIGSTOP & HUP cuz it was eating one of my my cores at 100%)

I'll try again with 6.1.4 and maybe use GCC or a newer LLVM?
Comment 62 Mario Lobo 2020-04-26 23:25:08 UTC
(In reply to Darin Luckie from comment #61)

See comment #57 to see what happens in my case.

I recently switched to 12 STABLE so I'll give it a go in a few days to see what happens.
Comment 63 Mario Lobo 2020-04-28 13:44:45 UTC
System: FreeBSD 12.1-STABLE r360328 amd64

I just attempted to compile and run VBox 6.0.8 (which works perfectly on my 11.3 STABLE).

I compiles fine but it doesn't start the VMs. The GUI is fully operational but when you choose to start a VM (any type), a dialog shows saying:

"Starting process for VM "whatever" (1/2)"

And hangs there forever. The logs indicates that all processes are started but the VM's log shows this:

00:12:17.463217 GIM: HyperV: Resetting MMIO2 regions and MSRs
00:12:17.473293 Changing the VM state from 'DESTROYING' to 'TERMINATED'
00:12:17.482427 Console: Machine state changed to 'PoweredOff'
00:12:17.483007 GUI: Request to close Runtime UI because VM is powered off already.
00:12:17.483135 GUI: Passing request to close Runtime UI from machine-logic to UI session.

Nothing is ever shown on screen or console.
Comment 64 Mario Lobo 2020-04-28 17:30:36 UTC
Tried all VBox 6.x.x that work ok on 11-STABLE.

Conclusion:
None of them work on 12-STABLE. Only the current port version (5.2.34) woks on it.
Comment 65 Mario Lobo 2020-05-05 23:31:05 UTC
Well ... I tried everything I could with VBox on 12.1-STABLE. Not a glimpse of success. Even the official 5.2.34 port is sluggish on it and it still has glitches.

Result: went back to 11.3-STABLE where a working 6.0.8 is very fast. 

Bhyve is promissing but still not practical yet.
Comment 66 Mario Lobo 2020-05-08 22:59:10 UTC
11.4-STABLE breaks VBox 6.x.x completely! 

So, I went back to 11.3-STABLE r359971 (last one from the .iso) and VBox 6.x.x came alive again.
Comment 67 VVD 2020-05-16 13:11:33 UTC
Released new versions May 14 2020:
5.2.42: https://www.virtualbox.org/wiki/Changelog-5.2#v42
May 15 2020:
6.0.22: https://www.virtualbox.org/wiki/Changelog-6.0#v22
6.1.8: https://www.virtualbox.org/wiki/Changelog-6.1#v8
Comment 68 Mario Lobo 2020-05-20 00:46:34 UTC
Created attachment 214671 [details]
Port of VitualBox 5.2.42
Comment 69 didier.castellacci 2020-05-20 18:20:52 UTC
(In reply to Mario Lobo from comment #68)
Hello,

I have tried untar (tar zxvf) Port of VitualBox 5.2.42 I have problem with an impossible link to decompress

Thank you
Didier
Comment 70 didier.castellacci 2020-05-20 18:37:31 UTC
This is what i get

 sudo tar zxvf vbox_port-5.2.42.tar.gz 
x virtualbox-ose
x virtualbox-ose/Makefile: Cannot extract through symlink virtualbox-ose/Makefile
x virtualbox-ose/distinfo: Cannot extract through symlink virtualbox-ose/distinfo
x virtualbox-ose/pkg-descr: Cannot extract through symlink virtualbox-ose/pkg-descr
x virtualbox-ose/files/: Cannot extract through symlink virtualbox-ose/files
src_VBox_Runtime_r3_freebsd_systemmem-freebsd.cpp
src_VBox_Frontends_VirtualBox_src_settings_global_UIGlobalSettingsNetworkDetailsHost.cpp: Cannot extract through symlink virtualbox-ose/files/extrapatch-src_VBox_Frontends_VirtualBox_src_settings_global_UIGlobalSettingsNetworkDetailsHost.cpp
x virtualbox-ose/pkg-message: Cannot extract through symlink virtualbox-ose/pkg-message
x virtualbox-ose/pkg-plist: Cannot extract through symlink virtualbox-ose/pkg-plist
x virtualbox-ose-kmod
x virtualbox-ose-kmod/distinfo: Cannot extract through symlink virtualbox-ose-kmod/distinfo
x virtualbox-ose-kmod/pkg-descr: Cannot extract through symlink virtualbox-ose-kmod/pkg-descr
x virtualbox-ose-kmod/files/: Cannot extract through symlink virtualbox-ose-kmod/files
x virtualbox-ose-kmod/files/vboxnet.in: Cannot extract through symlink virtualbox-ose-kmod/files/vboxnet.in
x virtualbox-ose-kmod/pkg-plist: Cannot extract through symlink virtualbox-ose-kmod/pkg-plist
x virtualbox-ose-kmod/Makefile: Cannot extract through symlink virtualbox-ose-kmod/Makefile
tar: Error exit delayed from previous errors.


Thank you
Didier
Comment 71 per 2020-05-20 19:38:28 UTC
(In reply to didier.castellacci from comment #70)
Extremely weird tarball, with 'tar ztvf vbox_port-5.2.42.tar.gz' you'll see

lrwxr-xr-x  0 root   wheel       0 May 11 19:16 virtualbox-ose -> /Vmachines/ports/emulators/virtualbox-ose.5234
-rw-r--r--  0 root   wheel   13499 May 20 02:06 virtualbox-ose/Makefile
-rw-r--r--  0 root   wheel     324 May 20 02:37 virtualbox-ose/distinfo
...

and similarly for the supposedly-directory virtualbox-ose-kmod. It seems to unpack properly with 'tar ztvfU vbox_port-5.2.42.tar.gz', although it sounds like a "side effect" of the -U/--unlink/--unlink-first option...
Comment 72 per 2020-05-20 19:50:38 UTC
(In reply to per from comment #71)

Sorry, should of course have been "...unpack properly with 'tar zxvfU vbox_port-5.2.42.tar.gz'..."
Comment 73 Mario Lobo 2020-05-21 03:00:41 UTC
Sorry! My mistake.

I have virtuabox-ose and virtualbox-ose-kmod symbolically linked to whatever port I'm working on. I.e:

virtualbox-ose.5242
virtualbox-ose-kmod.5242

And I packed the ports from the sym links instead of the real dir.

Forgive me.
Comment 74 didier.castellacci 2020-05-21 14:45:28 UTC
(In reply to Li-Wen Hsu from comment #36)

Hello

I installed Virtualbox 6.0.12 via https://github.com/lwhsu/freebsd-ports-virtualbox-ose

I was able to build without problem.

I start VirtualBox 6.0.12 interface OK when I try to start a vm it crashes


Here is the message

: Failed to open a session for the virtual machine Ubuntu 20.04 Office ip12.

The virtual machine 'Ubuntu 20.04 Office ip12' has terminated unexpectedly during startup with exit code 1 (0x1).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: MachineWrap
Interface: IMachine {5047460a-265d-4538-b23e-ddba5fb84976}

Here is the log of the virtualbox 6.0.12



00:00:02.970096 VirtualBox VM 6.0.20 r137117 freebsd.amd64 (Apr 25 2020 07:49:46) release log
00:00:02.970098 Log opened 2020-05-20T17:45:40.700683000Z
00:00:02.970099 Build Type: release
00:00:02.970108 OS Product: FreeBSD
00:00:02.970110 OS Release: 12.1-RELEASE-p5
00:00:02.970113 OS Version: FreeBSD 12.1-RELEASE-p5 GENERIC
00:00:02.970133 Host RAM: 7893MB (7.7GB) total, 394MB available
00:00:02.970137 Executable: /usr/home/opt/local/lib/virtualbox/VirtualBoxVM
00:00:02.970138 Process ID: 1545
00:00:02.970139 Package type: BSD_64BITS_GENERIC (OSE)
00:00:02.972699 Installed Extension Packs:
00:00:02.972725   VNC (Version: 6.0.20 r137117; VRDE Module: VBoxVNC)
00:00:02.973528 Console: Machine state changed to 'Starting'
00:00:02.973759 Qt version: 5.13.2
00:00:02.973771 X11 Window Manager code: 0
00:00:02.976282 X Server details: vendor: The X.Org Foundation, release: 12008000, protocol version: 11.0, display string: :0
00:00:02.976309 Using XKB for keycode to scan code conversion
00:00:02.992671 SUP: Loaded VMMR0.r0 (/usr/home/opt/local/lib/virtualbox/VMMR0.r0) at 0xXXXXXXXXXXXXXXXX - ModuleInit at XXXXXXXXXXXXXXXX and ModuleTerm at XXXXXXXXXXXXXXXX
00:00:02.992726 SUP: VMMR0EntryEx located at XXXXXXXXXXXXXXXX and VMMR0EntryFast at XXXXXXXXXXXXXXXX
00:00:02.995523 Guest OS type: 'Ubuntu_64'
00:00:02.998285 fHMForced=true - SMP
00:00:02.998310 fHMForced=true - 64-bit guest
00:00:03.009395 File system of '/home/bs/VirtualBox VMs/Ubuntu 20.04 Office ip12/Snapshots' (snapshots) is unknown
00:00:03.009413 File system of '/home/bs/VirtualBox VMs/Ubuntu 20.04 Office ip12/Ubuntu 20.04 Office.vmdk' is zfs
00:00:03.024877 Shared clipboard service loaded
00:00:03.024909 Shared clipboard mode: Bidirectional
00:00:03.026733 Drag and drop service loaded
00:00:03.026757 Drag and drop mode: Bidirectional
00:00:03.028695 ************************* CFGM dump *************************
00:00:03.028697 [/] (level 0)
00:00:03.042354   CSAMEnabled       <integer> = 0x0000000000000001 (1)
00:00:03.042387   CpuExecutionCap   <integer> = 0x0000000000000064 (100)
00:00:03.042389   EnablePAE         <integer> = 0x0000000000000000 (0)
00:00:03.042390   HMEnabled         <integer> = 0x0000000000000001 (1)
00:00:03.042391   MemBalloonSize    <integer> = 0x0000000000000000 (0)
00:00:03.042391   Name              <string>  = "Ubuntu 20.04 Office ip12" (cb=25)
00:00:03.042393   NumCPUs           <integer> = 0x0000000000000004 (4)
00:00:03.042394   PATMEnabled       <integer> = 0x0000000000000001 (1)
00:00:03.042395   PageFusionAllowed <integer> = 0x0000000000000000 (0)
00:00:03.042395   RamHoleSize       <integer> = 0x0000000020000000 (536 870 912, 512 MB)
00:00:03.042397   RamSize           <integer> = 0x0000000080000000 (2 147 483 648, 2 048 MB)
00:00:03.042399   RawR0Enabled      <integer> = 0x0000000000000001 (1)
00:00:03.042400   RawR3Enabled      <integer> = 0x0000000000000001 (1)
00:00:03.042400   TimerMillies      <integer> = 0x000000000000000a (10)
00:00:03.042401   UUID              <bytes>   = "66 b3 51 b4 29 d8 49 48 be c9 0c 28 3e 4c e1 9d" (cb=16)
00:00:03.042405 
00:00:03.042406 [/CPUM/] (level 1)
00:00:03.042407   GuestCpuName       <string>  = "host" (cb=5)
00:00:03.042408   NestedHWVirt       <integer> = 0x0000000000000000 (0)
00:00:03.042409   PortableCpuIdLevel <integer> = 0x0000000000000000 (0)
00:00:03.042410   SpecCtrl           <integer> = 0x0000000000000000 (0)
00:00:03.042411 
00:00:03.042411 [/CPUM/IsaExts/] (level 2)
00:00:03.042412 
00:00:03.042413 [/DBGC/] (level 1)
00:00:03.042414   GlobalInitScript <string>  = "/home/bs/.config/VirtualBox/dbgc-init" (cb=38)
00:00:03.042415   HistoryFile      <string>  = "/home/bs/.config/VirtualBox/dbgc-history" (cb=41)
00:00:03.042415   LocalInitScript  <string>  = "/home/bs/VirtualBox VMs/Ubuntu 20.04 Office ip12/dbgc-init" (cb=59)
00:00:03.042416 
00:00:03.042417 [/DBGF/] (level 1)
00:00:03.042418   Path <string>  = "/home/bs/VirtualBox VMs/Ubuntu 20.04 Office ip12/debug/;/home/bs/VirtualBox VMs/Ubuntu 20.04 Office ip12/;/home/bs/" (cb=116)
00:00:03.042419 
....
00:02:00.972727 /PROF/CPU3/EM/NEMExecuteCalled          0 times
00:02:00.972735 /PROF/CPU3/EM/RAWTotal                  0 times
00:02:00.972743 /PROF/CPU3/EM/REMTotal                  0 times
00:02:00.972752 /PROF/CPU3/EM/RecordedExits        230851 times
00:02:00.972760 /PROF/CPU3/EM/Total              412372382294 ticks/call (412372382294 ticks,       1 times, max 412372382294, min 412372382294)
00:02:00.972771 /PROF/CPU3/VM/Halt/Block          2345064 ns/call (103089032281 ticks,   43960 times, max 265116938, min       1)
00:02:00.972780 /PROF/CPU3/VM/Halt/BlockInsomnia  2413592 ns/call ( 77722504929 ticks,   32202 times, max 232904767, min       1)
00:02:00.972789 /PROF/CPU3/VM/Halt/BlockOnTime    2208746 ns/call (  3271153280 ticks,    1481 times, max  92121137, min    2126)
00:02:00.972798 /PROF/CPU3/VM/Halt/BlockOverslept   526209 ns/call (  5407859383 ticks,   10277 times, max   8825929, min   50108)
00:02:00.972808 /PROF/CPU3/VM/Halt/R0HaltBlock          0 ns/call (           0 ticks,       0 times, max         0, min      -1)
00:02:00.972818 /PROF/CPU3/VM/Halt/R0HaltBlockInsomnia        0 ns/call (           0 ticks,       0 times, max         0, min      -1)
00:02:00.972826 /PROF/CPU3/VM/Halt/R0HaltBlockOnTime        0 ns/call (           0 ticks,       0 times, max         0, min      -1)
00:02:00.972835 /PROF/CPU3/VM/Halt/R0HaltBlockOverslept        0 ns/call (           0 ticks,       0 times, max         0, min      -1)
00:02:00.972844 /PROF/CPU3/VM/Halt/R0HaltExec           0 times
00:02:00.972852 /PROF/CPU3/VM/Halt/R0HaltExec/FromBlock        0 times
00:02:00.972860 /PROF/CPU3/VM/Halt/R0HaltExec/FromSpin        0 times
00:02:00.972869 /PROF/CPU3/VM/Halt/R0HaltHistoryCounter    23193 times
00:02:00.972877 /PROF/CPU3/VM/Halt/R0HaltHistorySucceeded        0 times
00:02:00.972885 /PROF/CPU3/VM/Halt/R0HaltHistoryToRing3      156 times
00:02:00.972893 /PROF/CPU3/VM/Halt/Timers            3607 ns/call (   277866727 ticks,   77019 times, max   2286595, min       2)
00:02:00.972903 /PROF/CPU3/VM/Halt/Yield             1525 ns/call (      253194 ticks,     166 times, max      5095, min     688)
00:02:00.972912 /Public/Net/E1k0/BytesReceived          0 bytes
00:02:00.972920 /Public/Net/E1k0/BytesTransmitted    13128 bytes
00:02:00.972928 /REM/TbFlushCount                       0 times
00:02:00.972937 /REM/TbPhysInvldCount                   0 times
00:02:00.972945 /REM/TlbFlushCount                      1 times
00:02:00.972954 /SELM/LoadHidSel/GstReadErrors          0 times
00:02:00.972963 /SELM/LoadHidSel/NoGoodGuest            0 times
00:02:00.972973 /TM/CPU/00/cNsExecuting          12466236412 ns
00:02:00.972982 /TM/CPU/00/cNsHalted             102441383975 ns
00:02:00.972993 /TM/CPU/00/cNsOther              2848071704 ns
00:02:00.973003 /TM/CPU/00/cNsTotal              117755692091 ns
00:02:00.973011 /TM/CPU/00/cPeriodsExecuting      1358018 count
00:02:00.973019 /TM/CPU/00/cPeriodsHalted           33346 count
00:02:00.973028 /TM/CPU/00/pctExecuting                 9 %
00:02:00.973036 /TM/CPU/00/pctHalted                   89 %
00:02:00.973045 /TM/CPU/00/pctOther                     1 %
00:02:00.973053 /TM/CPU/01/cNsExecuting          11340450238 ns
00:02:00.973061 /TM/CPU/01/cNsHalted             104772908457 ns
00:02:00.973070 /TM/CPU/01/cNsOther              1708851925 ns
00:02:00.973079 /TM/CPU/01/cNsTotal              117822210620 ns
00:02:00.973087 /TM/CPU/01/cPeriodsExecuting       240840 count
00:02:00.973096 /TM/CPU/01/cPeriodsHalted           25686 count
00:02:00.973104 /TM/CPU/01/pctExecuting                 9 %
00:02:00.973113 /TM/CPU/01/pctHalted                   89 %
00:02:00.973121 /TM/CPU/01/pctOther                     1 %
00:02:00.973129 /TM/CPU/02/cNsExecuting          10056021804 ns
00:02:00.973138 /TM/CPU/02/cNsHalted             106243871772 ns
00:02:00.973146 /TM/CPU/02/cNsOther              1522289924 ns
00:02:00.973155 /TM/CPU/02/cNsTotal              117822183500 ns
00:02:00.973163 /TM/CPU/02/cPeriodsExecuting       232198 count
00:02:00.973172 /TM/CPU/02/cPeriodsHalted           21877 count
00:02:00.973180 /TM/CPU/02/pctExecuting                 8 %
00:02:00.973189 /TM/CPU/02/pctHalted                   90 %
00:02:00.973197 /TM/CPU/02/pctOther                     1 %
00:02:00.973205 /TM/CPU/03/cNsExecuting          12514785973 ns
00:02:00.973214 /TM/CPU/03/cNsHalted             103415052549 ns
00:02:00.973222 /TM/CPU/03/cNsOther              1892367054 ns
00:02:00.973231 /TM/CPU/03/cNsTotal              117822205576 ns
00:02:00.973240 /TM/CPU/03/cPeriodsExecuting       230851 count
00:02:00.973248 /TM/CPU/03/cPeriodsHalted           23242 count
00:02:00.973257 /TM/CPU/03/pctExecuting                11 %
00:02:00.973265 /TM/CPU/03/pctHalted                   87 %
00:02:00.973273 /TM/CPU/03/pctOther                     0 %
00:02:00.973281 /TM/CPU/pctExecuting                    9 %
00:02:00.973291 /TM/CPU/pctHalted                      89 %
00:02:00.973299 /TM/CPU/pctOther                        1 %
00:02:00.973308 /TM/MaxHzHint                           0 Hz
00:02:00.973316 /TM/R0/1nsSteps                       111 times
00:02:00.973325 /TM/R3/1nsSteps                      1191 times
00:02:00.973334 /TM/TSC/offCPU0                  18446744073698307537 ticks
00:02:00.973343 /TM/TSC/offCPU1                  18446744073698307537 ticks
00:02:00.973352 /TM/TSC/offCPU2                  18446744073698307537 ticks
00:02:00.973361 /TM/TSC/offCPU3                  18446744073698307537 ticks
00:02:00.973370 /TM/VirtualSync/CurrentOffset      151040 ns
00:02:00.973378 /VUSB/0/cUrbsInPool                     0 count
00:02:00.973388 ********************* End of statistics **********************
00:02:00.973702 VUSB: Detached 'HidMouse' from port 1 on RootHub#0
00:02:00.976054 NAT: Zone(nm:mbuf_cluster, used:0)
00:02:00.976079 NAT: Zone(nm:mbuf_packet, used:0)
00:02:00.976089 NAT: Zone(nm:mbuf, used:0)
00:02:00.976099 NAT: Zone(nm:mbuf_jumbo_pagesize, used:0)
00:02:00.976110 NAT: Zone(nm:mbuf_jumbo_9k, used:0)
00:02:00.976121 NAT: Zone(nm:mbuf_jumbo_16k, used:0)
00:02:00.976131 NAT: Zone(nm:mbuf_ext_refcnt, used:0)
00:02:00.976165 E1000#0: Interrupt attempts: 394
00:02:00.976174 E1000#0: Interrupts raised : 219
00:02:00.976183 E1000#0: Interrupts lowered: 0
00:02:00.976191 E1000#0: ICR outside ISR   : 0
00:02:00.976200 E1000#0: IMS raised ints   : 9
00:02:00.976208 E1000#0: Interrupts skipped: 158
00:02:00.976216 E1000#0: Masked interrupts : 17
00:02:00.976224 E1000#0: Early interrupts  : 0
00:02:00.976232 E1000#0: Late interrupts   : 8
00:02:00.976240 E1000#0: Lost interrupts   : 0
00:02:00.976249 E1000#0: Interrupts by RX  : 0
00:02:00.976257 E1000#0: Interrupts by TX  : 165
00:02:00.976265 E1000#0: Interrupts by ICS : 55
00:02:00.976273 E1000#0: Interrupts by RDTR: 0
00:02:00.976282 E1000#0: Interrupts by RDMT: 0
00:02:00.976290 E1000#0: Interrupts by TXQE: 0
00:02:00.976298 E1000#0: TX int delay asked: 0
00:02:00.976306 E1000#0: TX delayed:         0
00:02:00.976314 E1000#0: TX delay expired:   0
00:02:00.976322 E1000#0: TX no report asked: 44
00:02:00.976330 E1000#0: TX abs timer expd : 0
00:02:00.976339 E1000#0: TX int timer expd : 0
00:02:00.976347 E1000#0: RX abs timer expd : 0
00:02:00.976355 E1000#0: RX int timer expd : 0
00:02:00.976363 E1000#0: TX CTX descriptors: 44
00:02:00.976372 E1000#0: TX DAT descriptors: 44
00:02:00.976380 E1000#0: TX LEG descriptors: 121
00:02:00.976388 E1000#0: Received frames   : 0
00:02:00.976396 E1000#0: Transmitted frames: 165
00:02:00.976405 E1000#0: TX frames up to 1514: 165
00:02:00.976413 E1000#0: TX frames up to 2962: 0
00:02:00.976421 E1000#0: TX frames up to 4410: 0
00:02:00.976429 E1000#0: TX frames up to 5858: 0
00:02:00.976437 E1000#0: TX frames up to 7306: 0
00:02:00.976446 E1000#0: TX frames up to 8754: 0
00:02:00.976454 E1000#0: TX frames up to 16384: 0
00:02:00.976462 E1000#0: TX frames up to 32768: 0
00:02:00.976470 E1000#0: Larger TX frames    : 0
00:02:00.976479 E1000#0: Max TX Delay        : 0
00:02:00.977033 GIM: KVM: Resetting MSRs
00:02:00.981667 Changing the VM state from 'DESTROYING' to 'TERMINATED'
00:02:00.984794 Console: Machine state changed to 'PoweredOff'
00:02:00.984987 GUI: Request to close Runtime UI because VM is powered off already.
00:02:00.985018 GUI: Passing request to close Runtime UI from machine-logic to UI session.
Comment 75 Mario Lobo 2020-05-21 16:10:06 UTC
It's about the same error that happens with all 6.0.x and 6.1.x versions I tried.
Comment 76 didier.castellacci 2020-05-21 18:28:44 UTC
(In reply to Mario Lobo from comment #75)

Hello

I installed via Virtualbox 5.2.34 ports to build it went well.

Virtualbox 5.2.34 interface starts well

but starting a vm it crashes

Here is the error message

Kernel driver not accessible Abort

Failed to open a session for the virtual machine Ubuntu 20.04 Office ip12.

The virtual machine 'Ubuntu 20.04 Office ip12' has terminated unexpectedly during startup with exit code 1 (0x1).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: MachineWrap
Interface: IMachine {85cd948e-a71f-4289-281e-0ca7ad48cd89}

Thank you
Didier
Comment 77 Cy Schubert freebsd_committer 2020-05-21 18:36:46 UTC
(In reply to didier.castellacci from comment #76)

Did you load the drivers?
Comment 78 didier.castellacci 2020-05-21 18:45:22 UTC
(In reply to Cy Schubert from comment #77)



Did you load the drivers?
Yes


In

pwd
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/src


sudo make load

 ll *.ko
-r-xr-xr-x  1 root  vboxusers  uarch 460288 May 21 19:53 vboxdrv.ko*
-r-xr-xr-x  1 root  vboxusers  uarch  10016 May 21 19:53 vboxnetadp.ko*
-r-xr-xr-x  1 root  vboxusers  uarch  28008 May 21 19:53 vboxnetflt.ko*




kldstat
Id Refs Address                Size Name
 1   73 0xffffffff80200000  2448f20 kernel
 3    2 0xffffffff826d3000     a5b8 opensolaris.ko
 4    1 0xffffffff826de000   3a99a8 zfs.ko
 6    2 0xffffffff82c25000     9e30 netgraph.ko
 7    1 0xffffffff82c2f000     1710 ng_ether.ko
 9    1 0xffffffff82c35000   152fd0 radeonkms.ko
10    2 0xffffffff82d88000    76570 drm.ko
11    5 0xffffffff82dff000    10eb0 linuxkpi.ko
12    4 0xffffffff82e10000    12f30 linuxkpi_gplv2.ko
13    2 0xffffffff82e23000      6d0 debugfs.ko
14    1 0xffffffff82e24000     f181 ttm.ko
15    1 0xffffffff82e34000      a75 radeon_RS780_pfp_bin.ko
16    1 0xffffffff82e35000     5573 radeon_RS780_me_bin.ko
17    1 0xffffffff82e3b000      d73 radeon_R600_rlc_bin.ko
18    1 0xffffffff82e3c000    161b5 radeon_RS780_uvd_bin.ko
19    1 0xffffffff82e53000     2668 intpm.ko
20    1 0xffffffff82e56000      b50 smbus.ko
21    1 0xffffffff82e57000     18a0 uhid.ko
22    1 0xffffffff82e59000     2928 ums.ko
23    1 0xffffffff82e5c000     1aa0 wmt.ko
24    1 0xffffffff82e5e000    32830 pf.ko
25    1 0xffffffff82e91000     1aa0 fdescfs.ko
28    3 0xffffffff82e93000    52748 vboxdrv.ko
29    2 0xffffffff82c22000     2ce0 vboxnetflt.ko
30    1 0xffffffff82c31000     3f30 vboxnetadp.ko



on the other hand in the directory /boot/modules the rights are:


ll /boot/modules/vb*
-r-xr-xr-x  1 root  wheel  - 460288 May 21 20:37 /boot/modules/vboxdrv.ko*
-r-xr-xr-x  1 root  wheel  -  10016 May 21 20:37 /boot/modules/vboxnetadp.ko*
-r-xr-xr-x  1 root  wheel  -  28008 May 21 20:37 /boot/modules/vboxnetflt.ko*


Thank you
Didier
Comment 79 didier.castellacci 2020-05-21 19:00:09 UTC
(In reply to Cy Schubert from comment #77)

I don't have a VirtualBoxVM bin
This is normal the make command (sudo make DISABLE_VULNERABILITIES = yes) did not generate it for me

Thank You
Didier
Comment 80 Cy Schubert freebsd_committer 2020-05-21 19:26:34 UTC
(In reply to didier.castellacci from comment #79)

There is no VirtualBoxVM binary.
Comment 81 didier.castellacci 2020-05-22 10:36:35 UTC
(In reply to Cy Schubert from comment #80)


Hello

I installed via Virtualbox 5.2.34 ports

I set as compilation option

virtualbox-ose ports

sudo make config
sudo make build-depends-list
sudo make run-depends-list


sudo make package DISABLE_VULNERABILITIES = yes

Here is the error message


===> Staging rc.d startup script(s)
===>  Installing for virtualbox-ose-kmod-5.2.34
===>  Checking if virtualbox-ose-kmod is already installed
===>   Registering installation for virtualbox-ose-kmod-5.2.34 as automatic
Installing virtualbox-ose-kmod-5.2.34...
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/etc/rc.d/vboxnet - found
===>   Returning to build of virtualbox-ose-5.2.34_4
===>   virtualbox-ose-5.2.34_4 depends on executable: gtk-update-icon-cache - found
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/libdata/pkgconfig/xcb.pc - found
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/libdata/pkgconfig/xcursor.pc - found
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/libdata/pkgconfig/xinerama.pc - found
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/libdata/pkgconfig/xmu.pc - found
===>   virtualbox-ose-5.2.34_4 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found
===>   Generating temporary packing list
===> Creating groups.
===> Creating users
cd /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/sdk/bindings/xpcom &&  /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE "idl samples" /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/share/virtualbox-ose
/bin/mkdir -p /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/include/virtualbox
cd /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include &&  /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE "*" /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/include/virtualbox
/bin/mkdir -p /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
cd /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE  "*.fd *.r0 *.rc *.so components" /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/src/VBox/Installer/freebsd/VBox.sh  /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxAutostart /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxBalloonCtrl /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxBugReport /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxHeadless /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxManage /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VirtualBox /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxSDL /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxExtPackHelperApp /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxNetAdpCtl /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxNetDHCP /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxNetNAT /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxSVC /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxXPCOMIPCD /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
install  -s -m 555 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/VBoxTestOGL /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VBoxAutostart
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VBoxBalloonCtrl
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VBoxBugReport
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VBoxHeadless
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VBoxManage
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VirtualBox
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VBoxSDL
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/VBoxVRDP
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/vboxautostart
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/vboxballoonctrl
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/vboxbugreport
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/vboxheadless

/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/vboxmanage
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/virtualbox
/bin/ln -fs ../lib/virtualbox/VBox.sh /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/bin/vboxsdl
cd /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/obj/VirtualBox/qtnls &&  /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE "*.qm" /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/share/virtualbox-ose/nls
install  -m 0644  /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/src/VBox/Frontends/VirtualBox/images/OSE/VirtualBox_48px.png  /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/share/pixmaps/VBox.png
install  -m 0644  /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/src/VBox/Installer/freebsd/virtualbox.desktop  /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/share/applications/virtualbox.desktop
/bin/mkdir -p /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox/ExtensionPacks/VNC/freebsd.amd64
install  -m 0644 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/ExtensionPacks/VNC/ExtPack*  /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox/ExtensionPacks/VNC/
install  -s -m 0644 /usr/home/opt/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.34/out/freebsd.amd64/release/bin/ExtensionPacks/VNC/freebsd.amd64/*  /usr/home/opt/ports/emulators/virtualbox-ose/work/stage/usr/local/lib/virtualbox/ExtensionPacks/VNC/freebsd.amd64/
====> Compressing man pages (compress-man)
===> Staging rc.d startup script(s)
===>  Building package for virtualbox-ose-5.2.34_4
pkg-static: Unable to access file /usr/home/opt/ports/emulators/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxHeadless.so:No such file or directory
pkg-static: Unable to access file /usr/home/opt/ports/emulators/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxNetDHCP.so:No such file or directory
pkg-static: Unable to access file /usr/home/opt/ports/emulators/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxNetNAT.so:No such file or directory
pkg-static: Unable to access file /usr/home/opt/ports/emulators/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxSDL.so:No such file or directory
pkg-static: Unable to access file /usr/home/opt/ports/emulators/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxVMMPreload.so:No such file or directory
pkg-static: Unable to access file /usr/home/opt/ports/emulators/virtualbox-ose/work/stageusr/local/lib/virtualbox/VirtualBox.so:No such file or directory
*** Error code 1

Stop.
make[1]: stopped in /usr/home/opt/ports/emulators/virtualbox-ose
*** Error code 1

Stop.
make: stopped in /usr/home/opt/ports/emulators/virtualbox-ose
[bs@MyFreeBSD]$ 




Thank you
Didier
Comment 82 didier.castellacci 2020-05-22 12:01:41 UTC
(In reply to Cy Schubert from comment #80)


Hello

I installed via Virtualbox 5.2.42 ports

I set as compilation option

virtualbox-ose ports

sudo make config
sudo make build-depends-list
sudo make run-depends-list


sudo make package DISABLE_VULNERABILITIES = yes


I have the same problem as with version 5.2.34




Here is the error message

===>  Building package for virtualbox-ose-5.2.42
pkg-static: Unable to access file /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxHeadless.so:No such file or directory
pkg-static: Unable to access file /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxNetDHCP.so:No such file or directory
pkg-static: Unable to access file /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxNetNAT.so:No such file or directory
pkg-static: Unable to access file /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxSDL.so:No such file or directory
pkg-static: Unable to access file /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose/work/stageusr/local/lib/virtualbox/VBoxVMMPreload.so:No such file or directory
pkg-static: Unable to access file /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose/work/stageusr/local/lib/virtualbox/VirtualBox.so:No such file or directory
*** Error code 1

Stop.
make[1]: stopped in /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose
*** Error code 1

Stop.
make: stopped in /usr/home/bs/Downloads/VirtualBox/freebsd-ports-virtualbox-ose-5.2.42/virtualbox-ose
[bs@MyFreeBSD]$ 




Thank you
Didier
Comment 83 didier.castellacci 2020-05-22 18:42:56 UTC
(In reply to Cy Schubert from comment #80)

Hello

I successfully installed Virtualbox 5.2.42 via ports

The vm opens I was able to install Ubuntu 20.04 and Installed Guest addition for 5.2.42

I have a problem running mp3 music and mp4 video.

When I connect with mozilla firefox on youtube and that I launch a music the music remains blocked from the beginning impossible to execute it.

Similar with mp3 players (mplayer, sox play) that I installed on ubuntu with codecs mpg123 etc ...

nothing works

Do you have an idea

Thank you
Didier
Comment 84 VVD 2020-05-23 08:01:22 UTC
(In reply to Mario Lobo from comment #73)
> And I packed the ports from the sym links instead of the real dir.
Can you, please, pack it without symlinks?
Comment 85 Mario Lobo 2020-05-23 13:11:08 UTC
There are only 3 things that need to be done on the official 5.2.34 port to move to 5.2.42:

1) Adjust both Makefiles (virtualbox-ose & virtualbox-ose-kmod)

change PORTVERSION=     5.2.34  to  PORTVERSION=        5.2.42
remove PORTREVISION=    4

2) remove patch-src_VBox_Devices_PC_vbox-cpuhotplug.dsl from
virtualbox-ose/files

3) recalculate distinfo, which becomes this:

SHA256 (VirtualBox-5.2.42.tar.bz2) =
e5bee2e34f349aac115ee93974febfe3213ad5e94045fa36b9f04b5f8caa3720
SIZE (VirtualBox-5.2.42.tar.bz2) = 124013981
SHA256 (VBoxGuestAdditions_5.2.42.iso) =
ff784417295e48e3cee80a596faf05e3b0976e1b94d3b88427939912b0c1fc45
SIZE (VBoxGuestAdditions_5.2.42.iso) = 49833984


Thatś it!

OBS - these alterations also work for virtualbox-guestadditions and the no-x11 ports.
Comment 86 VVD 2020-05-23 16:51:23 UTC
(In reply to Mario Lobo from comment #85)

It need a lot of fixes in patches.
For example:
-@@ -2538,6 +2534,10 @@ ifeq ($(KBUILD_HOST),win) ## @todo can drop this now, 
+@@ -2550,6 +2546,10 @@ ifeq ($(KBUILD_HOST),win) ## @todo can drop this now,
…
-@@ -4158,6 +4154,7 @@ ifdef VBOX_WITH_RAW_MODE
+@@ -4218,6 +4218,7 @@ ifdef VBOX_WITH_RAW_MODE
…
-@@ -4299,6 +4296,7 @@ ifeq ($(VBOX_LDR_FMT),elf)
+@@ -4359,6 +4360,7 @@ ifeq ($(VBOX_LDR_FMT),elf)

And there are warnings during make patch:
===>  Applying FreeBSD patches for virtualbox-ose-5.2.42 from /usr/ports/emulators/virtualbox-ose/files
No such line 731 in input file, ignoring
No such line 435 in input file, ignoring
Comment 87 VVD 2020-06-05 18:02:16 UTC
6.1.10 released: https://www.virtualbox.org/wiki/Changelog-6.1
Comment 88 Mikhail Teterin freebsd_committer 2020-06-22 02:23:28 UTC
I'd like to propose, we drop the attempts to keep the Virtual Box hosting side (ose and ose-kmod) at the same version as the Virtual Box guest side (the ose-additions).

There is no need for such synchronization -- even if people do use both (whom I'd estimate to be very few), the precise match of the hosting and guest software versions is not required.

Decoupling the two should make maintenance of both easier, and the upgrades -- more frequent.
Comment 89 Mario Lobo 2020-06-22 16:19:47 UTC
I agree with you completely, but we are lagging so far behind on the hosting side (ose and ose-kmod) that I think people that are trying to upgrade it aren't even thinking about the guest-additions port.
Comment 90 Mario Lobo 2020-06-22 21:09:59 UTC
For the record:

FreeBSD 13.0-CURRENT #1 r360882

Managed to compile cleanly virtualbox-ose-6.1.10 and virtualbox-ose-kmod-6.1.10.

Modules load OK:

kldstat | grep vbox
4    3 0xffffffff8122c000    8cba8 vboxdrv.ko
17    2 0xffffffff8334b000     4218 vboxnetflt.ko
20    1 0xffffffff8335f000     55e0 vboxnetadp.ko

vboxnet0: Ethernet address: 0a:00:27:00:00:00

GUI comes up fine but none of the VMs (no matter the guest OS) starts. 

Via GUI: The console never shows.

Via VBoxHeadless: 
VBoxHeadless --startvm Debian
Oracle VM VirtualBox Headless Interface 6.1.10
(C) 2008-2020 Oracle Corporation
All rights reserved.

Error: failed to start machine. Error message: Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3)

and back to prompt.
Comment 91 Mario Lobo 2020-06-22 21:34:06 UTC
A small correction.

Starting the VM with VBoxHeadless or VBoxSDL, it just hangs open on the terminal, the process doesn't end with ^C, and even if the terminal is closed, the process still hangs in there and only a reboot is able to kill it.

1448  1- I     0:00.06 /usr/local/lib/virtualbox/VBoxHeadless --startvm Debian

The previous VBoxHeadless error message came out because I already had a hanging attempt from trying to run an Ubuntu VM.
Comment 92 Mikhail Teterin freebsd_committer 2020-06-23 16:54:30 UTC
(In reply to Mario Lobo from comment #89)
> we are lagging so far behind on the hosting side (ose and ose-kmod) that I think people that are trying to upgrade it aren't even thinking about the guest-additions port.

We are, obviously, lagging on _both_ sides -- and the "not thinking" is mutual. Most people interested in -- and capable of -- upgrading one side, aren't using the other, and must rely on others for testing their changes. This leads to delays...

Delays so high, people lose interest, and Oracle manages to make several releases in between -- obsoleting the original work. That the work is happening in little GitHub repos is not helping either :(

This ticket is old, and has 90+ comments and lots of attachments -- our problem is not lack of interest or expertise, it is organizational.

I'd like to expand my proposal (from comment #88) with this plan:

1. Leave the current virtualbox-* ports be (or upgrade them to the latest 5.x).
2. Repo-copy each virtualbox-foo to the ...foo6.
3. Disconnect the new virtualbox-ose-additions6 (guest) from the new virtualbox-ose6 (host) by:
   a) giving the guest its own files/ (for patches) and distinfo;
   b) moving the guest-only patches from the host's files/ into the guest's;
   c) enumerate the few -- if any -- patches necessary to both sides as EXTRAPATCHES in the guest -- or even just copy them over.
4. Assign the sides to different maintainers.

If no one objects to these steps in principle -- and no one volunteers to do it -- I'll perform the copying/moving myself. I can also take up maintainership of the new virtualbox-ose-additions6, if there is no better candidate (my own usage is limited to a FreeBSD-11.x/i386 PAE guest inside a Windows 10 desktop).

Based on one of the many attachments here, I can also upgrade the new hosting virtualbox-ose6 port (once), but I will not be able to test it beyond "it compiles".
Comment 93 Mario Lobo 2020-06-23 17:35:34 UTC
Would anyone know how to set up a debug build of the VBox port?
Comment 94 Li-Wen Hsu freebsd_committer 2020-06-23 18:16:04 UTC
(In reply to Mario Lobo from comment #93)
There is a "DEBUG" option. I just checked my very old log (2016), need to check if when this option enabled, it still correctly passes BUILD_TYPE=debug to LocalConfig.kmk file.
Comment 95 Mario Lobo 2020-06-23 21:12:14 UTC
Marking the Debug option does not produce debug symbols for any of the VBox executables.
Comment 96 Mario Lobo 2020-06-24 17:33:37 UTC
I finally managed to get VBox into gdb.

Starting program: /Vmachines/ports/emulators/virtualbox-ose.6110/work/VirtualBox-6.1.10/out/freebsd.amd64/debug/bin/VBoxHeadless --startvm Debian
Oracle VM VirtualBox Headless Interface 6.1.10
(C) 2008-2020 Oracle Corporation
All rights reserved.

Type Manifest File: /root/.VirtualBox/xpti.dat
[New LWP 101112 of process 13360]
[New LWP 101131 of process 13360]
[New LWP 101141 of process 13360]
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
^C
Thread 2 received signal SIGINT, Interrupt.
[Switching to LWP 101112 of process 13360]
_umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:40
40      RSYSCALL_ERR(_umtx_op)

=============================================================

Starting program: /Vmachines/ports/emulators/virtualbox-ose.6110/work/VirtualBox-6.1.10/out/freebsd.amd64/debug/bin/VBoxSDL --startvm Debian
Oracle VM VirtualBox SDL GUI version 6.1.10
(C) 2005-2020 Oracle Corporation
All rights reserved.

Type Manifest File: /root/.VirtualBox/xpti.dat
[New LWP 101168 of process 13409]
[New LWP 101169 of process 13409]
[New LWP 101173 of process 13409]
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
^C
Thread 2 received signal SIGINT, Interrupt.
[Switching to LWP 101168 of process 13409]
_umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:40
40      RSYSCALL_ERR(_umtx_op)

=============================================================

Starting program: /Vmachines/ports/emulators/virtualbox-ose.6110/work/VirtualBox-6.1.10/out/freebsd.amd64/debug/bin/VirtualBoxVM --startvm Debian
[New LWP 101200 of process 13489]
[New LWP 101201 of process 13489]
^C
Thread 1 received signal SIGINT, Interrupt.
_umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:40
40      RSYSCALL_ERR(_umtx_op)


They all get stuck on the same line.
Comment 97 Samy Mahmoudi 2020-06-24 18:05:18 UTC
(In reply to Mario Lobo from comment #96)
> I finally managed to get VBox into gdb.
How did you do so?
Comment 98 Mario Lobo 2020-06-24 18:55:44 UTC
By compiling with the Debug option, and running the binaries directly from the port's work directory.

I.E.

gdb --args /usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.10/out/freebsd.amd64/debug/bin/VBoxSDL --startvm Debian

Doing this way, gdb finds the debug symbols and sources.
Comment 99 Samy Mahmoudi 2020-06-24 22:43:20 UTC
(In reply to Mario Lobo from comment #98)
Thank you for the explanation Mario.
Comment 100 Mario Lobo 2020-06-29 13:58:50 UTC
A few things I did that I forgot to mention.

Here are the steps I've done to compile it:

1) cd /usr/ports/emulators/virtualbox-ose/ 

   make config and mark Debug option
   make patch

2) cd /usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.10/

   add VBOX_WITHOUT_HARDENING=1 to LocalConfig.kmk
   (this makes it easier to run a debug session.)

3) kmk build-debug-amd64
Comment 101 Mario Lobo 2020-06-29 14:21:20 UTC
Created attachment 216038 [details]
VBox 6.1.10 port files

Here are the virtualbox-ose 6.1.10 port files
Comment 102 Mario Lobo 2020-06-29 14:22:39 UTC
Created attachment 216039 [details]
VBox 6.1.10 kmod port files

Here are the VBox 6.1.10 kmod port files
Comment 103 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-16 04:07:52 UTC
^Triage: 

- Needs patch update to 6.1.12
- Reset to Open (cant be In Progress without a real Assignee)

@VirtualBox team, is there any chance we'll need or want a virtualbox-ose61 port in tandem with the 5.x version?
Comment 104 Jason W. Bacon freebsd_committer 2020-08-30 00:35:47 UTC
(In reply to Kubilay Kocak from comment #103)

Or how about a virtualbox-ose-devel for easily testing either major or minor version updates?

I run FreeBSD as both a host and a guest and would be happy to provide feedback and assist in debugging.
Comment 105 PauAmma freebsd_triage 2020-08-30 03:22:02 UTC
(In reply to Jason W. Bacon from comment #104)
So would I, if both versions could coexist (and maybe even if they couldn't, but that's less clear to me).
Comment 106 eweiman 2020-09-20 06:14:51 UTC
I'd really like to have at least 6.1.0 available so that I can 
get the nested hypervisor support, and be able to run more than 
8 vCPUs inside a VM which I believe to have been fixed in 6.0

Can someone explain where we are really at here with what is 
holding this back from becoming a port with modern code?
We are well over 1.5 years behind current code and I guess
it is just not obvious to me as to why that is at this point. 

If someone really needs a legacy version of vbox it would seem
to make sense to have 2 different release branches, have one that 
runs 6.x and one legacy one that holds the final 5.x release.
Comment 107 Graham Perrin 2020-09-21 05:48:54 UTC
Sleep, wake
-----------

Re: bug 238499 please, can anyone tell whether the host panic at host resume time is reproducible with 6.1?
Comment 108 Christoph Moench-Tegeder freebsd_committer 2020-09-21 20:16:11 UTC
(In reply to Graham Perrin from comment #107)
Last time I tried these patches, I couldn't convince a guest to start under VirtualBox 6.1 on FreeBSD (mind you, the same guest images just work fine when exported/imported to a Linux host with vbox 6.1), basically matching the experience in comment #90 - so, no panic, but I doubt that'd classify as good news.
Comment 109 Mario Lobo 2020-09-22 15:52:14 UTC
I got as far as getting VBoxSDL 6.1.10 into GDB but due to family health problems I am still unable to move ahead.

Has anyone had any success with VBox 6.1.x in FBSD 12.x ou CURRENT?
Comment 110 Tamas Szakaly 2020-12-14 19:45:44 UTC
Created attachment 220555 [details]
VirtualBox 6.1.16 port files

Hi all,

I really needed nested virtualization today, so gave this one a look on my HardenedBSD 13-CURRENT box. Starting with the 6.1.10 port in this thread, I've managed to compile 6.1.16 and run a Windows 8.1 and a Kali Linux VM for a few hours without problems. I needed to apply the fixes from 5.2.44_3 (ports r549922) to prevent a kernel panic on vboxdrv load, and there is another bug in memobj-r0drv-freebsd.c that prevented VM start:

Compared to previous versions, rtR0MemObjNativeMapUser has two additional arguments: an offset (offSub), and a size (cbSub). The function uses cbSub as mapping size in the vm_map_find call, but another value (pMemToMap->cb, the same as in previous versions) in the other vm-related calls (vm_map_wire, vm_map_remove, etc.). If I replace pMemToMap->cb with cbSub, my VMs start and run OK.

I don't really understand all the related code as a whole, so I'm not sure if this is the proper fix, or just a bandaid to some underlying issue (e.g. I have no idea if it is OK that the value of pMemToMap->cb and cbSub differs), but maybe this will help somebody with more experience with VirtualBox's code base.

Cheers,
Toma
Comment 111 Mario Lobo 2020-12-15 17:39:37 UTC
Hi;

I tried your port. It compiled fine.

13.0-CURRENT FreeBSD 13.0-CURRENT #0 r367205: Sun Nov  1 17:45:13 -03 2020

The GUI comes up fine but whatever machine I choose, it doesn't start.

It hangs on the dialog:

"Creating process for virtual machine "XXX" (GUI/Qt) ... (1/2)"
Comment 112 Tamas Szakaly 2020-12-15 18:20:35 UTC
Just a quick question: did you try to cold-boot these VMs, or restore a saved state? I'm asking because restoring a state that was saved with 5.2.44 did not work for me. Although it did not hang, but gave an error message.

I'm on HardenedBSD (commit f8ab4cc8702de9a12716e69d87951bdc9c672a77, from 12th December), but I'll see if I can try this on a vanilla FreeBSD in the coming days. In the meanwhile: could you please attach the log file of one of your VMs?
Comment 113 Mario Lobo 2020-12-15 18:30:08 UTC
It was cold boot. A Win 8.1 machine that I already have and work fine under 5.2.44.

The process doesn't get far enough for the machine to produce a log.

The only log touched is VBoxSVC.log which is as follows:

00:00:00.000833 main     VirtualBox XPCOM Server 6.1.16 r140961 freebsd.amd64 (Dec 15 2020 13:53:04) release log
00:00:00.000841 main     Log opened 2020-12-15T17:31:46.273251000Z
00:00:00.000842 main     Build Type: release
00:00:00.000851 main     OS Product: FreeBSD
00:00:00.000855 main     OS Release: 13.0-CURRENT
00:00:00.000954 main     OS Version: FreeBSD 13.0-CURRENT #0 r367205: Sun Nov  1 17:45:13 -03 2020     root@Papi.lobos:/usr/obj/usr/src-13-HEAD/amd64.amd64/sys/LOBO
00:00:00.000957 main     Firmware type: failed - VERR_NOT_SUPPORTED
00:00:00.000977 main     Host RAM: 16301MB (15.9GB) total, 14564MB (14.2GB) available
00:00:00.000983 main     Executable: /usr/local/lib/virtualbox/VBoxSVC
00:00:00.000984 main     Process ID: 1513
00:00:00.000984 main     Package type: BSD_64BITS_GENERIC (OSE)
00:00:00.003484 main     IPC socket path: /tmp/.vbox-root-ipc/ipcd
00:00:00.112178 nspr-2   VirtualBox: object creation starts
00:00:00.112426 nspr-2   Home directory: '/root/.VirtualBox'
00:00:00.112996 nspr-2   Loading settings file "/root/.VirtualBox/VirtualBox.xml" with version "1.14-freebsd"
00:00:01.117887 nspr-2   HostDnsMonitor: initializing
00:00:01.117957 nspr-2   NAT: resolv.conf: nameserver 10.10.1.254
00:00:01.117965 nspr-2   NAT: resolv.conf: nameserver 1.1.1.1
00:00:01.117971 nspr-2   NAT: resolv.conf: nameserver 208.67.220.220
00:00:01.117999 nspr-2   HostDnsMonitor: updating information
00:00:01.118009 nspr-2   HostDnsMonitor: old information
00:00:01.118012 nspr-2     no server entries
00:00:01.118014 nspr-2     no domain set
00:00:01.118016 nspr-2     no search string entries
00:00:01.118019 nspr-2   HostDnsMonitor: new information
00:00:01.118021 nspr-2     server 1: 10.10.1.254
00:00:01.118023 nspr-2     server 2: 1.1.1.1
00:00:01.118026 nspr-2     server 3: 208.67.220.220
00:00:01.118028 nspr-2     no domain set
00:00:01.118030 nspr-2     no search string entries
00:00:01.124472 nspr-2   failed to create vboxnet0, error (0x80004005)
00:00:01.124873 nspr-2   VD: VDInit finished with VINF_SUCCESS
00:00:01.126114 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Linux/Spyket/Spyket.vbox" with version "1.13-freebsd"
00:00:01.127112 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Windows/WinXP/WinXP.vbox" with version "1.15-freebsd"
00:00:01.127798 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Mac/Mac-OSx/Mac-OSx.vbox" with version "1.13-freebsd"
00:00:01.128096 nspr-2   ERROR [COM]: aRC=VBOX_E_OBJECT_NOT_FOUND (0x80bb0001) aIID={d0a0163f-e254-4e5b-a1f2-011cf991c38d} aComponent={VirtualBoxWrap} aText={Could not find an open hard disk with UUID {a34d686c-374c-44af-90df-1613e8886051}}, preserve=false aResultDetail=0
00:00:01.128738 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Mac/Snow/Snow.vbox" with version "1.15-freebsd"
00:00:01.130080 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Misc/OS-2/OS-2.vbox" with version "1.13-freebsd"
00:00:01.130718 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Linux/Debian/Debian.vbox" with version "1.15-freebsd"
00:00:01.131473 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Windows/Windows 7 Allen/Windows 7 Allen.vbox" with version "1.15-freebsd"
00:00:01.132336 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Novell/Novell-5/Novell-5.vbox" with version "1.13-freebsd"
00:00:01.133191 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Novell/Wn98-Novell/Wn98-Novell.vbox" with version "1.13-freebsd"
00:00:01.133835 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Novell/Praieira Server/Praieira Server.vbox" with version "1.13-freebsd"
00:00:01.134539 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Novell/Praieira Client/Praieira Client.vbox" with version "1.13-freebsd"
00:00:01.135258 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Windows/Win8/Win8.vbox" with version "1.17-freebsd"
00:00:01.136167 nspr-2   Loading settings file "/root/.VirtualBox/Machines/BSD/OPNsense/OPNsense.vbox" with version "1.14-freebsd"
00:00:01.136777 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Linux/xuDBServer/xuDBServer.vbox" with version "1.15-freebsd"
00:00:01.137409 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Windows/Win764/Win764.vbox" with version "1.15-freebsd"
00:00:01.138050 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Windows/Win7-VC6/Win7-VC6.vbox" with version "1.15-freebsd"
00:00:01.138954 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Linux/Klinx/Klinx.vbox" with version "1.17-freebsd"
00:00:01.139642 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Windows/Win10/Win10.vbox" with version "1.17-freebsd"
00:00:01.140190 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Linux/DebianDocker/DebianDocker.vbox" with version "1.16-freebsd"
00:00:01.140891 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Mac/Yosemite/Yosemite.vbox" with version "1.15-freebsd"
00:00:01.142126 nspr-2   Loading settings file "/root/.VirtualBox/Machines/Linux/WinFx/WinFx.vbox" with version "1.16-freebsd"
00:00:01.143411 nspr-2   VirtualBox: object created
00:00:02.203270 nspr-3   Loading settings file "/root/.VirtualBox/Machines/Mac/Mac-OSx/Mac-OSx.vbox" with version "1.13-freebsd"
00:01:26.249633 nspr-4   Saving settings file "/root/.VirtualBox/Machines/Windows/Win8/Win8.vbox" with version "1.17-freebsd"
00:01:32.325670 nspr-2   Launched VM: 44045152 pid: 1559 (0x617) frontend: GUI/Qt name: Win8
00:12:30.675743 main     VirtualBox: object deletion starts
00:12:30.676510 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Snow.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.677208 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Debian.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.677456 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Windows7Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.677469 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Windows72Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.677726 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Novell-5.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.677974 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win98-Novell.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.678190 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Praieira_Server.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.678406 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Praieira_Client.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.678624 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win8Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.678635 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win82Allen.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.678996 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/OPNsense.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.679225 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/xuDBServer.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.679448 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win764.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.679660 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win7.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.679672 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win72.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.679896 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Klinx.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.680114 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Win10.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.680245 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/DebianDocker.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.680487 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Bootload for AMD.vmdk' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.680611 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/Mac OS X Yosemite Niresh Intel And AMD.vmdk' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.680945 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={ad47ad09-787b-44ab-b343-a082a3f2dfb1} aComponent={MediumWrap} aText={Medium '/Vmachines/WinFx.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:12:30.682121 main     HostDnsMonitor: shutting down ...
00:12:30.682126 main     HostDnsMonitor: shut down
00:12:30.682935 Watcher  ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={d0a0163f-e254-4e5b-a1f2-011cf991c38d} aComponent={VirtualBoxWrap} aText={The object is not ready}, preserve=false aResultDetail=0
00:12:30.683380 main     VirtualBox: object deleted
Comment 114 Mario Lobo 2020-12-15 18:42:17 UTC
Log from selectorwindows.log

00:00:03.819459 VirtualBox GUI VM Selector Window 6.1.16 r140961 freebsd.amd64 (Dec 15 2020 13:53:04) release log
00:00:03.819463 Log opened 2020-12-15T17:31:47.654342000Z
00:00:03.819464 Build Type: release
00:00:03.819475 OS Product: FreeBSD
00:00:03.819479 OS Release: 13.0-CURRENT
00:00:03.819482 OS Version: FreeBSD 13.0-CURRENT #0 r367205: Sun Nov  1 17:45:13 -03 2020     root@Papi.lobos:/usr/obj/usr/src-13-HEAD/amd64.amd64/sys/LOBO
00:00:03.819486 Firmware type: failed - VERR_NOT_SUPPORTED
00:00:03.819673 Host RAM: 16301MB (15.9GB) total, 14557MB (14.2GB) available
00:00:03.819678 Executable: /usr/local/lib/virtualbox/VirtualBox
00:00:03.819679 Process ID: 1505
00:00:03.819679 Package type: BSD_64BITS_GENERIC (OSE)
00:00:03.819718 Qt version: 5.14.2
00:00:04.011328 GUI: UIMediumEnumerator: Medium-enumeration started...
00:00:05.030960 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated: Screen 0 work area is actually resized to: 0x0 x 1920x1052
00:00:05.042760 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated: Screen 1 work area is actually resized to: 1920x0 x 1920x1080
00:00:08.585889 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:01:28.890408 GUI: UIMediumEnumerator: Medium-enumeration finished!
Comment 115 Tamas Szakaly 2020-12-19 08:58:28 UTC
Thanks for the info and the logs. This is definitely something entirely different than the error I got before the patches, and I'm not able to reproduce it.

I've just created a machine from the latest (2020. 12. 17.) VM image for 13-CURRENT, compiled the 6.1.16 port inside it, and now it runs an Ubuntu 20.10 LiveCD. So it seems to be working on a fresh install of vanilla FreeBSD, it's not something on my HardenedBSD box that makes it work.
Comment 116 Mario Lobo 2020-12-19 17:42:38 UTC
I'm bringing my system to today's date to test it again.
Comment 117 Daniel Morante 2020-12-21 01:51:42 UTC
(In reply to Mikhail Teterin from comment #92)

I'm in favor of that suggestion.  Keep the 5.x version as a separate port and make a new 6.x port.  Also separating the guest addons makes sense.  Maybe even  having a 3rd one named 'dev' would allow for better testing new/fixing releases.
Comment 118 Mario Lobo 2020-12-23 19:23:30 UTC
Updated my system to the latest main:

13.0-CURRENT FreeBSD 13.0-CURRENT #0 3cc0c0d66-c1(main): Tue Dec 22

and still no go for the 6.1.16 port.

(In reply to Tamas Szakaly from comment #115)
Comment 119 Adriaan de Groot freebsd_committer 2021-01-12 23:32:51 UTC
I have added an `emulators/virtualbox6-ose` to the **KDE** ports tree, which can be cloned with git on GitHub, at `freebsd/freebsd-ports-kde.git`. That is mostly so that **I** have a useful copy to build, possibly improve, etc.

This PR seems stalled, waiting on something that *looks* like abandonware, which is why I took (at least part of) the route suggested by Cy in comment#28, and gave this a parallel name. Poudriere seems happy:

```
[00:08:58] Built ports: emulators/virtualbox6-ose-kmod emulators/virtualbox6-ose
[13amd64-area51] [2021-01-13_00h19m39s] [committing:] Queued: 2  Built: 2  Failed: 0  Skipped: 0  Ignored: 0  Tobuild: 0   Time: 00:08:57
```

If I can get this to boot anything locally, I'll return to this PR to report.
Comment 120 Adriaan de Groot freebsd_committer 2021-01-13 00:20:09 UTC
I'm running FreeBSD 13.0-CURRENT #0: Sat Nov 28 01:53:18 CET 2020
, with WITNESS, nvidia-driver-440.100_1, and the virtualbox6-ose + kmod I built (against those older kernel sources) boots all my Linux VMs created earlier with no issue. It's certainly no *worse* for my purposes than 5 was.

UEFI support seems to be a little better. Graphics performance -- videos in the VM, for instance -- seems meh, but it was like that before as well (I don't know a thing about tuning the host / VM for that, and since most of the time the VM is just running a regular desktop and compiles, there's no reason for me to dig into it).

Take-aways:
- "works for me" (6.1.16, with Qt 5.15.2)
- cloning the kde@ ports tree means you can just poudriere-build `emulators/virtualbox6-ose` (I did not chase any of the port variants) and it may work for you too.
Comment 121 Graham Perrin 2021-01-18 19:37:58 UTC
Thanks, 

(In reply to Adriaan de Groot from comment #119)

> I have added an `emulators/virtualbox6-ose` to the **KDE** ports tree, which can be cloned with git on GitHub, at `freebsd/freebsd-ports-kde.git`. …

Sorry, I don't see it: 

<https://github.com/freebsd/freebsd-ports-kde/search?q=virtualbox6-ose>
Comment 122 Christoph Moench-Tegeder freebsd_committer 2021-01-18 19:42:17 UTC
(In reply to Graham Perrin from comment #121)
https://github.com/freebsd/freebsd-ports-kde/tree/virtualbox-6/emulators/virtualbox6-ose
Comment 123 Martin Birgmeier 2021-01-23 13:56:24 UTC
With the port posted by Christoph, on 12.2 release I get

--------------------
Failed to open a session for the virtual machine openSUSE Tumbleweed amd64 (v912).

Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

--------------------

Is the port only usable on head right now?

-- Martin
Comment 124 Martin Birgmeier 2021-01-23 13:59:04 UTC
In addition, enabling option guest additions requires that distinfo be changed to

TIMESTAMP = 1611407263
SHA256 (VirtualBox-6.1.16.tar.bz2) = 49c1990da16d8a3d5bda8cdb961ec8195a901e67e4c79aea44c1521a5fc2f9f1
SIZE (VirtualBox-6.1.16.tar.bz2) = 165470821
SHA256 (VBoxGuestAdditions_6.1.16.iso) = 88db771a5efd7c048228e5c1e0b8fba56542e9d8c1b75f7af5b0c4cf334f0584
SIZE (VBoxGuestAdditions_6.1.16.iso) = 60987392
Comment 125 Jason W. Bacon freebsd_committer 2021-01-23 15:15:47 UTC
(In reply to Martin Birgmeier from comment #123)

It failed to run for me on 12.2 a couple weeks ago as well.  Unfortunately I don't have much time for it right now, but I'm following the thread and will try to provide some feedback ASAP.
Comment 126 Graham Perrin 2021-02-06 06:18:24 UTC
Created attachment 222196 [details]
14.0-CURRENT failed build of emulators/virtualbox6-ose-kmod from freebsd/freebsd-ports-kde

(In reply to Adriaan de Groot from comment #119)

(In reply to Christoph Moench-Tegeder from comment #122)

    …
    /usr/local/bin/ccache cc  -O2 -pipe -fno-strict-aliasing -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DSUPDRV_WITH_RELEASE_LOGGER -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -Iinclude -I. -Ir0drv -include /wrkdirs/usr/ports/emulators/virtualbox6-ose-kmod/work/VirtualBox-6.1.16/out/freebsd.amd64/release/bin/src/vboxdrv/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include     -MD  -MF.depend.memobj-r0drv-freebsd.o -MTmemobj-r0drv-freebsd.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes -mno-avx  -std=iso9899:1999 -c /wrkdirs/usr/ports/emulators/virtualbox6-ose-kmod/work/VirtualBox-6.1.16/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c -o memobj-r0drv-freebsd.o
    /wrkdirs/usr/ports/emulators/virtualbox6-ose-kmod/work/VirtualBox-6.1.16/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:877:80: error: too few arguments to function call, expected 6, have 5
        int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, FALSE);
                ~~~~~~~~~~~~~~                                                   ^
    /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
    int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
        ^
    1 error generated.
    *** Error code 1
    …

----

    % poudriere jail -i -j main
    Jail name:         main
    Jail version:      14.0-CURRENT 1400003
    Jail arch:         amd64
    Jail method:       src=/usr/src
    Jail mount:        /usr/local/poudriere/jails/main
    Jail fs:           copperbowl/poudriere/jails/main
    Jail updated:      2021-01-30 19:59:28
    % freebsd-version -kru
    14.0-CURRENT
    14.0-CURRENT
    14.0-CURRENT
    % uname -v
    FreeBSD 14.0-CURRENT #84 main-53729367d3: Sat Jan 30 18:47:56 GMT 2021     root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
    %
Comment 127 Graham Perrin 2021-02-06 06:43:26 UTC
Created attachment 222197 [details]
distinfo for virtualbox6-ose-6.1.18

(In reply to Graham Perrin from comment #126)

Given the recent release of 6.1.18, <https://www.virtualbox.org/wiki/Changelog-6.1#v18>

root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default/emulators/virtualbox6-ose # sed -i -e 's|6.1.16|6.1.18|g' ./Makefile
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default/emulators/virtualbox6-ose # rm distinfo 
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default/emulators/virtualbox6-ose # cd ../virtualbox6-ose-kmod
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default/emulators/virtualbox6-ose-kmod # sed -i -e 's|6.1.16|6.1.18|g' ./Makefile
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default/emulators/virtualbox6-ose-kmod # rm distinfo
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default/emulators/virtualbox6-ose-kmod # cd ../..
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default # make makesum -C emulators/virtualbox6-ose
===>  License GPLv2 accepted by the user
===>  License GPLv2 accepted by the user
===>   virtualbox6-ose-6.1.18 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by virtualbox6-ose-6.1.18 for building
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default # cat emulators/virtualbox6-ose/distinfo
TIMESTAMP = 1612593255
SHA256 (VirtualBox-6.1.18.tar.bz2) = 108d42b9b391b7a332a33df1662cf7b0e9d9a80f3079d16288d8b9487f427d40
SIZE (VirtualBox-6.1.18.tar.bz2) = 165507486
SHA256 (VBoxGuestAdditions_6.1.18.iso) = 904432eb331d7ae517afaa4e4304e6492b7947b46ecb8267de7ef792c4921b4c
SIZE (VBoxGuestAdditions_6.1.18.iso) = 61157376
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default #
Comment 128 Graham Perrin 2021-02-06 06:45:49 UTC
Created attachment 222198 [details]
distinfo for virtualbox6-ose-kmod-6.1.18

root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default # make makesum -C emulators/virtualbox6-ose-kmod
===>  License GPLv2 accepted by the user
===>  License GPLv2 accepted by the user
===>   virtualbox6-ose-kmod-6.1.18 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by virtualbox6-ose-kmod-6.1.18 for building
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default # cat emulators/virtualbox6-ose-kmod/distinfo
TIMESTAMP = 1612593451
SHA256 (VirtualBox-6.1.18.tar.bz2) = 108d42b9b391b7a332a33df1662cf7b0e9d9a80f3079d16288d8b9487f427d40
SIZE (VirtualBox-6.1.18.tar.bz2) = 165507486
root@mowa219-gjp4-8570p:/usr/local/poudriere/ports/default #
Comment 129 Graham Perrin 2021-02-06 06:54:18 UTC
Created attachment 222199 [details]
6.1.18 in lieu of 6.1.16

(In reply to Graham Perrin from comment #126)

virtualbox6-ose-kmod-6.1.18 similarly failed to build: 

    …
    /usr/local/bin/ccache cc  -O2 -pipe -fno-strict-aliasing -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DSUPDRV_WITH_RELEASE_LOGGER -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -Iinclude -I. -Ir0drv -include /wrkdirs/usr/ports/emulators/virtualbox6-ose-kmod/work/VirtualBox-6.1.18/out/freebsd.amd64/release/bin/src/vboxdrv/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include     -MD  -MF.depend.memobj-r0drv-freebsd.o -MTmemobj-r0drv-freebsd.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes -mno-avx  -std=iso9899:1999 -c /wrkdirs/usr/ports/emulators/virtualbox6-ose-kmod/work/VirtualBox-6.1.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c -o memobj-r0drv-freebsd.o
    /wrkdirs/usr/ports/emulators/virtualbox6-ose-kmod/work/VirtualBox-6.1.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:877:80: error: too few arguments to function call, expected 6, have 5
        int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, FALSE);
                ~~~~~~~~~~~~~~                                                   ^
    /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
    int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
        ^
    1 error generated.
    *** Error code 1
    …
Comment 130 Graham Perrin 2021-02-06 08:02:38 UTC
Created attachment 222201 [details]
distinfo for virtualbox6-ose-6.1.18

My bad, the previous file unnecessarily included info for the guest additions .iso
Comment 131 Cy Schubert freebsd_committer 2021-02-09 15:41:57 UTC
Should we consider renaming virtualbox-ose and friends to virtualbox-ose52 and create a new virtualbox-ose61 group of ports?
Comment 132 Jason W. Bacon freebsd_committer 2021-02-09 16:43:20 UTC
(In reply to Cy Schubert from comment #131)

Renaming ports breaks pkg upgrade (unless something has changed since I last checked).  Pkgsrc has a SUPERCEDES variable to indicate the previous package name, but AFAIK we don't have anything equivalent in ports.  This has been an ongoing annoyance for ports with versions in their name like php7*, emacs2*, etc. when the older ports are removed and it gives users a bad impression of FreeBSD.

I'd advise always keeping vanilla virtualbox-ose in the tree in some form, maybe as the stable version with virtualbox-ose-devel for bleeding edge.  Looks like the emacs maintainers have switched to this approach and removed the version-specific ports.  When 6.x is well-tested we could sync it to virtualbox-ose and  add virtualbox-ose5* if anyone still wants to keep it around.  virtualbox-ose-devel can provide either newer versions of 6.x or move onto 7.x when appropriate.

Best,

    JB
Comment 133 Cy Schubert freebsd_committer 2021-02-09 16:52:58 UTC
Create a meta-port that points to the currently recommended real port. I do this with krb5 and cfengine, both of which people need to run the older software for various reasons. For example I did this for KRB5 because an admin at MIT needed to stay at an older level. I maintain the krb5-NNN - 2 for one year after NNN is released, giving users of older software a year to migrate off it.

Then of course there's MOVED. We might be able to leverage that in pkgng, but this veers way off topic now.

A meta-port might pointing to the real port help.
Comment 134 Christoph Moench-Tegeder freebsd_committer 2021-02-09 22:49:45 UTC
(In reply to Martin Birgmeier from comment #123)
Some progress here: I can reproduce your problem (this one: "Failed to construct device 'VMMDev' instance #0" - please do not confuse this with other... hickups).

To be very clear, the reproducer is:
- FreeBSD 12.2-RELEASE-p3 amd64
- virtualbox and kmod 6.1.16 from https://github.com/freebsd/freebsd-ports-kde/tree/virtualbox-6/emulators/virtualbox6-ose branch virtualbox-6 commit b23261a0ddb509b882130860891cacda768ca508 (Jan 13).
- swap out the "old" virtualbox packages for the new virtualbox6-ose{,-kmod} packages
- start an existing VM (as in "was created under virtualbox 5.2")
- get error "Failed to contruct device 'VMMDev'..."

There may be other ways to demonstrate the problem, but this is the one I used.

With some poking, I diagnosed:
on the way from VMMDev::i_guestPropLoadAndConfigure() (src/VBox/Main/src-client/VMMDevInterface.cpp) through Console::i_pullGuestProperties() (src/VBox/Main/src-client/ConsoleImpl.cpp), SessionMachine::pullGuestProperties() (src/VBox/Main/src-server/MachineImpl.cpp) and back the "SafeArray<LONG64> timestampsOut" is casted through "'PRInt64 **' (aka 'long **')" and std::vector<LONG64> by way of the "ComSafeArrayAsOut..." mechanisms (insert rant about hard-to-get-the-details casting). While the std::vector<> form is being resize()ed in pullGuestProperties(), the SafeArray<> side in i_guestPropLoadAndConfigure() does not see the result and trips the error condition which is reported as "INTERNAL_ERROR_3". Note that pullGuestProperties() is in the VBoxSVC process, while the other functions seem to be in the "central" virtualbox process (judging from logging and some poking) - there's some remote-calling going on.

Solution: The whole construction has been working "somewhere", else no recent VirtualBox version would ever work. Eliminating the obvious (clang), I forced compilation with gcc by dropping a "USE_GCC=yes" into the port's Makefile. Success!

Summary: clang (at least from system llvm "10.0.1") compiles the casting-constructs in an unexpected way. (Between the C++ casting rules and the not-fully-understood (by me) multiple-castings-while-crossing-subsystems I'm very reluctant to declare one or the other compiler "wrong"). With this resolved, I guess we can finally have virtualbox61* (or whatever, I don't care much about the name) ports. Can anyone confirm this?
Comment 135 Mario Lobo 2021-02-11 11:24:37 UTC
System: FreeBSD 13.0-ALPHA2 #0 stable/13-035f4ea71: Fri Jan 22

Tried freebsd-ports-kde/tree/virtualbox-6/emulators/virtualbox6-ose.

virtualbox6-ose compiled without errors, BUT virtualbox6-ose-kmod presented several problems during compilation:

1) src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c

   Had add #include <sys/mutex.h> to it, or in mtx_lock/unlock(&Giant), compile
   would stop with "Giant: undefined identifier".

2) src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c

   switch:
   int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, FALSE);
   To:
   int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, 0, 
                            VM_MAP_PROTECT_SET_PROT);

   or compilation stops with "vm_map_protect: too few parameters"

3) On both files above, commented IPRT_FREEBSD_SAVE_EFL_AC() and 
   IPRT_FREEBSD_RESTORE_EFL_AC() 
   
   They didn't error the compilation but issued "unidentified symbol" for both 
   during loading of the modules, BUT commenting them caused a kernel panic when 
   loading the modules.

4) Issuing make patch on virtualbox6-ose-kmod IS NOT applying the patches to the 
   above files.


With no modules, I could not test further.
Comment 136 martin ilavsky 2021-02-11 12:40:10 UTC
I used Christop's KDE ports from https://github.com/freebsd/freebsd-ports-kde/tree/virtualbox-6/emulators/virtualbox6-ose to compile and install virtualbox6-ose-6.1.16 and virtualbox6-ose-kmod-6.1.16.

I was able to start the VM if VM had no network assigned. When I try to create hostonly interface I got panic:


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address   = 0x28
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80cb788a
stack pointer           = 0x28:0xfffffe002eb44710
frame pointer           = 0x28:0xfffffe002eb44740
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1595 (VBoxNetAdpCtl)
trap number             = 12
panic: page fault
cpuid = 1
time = 1613046633
KDB: stack backtrace:
#0 0xffffffff80c0a8f5 at kdb_backtrace+0x65
#1 0xffffffff80bbeb1b at vpanic+0x17b
#2 0xffffffff80bbe993 at panic+0x43
#3 0xffffffff8108f911 at trap_fatal+0x391
#4 0xffffffff8108f96f at trap_pfault+0x4f
#5 0xffffffff8108efb6 at trap+0x286
#6 0xffffffff81066f38 at calltrap+0x8
#7 0xffffffff82b8e02a at vboxNetAdpOsCreate+0x1a
#8 0xffffffff82b8e619 at vboxNetAdpCreate+0xc9
#9 0xffffffff82b8e4f6 at VBoxNetAdpFreeBSDCtrlioctl+0x86
#10 0xffffffff80a79100 at devfs_ioctl+0xb0
#11 0xffffffff8124722b at VOP_IOCTL_APV+0x7b
#12 0xffffffff80c9ca7a at vn_ioctl+0x16a
#13 0xffffffff80a796ee at devfs_ioctl_f+0x1e
#14 0xffffffff80c286a7 at kern_ioctl+0x2b7
#15 0xffffffff80c2834a at sys_ioctl+0xfa
#16 0xffffffff810904c7 at amd64_syscall+0x387
#17 0xffffffff8106785e at fast_syscall_common+0xf8

This happened both on physical HW and VM.

Physical HW: 12.2-RELEASE r367186 amd64
VM: 12.2-RELEASE r366954 amd64

Tried with both VIMAGE support enabled and disabled.
Comment 137 Graham Perrin 2021-02-15 18:06:08 UTC
(In reply to Mario Lobo from comment #135)

Does recently fixed bug 252675 relate to point 2?
Comment 138 Mario Lobo 2021-02-15 18:51:31 UTC
(In reply to Graham Perrin from comment #137)

1) and 2) are the smallest of problems. I corrected them manually. 3) and 4) are more severe and I have no idea on how to fix.
Comment 139 Mario Lobo 2021-02-18 15:20:25 UTC
I don't know exactly how it happened but SUCCESS!


FreeBSD 13.0-STABLE #1 stable/13-0dc5c9467: Thu Feb 11

[~]>pkg info | grep virtualbox
virtualbox-ose-6.1.16          General-purpose full virtualizer for x86 hardware
virtualbox-ose-kmod-6.1.16     VirtualBox kernel module for FreeBSD

I had a port of 6.1.16 I'd been working on, but on 13-CURRENT. Then the KDE port came out. Adjusted the patches for 1) and 2) mentioned on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878#c135. Tried it on:

- 13-CURRENT 
- ALPHA2
- The above STABLE

None worked. GUI comes up but starting a VM hangs forever.

I went back to the port I was working on. Copied the adjusted patches to it.

Then I tried Christoph Moench-Tegeder USE_GCC=yes tip. The GUI doesn't start and dumps core.

So I just tried it straight on (no USE_GCC=yes) and everything worked. Every VM started absolutely normal. Windows, linux, even a hackintosh.

If anybody is interested in trying, I can tar both ports and attach here.
Comment 140 Jason W. Bacon freebsd_committer 2021-02-18 15:58:14 UTC
(In reply to Mario Lobo from comment #139)

Yes, please.  Would be nice if we had a framework to collaborate on instead of piecing together from various patches, which is an error-prone process.  I volunteer my WIP collection:

https://github.com/outpaddling/freebsd-ports-wip

I will add anyone who wants to contribute as a collaborator, or at least post the latest framework here and add patches people send.
Comment 141 Mario Lobo 2021-02-18 19:22:04 UTC
Created attachment 222558 [details]
VirtualBox 6.1.16 port

Working port of VirtualBox 6.1.16 tested under FreeBSD 13.0-STABLE #1 stable/13-0dc5c9467: Thu Feb 11 13:36:07 -03 2021.
Comment 142 Mario Lobo 2021-02-18 19:25:28 UTC
(In reply to Jason W. Bacon from comment #140)

Jason;

Please fell free to upload this to your git if your tests with it are successful.
Comment 143 Jason W. Bacon freebsd_committer 2021-02-18 21:49:32 UTC
It builds on 12.2-RELEASE and the GUI works, but I cannot create or launch a guest:

Trying to create a new VM:

Failed to register the virtual machine .
Callee RC: NS_ERROR_ABORT (0x80004004)

Trying to launch a VM created on 5.x:

Failed to open a session for the virtual machine FreeBSD12.
The VM session was aborted.
Result Code: NS_ERROR_FAILURE (0x80004005)
Component: SessionMachine
Interface: ISession {c0447716-ff5a-4795-b57a-ecd5fffa18a4}

The port is available here:

https://github.com/outpaddling/freebsd-ports-wip/tree/master/virtualbox-ose-devel

Please send unified diffs against it or if you want to commit yourself I can add collaborators.
Comment 144 Mario Lobo 2021-02-20 16:02:41 UTC
More good news!

The very port that I previously attached, just compiled and ran perfectly on a 
FreeBSD 14.0-CURRENT #3 main-a63eae65ff: Sat Jan 30 14:51:28 -03 2021.

This one is on a desktop AMD FX-8320E Eight-Core Processor.

My previous successful attempt was on laptop Acer Aspire Intel I5 8th gen.

I must say that with 6.1.16, all VMs run quite faster and smoother than with ver 5.x, and all graphic controllers (VBoxVGA, VBoxSVGA, etc..) work perfectly.


On side note, I downloaded the port file I attached previously to the desktop just make sure that it was the same I used on the laptop.
Comment 145 Mario Lobo 2021-02-20 16:40:05 UTC
(In reply to Jason W. Bacon from comment #143)

Jason, before I do that, I would appreciate if more people download what I attached here and see if it works for them first.
Comment 146 imbutler 2021-02-20 21:59:14 UTC
(In reply to Mario Lobo from comment #145)

I just built this from your tarball on ..

FreeBSD 14.0-CURRENT #96 main-a8e431e153: Sat Feb 20 14:27:02 EST 2021     

 .. and everything seems to work as desired. It's even faster than my old 6.0 version :-)
Comment 147 Guido Falsi freebsd_committer 2021-02-20 22:18:29 UTC
I'm on my way to test this one too. I am testing it in poudriere in the while.

@ Mario Lobo

your tarball ports only includes part of commit r562683, an ifdef is required to make it work both before and after src commit 0659df6faddf.

After fixing this I've also observed a strange failure on 12.2 i386, which I'll investigate later.

One more question, why did you change ${ECHO_CMD} to ${ECHO}? While it works the same I guess the former is preferred in ports.


I'll send a revised tarball once I'm done with my tests.
Comment 148 imbutler 2021-02-20 23:12:10 UTC
As a side note - I just adjusted the two Makefiles to pull 6.1.18 and ran 'make makesum' to fix the distinfo files. Works just as well,

  imb
Comment 149 Mario Lobo 2021-02-21 01:58:25 UTC
(In reply to Guido Falsi from comment #147)
Guido;

The only changes I made on patches were:

1) The ones I mentioned on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878#c135

2) I adapted a patch made for version 5.x that makes VMs work with OSS.

That was it. I didn't touch anything else.
Comment 150 Mario Lobo 2021-02-21 01:59:52 UTC
(In reply to imbutler from comment #148)

Will do that first thing tomorrow!
Comment 151 Graham Perrin 2021-02-21 04:19:51 UTC
Created attachment 222693 [details]
Screenshot of the application

(In reply to Mario Lobo from comment #141)

The application runs but I can not load the kernel module. 

I did run portsnap auto before slotting files into place. 

root@mowa219-gjp4-8570p:~ # tail -n 15 /var/log/messages
Feb 21 02:27:47 mowa219-gjp4-8570p pkg[27139]: gsoap-2.8.111 installed
Feb 21 02:27:47 mowa219-gjp4-8570p pkg[27139]: yasm-1.3.0 installed
Feb 21 02:30:47 mowa219-gjp4-8570p pkg[28533]: virtualbox-ose-5.2.44_4 deinstalled
Feb 21 02:30:56 mowa219-gjp4-8570p pkg[28533]: virtualbox-ose-kmod-5.2.44_4 deinstalled
Feb 21 02:32:16 mowa219-gjp4-8570p pkg-static[29251]: virtualbox-ose-kmod-6.1.16 installed
Feb 21 03:31:39 mowa219-gjp4-8570p sm-mta[38576]: 11L3Vbjd038576: Losing ./qf11L3Vbjd038576: savemail panic
Feb 21 03:31:39 mowa219-gjp4-8570p sm-mta[38576]: 11L3Vbjd038576: SYSERR(root): savemail: cannot save rejected email anywhere
Feb 21 03:32:29 mowa219-gjp4-8570p pkg-static[39178]: virtualbox-ose-6.1.16 installed
Feb 21 03:38:22 mowa219-gjp4-8570p kernel: KLD vboxdrv.ko: depends on kernel - not available or version mismatch
Feb 21 03:38:22 mowa219-gjp4-8570p kernel: linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type
Feb 21 03:49:42 mowa219-gjp4-8570p pkg-static[42743]: virtualbox-ose-kmod-6.1.16 deinstalled
Feb 21 03:49:45 mowa219-gjp4-8570p pkg-static[42818]: virtualbox-ose-kmod-6.1.16 installed
Feb 21 03:50:16 mowa219-gjp4-8570p kernel: KLD vboxdrv.ko: depends on kernel - not available or version mismatch
Feb 21 03:50:16 mowa219-gjp4-8570p kernel: linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type
Feb 21 03:53:13 mowa219-gjp4-8570p su[43372]: grahamperrin to root on /dev/pts/2
root@mowa219-gjp4-8570p:~ # freebsd-version -kru
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
root@mowa219-gjp4-8570p:~ # date ; uname -a
Sun Feb 21 03:53:55 GMT 2021
FreeBSD mowa219-gjp4-8570p 14.0-CURRENT FreeBSD 14.0-CURRENT #14 main-f44e67d120: Wed Feb 10 23:57:02 GMT 2021     root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
root@mowa219-gjp4-8570p:~ #
Comment 152 VVD 2021-02-21 07:56:33 UTC
If it's possible, keep 6.0 in ports too.
6.1.0 have this in changelog (https://www.virtualbox.org/wiki/Changelog-6.1#v0):
> Virtualization core: Drop recompiler, i.e. running VMs now needs a CPU supporting hardware virtualization

It's Core 2 Duo E7xxx/E4xxx, Pentium Dual-Core E2xxx, Celeron E1xxx, Core 2 Quad Q8200/Q8300 and a lot of mobile CPUs.
Comment 153 Guido Falsi freebsd_committer 2021-02-21 10:56:13 UTC
(In reply to Mario Lobo from comment #149)

Thanks, I did not mean to criticize, I only needed some clarifications.

I think you really did a great work on this.

I only changed some minor things to reduce differences with the present ports tree and added an ifdef to make it work on 12 and 11. As I said I'm still getting a strange error on i386 I need to investigate.

Before sending my changes I'm also trying to fix additions ports, since we really need them updated together with the main port.


I hope to be able to contribute my work later today, after properly testing it.
Comment 154 martin ilavsky 2021-02-21 12:30:25 UTC
Will 6.x version actually compile/work on FreeBSD 12.2 ? I've downloaded Mario's port from Feb 18 and tried to compile it. I got the error:

--- memobj-r0drv-freebsd.o ---
/root/vbox6/virtualbox-ose-kmod/work/VirtualBox-6.1.16/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:877:78: error: use of undeclared identifier 'VM_MAP_PROTECT_SET_PROT'
    int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, 0, VM_MAP_PROTECT_SET_PROT);
                                                                             ^
1 error generated.
*** [memobj-r0drv-freebsd.o] Error code 1

I checked the r366954 12 sources and was not able to find this identifier. Then I found this commit:

https://cgit.freebsd.org/src/commit/?id=0659df6faddfb27ba54a2cae2a12552cf4f823a0

While I didn't expect it would be there I did checkout the latest 12 stable sources with svn - revision 369328 - to no success.
Comment 155 Mario Lobo 2021-02-21 13:02:07 UTC
(In reply to martin ilavsky from comment #154)
Martin;

That was the problem I was having with the KDE port. See item 4) on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878#c135.

That doesn't happen with the attached port.

Also notice that I am on 

svn info /usr/ports

Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: https://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 563420
Node Kind: directory
Schedule: normal
Last Changed Author: jbeich
Last Changed Rev: 563419
Last Changed Date: 2021-01-30 12:33:28 -0300 (Sat, 30 Jan 2021)
Comment 156 Mario Lobo 2021-02-21 13:06:39 UTC
(In reply to Guido Falsi from comment #153)

No critisism taken, Guido!

We are all helping each other here.
Comment 157 Mario Lobo 2021-02-21 13:25:26 UTC
(In reply to martin ilavsky from comment #154)

Martin;

I gave you a wrong answer!

You have a reverse problem. It seems that on 12.x, vm_map_protect() had not changed its specs to 6 parameters yet, so the patch file patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c needs a conditional in there to check fo BSD < 13.

We need to find out exactly at what src revision this change occurred.
Comment 158 martin ilavsky 2021-02-21 13:26:58 UTC
(In reply to Mario Lobo from comment #155)
Strange, I have it the other way around. I didn't have this problem on KDE ports (used the branch origin/virtualbox-6) and was able to compile it. Problem was I had either kernel panic in the netdrv or system hung during kldunload phase. 

In your port version I see this patch (patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c) which does include the patch and introduces this symbol. 

While I think it doesn't matter either version was compiled outside the /usr/ports


Edit after update: I see you were faster then me.
Comment 159 martin ilavsky 2021-02-21 13:38:33 UTC
Mario,
It seems it is the commit I pasted above.
Comment 160 Mario Lobo 2021-02-21 13:45:21 UTC
(In reply to imbutler from comment #148)

I second that!

6.1.18 is working just fine too!
Comment 161 Mario Lobo 2021-02-21 13:51:35 UTC
(In reply to martin ilavsky from comment #159)

Well, the identifier is in /sys/vm/vm_map.h. If you updated your src,build world+kernel and install world, the VM_MAP_PROTECT_SET_PROT identifier IS there!

And vbox kmod should compile fine.
Comment 162 martin ilavsky 2021-02-21 14:18:29 UTC
(In reply to Mario Lobo from comment #161)
Sorry for stupid question but if I fetch the head src won't I be on 13.0 ? Or am I wrong?
Comment 163 Mario Lobo 2021-02-21 14:24:34 UTC
(In reply to martin ilavsky from comment #162)

Here is what I did:

mkdir /usr/src.main
mkdir /usr/src.stable-13

to follow current:

git clone -o freebsd -b main --single-branch --depth 1 https://git.freebsd.org/src.git /usr/src.main

to follow stable/13:

git clone -o freebsd -b stable/13 --single-branch --depth 1 https://git.freebsd.org/src.git /usr/src.stable-13
Comment 164 Mario Lobo 2021-02-21 14:25:33 UTC
Then just "git pull" inside the directory you want to update.
Comment 165 Mario Lobo 2021-02-21 14:33:23 UTC
Here you can see all -b options you can have:

https://cgit.freebsd.org/src/refs/heads
Comment 166 Guido Falsi freebsd_committer 2021-02-21 14:44:41 UTC
(In reply to Mario Lobo from comment #157)

The VM_MAP_PROTECT_SET_PROT is fixed in the official tree by revision 
562683

here is the relevent diff:

https://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c?r1=562683&r2=562682&pathrev=562683


as you can see "#if __FreeBSD_version >= 1300135" does the trick, that's the nearest value of __FreeBSD_version.

I'm preparing a new patched port including this change. But before attaching it here I'd also like to fix the addition ports.

I'm now fighting with this error for the additions:

Build: Compiling VBoxService - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/src/VBox/Additions/common/VBoxService/VBoxServiceUtils.cpp
In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/src/VBox/Additions/common/VBoxControl/VBoxControl.cpp:37:
In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/include/VBox/VBoxGuestLib.h:37:
In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/include/VBox/VMMDev.h:40:
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/include/VBox/VMMDevCoreTypes.h:293:15: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef struct
              ^
               HGCMFunctionParameter32
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/include/VBox/VMMDevCoreTypes.h:328:5: note: type is not C-compatible due to this member declaration
    void SetUInt32(uint32_t u32)
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/include/VBox/VMMDevCoreTypes.h:368:3: note: In file included from /usr/local/include/xorg/scrnintstr.h:53:
In file included from /usr/local/include/xorg/cursor.h:53:
In file included from /usr/local/include/xorg/privates.h:150:
/usr/local/include/xorg/dix.h:139:15: error: unknown type name '_X_NOTSAN'
static inline _X_NOTSAN Bool
              ^
/usr/local/include/xorg/dix.h:139:8: error: 'inline' can only appear on functions
static inline _X_NOTSAN Bool
       ^
/usr/local/include/xorg/dix.h:139:29: error: expected ';' after top level declarator
static inline _X_NOTSAN Bool
                            ^
                            ;
kBuild: Compiling VBoxService - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/src/VBox/Additions/common/VBoxService/VBoxServiceStats.cpp
/usr/local/include/xorg/dix.h:340:12: error: unknown type name 'TimeStamp'; did you mean 'TimeStampPtr'?
           TimeStamp time);
           ^~~~~~~~~
           TimeStampPtr
/usr/local/include/xorg/dix.h:119:28: note: 'TimeStampPtr' declared here
typedef struct _TimeStamp *TimeStampPtr;
                           ^
type is given name 'HGCMFunctionParameter32' for linkage purposes by this typedef declaration
} HGCMFunctionParameter32;
  ^



I suspect adding a "#include <X11/Xfuncproto.h>" line in the right place could fix it, but not sure if it's correct.
Comment 167 Mario Lobo 2021-02-21 15:22:36 UTC
(In reply to Guido Falsi from comment #166)
Excellent, Guido!

Patch applied!
Comment 168 Guido Falsi freebsd_committer 2021-02-21 15:40:33 UTC
Created attachment 222701 [details]
VirtualBox 6.1.18 revised patch

I'm attaching a patch relative to the head of the ports tree from subversion (still the official repo). I'm using a diff because it's easier to work with for committers.

This is based on Lobo tarball, I reduced diff with the official ports tree, updated to 6.1.18, included the patch from r562683 and tried to fix the additions ports.

Unluckily additions fail with a strange xorg related compile time error.

Looks like the problem is related to virtualbox embedding most of xorg and embedding an older version than what we have. I'm not sure I will be able to fix this.

I found a reference to a similar error in bug #196678 but I could not understand how it was fixed by looking at the (huge) patch.

Any help appreciated on this.

I'd like to fix additions (which is required to land this) and then I'd repocopy the old virtualbox ports to "virtualbox5" or something similar and create a code review. But to go ahead we definitely need additions working.
Comment 169 Guido Falsi freebsd_committer 2021-02-21 15:41:30 UTC
(In reply to Guido Falsi from comment #168)

BTW simply including X11/Xfuncproto.h is not working, altough it's related to the issue.
Comment 170 Mario Lobo 2021-02-21 16:07:02 UTC
Guido;

Your "#if __FreeBSD_version >= 1300135" patch didn't apply cleanly so I re-did the whole this and came up with this from diff -Naur patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c.orig patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c:

--- patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c.orig	2021-02-10 14:22:09.000000000 -0300
+++ patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c	2021-02-21 12:53:21.000000000 -0300
@@ -1,5 +1,5 @@
---- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig	2020-10-16 13:38:10.000000000 -0300
-+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c	2021-02-10 14:16:36.331990000 -0300
+--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig	2021-01-07 12:42:08.000000000 -0300
++++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c	2021-02-21 12:44:13.000000000 -0300
 @@ -129,6 +129,7 @@
  
  DECLHIDDEN(int) rtR0MemObjNativeFree(RTR0MEMOBJ pMem)
@@ -341,17 +341,23 @@
  
      if ((fProt & RTMEM_PROT_NONE) == RTMEM_PROT_NONE)
          ProtectionFlags = VM_PROT_NONE;
-@@ -819,7 +874,8 @@
+@@ -818,8 +873,13 @@
+         ProtectionFlags |= VM_PROT_WRITE;
      if ((fProt & RTMEM_PROT_EXEC) == RTMEM_PROT_EXEC)
          ProtectionFlags |= VM_PROT_EXECUTE;
- 
+-
 -    int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, FALSE);
-+    int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, 0, VM_MAP_PROTECT_SET_PROT);
++    
++	#if __FreeBSD_version >= 1300135
++        int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, 0, VM_MAP_PROTECT_SET_PROT);
++    #else
++        int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, FALSE);
++    #endif		
 +    IPRT_FREEBSD_RESTORE_EFL_AC();
      if (krc == KERN_SUCCESS)
          return VINF_SUCCESS;
  
-@@ -844,11 +900,19 @@
+@@ -844,11 +904,19 @@
  
              vm_offset_t pb = (vm_offset_t)pMemFreeBSD->Core.pv + ptoa(iPage);
  
@@ -375,7 +381,7 @@
          }
  
          case RTR0MEMOBJTYPE_MAPPING:
-@@ -857,11 +921,15 @@
+@@ -857,11 +925,15 @@
  
              if (pMemFreeBSD->Core.u.Mapping.R0Process != NIL_RTR0PROCESS)
              {
@@ -392,7 +398,7 @@
              }
              return vtophys(pb);
          }
-@@ -872,9 +940,11 @@
+@@ -872,9 +944,11 @@
          {
              RTHCPHYS addr;
Comment 171 Guido Falsi freebsd_committer 2021-02-21 16:58:23 UTC
(In reply to Mario Lobo from comment #170)

The patch could not be applied as is, I only pointed you to the correct patch against old virtualbox 5. You should have modified the file and recreated the patch.

Anyway I've attached patches against the head of the subversion repositories, Which include that one too.

I'm also going to update that patch later. I'm making progress with the additions, but I had to reapply some more recent virtualbox changes which were lost for some reason after grabbing your tarball.

Please give me a little more time to clean things up a little. This is a complex port and I'm also trying to clean things up a little to put it in shape to be committed.
Comment 172 Jason W. Bacon freebsd_committer 2021-02-21 18:31:57 UTC
(In reply to Guido Falsi from comment #168)

The patch applied cleanly for me and I pushed the resulting port to

https://github.com/outpaddling/freebsd-ports-wip/tree/master/virtualbox-ose-devel

It builds cleanly on 12.2-RELEASE, but now triggers a panic when I try to start a VM instead of the error popup I got with 6.1.16.

12.2-RELEASE-p3 FreeBSD 12.2-RELEASE-p3 GENERIC  amd64

panic: breakpoint instruction fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
vboxdrv: ffffffff8318e020 VMMR0.r0

!!Assertion Failed!!
Expression: rc == KERN_SUCCESS
Location  : /usr/ports/wip/virtualbox-ose-kmod-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c(773) int rtR0MemObjNativeMapUser(PPRTR0MEMOBJINTERNAL, RTR0MEMOBJ, RTR3PTR, size_t, unsigned int, RTR0PROCESS, size_t, size_t)
0x1


Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 4; apic id = 04
instruction pointer	= 0x20:0xffffffff824f1dde
stack pointer	        = 0x28:0xfffffe004ded64d0
frame pointer	        = 0x28:0xfffffe004ded6520
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, IOPL = 0
current process		= 2947 (VirtualBoxVM)
trap number		= 3
panic: breakpoint instruction fault
cpuid = 4
time = 1613931224
KDB: stack backtrace:
#0 0xffffffff80c0aa85 at kdb_backtrace+0x65
#1 0xffffffff80bbed3b at vpanic+0x17b
#2 0xffffffff80bbebb3 at panic+0x43
#3 0xffffffff8108e911 at trap_fatal+0x391
#4 0xffffffff8108dd97 at trap+0x67
#5 0xffffffff81066938 at calltrap+0x8
#6 0xffffffff824efb06 at RTR0MemObjMapUserExTag+0x1a6
#7 0xffffffff8319673e at __stop_set_sysinit_set+0x8cf6
#8 0xffffffff831961e9 at __stop_set_sysinit_set+0x87a1
#9 0xffffffff831bcde6 at __stop_set_sysinit_set+0x2f39e
#10 0xffffffff824b17f2 at supdrvIOCtlInnerUnrestricted+0x1a02
#11 0xffffffff824c76aa at VBoxDrvFreeBSDIOCtl+0x1ca
#12 0xffffffff80a79250 at devfs_ioctl+0xb0
#13 0xffffffff8124622b at VOP_IOCTL_APV+0x7b
#14 0xffffffff80c9cc0a at vn_ioctl+0x16a
#15 0xffffffff80a7983e at devfs_ioctl_f+0x1e
#16 0xffffffff80c28837 at kern_ioctl+0x2b7
#17 0xffffffff80c284da at sys_ioctl+0xfa
Comment 173 Guido Falsi freebsd_committer 2021-02-21 19:34:50 UTC
Created attachment 222704 [details]
VirtualBox 6.1.18 revised patch

New updated patch, again relative to head of the subversion repo.

This patch also includes fixes for additions.

The bcmp fix comes from here:

https://lists.freebsd.org/pipermail/freebsd-virtualization/2020-May/008448.html


I fixed the xproto issue by updating the include file embedded in virtualbox to a newer version. Not completely sure this is correct though.
Comment 174 Guido Falsi freebsd_committer 2021-02-21 19:36:51 UTC
(In reply to Jason W. Bacon from comment #172)

I'm not really able to debug your issue, but please try the newer patch I attached, it includes some more fixes from the ports tree which were lost in the previous iteration.

I'm running with this patch applied and virtualbox 6 works quite fine, but I'm on recent head here.

I'm unable to test on 12.2 right now, but I could create a setup if needed and if I can find further time for this.
Comment 175 Guido Falsi freebsd_committer 2021-02-21 19:37:51 UTC
(In reply to Guido Falsi from comment #173)
Forgot to mention, you can also grab a tarball with the already patched ports here, if it's easier for you:

https://people.freebsd.org/~madpilot/virtualbox-ose-ports-6.1.18.txz
Comment 176 martin ilavsky 2021-02-21 21:17:51 UTC
@Mario: 
Thanks. But then still I can choose between 13 and 14. There's no version of 12 where this commit was done. Or is my logic faulty here? I was trying to make this version work on 12.

When I tried the KDE versions I mentioned above I had a crash. I now fetched Guido's ports to see if I can make the 6.1.18 version work on 12. While I can build it I ran to the same issue I did before. 

I've two test VMs on this box: vm01 (created on vbox6) and vblx01 (copied over from vbox5). They both have two network interfaces (nic0: nat with egress iface, nic1: hostonly iface). 

I can start vm01 OK. I can power it off. I can't remove the modules though:

# /usr/local/etc/rc.d/vboxnet onestart
# VBoxManage startvm vm01 --type headless
# VBoxManage controlvm vm01 poweroff
# /usr/local/etc/rc.d/vboxnet onestop

Machine is responding and login to it is possible, but:
  kldstat command gets frozen
  VBoxNetDHCP is using cpu on 100%
  hostonly interface is destroyed
It's possible to reboot the host with reboot.

If I start mixing the start with the other VM too though (after clean boot):

# VBoxManage startvm vblx01 --type headless
Waiting for VM "vblx01" to power on...
VBoxManage: error: Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole
#

After this I can't start even vm01. 

The vblx01 start actually core dumps:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000802c4c376 in rfbClientIteratorNext (i=0x8019e11e0) at /usr/ports/net/libvncserver/work/libvncserver-LibVNCServer-0.9.13/libvncserver/rfbserver.c:214
214	/usr/ports/net/libvncserver/work/libvncserver-LibVNCServer-0.9.13/libvncserver/rfbserver.c: No such file or directory.
   0x0000000802c4c36e <rfbClientIteratorNext+62>:	48 8b 4d f0	mov    rcx,QWORD PTR [rbp-0x10]
   0x0000000802c4c372 <rfbClientIteratorNext+66>:	48 8b 49 08	mov    rcx,QWORD PTR [rcx+0x8]
=> 0x0000000802c4c376 <rfbClientIteratorNext+70>:	48 8b 89 60 02 00 00	mov    rcx,QWORD PTR [rcx+0x260]

(gdb) i r $rcx
rcx            0x0                 0
(gdb)

Reboot doesn't go through, system is hung.
Comment 177 Guido Falsi freebsd_committer 2021-02-21 21:41:10 UTC
With my patches I get a build failure on i386, this is the error:

===========================================================================
=======================<phase: build          >============================
===>  Building for virtualbox-ose-kmod-6.1.18
cd /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-6.1.18/src/VBox/HostDrivers && /bin/sh -c  '. /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-6.1.18/env.sh && VBOX_LIBPATH_X11=/usr/local VBOX_FREEBSD_SRC=/usr/src/sys /usr/local/bin/kmk HostDrivers-scripts vboxdrv-src VBoxNetFlt-src VBoxNetAdp-src'
../../../Config.kmk:2943: /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-6.1.18/out/freebsd.x86/release/DynamicConfig.kmk: No such file or directory
../../../Config.kmk:7726: /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-6.1.18/out/freebsd.x86/release/revision.kmk: No such file or directory
/wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-6.1.18/kBuild/footer-pass2-compiling-targets.kmk:736: *** missing separator.  Stop.
*** Error code 2

Stop.


The two "No such file or directory" errors are expected and always happen. The problem is the missing separator.

footer-pass2-compiling-targets.kmk comes from kbuild and is a very complex Makefile, I can't find any evident errors in it. I tried merging some newer commits from kbuild repo but it only caused more failures, so I'm at a loss how to fix that.
Comment 178 Guido Falsi freebsd_committer 2021-02-21 21:43:30 UTC
(In reply to Guido Falsi from comment #177)

My patches are only a cleanup of Mario Ones, and are meant to be functionally the same. So it is expected for them to keep failing just as they used to.

At present I have tested only on head (14), and there virtualbox 6 works fine.

I don't have any physical machines with 12.2 handy to test on. I want to do that but can't do it right away.
Comment 179 Mario Lobo 2021-02-22 12:05:27 UTC
(In reply to Guido Falsi from comment #177)

@Guido

Did you notice comment #152? If I understood it correctly, I believe VboX 6.1.x won't be able to run on i386 arch.

As soon as I get a break, I'll give additions port a spin.

@Martin

Sorry but all my attempts to run BSD 12.x on the hardware I have were frustrating, so I abandoned it and skipped straight to CURRENT (13 at the time) and now I'm on 13-STABLE on my laptop and 14-CURRENT on my desktop.
Comment 180 Guido Falsi freebsd_committer 2021-02-22 13:40:48 UTC
(In reply to Mario Lobo from comment #179)

I see. Well on i386 it actually fails to build, and early in the process.

So this version is going to work only on 64bit hardware and most probably only for 13 and beyond?

Information about this needs to be added to the Makefiles via IGNORE and NOT_FOR_ARCHS/ONLY_FOR_ARCHS flags.

My plan is to propose moving the 5.x virtualbox-ose ports to "-legacy" parallel ports. If someone wants to upgrade those legacy ports to 6.0 at some point that's an option. Considering these restrictions removing the old versions right away is out of the question.

I already have changes almost ready for what I described above. I want to polish them a little more (and add the required ignore flags) and then I'll file a code review on out phabricator instance.
Comment 181 Cy Schubert freebsd_committer 2021-02-22 13:56:07 UTC
Here, virtualbox-ose-additions failed to build on amd64. Poudriere reports a "header" error. This is on a recent 14-CURRENT.

kBuild: Compiling VBox-liblzf - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/libs/liblzf-3.4/lzf_c.c
kBuild: Compiling VBox-liblzf - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/libs/liblzf-3.4/lzf_d.c
kBuild: Generating /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/VBoxRTImp/VBoxRTImpImp.c
/usr/local/bin/kmk_sed -e '/not-freebsd/d' -e '/not-amd64/d' -f /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/bldprogs/deftoimp.sed --append /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/VBoxRTImp/VBoxRTImpImp.c /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Runtime/VBox/VBoxRTImp.def /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Runtime/VBox/VBoxRTImp-gcc.def
kBuild: Pass - DLLs
kBuild: Compiling vboxvideo_drv_system - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/getmode.c
In file included from <built-in>:1:
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/VBoxVideoIPRT.h:62:10: fatal error: 'compiler.h' file not found
#include "compiler.h"  /* Can pull in <sdtint.h>.  Must come after xf86_ansic.h on XFree86. */
         ^~~~~~~~~~~~
kBuild: Compiling vboxvideo_drv_system - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/pointer.c
kBuild: Compiling vboxvideo_drv_system - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/setmode.c
In file included from <built-in>:1:
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/VBoxVideoIPRT.h:62:10: fatal error: 'compiler.h' file not found
#include "compiler.h"  /* Can pull in <sdtint.h>.  Must come after xf86_ansic.h on XFree86. */
         ^~~~~~~~~~~~
In file included from <built-in>:1:
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/VBoxVideoIPRT.h:62:10: fatal error: 'compiler.h' file not found
#include "compiler.h"  /* Can pull in <sdtint.h>.  Must come after xf86_ansic.h on XFree86. */
         ^~~~~~~~~~~~
1 error generated.
kmk: *** [/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/getmode.o] Error 1
The failing command:
@cc -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-unused-parameter -Wno-language-extension-token  -Wno-gnu-folding-constant -Wno-gnu-anonymous-struct  -Wno-string-plus-int -Wno-nested-anon-types -Wno-variadic-macros -Wno-long-long -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Werror-implicit-function-declaration   -Wno-variadic-macros -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT  -fPIC -std=c99 -include /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/VBoxVideoIPRT.h -include /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/HGSMIMemAlloc.h -include xorg-server.h -m64 -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Runtime/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/include/VBox/Graphics -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/dtrace -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_DEBUGGER -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\" -DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=\"/usr/local/lib/virtualbox\" -DIN_RING3 -DIN_GUEST -DIN_GUEST_R3 -DIN_RT_R3 -DGC_ARCH_BITS=64 -DRT_NEED_NEW_AND_DELETE -DPIC -DVBOX_GUESTR3XORGMOD -DRTMEM_NO_WRAP_TO_EF_APIS -D_XSERVER64 -DIN_MODULE -DXORG_7X -DRENDER=1 -DIN_RT_STATIC -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DVBOXVIDEO_13 -DNO_ANSIC -DPCIACCESS -DXSERVER_LIBPCIACCESS -DHC_ARCH_BITS=64 -Wp,-MD,/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/getmode.o.dep -Wp,-MT,/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/getmode.o -Wp,-MP -o /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/getmode.o /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/getmode.c
kmk: *** Waiting for unfinished jobs....
11 error generated.
 error generated.
kmk: *** [/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/setmode.o] Error 1
The failing command:
@cc -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-unused-parameter -Wno-language-extension-token  -Wno-gnu-folding-constant -Wno-gnu-anonymous-struct  -Wno-string-plus-int -Wno-nested-anon-types -Wno-variadic-macros -Wno-long-long -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Werror-implicit-function-declaration   -Wno-variadic-macros -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT  -fPIC -std=c99 -include /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/VBoxVideoIPRT.h -include /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/HGSMIMemAlloc.h -include xorg-server.h -m64 -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Runtime/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/include/VBox/Graphics -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/dtrace -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_DEBUGGER -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\" -DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=\"/usr/local/lib/virtualbox\" -DIN_RING3 -DIN_GUEST -DIN_GUEST_R3 -DIN_RT_R3 -DGC_ARCH_BITS=64 -DRT_NEED_NEW_AND_DELETE -DPIC -DVBOX_GUESTR3XORGMOD -DRTMEM_NO_WRAP_TO_EF_APIS -D_XSERVER64 -DIN_MODULE -DXORG_7X -DRENDER=1 -DIN_RT_STATIC -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DVBOXVIDEO_13 -DNO_ANSIC -DPCIACCESS -DXSERVER_LIBPCIACCESS -DHC_ARCH_BITS=64 -Wp,-MD,/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/setmode.o.dep -Wp,-MT,/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/setmode.o -Wp,-MP -o /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/setmode.o /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/setmode.c
kmk: *** [/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/pointer.o] Error 1
The failing command:
@cc -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-unused-parameter -Wno-language-extension-token  -Wno-gnu-folding-constant -Wno-gnu-anonymous-struct  -Wno-string-plus-int -Wno-nested-anon-types -Wno-variadic-macros -Wno-long-long -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Werror-implicit-function-declaration   -Wno-variadic-macros -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT  -fPIC -std=c99 -include /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/VBoxVideoIPRT.h -include /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/HGSMIMemAlloc.h -include xorg-server.h -m64 -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Runtime/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/include/VBox/Graphics -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/dtrace -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_DEBUGGER -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\" -DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=\"/usr/local/lib/virtualbox\" -DIN_RING3 -DIN_GUEST -DIN_GUEST_R3 -DIN_RT_R3 -DGC_ARCH_BITS=64 -DRT_NEED_NEW_AND_DELETE -DPIC -DVBOX_GUESTR3XORGMOD -DRTMEM_NO_WRAP_TO_EF_APIS -D_XSERVER64 -DIN_MODULE -DXORG_7X -DRENDER=1 -DIN_RT_STATIC -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DVBOXVIDEO_13 -DNO_ANSIC -DPCIACCESS -DXSERVER_LIBPCIACCESS -DHC_ARCH_BITS=64 -Wp,-MD,/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/pointer.o.dep -Wp,-MT,/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/pointer.o -Wp,-MP -o /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/vboxvideo_drv_system/pointer.o /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-devel/work/VirtualBox-6.1.18/src/VBox/Additions/x11/vboxvideo/pointer.c
kmk: *** Exiting with status 2
*** Error code 2

Stop.
make: stopped in /usr/ports/emulators/virtualbox-ose-additions-devel
=>> Cleaning up wrkdir
===>  Cleaning for virtualbox-ose-additions-devel-6.1.18
build of emulators/virtualbox-ose-additions-devel | virtualbox-ose-additions-devel-6.1.18 ended at Sun Feb 21 19:17:36 PST 2021
build time: 00:13:59
!!! build failure encountered !!!
Comment 182 Guido Falsi freebsd_committer 2021-02-22 14:08:27 UTC
(In reply to Cy Schubert from comment #181)

I suspect that's due to me testing disabling MAKE_JOBS_UNSAFE.

Please uncomment the UNSAFE line and that error should disappear.
Comment 183 Jason W. Bacon freebsd_committer 2021-02-22 14:33:06 UTC
(In reply to Mario Lobo from comment #179)

> Sorry but all my attempts to run BSD 12.x on the hardware I have were 
> frustrating, so I abandoned it and skipped straight to CURRENT (13 at the time) 
> and now I'm on 13-STABLE on my laptop and 14-CURRENT on my desktop.

What problems did you have running 12.2-RELEASE?  I've debugged and patched desktop-installer for a wide variety of hardware so maybe I can offer some suggestions.
Comment 184 Cy Schubert freebsd_committer 2021-02-22 15:51:25 UTC
(In reply to Guido Falsi from comment #182)
Same failure under poudriere and on a VirtualBox VM building through make at $JOB. All are running very recent 14-CURRENT.
Comment 185 Guido Falsi freebsd_committer 2021-02-22 16:11:12 UTC
(In reply to Cy Schubert from comment #184)

Are you sure you added back the MAKE_JOBS_UNSAFE=yes line?

I did see this too, without that line, there's a race condition on creating that file. I forgot to add it back before updating the patches here.

I'm testing on 14 main-n244785-a78fee81826
Comment 186 Mario Lobo 2021-02-22 17:05:39 UTC
(In reply to Jason W. Bacon from comment #183)

Thanks Jason but I've already moved on. And also my machines are running smoothly and fast (both of them) so I don't want to move backwards.
Comment 187 Cy Schubert freebsd_committer 2021-02-22 18:01:19 UTC
(In reply to Guido Falsi from comment #185)

I'm using MAKE_JOBS_UNSAFE=yes at home in poudriere and at $JOB using make. Same result on both. uname -a:

FreeBSD slippy 14.0-CURRENT FreeBSD 14.0-CURRENT #21 komquats-n244974-ba27dd8be821-dirty: Mon Feb 22 05:58:16 PST 2021     root@cwsys:/export/obj/opt/src/git-src/amd64.amd64/sys/BREAK  amd64
Comment 188 Guido Falsi freebsd_committer 2021-02-22 18:02:24 UTC
I created a review from the patches posted here.

Thanks to all who contributed patches suggestions and testing.

Still more work is needed to get this landed on the ports tree.

Any further testing and reports are very welcome.



https://reviews.freebsd.org/D28871
Comment 189 Guido Falsi freebsd_committer 2021-02-22 18:07:39 UTC
(In reply to Cy Schubert from comment #187)

I'll try to investigate this.


In the while you can try with the patches from the code review which are newer. Maybe something wrong slipped into the last patch I uploaded here!
Comment 190 imbutler 2021-02-22 18:52:37 UTC
(In reply to Guido Falsi from comment #188)
I believe the additions should be enabled for i386 as it's only the host that's constrained to amd64.

Reference: https://www.virtualbox.org/wiki/Guest_OSes

  imb
Comment 191 Guido Falsi freebsd_committer 2021-02-22 20:52:25 UTC
(In reply to imbutler from comment #190)

> I believe the additions should be enabled for i386 as it's only the host that's constrained to amd64.

I would be happy to do that if I were able to build them on i386.

Unluckily they give a gmake error, see comment #177

I tried to fix that but have not succeeded. The build system is quite complex and I have no idea how to fix that error. If you can provide some patch I will be happy to test and integrate them.

As a fallback virtualbox 5.x additions work well enough though.
Comment 192 Cy Schubert freebsd_committer 2021-02-22 23:38:41 UTC
The vbox 5 additions don't handle video properly while running under vbox 6 on a Windows 10 host.

I'll see what I can do this week.
Comment 193 Graham Perrin 2021-02-23 02:08:45 UTC
14.0-CURRENT

Some success. Very pleasing!

For the failures outlined below, do you require any additional detail – the VirtualBox log file, maybe? 

If so: logged here, or in the review?

----


A previously saved Windows 10 guest 
with 1,024 MB memory: 

☑ resumed then closed (restored snapshot) without difficulty. 

----

A previously saved Windows 10 guest 
with 3,072 MB memory: 

☑ resumed then saved without difficulty. 

----

A previously saved helloSystem (FreeBSD 13.0-BETA2) guest
with 4,096 MB memory: 

Failed to open a session …

Failed to load unit 'pgm' (VERR_PGM_PHYS_PAGE_RESERVED).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}


----

A previously saved Manjaro Linux guest: 

Failed to open a session …

Failed to load unit 'pgm' (VERR_PGM_PHYS_PAGE_RESERVED).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

---

A previously saved GhostBSD guest: 

Failed to open a session …

Failed to load unit 'HGCM' (VERR_SSM_UNEXPECTED_DATA).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

----

For the phrase in the helloSystem and Linux cases, Google finds: 

[opensuse] Can't start my Tumbleweed VM in VirtualBox; no problem starting Leap 42.3 guest.
<https://lists.opensuse.org/opensuse/2019-05/msg00608.html>
    2019-05-21

virtualbox.org • View topic - [Solved] Restore fails OSX Guest on OSX Host "LoadExec failed for 'pgm'..."
<https://forums.virtualbox.org/viewtopic.php?f=22&t=94173>
    2019-08-04

----

For the phrase in the GhostBSD case, Google finds: 

#6314 (Failed to load unit 'HGCM' (VERR_INVALID_PARAMETER) on restoring from saved state) – Oracle VM VirtualBox
<https://www.virtualbox.org/ticket/6314>
    2010 through 2019, reopened defect

– and various other results.
Comment 194 Graham Perrin 2021-02-23 02:10:28 UTC
(In reply to Graham Perrin from comment #193)

Correction: 

> A previously saved Windows 10 guest 
> with 1,024 MB memory: 

– that was a FreeBSD guest. 

Windows 10 with so little memory? Not bloody likely :-)
Comment 195 Derek Schrock 2021-02-23 03:01:08 UTC
(In reply to Christoph Moench-Tegeder from comment #134)

I can't really comment on any of the C++ side of things however my init. builds of 6.1.18 had DEBUG on (without USE_GCC) and I was able use vbox without issue on 12.2-RELEASE-p3.

Rebuilding with default options (DEBUG off) I ran in the issue mentioned here (and else where).

I don't know this shines any light on the issue but something I've noticed.
Comment 196 Cy Schubert freebsd_committer 2021-02-23 03:56:52 UTC
After having completed starting and stopping all VMs, and exiting VirtualBox GUI, VBoxNetDHCP goes into a tight loop. truss -p shows:

slippy# truss -p 4526
SIGNAL 9 (SIGKILL) code=SI_NOINFO

^Cc^Ctruss: Unexpected stop in waitpid: Interrupted system call

Kill -15 does nothing.

slippy# kill 4526

Neither will kill -9 kill it.

slippy# kill -9 4526

However a kill -17 followed by a kill -9 will kill the looping VBoxNetDHCP.

VBoxNetDHCP only starts looping after the GUI is exited. It doesn't if the guest obtained a DHCP assigned address or not. It doesn't matter if the guest enabled network interfaces or not. The loop always occurs and the workaround above is always the same. I suspect there may be some pipe or other IPC being used that the VBoxNetDHCP reacts "uncomfortably" when the other side of the communication disappears.
Comment 197 Guido Falsi freebsd_committer 2021-02-23 08:08:05 UTC
(In reply to Graham Perrin from comment #193)

What do you mean by "previously saved"? If you mean a live machine saved state while running, using those across upgrades is explicitly unsupported by upstream.


Apart from this, if these are simply VMs you had shut down in previous version and now fail to start it can be very difficult to debug these, I have very little knowledge of actual virtualbox internals.

Have you tried checking their configuration? maybe some parameters should be tweaked.

Another thing you could try is create a new VM with the same config and attach the failing VM HD to it. That is akin to moving an HD accross identical physical machines, and could give you an identical running system. (ok windows could scream about changing hal and require reactivation, you could try to help it by copying the ethernet MAC address)
Comment 198 Guido Falsi freebsd_committer 2021-02-23 08:11:19 UTC
(In reply to Cy Schubert from comment #192)

As I said 6.1 guest additions are disabled on i386 because they fail to build. I would really like to enable them, but I've not been able to make them build.

Gmake errors out early in the build process.
Comment 199 Graham Perrin 2021-02-23 08:28:13 UTC
(In reply to Graham Perrin from comment #193)

As far as I can tell, from a test of all available guests: 

* in _all_ cases where a saved state can not be restored, the guest 
  will boot _after the state is discarded_ 

– and these guests will boot, without the states, from most, if not all, snapshots: 

* including snapshots of running systems. 

Not all states that were saved prior to the upgrade are bugged. 

----

Without paying to attention to the details of restoration failures: I have seen this type of thing, with saved states, years ago, occasionally, following updates to VirtualBox. 

I learnt to cautiously gracefully shut down all guests before performing any update. 

On this occasion: before the major upgrade, I took a ZFS snapshot of the volume where I store all VirtualBox data. So now I'm carefree in discarding states, I'll restore from the snapshot (and can downgrade/upgrade as I please).
Comment 200 Guido Falsi freebsd_committer 2021-02-23 08:53:33 UTC
(In reply to Graham Perrin from comment #199)

Keeping saved states across major updates has never been supported by virtualbox. It could work sometimes, but there are no warranties.

If you think about it is like suspending or hibernating your laptop, then opening it and changing graphics card and network adapter under it. Maybe it will boot up and recover, most probably it will not.

The recommended way is to completely shutdown the machines before upgrading.

Maybe I should add such a notice in the UPDATING file along with other advice.
Comment 201 Graham Perrin 2021-02-23 09:07:16 UTC
(In reply to Guido Falsi from comment #197)

> … If you mean a live machine saved state while running, using those 
> across upgrades is explicitly unsupported by upstream. …

This is most useful, thank you. 

At least one such state did survive the upgrade, however I'll no longer assume that all saved run states should survive. 

I'll downgrade, restore from my ZFS snapshot, start each guest, take a VirtualBox snapshot of each guest then retest the major upgrade scenario. 

### Thoughts
============

Might it help to add concise forewarnings? 

For <https://www.freshports.org/emulators/virtualbox-ose/#description> to present: 

    Users of VirtualBox 5.2.44 are advised to have a snapshot of each 
    running guest machine before the major upgrade to VirtualBox 6.1.⋯.

– and for <https://www.freshports.org/emulators/virtualbox-ose/#message> to offer a little more detail: 

    Running machines that were saved without a _snapshot_ of the run, 
    by VirtualBox 5.2.44, might not start following the major upgrade 
    to VirtualBox 6.1.⋯. Either: 
 
    a) before the upgrade, stop each machine (take snapshots if required); 

       or 

    b) following the upgrade, discard the saved state of any machine that 
       will not start. 

----

At a glance, I see no precautionary words at <https://www.virtualbox.org/manual/UserManual.html#KnownProblems> or in any other part of the manual, so I guess that the written knowledge is elsewhere (in forums, maybe …). 

I should aim to update <https://wiki.freebsd.org/VirtualBox> in due course. 

Thanks again
Comment 202 Guido Falsi freebsd_committer 2021-02-23 09:34:07 UTC
(In reply to Graham Perrin from comment #201)

I'm planning t put a notice in the UPDATING entry that will go with the update.

While I could not find real documentation about this, there are a bunch of tickets and posts in the forums about saved states. Tickets make it clear they are expected to work between minor updates (but Personally I would not count on that either), but not major ones.

some random refs:

https://forums.virtualbox.org/viewtopic.php?f=1&t=90991#p436905

https://forums.virtualbox.org/viewtopic.php?f=7&t=82798#p391397

https://www.virtualbox.org/ticket/13461
Comment 203 Mario Lobo 2021-02-23 14:01:05 UTC
(In reply to Guido Falsi from comment #188)

Guido;

Does the attachment you posted here contains everything in D28871 (except the directory renames, UPDATING, etc...)?
Comment 204 Guido Falsi freebsd_committer 2021-02-23 15:25:33 UTC
(In reply to Mario Lobo from comment #203)

No it does not, that's why I marked it obsolete. Please grab the patch from the code review. I can provide a tarball of the updated ports i you want.

BTW I'm in the process of updating the code review. One mistake I need to correct is that the virtualbox-ose-legacy port there depends on the non legacy kmod. I'm testing compiling with clang/llvm 11 on 12.2 to see if this makes it work. Unluckily recompiling clang/llvm AND virtualbox is taking longer than expected.
Comment 205 Mario Lobo 2021-02-23 16:09:13 UTC
(In reply to Guido Falsi from comment #204)

If you could attach the tar ball I would appreciate it.

I'd rather wait for your whole diff to go into the ports tree.
Comment 206 Guido Falsi freebsd_committer 2021-02-23 16:48:13 UTC
(In reply to Mario Lobo from comment #205)

You can grab the latest version of the patch as a tarball here:

https://people.freebsd.org/~madpilot/virtualbox-ose-ports-6.1.18.txz

If you want to use the legacy ports you may need to manually ad the to the category Makefile.
Comment 207 Jason W. Bacon freebsd_committer 2021-02-23 17:59:36 UTC
(In reply to Guido Falsi from comment #204)

Building with llvm11 (from pkg) fixes VM creation on 12.2-RELEASE, but I still get a panic when starting one.

Note that I was not getting a panic with 6.1.16 even with base clang.
Comment 208 Guido Falsi freebsd_committer 2021-02-23 19:09:03 UTC
(In reply to Jason W. Bacon from comment #207)


I made a test right now, compiling on 12.2 with base clang and it fails to start a VM previously created in 5.x, this is the error:

Failed to open a session for the virtual machine first.

Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}


Last lines from the log:

00:00:02.084349 AssertLogRel /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.18/src/VBox/Main/src-client/VMMDevInterface.cpp(982) int VMMDev::i_guestPropLoadAndConfigure(): timestampsOut.size() == cProps
00:00:02.084363 AssertLogRel /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.18/src/VBox/Main/src-client/VMMDevInterface.cpp(1178) static int VMMDev::drvConstruct(PPDMDRVINS, PCFGMNODE, uint32_t): RT_SUCCESS_NP(rc)
00:00:02.084373 VERR_INTERNAL_ERROR_3 (-227) - Internal error no. 3.
00:00:02.085008 PDM: Failed to construct 'VMMDev'/0! VERR_INTERNAL_ERROR_3 (-227) - Internal error no. 3.
00:00:02.085022 VMSetError: /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.18/src/VBox/VMM/VMMR3/PDMDevice.cpp(474) int pdmR3DevInit(PVM); rc=VERR_INTERNAL_ERROR_3
00:00:02.085025 VMSetError: Failed to construct device 'VMMDev' instance #0
00:00:02.220170 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3)}, preserve=false aResultDetail=-227
00:00:02.250828 Console: Machine state changed to 'PoweredOff'
00:00:02.266115 Power up failed (vrc=VERR_INTERNAL_ERROR_3, rc=NS_ERROR_FAILURE (0X80004005))
00:00:02.769918 GUI: UIMachineViewNormal::resendSizeHint: Restoring guest size-hint for screen 0 to 800x600
00:00:02.769959 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={4680b2de-8690-11e9-b83d-5719e53cf1de} aComponent={DisplayWrap} aText={The console is not powered up}, preserve=false aResultDetail=0
00:00:02.770013 GUI: Aborting startup due to power up progress issue detected...


Not very helpful actually.


I had full success forcing ports to use llvm11 from ports on 12.2, while trying to force gcc fails to build with various errors.
Comment 209 martin ilavsky 2021-02-23 19:23:41 UTC
(In reply to Guido Falsi from comment #208)
It seems the same error as I pasted above. The start actually created a core dump in my case. It seems to be in the VNC ext module. But maybe it's a victim of a previous VMMDev error.
Comment 210 Guido Falsi freebsd_committer 2021-02-23 20:21:18 UTC
(In reply to martin ilavsky from comment #209)

Yes, but debugging this error is beyond my abilities.

Anyway I have had success by forcing build using clang 11 from ports. That's what the patches in the review are doing.

Only thing those patches are forcing llvm11 for both the main port and the kmod. I'm almost sure the kmod would work fine also with base clang on 12.2. I'm going to make a test in that direction.


It's been noted that adding a clang11 dependency on virtualbox would make it required to compile tree big compilers (llvm90, llvm11, gcc10 for kBuild). This is unfortunate, but I think we should get this virtualbox version in the tree, things can be adjusted later.

The big dependencies are not a problem for the cluster which would build them all anyway.
Comment 211 Jason W. Bacon freebsd_committer 2021-02-23 20:45:40 UTC
(In reply to Jason W. Bacon from comment #207)

I do get a panic with 1.1.16 now that I'm compiling with llvm11.  I think the panic was just headed off by other errors that terminated the process with 1.1.16 + base clang.

So now I can create a VM, but still get a panic trying to start a VM whether it was from 5.x or newly created.

FreeBSD head.albacore 12.2-RELEASE-p3 FreeBSD 12.2-RELEASE-p3 GENERIC  amd64

I'll try stripping down loadable modules and vbox build options to see if there's at least a workaround.

===

panic: breakpoint instruction fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
vboxdrv: ffffffff82e7e020 VMMR0.r0

!!Assertion Failed!!
Expression: rc == KERN_SUCCESS
Location  : /usr/ports/wip/virtualbox-ose-kmod-devel/work/VirtualBox-6.1.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c(773) int rtR0MemObjNativeMapUser(PPRTR0MEMOBJINTERNAL, RTR0MEMOBJ, RTR3PTR, size_t, unsigned int, RTR0PROCESS, size_t, size_t)
0x1


Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer     = 0x20:0xffffffff82e447ae
stack pointer           = 0x28:0xfffffe00641d94a0
frame pointer           = 0x28:0xfffffe00641d94f0
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, IOPL = 0
current process         = 15796 (VirtualBoxVM)
trap number             = 3
panic: breakpoint instruction fault
cpuid = 1
time = 1614111746
KDB: stack backtrace:
#0 0xffffffff80c0aa85 at kdb_backtrace+0x65
#1 0xffffffff80bbed3b at vpanic+0x17b
#2 0xffffffff80bbebb3 at panic+0x43
#3 0xffffffff8108e911 at trap_fatal+0x391
#4 0xffffffff8108dd97 at trap+0x67
#5 0xffffffff81066938 at calltrap+0x8
#6 0xffffffff82e42469 at RTR0MemObjMapUserExTag+0x1b9
#7 0xffffffff82e8678f at g_pLogger+0x8817
#8 0xffffffff82e86249 at g_pLogger+0x82d1
#9 0xffffffff82eaced5 at g_pLogger+0x2ef5d
#10 0xffffffff82e055e1 at supdrvIOCtlInnerUnrestricted+0x12b1
#11 0xffffffff82e042b8 at supdrvIOCtl+0x88
#12 0xffffffff82e1c2c4 at VBoxDrvFreeBSDIOCtlSlow+0x174
#13 0xffffffff82e1bfa1 at VBoxDrvFreeBSDIOCtl+0x51
#14 0xffffffff80a79250 at devfs_ioctl+0xb0
#15 0xffffffff8124622b at VOP_IOCTL_APV+0x7b
#16 0xffffffff80c9cc0a at vn_ioctl+0x16a
#17 0xffffffff80a7983e at devfs_ioctl_f+0x1e
Uptime: 1h15m15s
Dumping 1123 out of 4009 MB:..2%..12%..22%..32%..42%..52%..62%..72%..82%..92%

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/uplcom.ko...Reading symbols from /usr/lib/debug//boot/kernel/uplcom.ko.debug...done.
done.
Loaded symbols for /boot/kernel/uplcom.ko
Reading symbols from /boot/kernel/ucom.ko...Reading symbols from /usr/lib/debug//boot/kernel/ucom.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ucom.ko
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /usr/lib/debug//boot/kernel/ipmi.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ipmi.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /usr/lib/debug//boot/kernel/smbus.ko.debug...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_ubt.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ng_ubt.ko
Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_hci.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ng_hci.ko
Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_bluetooth.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ng_bluetooth.ko
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /usr/lib/debug//boot/kernel/netgraph.ko.debug...done.
done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
Reading symbols from /boot/kernel/fuse.ko...Reading symbols from /usr/lib/debug//boot/kernel/fusefs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/fuse.ko
Reading symbols from /boot/kernel/radeonkms.ko...Reading symbols from /usr/lib/debug//boot/kernel/radeonkms.ko.debug...done.
done.
Loaded symbols for /boot/kernel/radeonkms.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from /usr/lib/debug//boot/kernel/drm.ko.debug...done.
done.
Loaded symbols for /boot/kernel/drm.ko
Reading symbols from /boot/kernel/linuxkpi.ko...Reading symbols from /usr/lib/debug//boot/kernel/linuxkpi.ko.debug...done.
done.
Loaded symbols for /boot/kernel/linuxkpi.ko
Reading symbols from /boot/modules/linuxkpi_gplv2.ko...done.
Loaded symbols for /boot/modules/linuxkpi_gplv2.ko
Reading symbols from /boot/modules/debugfs.ko...done.
Loaded symbols for /boot/modules/debugfs.ko
Reading symbols from /boot/modules/ttm.ko...done.
Loaded symbols for /boot/modules/ttm.ko
Reading symbols from /boot/modules/radeon_CAICOS_pfp_bin.ko...done.
Loaded symbols for /boot/modules/radeon_CAICOS_pfp_bin.ko
Reading symbols from /boot/modules/radeon_CAICOS_me_bin.ko...done.
Loaded symbols for /boot/modules/radeon_CAICOS_me_bin.ko
Reading symbols from /boot/modules/radeon_BTC_rlc_bin.ko...done.
Loaded symbols for /boot/modules/radeon_BTC_rlc_bin.ko
Reading symbols from /boot/modules/radeon_CAICOS_mc_bin.ko...done.
Loaded symbols for /boot/modules/radeon_CAICOS_mc_bin.ko
Reading symbols from /boot/modules/radeon_CAICOS_smc_bin.ko...done.
Loaded symbols for /boot/modules/radeon_CAICOS_smc_bin.ko
Reading symbols from /boot/modules/radeon_SUMO_uvd_bin.ko...done.
Loaded symbols for /boot/modules/radeon_SUMO_uvd_bin.ko
Reading symbols from /boot/kernel/uhid.ko...Reading symbols from /usr/lib/debug//boot/kernel/uhid.ko.debug...done.
done.
Loaded symbols for /boot/kernel/uhid.ko
Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ums.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Loaded symbols for /boot/kernel/linux_common.ko
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Loaded symbols for /boot/kernel/linux64.ko
Reading symbols from /boot/kernel/pty.ko...Reading symbols from /usr/lib/debug//boot/kernel/pty.ko.debug...done.
done.
Loaded symbols for /boot/kernel/pty.ko
Reading symbols from /boot/kernel/autofs.ko...Reading symbols from /usr/lib/debug//boot/kernel/autofs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/autofs.ko
Reading symbols from /boot/kernel/mac_ntpd.ko...Reading symbols from /usr/lib/debug//boot/kernel/mac_ntpd.ko.debug...done.
done.
Loaded symbols for /boot/kernel/mac_ntpd.ko
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
#0  doadump () at src/sys/amd64/include/pcpu_aux.h:55
55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0  doadump () at src/sys/amd64/include/pcpu_aux.h:55
#1  0xffffffff80bbe955 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:451
#2  0xffffffff80bbed93 in vpanic (fmt=<value optimized out>, 
    ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:880
#3  0xffffffff80bbebb3 in panic (fmt=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:807
#4  0xffffffff8108e911 in trap_fatal (frame=<value optimized out>, 
    eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:921
#5  0xffffffff8108dd97 in trap (frame=0xfffffe00641d93e0)
    at src/sys/amd64/include/counter.h:86
#6  0xffffffff81066938 in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:289
#7  0xffffffff82e447ae in rtR0MemObjNativeMapUser ()
   from /boot/modules/vboxdrv.ko
#8  0xfffffe00641d9528 in ?? ()
#9  0xfffff800798b9000 in ?? ()
#10 0x0000000300000001 in ?? ()
#11 0xfffff800990d1a60 in ?? ()
#12 0x0000000816be6000 in ?? ()
#13 0xfffffe002b737048 in ?? ()
#14 0x0000000000001000 in ?? ()
#15 0x0000000000000000 in ?? ()
Current language:  auto; currently minimal
(kgdb)
Comment 212 Jason W. Bacon freebsd_committer 2021-02-23 23:31:18 UTC
Created attachment 222774 [details]
Kernel modules, pacakges, services

After disabling all non-essential kernel modules and build options, I'm still getting a panic trying to start any VM on 12.2-RELEASE.  Attached a dump of my environment.  Maybe someone who has it working on 12.2 can spot a key difference.  I'm getting panics on a MacBook Pro with scfb driver and an Optiplex using the radeon driver with drm-kmod.
Comment 213 Daniel Morante 2021-02-24 08:25:20 UTC
I don't know if it's too early to test, but is someone with a working installation able to do a quick test to see if sysutils/vagrant still works with this 6.1 port?

The below should be sufficient to make sure it all works:

```
pkg install -y vagrant
mkdir ~/vagrant_test; cd ~/vagrant_test
vagrant init freebsd/FreeBSD-12.2-RELEASE
vagrant up
vagrant ssh
exit
vagrant destroy
```
Comment 214 Guido Falsi freebsd_committer 2021-02-24 10:56:35 UTC
(In reply to Daniel Morante from comment #213)

The test you describe works fine.

I do use vagrant from time to time for testing certain things and later I'll do some testing with my setups.

At present I'd say it works fine.
Comment 215 Jason W. Bacon freebsd_committer 2021-02-24 15:44:00 UTC
I'm successfully running on 12.2-RELEASE using binary packages built under poudriere and llvm11 for both the main port and kmod.  I have not tried using kmod built with base compiler.  I suspect something was leaking into the build outside the poudriere env.  There's nothing in make.conf on these systems that I would expect to cause trouble (some of my systems have CFLAGS+=-march=native to optimize scientific software).

# Added by auto-admin from /home/bacon/scripts/jb-desktop-root
DEVELOPER=yes
# End auto-admin addition

# Added by freebsd-wip-checkout
USE_LOCAL_MK=yes
# End addition

# Added by auto-admin from /usr/local/sbin/auto-install-linux_base
DEFAULT_VERSIONS+=linux=c7_64
# End auto-admin addition

Booting from an ISO is a bit wonky, but I'm not sure if that's specific to the FreeBSD host.  I always get a dialog to select an optical disk when starting a VM, even if I loaded an ISO under Storage already.
Comment 216 Jason W. Bacon freebsd_committer 2021-02-24 16:30:20 UTC
More data:

I was able to successfully install and boot a CentOS 7 guest after enabling host I/O cache on the SATA controller for the VDI boot disk.  This is the opposite behavior from previous versions, where it had to be disabled for Linux guests.

All of my VMs are marked "Aborted" even after proper shutdown.

I worked around problems booting from an ISO by removing the disc from the virtual drive and then reloading it, followed by selecting the ISO rather then the virtual DVD drive in the dialog that pops up for "Start".
Comment 217 martin ilavsky 2021-02-26 20:16:46 UTC
I installed 13beta3 (I see beta4 is being pushed to ftp server as I write this), used the 6.1.18 ports from Guido's post (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878#c206).
Used the lx01 from 5.x VBox. Again, I have one hostonly interface. 

I was able to import the VM and run it just fine. When I powered it off (from OS) and tried to query the status: 

VBoxManage list runningvms

The command hung. VBoxNetDHCP is on 100%. As expected processed cannot be killed. Few second dtrace on the process showed:

$ dtrace -n 'syscall:::entry { @[probefunc] = count() }' -p 2221
  fcntl                                                             1
  fstat                                                             1
  mmap                                                              1
  nanosleep                                                         1
  open                                                              1
  setitimer                                                         1
  wait4                                                             1
  getdirentries                                                     2
  sigreturn                                                         2
  getfsstat                                                         3
  ptrace                                                            3
  fstatat                                                           5
  socket                                                            6
  read                                                              7
  sigaction                                                        10
  write                                                            13
  close                                                            16
  poll                                                             17
  __sysctl                                                         19
  openat                                                           21
  select                                                           22
  _umtx_op                                                         38
  sigprocmask                                                      55
  __sysctlbyname                                                  120
  ioctl                                                           141
$

Reboot ended up in kernel panic. For some reason I don't see anything in the logs though. The 2nd attempt ended up with the machine waiting for 5 mins or so and then reboot occurred.
Comment 218 Guido Falsi freebsd_committer 2021-02-26 20:30:15 UTC
(In reply to martin ilavsky from comment #217)

Please test with the patch from the code review. That's newer and has changes that could inlcuence what you're seeing:

https://reviews.freebsd.org/D28871


The patch I posted here is marked obsolete intentionally.
Comment 219 Guido Falsi freebsd_committer 2021-02-26 20:31:33 UTC
(In reply to Guido Falsi from comment #218)

BTW the ports from the review are also available as a tarball here:

https://people.freebsd.org/~madpilot/virtualbox-ose-ports-6.1.18.txz
Comment 220 martin ilavsky 2021-02-26 22:02:45 UTC
(In reply to Guido Falsi from comment #219)
Thanks. In the mean time I booted to 13.0-beta4 (releng/13.0-n244592-e32bc253629)  and did the fresh install of the virtualbox from your repo. Unfortunately I see the same behavior.

I did copy the vdi to other location and created a new vm. I even left the virtio drivers out and left the default ones (82540EM). VM started up and went down without problem. It even seemed all is ok till I executed the VBoxManage command. VBoxNetDHCP is again on 100%. Same situation as before.
Comment 221 Guido Falsi freebsd_committer 2021-02-28 12:01:19 UTC
(In reply to Jason W. Bacon from comment #216)

I'm not seeing anything similar, in fact all VMs I tested crating have no problem booting from ISOs or starting stopping, resetting snapshots.

The problem you see seem all related to disk access in some way though.

What version of FreeBSD are you testing on? Any special disk setup?
Comment 222 Guido Falsi freebsd_committer 2021-02-28 12:04:07 UTC
(In reply to martin ilavsky from comment #217)

I can reproduce this on head.

It did take a little while because at first I did not notice you are using host only networking.

Looks like a bug in VBoxNetDHCP, but I have no idea what. I don't know if I will be able to fix this.

I'm attaching here a backtrace of the crash, which, as you said, happens at system shutdown, just in case:

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address   = 0x28
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff81f6b501
stack pointer           = 0x0:0xfffffe011e9b1f60
frame pointer           = 0x0:0xfffffe011e9b1f80
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 25646 (VBoxNetDHCP)
trap number             = 12
panic: page fault
cpuid = 2
time = 1614511401
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe011e9b1c10
vpanic() at vpanic+0x181/frame 0xfffffe011e9b1c60
panic() at panic+0x43/frame 0xfffffe011e9b1cc0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe011e9b1d20
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe011e9b1d80
trap() at trap+0x27d/frame 0xfffffe011e9b1e90
calltrap() at calltrap+0x8/frame 0xfffffe011e9b1e90
--- trap 0xc, rip = 0xffffffff81f6b501, rsp = 0xfffffe011e9b1f60, rbp = 0xfffffe011e9b1f80 ---
ng_name2noderef() at ng_name2noderef+0xd1/frame 0xfffffe011e9b1f80
ng_path2noderef() at ng_path2noderef+0x8a/frame 0xfffffe011e9b21e0
ng_address_path() at ng_address_path+0x3b/frame 0xfffffe011e9b2220
vboxNetFltPortOsSetActive() at vboxNetFltPortOsSetActive+0x358/frame 0xfffffe011e9b24a0
vboxNetFltPortSetState() at vboxNetFltPortSetState+0x6d/frame 0xfffffe011e9b24d0
__stop_set_modmetadata_set() at 0xffffffff840af693/frame 0xfffffe011e9b2510
__stop_set_modmetadata_set() at 0xffffffff840b3ba8/frame 0xfffffe011e9b2550
supdrvDestroySession() at supdrvDestroySession+0x11b/frame 0xfffffe011e9b2590
supdrvSessionRelease() at supdrvSessionRelease+0x6f/frame 0xfffffe011e9b25a0
vboxdrvFreeBSDDtr() at vboxdrvFreeBSDDtr+0x9/frame 0xfffffe011e9b25b0
devfs_fpdrop() at devfs_fpdrop+0xa3/frame 0xfffffe011e9b25d0
devfs_close_f() at devfs_close_f+0x44/frame 0xfffffe011e9b2600
_fdrop() at _fdrop+0x11/frame 0xfffffe011e9b2620
closef() at closef+0x24b/frame 0xfffffe011e9b26b0
fdescfree_fds() at fdescfree_fds+0xdc/frame 0xfffffe011e9b2700
fdescfree() at fdescfree+0x3e8/frame 0xfffffe011e9b27d0
exit1() at exit1+0x400/frame 0xfffffe011e9b2830
sigexit() at sigexit+0x133/frame 0xfffffe011e9b2b00
postsig() at postsig+0x251/frame 0xfffffe011e9b2bc0
ast() at ast+0x307/frame 0xfffffe011e9b2bf0
doreti_ast() at doreti_ast+0x1f/frame 0x7fffdff7ce00
Comment 223 martin ilavsky 2021-02-28 12:15:49 UTC
(In reply to Guido Falsi from comment #221)
I have this issue in VM and on actual HW. On a contrary I think problem is in the network. ( As you said before I was able to reply. ) 
As mentioned I tested it on handful of FreeBSD 13s, this last test was on 13beta4 (releng/13.0-n244592-e32bc253629) with the ports here provided.


If I remove the hostonly iface from the VM, do a start/stop, all seems to be OK. At least, nothing is stuck. But if I try to remove the kernel modules (/usr/local/etc/rc.d/vboxnet onestop) I see the warning about memory leaks:

Warning: memory type iprtheap leaked memory on destroy (5 allocations, 640 bytes leaked).
Comment 224 Guido Falsi freebsd_committer 2021-02-28 13:02:29 UTC
(In reply to martin ilavsky from comment #217)

It is not happening always for me. But I did see it.

I noticed VBoxNetDHCP by default generates a log. The location of the log is passed via command line, you can see it with "ps -axw | grep -i dhcp".

While I don't have much hope on this, could you take a look at your log? Anything that looks useful there?
Comment 225 Guido Falsi freebsd_committer 2021-02-28 13:05:02 UTC
(In reply to martin ilavsky from comment #223)

Problem is definitely in or in something strictly related to VBoxNetDHCP. But not easy to find where.


Interesting it is not happening every time for me. I have no clue what is going on unluckily.
Comment 226 martin ilavsky 2021-02-28 14:24:39 UTC
I'm running it now under root (which I normally don't do), log files are under ~/.config/VirtualBox. But there's nothing being logged during this issue. 
Interestingly enough though I don't use DHCP for this interface, I statically set the IP:

# VBoxManage hostonlyif create
# VBoxManage hostonlyif ipconfig vboxnet0 --ip 192.168.24.1 --netmask 255.255.255.0

Logs show:

# cat ~/.config/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.log
00:00:00.003318 VirtualBox DHCP Server 6.1.18 r142142 freebsd.amd64 (Feb 28 2021 13:05:05) release log
00:00:00.003323 Log opened 2021-02-28T14:14:58.312428000Z
00:00:00.003324 Build Type: release
00:00:00.003346 OS Product: FreeBSD
00:00:00.003358 OS Release: 13.0-BETA4
00:00:00.003370 OS Version: FreeBSD 13.0-BETA4 #0 releng/13.0-n244592-e32bc253629: Fri Feb 26 06:17:34 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
00:00:00.003373 Firmware type: failed - VERR_NOT_SUPPORTED
00:00:00.003430 Host RAM: 32549MB (31.7GB) total, 30969MB (30.2GB) available
00:00:00.003436 Executable: /usr/local/lib/virtualbox/VBoxNetDHCP
00:00:00.003437 Process ID: 1698
00:00:00.003438 Package type: BSD_64BITS_GENERIC (OSE)
00:00:00.003474 --config:  HostInterfaceNetworking-vboxnet0
00:00:00.003489 --comment: HostInterfaceNetworking-vboxnet0
00:00:00.004156 IP address:   192.168.56.100/24
00:00:00.004179 Address pool: 192.168.56.101 - 192.168.56.254
00:00:00.004221 MAC address is not specified: will use generated MAC 08:00:27:91:c2:e8
00:00:00.004251 Db::i_enterFixedAddressAssignment: 08:00:27:91:c2:e8: 192.168.56.100
00:00:00.004272 loading leases from /root/.config/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases
00:00:00.004425 Runtime error opening '/root/.config/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases' for reading: -102 (File not found.)
#

Contents of the log doesn't change when the issue occur. 

Interestingly enough if I stress it a bit:

# VBoxManage startvm vblx01 --type headless
# VBoxManage controlvm vblx01 poweroff

Issue with the DHCP starts almost immediately. Now I try to remove the interface:

# VBoxManage hostonlyif remove vboxnet0

Command is hung and it's waiting. (actually this is where I miss the strace command. I'm not that good with dtrace..). If I execute this command from other console:

ifconfig vboxnet0 123

The command gets through, interface gets destroyed. I can then remove the modules too. The leak message could be because I did compile the virtualbox with the WITH_DEBUG=yes in make.conf now. 

I can reproduce this every time.
Comment 227 Guido Falsi freebsd_committer 2021-02-28 15:20:34 UTC
(In reply to martin ilavsky from comment #226)

Looks like virtualbox will launch the VBoxNetDHCP whenever the host only network is used, Maybe it's controlled by the flag to enable/disable DHCP support in networks configurations.

Once it starts it fails to stop when it tries to detach from the network interfaces it creates.

Attaching gdb to the hung process I get this (I'm running a binary without debugging symbols, maybe I'll try WITH_DEBUG later):

(gdb) bt
#0  0x000000080038379a in ioctl () from /lib/libc.so.7
#1  0x0000000801318e0d in ?? () from /usr/local/lib/virtualbox/VBoxRT.so
#2  0x0000000801311d36 in SUPR3CallVMMR0Ex () from /usr/local/lib/virtualbox/VBoxRT.so
#3  0x0000000801c4c547 in ?? () from /usr/local/lib/virtualbox/VBoxNetDHCP.so
#4  0x0000000801c4d5a1 in ?? () from /usr/local/lib/virtualbox/VBoxNetDHCP.so
#5  0x0000000801c4d6a1 in TrustedMain () from /usr/local/lib/virtualbox/VBoxNetDHCP.so


And tracking this in the source code it it's locked in a ioctl launched at detach time. (I'm guessing the function at frame #1 is suplibOsIOCtl in source file src/VBox/HostDrivers/Support/freebsd/SUPLib-freebsd.cpp, but not much can be gathered by looking at that one only, because it's simply a wrapper around ioctl(2).

frame #3 that ends up calling SUPR3CallVMMR0Ex should be VBoxNetDhcpd::ifClose() in file src/VBox/NetworkServices/Dhcpd/VBoxNetDhcpd.cpp, it is called CALL_VMMR0 which is defined at the start of that file. It's interesting the return code from this ioctl is ignored here, OTOH it looks like this is only called in the object destructor, so the return code should not make much difference.

Detaching GDB caused the same panic I got when trying to shutdown the machine.

This gives a good idea of the code path it gets stuck in, but I don't have enough knowledge of the virtualbox inner workings to make much of this information. Maybe someone reading here has a clue.

I think it is possible the process to recover if the ioctl timeouts or something external makes it return, like what you are doing with ifconfig.
Comment 228 Guido Falsi freebsd_committer 2021-02-28 15:37:32 UTC
(In reply to Guido Falsi from comment #227)

I must admit I also suspect this internal dhcp server is not working properly, at least on FreeBSD. I have not been able to get an IP from it in testing.
Comment 229 Guido Falsi freebsd_committer 2021-02-28 15:42:04 UTC
(In reply to martin ilavsky from comment #226)

Since you're not using dhcp I verified you can stop virtualbox from launching VBoxNetDHCP by disabling the dhcp server in the internal network configuration. You can do this from the UI and also command line.

This should be fixed anyway, but looks like an upstream bug, should this stop the update?

Also, has this ever been working actually? In the past when I tried to use this feature it failed for me, usually simply not assigning IPs to machines.
Comment 230 Graham Perrin 2021-02-28 17:51:07 UTC
(In reply to Guido Falsi from comment #229)

> … should this stop the update? …

IMHO: no. 

The feature either does or does not work with 5.2.4.4 (I have no idea). 

If it does work with 5.2.4.4 – and if it is critical to a person's use case – then there will be the option of that person preferring `-legacy` (and engaging in work towards a fix for 6.1.⋯, which can be separated from the scope of this bug 234878 sooner rather than later). 

HTH
Comment 231 Mario Lobo 2021-02-28 18:59:26 UTC
(In reply to Guido Falsi from comment #229)

> should this stop the update?

God! NO, please, NO! Specially after all the effort 
that so many people put into this, and specially
you, Guido.
Comment 232 Guido Falsi freebsd_committer 2021-02-28 19:31:04 UTC
(In reply to Mario Lobo from comment #231)

Thanks for the support!

I made a misleading statement about the VBoxNetDHCP situation though.

I tested some more.

On 12.2 with Virtualbox 5.2.44 host only network VBoxNetDHCP server works fine and I could not make it hang or crash.

On 14 (head) with Viretualbox 6.1.18 the host only network VBoxNetDHCP server actually works fine, until one tries to stop it, for example by removing the network from the configuration, and then hangs, or causes crash on reboot.

SO there is a regression, and an annoying one at that, but unluckily I have no solution for it right away. I guess it's an interaction between VBoxNetDHCP and netgraph through ioctls. Someone with better knowledge of these parts could maybe find a solution.

I need to find time to study the situation and maybe I can hack some patch but I can't make promises on this.
Comment 233 martin ilavsky 2021-02-28 19:41:20 UTC
(In reply to Guido Falsi from comment #229)
I never used DHCP on hostonly interfaces. It was always up as per default. Never paid any attention to it frankly. 
I tested this on my live server now. FreeBSD 12.2 with 5.2.44 VirtualBox: VM got the IP address from this DHCP server.

On the test machine I've disabled the DHCP for this network: 

# VBoxManage dhcpserver remove --interface=vboxnet0

And I was able to work with these VMs without problem. What I found out though every poweron/poweroff I get leak of 4 allocations, each 128B of size.

I glanced on the issue with hung DHCP with gdb too. Problem is I never looked at the VirtualBox src before. It's a lot to take in. My debugger hung when I wanted to detach it but I was able to kill it (with the trick I described above).
Comment 234 Jason W. Bacon freebsd_committer 2021-02-28 22:01:21 UTC
(In reply to Jason W. Bacon from comment #211)

12.2-RELEASE, nothing special about disk setup.

This is the error I usually get trying to boot from the 12.2 ISO:

Failed to open a session for the virtual machine FreeBSD-test.

The VM session was aborted.

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: SessionMachine
Interface: ISession {c0447716-ff5a-4795-b57a-ecd5fffa18a4}
Comment 235 Graham Perrin 2021-03-01 02:11:08 UTC
(In reply to Jason W. Bacon from comment #234)

With EFI for the guest, or without?

----

14.0-CURRENT host here. With EFI enabled it's as if there's no detection of the optical drive, I'm not sure how to describe it but no matter how fast I key F12 there's no boot manager dialogue. 

If I recall correctly, I found the same symptom with EFI at least one other .iso (for helloSystem?) in a different guest machine. 

----

EFI disabled: boots fine and reaches the installer dialogue. 

FreeBSD-12.2-STABLE-amd64-20210211-r369250-disc1.iso
Comment 236 Guido Falsi freebsd_committer 2021-03-01 08:08:22 UTC
(In reply to Graham Perrin from comment #235)

Ah, I actually never use the EFI option in the jail configuration. The checkbox itself has a scary warning in its label and it's described as to be used for special applications, not for ordinary VM use (with the exception of virtualizing MacOSX).

I don't think it is that much supported by upstream and some problems with it can be expected.


Ref.: https://www.virtualbox.org/manual/ch03.html#efi
Comment 237 Graham Perrin 2021-03-01 08:47:25 UTC
(In reply to Guido Falsi from comment #236)

Thank you. I have read less polite comments about EFI in VirtualBox :-)

To clarify: 

* no such failures with 5.2.44

– a 6.⋯ inability to boot with EFI from .iso files will _significantly_ impair my ability to use/test various things with VirtualBox. 

----

Please, can anyone else confirm failures to boot from ISOs with EFI enabled in the guest?

Is the same (or similar) true for booting from _physical_ optical media with EFI enabled in the guest?
Comment 238 Guido Falsi freebsd_committer 2021-03-01 09:16:22 UTC
(In reply to Graham Perrin from comment #237)

I understand your problem, but there is little we can do for this kind of upstream changes.

Anyway virtualbox 5.x is not going to be removed, my proposed patch keeps it in the tree as "-legacy", at least until it keeps working there is no reason to remove it.
Comment 239 Daniel Morante 2021-03-01 09:45:20 UTC
Speaking of upstream... once you guys are done, do you plan on trying to get these patches included upstream so that it's easier to update minor releases in the future?
Comment 240 Guido Falsi freebsd_committer 2021-03-01 10:01:24 UTC
(In reply to Daniel Morante from comment #239)
Ideally yes, but it's not easy.

First of all it would be useful if whoever created a patch would try to upstream it, since he has an understanding of the patch and why it is needed in the form it is proposed and can better reply to upstream questions.

I could try to push some, but for others I don't have a good understanding of how they work.

Apart from this, do we have someone in good standing with the upstream? Some open channel? that would help a lot!
Comment 241 Jason W. Bacon freebsd_committer 2021-03-01 13:54:19 UTC
(In reply to Graham Perrin from comment #235)

No EFI.  It's not a matter of not seeing the drive, vbox errors out trying to boot.  And I can work around it by ejecting the ISO and reloading it.

Anyone else seeing this issue?  Might be peculiar to my poudriere build.
Comment 242 Jason W. Bacon freebsd_committer 2021-03-01 13:55:12 UTC
(In reply to Guido Falsi from comment #240)

Strong argument for documenting our patches.  :-/
Comment 243 Guido Falsi freebsd_committer 2021-03-01 14:48:45 UTC
(In reply to Jason W. Bacon from comment #242)

I also had a look. Oracle requires contributors to sign an agreement. This complicates matters, because with such a legal requirement, One person cannot act as a proxy packaging and submitting patches provided by others.

Each originator of each patch should sign it and upstream his own patches.

--- Persona opinion

I'm no lawyer, but I guess for minor and obvious changes, like most #ifdefs this does not really apply, one can proxy, because the original work of adding an #ifdef does not really qualify as "original work", and extracting them from the port and putting them in one neat patch is much more work.

Anyway, I'd rather have some legal information before signing such an agreement and then sending third party patches upstream.

--- End of personal opinion
Comment 244 Guido Falsi freebsd_committer 2021-03-01 14:51:33 UTC
(In reply to Guido Falsi from comment #243)

Ok I did not read it all...patches can be submitted under the MIT license too...This could simplify things... I assume contribution to the ports tree are intended under BSD license, quite similar.
Comment 245 Mario Lobo 2021-03-01 17:12:49 UTC
(In reply to Guido Falsi from comment #244)

Guido;

  I'm subscribed to the vbox-dev mailing list and I have seen people submitting patches through the list all the time. I believe that al that is required is that you state (in the e-mail itself even) that the patch is submitted under the MIT license.

https://www.virtualbox.org/wiki/Mailing_lists
Comment 246 Guido Falsi freebsd_committer 2021-03-02 10:33:37 UTC
(In reply to Mario Lobo from comment #245)

I saw that, but at the same time, simply stating that a patch is under MIT does not make it so, unless I'm the original author of the patch.


Now, not every patch qualifies for copyright, really. AFAIK to get copyright protection something must qualify as an original work on intellect. Simply changing a #define line to conform to some external requirement or mechanically adding an #ifdef for a modified function prototype does not.

Apart from this I don't even know under what kind of license we are distributing patches with our ports.

Anyway what I can realistically do at present is collect the "#if __FreeBSD_version" changes we accumulated and some addition to #include lines I see. This would be a good diff reduction, and would not require much understanding of the underlying changes.

More complex patches I see, which add or remove code that I don't fully understand should be sent upstream by people really understanding them. Ideally the ones that created them.

We also have some custom parts, like the virtual filesystem sharing code which I don't know if we intend to upstream at all. But that part has a known author and maintainer, so the decision rests on him!
Comment 247 Mario Lobo 2021-03-02 11:39:43 UTC
(In reply to Guido Falsi from comment #227)

It doesn't happen with "host only network" only. It happens also with Nat Network, or any time VBoxNetDHCP is invoked.

/usr/local/lib/virtualbox/VBoxNetDHCP --comment Natnet1 --config /root/.VirtualBox/Natnet1-Dhcpd.config --log

Even if the VM shuts down properly and the GUI shows it in a Powered off state, 
the VM process still shows under 'ps ax', and trying to edit any of its parameters issues:

The machine 'Whatever' is already locked for a session (or being unlocked).

Result Code: VBOX_E_INVALID_OBJECT_STATE (0x80BB0007)
Component: MachineWrap
Interface: IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}

Killing the VM process doesn't help the above.

Starting it again is impossible, and so is killing the VBoxNetDHCP process.

The only way to recover from this is to reboot the host.

I must also say that the problem is ONLY on shutting it down. The VM works perfectly while up.

It happens the same way no matter what guest OS I'm using.

The only scenario where this doesn't happen is if you use bridged interface.

One side note on bridged interface: I have 3 Ubuntu guests. 2 & 3 where cloned from 1. They all have different MAC addresses (checked with ifconfig on each) and they're all configured for DHCP. However, they are all getting the SAME ip addresses from DHCP, no matter how many times I recycle their MAC.

OBS - A windows VM running alongside with them gets a different IP from the same DHCP server!

For the record:

FreeBSD 13.0-STABLE #2 stable/13-04535d6a5: Tue Feb 23 11:47:23 -03 2021

virtualbox-ose-6.1.18 compiled from your last virtualbox-ose-ports-6.1.18.txz
Comment 248 Mario Lobo 2021-03-02 11:47:48 UTC
(In reply to Mario Lobo from comment #247)

One addendum:

It freezes EVERYTHING! Even if you close the GUI, it remains running:

 4834  -  S      0:27.25 /usr/local/lib/virtualbox/VirtualBox
 4841  -  S      0:03.03 /usr/local/lib/virtualbox/VBoxXPCOMIPCD
 4843  -  S      0:07.82 /usr/local/lib/virtualbox/VBoxSVC --auto-shutdown
10056  -  R     39:16.11 /usr/local/lib/virtualbox/VBoxNetDHCP --comment Natnet1 --config /root/.VirtualBox/Natnet1-Dhcpd.config --log

And you can't open it again either.

4834  -  S      0:27.31 /usr/local/lib/virtualbox/VirtualBox
 4841  -  S      0:03.05 /usr/local/lib/virtualbox/VBoxXPCOMIPCD
 4843  -  S      0:07.90 /usr/local/lib/virtualbox/VBoxSVC --auto-shutdown
10056  -  R     42:24.31 /usr/local/lib/virtualbox/VBoxNetDHCP --comment Natnet1 --config /root/.VirtualBox/Natnet1-Dhcpd.config --log /root/
10057  -  Z      0:00.10 <defunct>
20502  -  S      0:00.37 /usr/local/lib/virtualbox/VirtualBox

I hangs before opening.
Comment 249 Guido Falsi freebsd_committer 2021-03-02 11:51:21 UTC
(In reply to Mario Lobo from comment #247)

Yes, there is a bug in VBoxNetDHCP and whenever that process is launched this kind of behavior shows up.

It's not happening with bridged and simple NAT interfaces, but will happen with al the "networked" ones, which interface through netgraph AFAIK.

The internal workings of that part are complex, since it is aall getting through the virtualbox networking kernel modules, vboxnetflt.ko and vboxnetadp.ko.

The actual bug could well be in one of those, I'm inclined to point at vboxnetflt.ko, but it is just an idea with no proof.

Hacking on those requires a lot of studying them and the interfaces they use.

I'd like to find time and resources to do such studying, but I can't make promises for this, even less for actual results.

Anyway I would not expect a solution to such a nasty bug to pop out of nowhere in a short time. If this bug is a blocker for the update, the update will stay blocked for a while.
Comment 250 Mario Lobo 2021-03-02 13:26:58 UTC
(In reply to Guido Falsi from comment #249)

I've just compiled the legacy port to check if the same issues are present and report back.
Comment 251 Mario Lobo 2021-03-02 14:22:50 UTC
(In reply to Mario Lobo from comment #250)

virtualbox-ose-5.2.44_4     
virtualbox-ose-kmod-5.2.44_3

10153  -  S      0:03.88 /usr/local/lib/virtualbox/VBoxSVC --auto-shutdown
10833  -  S      0:16.90 /usr/local/lib/virtualbox/VirtualBox --startvm 18aaeb8c-7e6f-48b5-861e-baf5d59ba442 --no-startvm-er
10839  -  S      0:00.03 /usr/local/lib/virtualbox/VBoxNetDHCP --ip-address 10.0.2.3 --lower-ip 10.0.2.4 --mac-address 08:00:27:1B:2B:4E --ne
10840  -  S      0:00.09 /usr/local/lib/virtualbox/VBoxNetNAT --ip-address 10.0.2.1 --netmask 255.255.255.0 --network Natnet1 --trunk-type wh
10953  -  S      0:17.34 /usr/local/lib/virtualbox/VirtualBox Worker 01 --startvm 2c572a8f-95f6-4fb6-8173-3d782cc2142b --no-

Shutting down the VMs stops both VBoxNetNAT and VBoxNetDHCP processes.
No hangs or problems.

This still persists on legacy:

"One side note on bridged interface: I have 3 Ubuntu guests. 2 & 3 where cloned from 1. They all have different MAC addresses (checked with ifconfig on each) and they're all configured for DHCP. However, they are all getting the SAME ip addresses from DHCP, no matter how many times I recycle their MAC."

OBS - when using Nat network, they get different IPs.

=====================================================================

virtualbox-ose-6.1.18   
virtualbox-ose-kmod-6.1.18

4834  -  S      0:27.25 /usr/local/lib/virtualbox/VirtualBox
 4841  -  S      0:03.03 /usr/local/lib/virtualbox/VBoxXPCOMIPCD
 4843  -  S      0:07.82 /usr/local/lib/virtualbox/VBoxSVC --auto-shutdown
10056  -  R     39:16.11 /usr/local/lib/virtualbox/VBoxNetDHCP --comment Natnet1 --config /root/.VirtualBox/Natnet1-Dhcpd.config --log

It seems that in 6.x, VBoxNetNAT and VBoxNetDHCP got unified.
Comment 252 Guido Falsi freebsd_committer 2021-03-02 14:53:49 UTC
I need to take a better look at this VBoxNetDHCP issue. There is also a chance it's not that difficult to fix once one gets the whole picture of how the thing actually works.

So I'm not going to commit the update in this week, hoping to find some time to study the issue a little.
Comment 253 Guido Falsi freebsd_committer 2021-03-02 18:15:40 UTC
I'm trying to get virtualbox logging up to extract some logging from the kernel modules. But documentation is not really clear.

I found this:

https://www.virtualbox.org/wiki/VBoxLogging

If anyone knows how to get that up, please give me indications.

It talks about env vars, but I don't know exactly to which process I should pass them, and, if I'm understanding, I need to compile virtualbox with some special flags, but I'm not completely sure which ones.
Comment 254 Christoph Moench-Tegeder freebsd_committer 2021-03-02 20:31:57 UTC
(In reply to Guido Falsi from comment #253)
I did have some success with that. Let me summarize my notes:
- the RELEASE variables (VBOX_RELEASE_LOG..., VBOXSVC_RELEASE_LOG...) work even if virtualbox is compiled without "special" flags (i.e. normal ports build) - use these
- when debugging VM behaviour, you will need both VBOX logging and VBOXSVC logging - if in doubt, use both
- logging variables:
  - start with
    VBOX_RELEASE_LOG_DEST="dir=/path/to/writable/dir/"
  - control the logging format
    VBOX_RELEASE_LOG_FLAGS="time tid thread"
  - what subsystems you want to see
    VBOX_RELEASE_LOG="+dev_vmm.e.l.f +main.e.l.f"[...]
    this is where my notes get... thin, but I think the documentation (and it's links) does help here (I write less notes when I feel the docs are ok'ish)
  - set the corresponding VBOXSVC_* variables to the same values
- exporting the variables in the same shell where you start the virtualbox GUI is enough, when you do all the operations via GUI (but don't forget to export... experience, duh)

Ping me if you think I could be somewhat more helpful.
Comment 255 Guido Falsi freebsd_committer 2021-03-02 21:42:09 UTC
(In reply to Christoph Moench-Tegeder from comment #254)

Thanks for your help.

With your indications and some documentation I did get virtualbox to log.

Unluckily this first experiment did not provide any insight, because VBoxNetDHCP failed to start multiple times. It was launched but quit before doing anything.

I'll try again tomorrow hoping to get some information.
Comment 256 Guido Falsi freebsd_committer 2021-03-04 14:11:25 UTC
(In reply to Guido Falsi from comment #227)

I finally got a full backtrace, with all details (attached below)

It proves my guesses wrong, the failure is in another code path.

The problem is due to a race condition. Most of the time virtualbox fails to stop VBoxNetDHCP in time and yanks the network interface from below it. VBoxNetDHCP keeps trying to process packets and hangs in a ioctl to ask for more packets (I guess, still have to check the source) and cause a panic later.

Not sure how to fix this. I have not been able to understand exactly how virtualbox stops the process, ideally we should teach it to make sure it is gone before removing interfaces.

Another solution, maybe even better, could be teaching VBoxNetDHCP to not hang when the interface is yanked from below it.

I still can't make promises, but before declaring this cause lost I need to spend a little more work on it.

As soome added information, while studying this I now also understand why internal networking can be quite slow. All traffic is actually pumped through this single process, which checks every packet for processing. While it performs very little work in packets it's not interested in, it's anyway a bottleneck. Unluckily this is by design and there is no easy solution short of a whole re-engineering of the whole thing.

NOTE: the line numbers in this backtrace could be slightly off, because I did have some small patches in the sources I was using.

(gdb) bt
#0  0x000000080038679a in ioctl () from /lib/libc.so.7
#1  0x0000000801613edd in suplibOsIOCtl (pThis=0x801644f58 <g_supLibData>, 
    uFunction=3225966215, pvReq=0x7fffffffe220, cbReq=72)
    at src/VBox/HostDrivers/Support/freebsd/SUPLib-freebsd.cpp:153
#2  0x000000080160312d in SUPR3CallVMMR0Ex (pVMR0=0, idCpu=4294967293, uOperation=456, 
    u64Arg=0, pReqHdr=0x7fffffffe3a0) at src/VBox/HostDrivers/Support/SUPLib.cpp:681
#3  0x0000000801f8e227 in VBoxNetDhcpd::ifPump (this=0x7fffffffe490)
    at src/VBox/NetworkServices/Dhcpd/VBoxNetDhcpd.cpp:398
#4  0x0000000801f91aa6 in VBoxNetDhcpd::main (this=0x7fffffffe490, argc=7, 
    argv=0x800a09000) at src/VBox/NetworkServices/Dhcpd/VBoxNetDhcpd.cpp:648
#5  0x0000000801f91d3b in TrustedMain (argc=7, argv=0x800a09000)
    at src/VBox/NetworkServices/Dhcpd/VBoxNetDhcpd.cpp:779
#6  0x00000000002073cc in SUPR3HardenedMain (pszProgName=0x201d72 "VBoxNetDHCP", 
    fFlags=0, argc=7, argv=0x800a09000, envp=0x7fffffffe698)
    at src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp:2685
#7  0x0000000000204ac8 in main (argc=7, argv=0x7fffffffe658, envp=0x7fffffffe698)
    at src/VBox/NetworkServices/Dhcpd/VBoxNetDhcpdHardened.cpp:23
Comment 257 Guido Falsi freebsd_committer 2021-03-04 14:13:33 UTC
(In reply to Guido Falsi from comment #256)

Forgot to mention, the ports as they are in the tree and in my patches fail to produce proper debug binaries.

I'll add fixes for this in the next set of patches in a few days.
Comment 258 Mario Lobo 2021-03-04 17:51:51 UTC
(In reply to Guido Falsi from comment #257)

Guido;

See what I did in comment #100 to get VBox into gdb. Maybe you can take it further.
Comment 259 Guido Falsi freebsd_committer 2021-03-06 20:50:29 UTC
Created attachment 223033 [details]
6.1.18 port files archive

I finally was able to identify the issue.

AS reported here the DHCP functionality was fundamentally rewritten. In the rewrite some logic is similar, but some parts were changed.

The old code passed a 2 seconds timeout to the ioctl call to get new data from the virtual network. The new code explicitly sets no timeout. Reinstating the two second timeout seems to fix the issue, allowing VBoxNetDHCP to quit properly.

I did some local testing and it seems to work fine now.

SO please test the new patched port, and report back. I'd rather get some third party positive feedback before committing this update to the official tree.

I'm attaching the tarball with the new ports. Also available at [1]

The patch can be downloaded from the related code review.


[1] https://people.freebsd.org/~madpilot/virtualbox-ose-ports-6.1.18.txz
Comment 260 Guido Falsi freebsd_committer 2021-03-06 20:55:03 UTC
(In reply to Guido Falsi from comment #259)

For people interested the simple patch for this is in files/patch-src_VBox_NetworkServices_Dhcpd_VBoxNetDhcpd.cpp
Comment 261 Jason W. Bacon freebsd_committer 2021-03-06 23:04:51 UTC
(In reply to Guido Falsi from comment #259)

As of this update:

1. My shut down VMs are no longer marked "aborted"

2. It's running flawlessly built locally from source (I did not have to install from a package built under poudriere to avoid panics this time)

Looking good!
Comment 262 Daniel Morante 2021-03-06 23:12:02 UTC
(In reply to Guido Falsi from comment #259)

I've mostly been watching, so I guess I'll go ahead and give this a try.  I'll report with my results.
Comment 263 martin ilavsky 2021-03-07 13:01:06 UTC
(In reply to Guido Falsi from comment #260)
I applied the patch, enabled the DHCP back and tested it. Process is now stopped without problem. Modules can be removed ok too.
It's worth mentioning again that memory leaks do occur. More poweron/poweroff cycles more leaks. This can be a problem on a server where these cycles happen too often.

As patch is in userland process it would be interesting to write a PoC if system can be crashed when user with virtualbox privileges starts to stress the networking.
Comment 264 Guido Falsi freebsd_committer 2021-03-07 13:41:33 UTC
(In reply to martin ilavsky from comment #263)

Please let's keep focused on the main task, getting a newer virtualbox in the tree limiting regressions as much as possible.

AFAIK memory leaks are a problem with virtualbox also in other OSes. This is a subject that should be raised with upstream, mainly.

Anyway I'll let these patches rest a little while ti give people some time for testing, then I'll commit the update, since it's anyway an improvement on having an old and EOLed version in the tree.
Comment 265 Jason W. Bacon freebsd_committer 2021-03-07 14:18:32 UTC
I installed a Xubuntu guest under 12.2-RELEASE for testing:

1. Like my recent CentOS guest, it froze up the entire console near the end of installation.  I tried again with host cache enabled on the SATA interface (off by default for Linux guests) and it seems to be working fine.

2. I'm still having issues booting from an ISO after first loading it.  Ejecting it and reloading works around the issue. Possibly related, the mouse cursor has what appears to be a "wait" form when I enter the Storage settings.  Clicking on the window restores it to normal and then I can load/eject media.  I don't see this as a show-stopper since there's a simple workaround and it only affects each guest once.
Comment 266 Guido Falsi freebsd_committer 2021-03-07 21:14:26 UTC
(In reply to Jason W. Bacon from comment #265)

1. Like my recent CentOS guest, it froze up the entire console near the end of installation.  I tried again with host cache enabled on the SATA interface (off by default for Linux guests) and it seems to be working fine.

I've run in similar situations in the past with 5.x. For a time FreeBSD guests were highly unstable depending on the disks setup.

Recently I have been unable to install linux mint in virtualbox due to crashes.

Disabling host cache or choosing a different virtual controller usually mitigates these.

While annoying I can't count this as a regression, only a slight change in bad behavior.

2. I'm still having issues booting from an ISO after first loading it.  Ejecting it and reloading works around the issue. Possibly related, the mouse cursor has what appears to be a "wait" form when I enter the Storage settings.  Clicking on the window restores it to normal and then I can load/eject media.  I don't see this as a show-stopper since there's a simple workaround and it only affects each guest once.

I see this is also annoying but I agree not a blocker since there is a workaround.
Comment 267 Jason W. Bacon freebsd_committer 2021-03-07 22:08:50 UTC
I should also mention that I was able to run headless CentOS under 5.x on a zvol rather than a VDI.  There were also graphics issues with Linux guests under 5.x that I'm not experiencing with 6.x, but booting headless gave me a working system I could use for code testing.  Maybe this info will be useful to someone...
Comment 268 martin ilavsky 2021-03-07 22:21:31 UTC
I focused a bit on the VMs that were created with 5.x version. Fresh boot, vboxnet modules just loaded. Freshly copied 5.x VM to a 13.0-beta4 host. Attempt to start the VM fails with the already mentioned error (VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine). Any other VM, even one created with the 6.x fails with the same error.

If I unload/load modules back (vboxnet onestop/onestart) and start the 6.x VM first I can then start the 5.x too. Interestingly enough then it doesn't matter which VM is started first, they all work OK (even after fresh reboot).
Comment 269 Mario Lobo 2021-03-08 12:28:59 UTC
(In reply to Guido Falsi from comment #260)

I confirm that the DHCP/NAT patch is working perfectly! Processes are stopped properly an VMs shutdown gracefully.

I also report that I had no trouble installing from ISO files of Ubuntu, windows and FreeBSD. Clean and flawless install on all of them. I haven't tested installing Debian, Gentoo or Fedora.

ALL my VMs from previous versions are working flawlessly!

Besides keep on observing an noting what I can, all that is left for me to do is to be enormously grateful to you, Guido, for your efforts, persistence, patience and cleverness.
Comment 270 Jason W. Bacon freebsd_committer 2021-03-08 14:32:49 UTC
(In reply to Guido Falsi from comment #266)

Forgot to mention, the console freeze can be remedied by killing the virtualbox process from an ssh session.  The console is then fully functional again without having to reboot.
Comment 271 Jason W. Bacon freebsd_committer 2021-03-08 14:37:52 UTC
(In reply to Mario Lobo from comment #269)

> Besides keep on observing an noting what I can, all that is left for me to do 
> is to be enormously grateful to you, Guido, for your efforts, persistence, 
> patience and cleverness.

Ditto here.  Debugging vbox is a monumental task and Guido's efforts bring a huge benefit to the FreeBSD community!
Comment 272 Daniel Morante 2021-03-08 23:49:41 UTC
I built a pkg repo for this updated version with Poudriere

https://pkg.ny-us.morante.net/poudriere/build.html?mastername=12amd64-virtualbox-virtualbox&build=2021-03-07_23h26m47s

The only issue I can across was that I couldn't resume a suspended VM.  

```
Failed to open a session for the virtual machine Windows.

Failed to load unit 'HGCM' (VERR_SSM_UNEXPECTED_DATA).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
```

That was solved by just discarding the snapshot.  I guess this is a normal occurrence with VirtualBox between upgrades (I don't know, I mostly use VMWare Workstation)

Besides that small issue, things seem to work correctly in both my FreeBSD and Windows guests.  I updated the guest add-ons and auto resize works fine. Vagrant also seems to be working properly too.

For anyone else interested in testing and don't want to build, the PKG repo is available at http://pkg.ny-us.morante.net/virtualbox/.  It's a 12.2 64-bit only, built with PulseAudio, and it can be used by creating this file:


/usr/local/etc/pkg/repos/VirtualBox.conf

```
VirtualBox: {
	url: "http://pkg.ny-us.morante.net/virtualbox/${ABI}",
	enabled: yes
}
```

Side note... Would it make sense to flavor this port to have options to use Pulse or OSS without having to build your own package?
Comment 273 Guido Falsi freebsd_committer 2021-03-09 08:29:24 UTC
(In reply to Daniel Morante from comment #272)

> That was solved by just discarding the snapshot.  I guess this is a normal
> occurrence with VirtualBox between upgrades

Yes, from what I gather from virtualbox forums bringing around snapshots between major upgrades is not supported and it is suggested to properly shutdown VMs before the upgrade or discarding the snapshot like you did after the fact. I'm going to put a note about this in the UPDATING file.



I'm running some final poudriere test, to make sure I don't break anything and plan committing this later today or tomorrow at worst (in case compilation takes longer than expected); the update should be available for latest package set users in a week or so.
Comment 274 commit-hook freebsd_committer 2021-03-09 18:28:41 UTC
A commit references this bug:

Author: madpilot
Date: Tue Mar  9 18:27:41 UTC 2021
New revision: 567950
URL: https://svnweb.freebsd.org/changeset/ports/567950

Log:
  - Update VirtualBox OSE to 6.1.18
  - Old VirtualBox OSE 5.2.44 preserved as "-legacy" versions of the
    ports (repocopied)
  - Add back extra patch removed in r528258, actually required to
    build DEBUG kmod
  - Correctly define WITH_DEBUG when enabling the DEBUG option, so
    binaries are not stripped

  Please note that this new version supports only amd64 CPUs. If you need
  to use older hardware please install the legacy ports.

  Note that moving VM snapshots across major updates is unsupported, it's
  strongly suggested to properly shutdown VMs before upgrading, please
  check UPDATING for further details.

  This update is the result of work from many people, and thanks to all
  who gave feedback and tested things.

  Patch based on work from: Mario Lobo <lobo@bsd.com.br> and jkim.

  PR:			234878
  Submitted by:		kunda <chitty_cloud@me.com>
  Approved by:		vbox (implicit)
  Reviewed by:		decke
  Tested by:		jwb,
  			martin ilavsky <ilavsky.martin@gmail.com>,
  			Mario Lobo <lobo@bsd.com.br>
  Relnotes:		https://www.virtualbox.org/wiki/Changelog-6.1
  Differential Revision:	https://reviews.freebsd.org/D28871

Changes:
  head/MOVED
  head/UPDATING
  head/emulators/Makefile
  head/emulators/virtualbox-ose/Makefile
  head/emulators/virtualbox-ose/distinfo
  head/emulators/virtualbox-ose/files/extrapatch-src-VBox-Additions-x11-VBoxClient-Makefile.kmk
  head/emulators/virtualbox-ose/files/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk
  head/emulators/virtualbox-ose/files/extrapatch-src_VBox_Frontends_VirtualBox_src_net_UIDownloaderAdditions.cpp
  head/emulators/virtualbox-ose/files/extrapatch-src_VBox_Frontends_VirtualBox_src_net_UIDownloaderExtensionPack.cpp
  head/emulators/virtualbox-ose/files/extrapatch-src_VBox_Frontends_VirtualBox_src_settings_global_UIGlobalSettingsNetworkDetailsHost.cpp
  head/emulators/virtualbox-ose/files/patch-Config.kmk
  head/emulators/virtualbox-ose/files/patch-configure
  head/emulators/virtualbox-ose/files/patch-include-VBox-vmm-cpumctx.h
  head/emulators/virtualbox-ose/files/patch-include-iprt-x86.h
  head/emulators/virtualbox-ose/files/patch-include_VBox_VBoxGL2D.h
  head/emulators/virtualbox-ose/files/patch-include_VBox_com_array.h
  head/emulators/virtualbox-ose/files/patch-include_iprt_assertcompile.h
  head/emulators/virtualbox-ose/files/patch-include_iprt_cdefs.h
  head/emulators/virtualbox-ose/files/patch-include_iprt_string.h
  head/emulators/virtualbox-ose/files/patch-include_iprt_types.h
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-common-VBoxGuest-VBoxGuest-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-common-VBoxGuest-freebsd-Makefile
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-common-VBoxGuest-freebsd-files_vboxguest
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-common-crOpenGL-FreeBSD_i386_exports.py
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-common-crOpenGL-FreeBSD_i386_exports_dri.py
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-common-crOpenGL-FreeBSD_i386_glxapi_exports.py
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-common-crOpenGL-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src-VBox-Additions-x11-Installer-98vboxadd-xclient
  head/emulators/virtualbox-ose/files/patch-src-VBox-Devices-PC-ipxe-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src-VBox-Devices-Storage-DrvHostBase-freebsd.cpp
  head/emulators/virtualbox-ose/files/patch-src-VBox-GuestHost-OpenGL-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src-VBox-HostDrivers-Support-freebsd-Makefile
  head/emulators/virtualbox-ose/files/patch-src-VBox-HostDrivers-Support-freebsd-files_vboxdrv
  head/emulators/virtualbox-ose/files/patch-src-VBox-HostDrivers-VBoxNetAdp-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src-VBox-HostDrivers-VBoxNetAdp-freebsd-VBoxNetAdp-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-files_vboxnetflt
  head/emulators/virtualbox-ose/files/patch-src-VBox-Installer-freebsd-VBox.sh
  head/emulators/virtualbox-ose/files/patch-src-VBox-Main-src-server-VirtualBoxImpl.cpp
  head/emulators/virtualbox-ose/files/patch-src-VBox-Main-src-server-freebsd-HostHardwareFreeBSD.cpp
  head/emulators/virtualbox-ose/files/patch-src-VBox-Main-webservice-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src-VBox-Runtime-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src-VBox-Runtime-r0drv-freebsd-sleepqueue-r0drv-freebsd.h
  head/emulators/virtualbox-ose/files/patch-src-recompiler-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src-recompiler-Sun-testmath.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_VBoxService_VBoxServiceVMInfo.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_dri__glx.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_fakedri__drv.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_glx.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_glx__c__exports.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_glx__proto.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_stub.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_pam_pam__vbox.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_freebsd_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_freebsd_vboxvfs_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_freebsd_vboxvfs_bcmp.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vfsops.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_x11_VBoxClient_logging.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_x11_x11include_xproto-7.0.18_X11_Xfuncproto.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Debugger_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_Audio_DrvHostALSAAudio.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_Audio_DrvHostOSSAudio.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_Graphics_DevVGA-SVGA3d-glLdr.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_Graphics_DevVGA-SVGA3d-glLdr.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_Graphics_DevVGA-SVGA3d-ogl.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_PC_ipxe_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_PC_vbox-cpuhotplug.dsl
  head/emulators/virtualbox-ose/files/patch-src_VBox_Devices_Storage_DrvHostBase-freebsd.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Frontends_VBoxManage_VBoxManageHelp.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Frontends_VBoxManage_VBoxManageModifyVM.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Frontends_VirtualBox_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Frontends_VirtualBox_src_globals_UIImageTools.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Frontends_VirtualBox_src_widgets_UIMenuToolBar.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Frontends_VirtualBox_src_widgets_UIMiniToolBar.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Frontends_VirtualBox_src_widgets_UIPopupBox.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_GuestHost_OpenGL_include_chromium.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostDrivers_Support_SUPDrv.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostDrivers_Support_SUPDrvInternal.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostDrivers_Support_freebsd_SUPDrv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostDrivers_VBoxNetAdp_freebsd_Makefile
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostDrivers_VBoxNetFlt_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostDrivers_VBoxNetFlt_freebsd_Makefile
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostDrivers_VBoxNetFlt_freebsd_VBoxNetFlt-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_HostServices_SharedOpenGL_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Main_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Main_include_HostPower.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Main_include_USBProxyBackend.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Main_src-client_ConsoleImpl2.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Main_src-server_HostImpl.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Main_src-server_freebsd_NetIf-freebsd.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_NetworkServices_Dhcpd_VBoxNetDhcpd.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_RDP-client-1.8.4-Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_common_err_RTErrConvertFromErrno.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_alloc-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_assert-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_mp-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_semevent-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_semeventmulti-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_semfastmutex-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_spinlock-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_the-freebsd-kernel.h
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_thread2-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_time-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r0drv_freebsd_timer-r0drv-freebsd.c
  head/emulators/virtualbox-ose/files/patch-src_VBox_Runtime_r3_posix_process-creation-posix.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_VMM_VMMR0_GVMMR0.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_VMM_VMMR3_VMReq.cpp
  head/emulators/virtualbox-ose/files/patch-src_VBox_VMM_include_IEMInternal.h
  head/emulators/virtualbox-ose/files/patch-src_libs_xpcom18a4_Makefile.kmk
  head/emulators/virtualbox-ose/files/patch-src_libs_xpcom18a4_nsprpub_pr_src_pthreads_ptsynch.c
  head/emulators/virtualbox-ose/files/patch-src_libs_xpcom18a4_xpcom_reflect_xptcall_src_md_unix_xptcinvoke__x86__64__linux.cpp
  head/emulators/virtualbox-ose/files/patch-src_recompiler_Makefile.kmk
  head/emulators/virtualbox-ose/pkg-plist
  head/emulators/virtualbox-ose-additions/Makefile
  head/emulators/virtualbox-ose-additions/distinfo
  head/emulators/virtualbox-ose-additions-legacy/
  head/emulators/virtualbox-ose-additions-legacy/Makefile
  head/emulators/virtualbox-ose-additions-nox11-legacy/
  head/emulators/virtualbox-ose-additions-nox11-legacy/Makefile
  head/emulators/virtualbox-ose-kmod/Makefile
  head/emulators/virtualbox-ose-kmod/distinfo
  head/emulators/virtualbox-ose-kmod-legacy/
  head/emulators/virtualbox-ose-kmod-legacy/Makefile
  head/emulators/virtualbox-ose-legacy/
  head/emulators/virtualbox-ose-legacy/Makefile
  head/emulators/virtualbox-ose-nox11-legacy/
  head/emulators/virtualbox-ose-nox11-legacy/Makefile
Comment 275 Guido Falsi freebsd_committer 2021-03-09 18:34:43 UTC
Update finally committed.

I'll close this report, if you have any issue or regression please file a new one for that issue by itself.

Thanks again to all who helped!
Comment 276 VVD 2021-03-09 20:33:46 UTC
(In reply to Guido Falsi from comment #275)
Commit please this one too: "www/phpvirtualbox: Update to 6.1 add legacy port"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254079
Comment 277 Guido Falsi freebsd_committer 2021-03-09 20:36:32 UTC
(In reply to VVD from comment #276)

I'm sorry, I never used that and am completely unable to test it.
Comment 278 VVD 2021-03-09 20:59:50 UTC
(In reply to Guido Falsi from comment #277)
No problem - probably somebody else from this thread have interest and will look + commit. :-]
Comment 279 Mikhail Teterin freebsd_committer 2021-03-09 22:40:36 UTC
> Please note that this new version supports only amd64 CPUs.

This part may be true about the hosting, but it is not true about the "guest additions"...
Comment 280 Guido Falsi freebsd_committer 2021-03-09 22:52:53 UTC
(In reply to Mikhail Teterin from comment #279)

As I stated somewhere above, the additions fail to build with a strange gmake error on i386.

I've been unable to make them build.

Patches welcome.
Comment 281 Guido Falsi freebsd_committer 2021-03-09 22:55:51 UTC
(In reply to Mikhail Teterin from comment #279)

see comment #177 and comment #191
Comment 282 Mario Lobo 2021-03-13 13:54:58 UTC
(In reply to Guido Falsi from comment #281)

Guido;

I noticed that the file patch-src_VBox_Devices_Audio_DrvHostOSSAudio.cpp is missing on the virtualbox-ose-legacy. Is it possible to add it to it?

Please let me know and I will attach it here.
Comment 283 Guido Falsi freebsd_committer 2021-03-13 14:41:17 UTC
(In reply to Mario Lobo from comment #282)

> I noticed that the file patch-src_VBox_Devices_Audio_DrvHostOSSAudio.cpp is
> missing on the virtualbox-ose-legacy. Is it possible to add it to it?

I copied the port to legacy prior to any changes.

The file you indicate was removed from the virtualbox port in r421965 in 2016. So no, in the legacy ports it's absent as it used to be.

Why should it be added?

This bug report is a mess. Please file a new one with a patch explaining why the virtualbox-ose-legacy ports now needs a patch file that has been removed 5 years ago.
Comment 284 Mario Lobo 2021-03-13 15:37:36 UTC
(In reply to Guido Falsi from comment #283)

For the same reason patch-src_VBox_Devices_Audio_DrvHostOSSAudio.cpp is present on 6.1.18:

It makes guest audio devices work with OSS, specially in windows guests.
Comment 285 Mario Lobo 2021-03-13 15:52:43 UTC
(In reply to Mario Lobo from comment #284)

see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233301
Comment 286 Guido Falsi freebsd_committer 2021-03-13 16:04:55 UTC
(In reply to Mario Lobo from comment #285)

I see, but that patch never really made it into the virtualbox 5.1.44 port. I simply copied the port as is, I did not remove the patch. I was not even aware of this issue.

So what you tell me is the same as asking me to add it. So please, file a proper bug report with attached patch so I can process it. Talking about this in a loosely related closed bug is not a good practice.
Comment 287 Mario Lobo 2021-03-13 16:12:06 UTC
(In reply to Guido Falsi from comment #286)

Sorry! Posted the wrong bug.

Here is the correct open one:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237472

The last post even mentions the new 6.1.18 port.
Comment 288 Mario Lobo 2021-03-13 17:26:13 UTC
(In reply to Mario Lobo from comment #287)

Guido:

I didn't mean to mess up THIS bug. I know that it is closed. 6.1.18 still isn't a working unanimity, The same as the the mentioned patch for 5.x, but the idea is that if it work for the majority, we're able to tackle more precisely the specific cases where it doesn't work. Even with legacy versions.

Please forgive my ignorance for port corrections procedures, and to assume that you could add the missing patch to 5.x. 

At least, the bug for that is still open.
Comment 289 Guido Falsi freebsd_committer 2021-03-13 17:49:59 UTC
(In reply to Mario Lobo from comment #288)

No problem, I'm looking at bug 237472. Please give me time to do my testing.
Comment 290 Graham Perrin 2021-03-18 09:08:17 UTC
(In reply to Graham Perrin from comment #235)

<https://www.virtualbox.org/ticket/20262>: 

#20262 (FreeBSD host, EFI guests, 6.1.18: F12 no longer presents the boot manager) – Oracle VM VirtualBox