Please update to 6.0 https://download.virtualbox.org/virtualbox/6.0.0/VirtualBox-6.0.0.tar.bz2
Please don't update it till www/phpvirtualbox add support of 6.0 branch.
Created attachment 201612 [details] Update to 6.0.4.
Please!!! Make 2 separate ports or wait phpvirtualbox 6.0: https://github.com/phpvirtualbox/phpvirtualbox/issues/154 Initial support already commited, but not released yet: https://github.com/phpvirtualbox/phpvirtualbox/commit/3a5a1ce787515183788fb2e63ae83c1b00f71ffc
(In reply to VVD from comment #3) Don't worry, I heard you. :-)
(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?
(In reply to VVD from comment #5) > Is it mean impossibility to build VirtualBox 6 on 32bit at all, or just Oracle stop make binary packages for 32bit hosts? It builds fine for now.
But how long are we going to wait for a 3rd party add-on for this port? At some point 2 ports have to been made if one is hold hostage by phpvirtualbox imo.
(In reply to Jung-uk Kim from comment #4) We can update phpvirtualbox right now, 6.0 support already commited. They can not do make release for a long time.
(In reply to Jung-uk Kim from comment #2) I applied your patch against revision 491653 and compilation went fine on 12.0-RELEASE-amd64. • Starting a VM graphically gets stuck at a 0% progress bar • Using vboxmanage is not better: Waiting for VM "Win7" to power on... While waiting, CPU usage stays close to zero. I am now rebuilding with DEBUG on...
(In reply to Jung-uk Kim from comment #2) With DEBUG on, I got an error at compilation: /usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.4/src/VBox/VMM/VMMR3/APIC.cpp:1336:43: error: comparison between pointer and integer ('void *' and 'RTR0PTR' (aka 'unsigned long')) Assert(pApicCpu->pvApicPageR3 == NIL_RTR0PTR);
Created attachment 204171 [details] Update to 6.0.6.
(In reply to Jung-uk Kim from comment #11) Thank you for your effort and the time you dedicate to this. It is much appreciated.
Created attachment 204412 [details] Update to 6.0.8.
Created attachment 204430 [details] Update to 6.0.8 (rebased)
Testing that latest patch, I can still reproduce the problems reported in comment #9 - starting a VM (via GUI, via VBoxManage, headless or with GUI - doesn't matter, it's all the same) waits "forever" (I gave up after ~10min latest) without anything relevant happening (when starting the VM via GUI, a progress bar appears after some time (15s? 30s?) but stays stuck at 0%). That affects old VMs carried over from a 5.2 installation, but also newly created VMs.
(In reply to Christoph Moench-Tegeder from comment #15) I only tested on 12.0-RELEASE. Did you test on CURRENT ? If you did not and if Jung-uk Kim can not reproduce on CURRENT, then we kind of know what is going on.
(In reply to Samy Mahmoudi from comment #16) This is 12.0-RELEASE-p4 - basically, the same setup/problem as you have (had?). It's not clear whether we have a solution for that (have we? did I miss it?).
(In reply to Christoph Moench-Tegeder from comment #17) We may have something if Jung-uk Kim can not reproduce our freezes on CURRENT. This would mean our problem is not only related to the port but also to the base system we both use. This would not be a solution though, only a starting point to investigate.
(In reply to Jung-uk Kim from comment #14) Hi again, Did you test launching a VM on FreeBSD-CURRENT ?
(In reply to Samy Mahmoudi from comment #19) > Did you test launching a VM on FreeBSD-CURRENT ? Yes, of course. Does it only happen with Windows guests? Did you turn on 2D/3D acceleration for the guests?
Created attachment 204727 [details] Update to 6.0.8 Never mind. Please try this.
(In reply to Jung-uk Kim from comment #21) Yay! Progress! Thanks! With aforementioned setup (and a Linux guest) the VM starts and seems to be ok. Only one glitch: "VBoxManage startvm --type headless" fails with: : cmt@elch:~$ VBoxManage startvm host1 --type headless : Waiting for VM "host1" to power on... : VBoxManage: error: Unable to load R3 module /usr/local/lib/virtualbox/VBoxDD.so (VBoxDD): /usr/local/lib/virtualbox/VBoxDD.so: Undefined symbol "glXMakeCurrent" (VERR_FILE_NOT_FOUND) : VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole This only happens with startvm in headless mode - other VBoxManage operations (like showinfo or controlvm) or even "start" without "--type headless" work just fine.
Created attachment 204742 [details] Update to 6.0.8 (fixed OpenGL issue) This patch should fix the OpenGL issue. Please try this.
(In reply to Jung-uk Kim from comment #23) This looks good - my VMs start (with and without GUI), new guest additions are working, shared folders ok... great!
Will the 6,0 update get committed any time soon?
Considering that this 3rd party add-on added support for vbox 6 with this commit a few months ago (April 2019) 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.
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.
It would make sense that we rename virtualbox-ose and friends to virtualbox-ose5 and add this as virtualbox-ose6. There are many examples of this in the tree such as xpdf and many others.
(In reply to Cy Schubert from comment #28) Agree - make separate ports with 5 and 6. VB 6 have stability problems on FreeBSD - already fixed? RemoteBox isn't web application (but phpvirtualbox is) - it's stand-alone rich client on GTK.
(In reply to VVD from comment #29) Why should it be mandatory to be a web app? I can work very well with virtualbox on remotebox on my remote server. The only difference is that you must install remotebox on every computer that needs access to virtualbox. I really don't see what is the problem? For me it is about the functionality and I prefer to be able to work with vbox 6 and install remotebox on more machines instead of waiting forever on phpvirtualbox
(In reply to BonHomme from comment #30) > Why should it be mandatory to be a web app? Are you serious? > The only difference is that you must install remotebox on every computer that needs access to virtualbox. 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?
(In reply to VVD from comment #31) Come on. Be a little bit practical please. How many people really need to reach Virtualbox from more than one or two machines? Beside that, once you installed Remotebox on the client and Freebsd, installing the next client is just a matter of a few minutes. Using phpvirtualbox or remotebox is just a matter of choice and what is most important to you as the Virtualbox funtionality in both solutions is the same. Only the access method is different. And for people that work with an unsupported platform nothing changes. They have to wait for phpvirtualbox anyway. So as remotebox is an excellent, very well working and very well maintained alternative to phpvirtualbox (remotebox supports V6 already since January 6 2019) I really don't understand why everybody using virtualbox must wait (more than 8 months) for phpvirtualbox to be ready. And as far as using an (untested?) and unsupported patch for Vbox 6: Are yóu serious?
> How many people really need to reach Virtualbox from more than one or two machines? At least 10 people in our company use it from different devices. And we regularly use it from arbitrary computers in the office. > Beside that, once you installed Remotebox on the client and Freebsd, installing the next client is just a matter of a few minutes. Please stop this stupid dispute "rich client vs web application"! Web application is zero-cost support on client side and "true" cross-platform. Rich client isn't. > And as far as using an (untested?) and unsupported patch for Vbox 6: Are yóu serious? And you think that this patch will become tested after the maintainer updates the port? "Are yóu serious?" Just make separate port for VB 6 and keep VB 5 as more stable version. And you can be happy to be beta-tester for this patch. But better get this patch included in the upstream.
Can we keep this civil and on-topic? Thank you. To summarize, the questions are: - Are there any outstanding issues with VirtualBox 6? (It works for me, but sometimes I'm one of the lucky ones...) - If there are any ports which cannot be updated to work with VirtualBox 6, is there anything preventing a repocopy and having both virtualbox 5 and 6 in the tree? (I don't mind the naming, let it be "virtualbox" and "virtualbox6" or "virtualbox5" and "virtualbox", or some variation thereof). Is that the state of things right now?
I too would like the VirtualBox ports upgraded (the current latest from upstream is 6.0.10) -- at least, the ose-guest-additions, because that's all I use. The one point, that all of the virtualbox ports have omitted so far is adding -DPAE to the compiler command lines building kernel modules. I'm trying to deal with this myself currently with things like this: .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).
My WIP for 6.0.12 is here: https://github.com/lwhsu/freebsd-ports-virtualbox-ose
(In reply to Li-Wen Hsu from comment #36) That 6.0.12 works fine for what I'm doing (FreeBSD host, guests are mostly Linux). One small nitpick: when downloading the Guest Additions ISO image, right when the download is at 100%, an error message pops up: "The network operation failed with the following error: During network request: Unknown reason." (that's really neither specific nor helpful...). Downloading the image manually into the right place works fine.
Created attachment 207660 [details] 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?
(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 *);
Sorry for not mentioning. FreeBSD 11.3-STABLE
I decided to skip 6.0. 6.1 is imminent.
(In reply to Jung-uk Kim from comment #41) Not sure if this helps, I was working on cleaning the patches for 6.1: https://github.com/lwhsu/freebsd-ports-virtualbox-ose/pull/1
(In reply to Li-Wen Hsu from comment #42) Oh, I didn't know. I already have a patch for 6.1.0 RC1.
(In reply to Jung-uk Kim from comment #43) As far as I remember, 6.1 drop support of i386 hosts...
Created attachment 209925 [details] VBOX 6.1.0 port
The above is mu attempt to compile VBox 6.1.0 after tweaking the patches. The VMs start and run OK. 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
Created attachment 209927 [details] Update to 6.1.0 (In reply to Mario Lobo from comment #45) Thanks but I already have 6.1 patches. Please let me know if I missed anything.
Note the patches are NOT final and you need to update devel/kBuild first.
(In reply to Jung-uk Kim from comment #48) Could you provide a link for your patches? To me, this is the version with the best performance I've seen! The VMs are really fast!.
(In reply to Jung-uk Kim from comment #48) Ok. Found the patches and applied them. I had to make little corrections on a few files but everything ended up compiling and running. The problems I mentioned on the attempt on my patches remained with yours: 1) with 2 monitors, the 2nd monitor doesn't get the same max resolution as the 1rst. Only after I resize de 2nd monitor, it adjusts to full screen. 2) Shutting down the VM freezes the host UI (in my case, kde). Had to alt+F1 to issue a ^C to kill kde. If I leave the VM on a background workspace, I can terminate the VM without having the host UI frozen. The status on VBox never gets past "stopping", although the logs show that the VM has finished. Other than that, the VMs run really fast and are fully operational while up.
So, I had been trying these patches as they came about. The 6.0.x line seemed to work perfectly fine (albeit that I've never been able to get audio to work in the guest, despite the host driver working on the host, but this was a problem for me in the 5.x line too and I don't know when that started happening). But 6.1.0 seems to be trouble galore. I've had the following issues at one point or another: * VMs won't start (I would get a pretty generic NS_ERROR_FAILURE 0x80004005 in component SessionMachine, and while others online say it was from starting from a snapshot, I was starting from an offline VM) * With a dual-monitor Windows 10 VM and using mouse integration, I was getting an issue with the mouse cursor treating the first monitor as if it was both monitors combined (so as I moved right, the cursor position inside the VM itself was going farther right than it should've) * When I tried to change the display type (which was originally VBoxVGA) to another option, I'd either start getting those generic errors from the first point or it would start fine, but the mouse issue would persist. At one point I switched back to VBoxVGA and ran into an issue where the guest display was some small 640x480 I think with an almost grayscale like 16-color-ish looking display. * Every time a VM shuts down, it says it aborted instead of being powered off. I see the following in one of the logs: 00:00:05.595427 !!Assertion Failed!! 00:00:05.595427 Expression: <NULL> 00:00:05.595428 Location : /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.0/src/VBox/VMM/VMMR3/MMHeap.cpp(667) void MMR3HeapFree(void *) 00:00:05.595433 Stack : 00:00:05.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.
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
Back to the group. I do not have enough time to work on it.
May be keep 3 different ports: emulators/virtualbox-ose-52 - old stable emulators/virtualbox-ose-60 - new, support CPUs without VT-x/AMD-V emulators/virtualbox-ose-61 - new, support CPUs with VT-x/AMD-V only
So, will be 6.1 landed in port-tree ? or still it is not stable.
(In reply to Hadi from comment #55) 6.1.0 is still unstable. The last stable version I compiled and I use is 6.0.8. The ports version is still 5.x, and VBox is already up to 6.1.4. I managed to compile version 6.1.0. It runs fine and it is pretty fast, at least in short tests. The problem is that instead of shutting down the machine, it aborts them, no matter what way you used to shut them down. The same happened with Jkim's patch for it. I wish I had the knowledge to "correct" the code but unfortunately I don't, so I guess I'll just have to wait.
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
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.
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
(In reply to Darin Luckie from comment #59) Did you use the port I attached (6.1.6) or made your own?
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?
(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.
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.
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.
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.
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.
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
Created attachment 214671 [details] Port of VitualBox 5.2.42
(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
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
(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...
(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'..."
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.
(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.
It's about the same error that happens with all 6.0.x and 6.1.x versions I tried.
(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
(In reply to didier.castellacci from comment #76) Did you load the drivers?
(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
(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
(In reply to didier.castellacci from comment #79) There is no VirtualBoxVM binary.
(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
(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
(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
(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?
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.
(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
6.1.10 released: https://www.virtualbox.org/wiki/Changelog-6.1
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.
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.
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.
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.
(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".
Would anyone know how to set up a debug build of the VBox port?
(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.
Marking the Debug option does not produce debug symbols for any of the VBox executables.
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.
(In reply to Mario Lobo from comment #96) > I finally managed to get VBox into gdb. How did you do so?
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.
(In reply to Mario Lobo from comment #98) Thank you for the explanation Mario.
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
Created attachment 216038 [details] VBox 6.1.10 port files Here are the virtualbox-ose 6.1.10 port files
Created attachment 216039 [details] VBox 6.1.10 kmod port files Here are the VBox 6.1.10 kmod port files
^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?
(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.
(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).
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.
Sleep, wake ----------- Re: bug 238499 please, can anyone tell whether the host panic at host resume time is reproducible with 6.1?
(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.
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?
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
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)"
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?
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
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!
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.
I'm bringing my system to today's date to test it again.
(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.
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)
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.
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.
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>
(In reply to Graham Perrin from comment #121) https://github.com/freebsd/freebsd-ports-kde/tree/virtualbox-6/emulators/virtualbox6-ose
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
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
(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.
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 %
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 #
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 #
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 …
Created attachment 222201 [details] distinfo for virtualbox6-ose-6.1.18 My bad, the previous file unnecessarily included info for the guest additions .iso
Should we consider renaming virtualbox-ose and friends to virtualbox-ose52 and create a new virtualbox-ose61 group of ports?
(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
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.
(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?
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.
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.
(In reply to Mario Lobo from comment #135) Does recently fixed bug 252675 relate to point 2?
(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.
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.
(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.
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.
(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.
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.
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.
(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.
(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 :-)
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.
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
(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.
(In reply to imbutler from comment #148) Will do that first thing tomorrow!
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:~ #
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.
(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.
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.
(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)
(In reply to Guido Falsi from comment #153) No critisism taken, Guido! We are all helping each other here.
(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.
(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.
Mario, It seems it is the commit I pasted above.
(In reply to imbutler from comment #148) I second that! 6.1.18 is working just fine too!
(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.
(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?
(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
Then just "git pull" inside the directory you want to update.
Here you can see all -b options you can have: https://cgit.freebsd.org/src/refs/heads
(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.
(In reply to Guido Falsi from comment #166) Excellent, Guido! Patch applied!
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.
(In reply to Guido Falsi from comment #168) BTW simply including X11/Xfuncproto.h is not working, altough it's related to the issue.
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;
(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.
(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
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.
(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.
(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
@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.
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.
(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.
(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.
(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.
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 !!!
(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.
(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.
(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.
(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
(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.
(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
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
(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!
(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
(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.
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.
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.
(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 :-)
(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.
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.
(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)
(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.
(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).
(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.
(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
(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
(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...)?
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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)
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.
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 ```
(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.
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.
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".
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.
(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.
(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
(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.
(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?
(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
(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).
(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?
(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.
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.
(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.
(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.
(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.
(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
(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.
(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.
(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).
(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}
(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
(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
(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?
(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.
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?
(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!
(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.
(In reply to Guido Falsi from comment #240) Strong argument for documenting our patches. :-/
(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
(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.
(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
(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!
(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
(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.
(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.
(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.
(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.
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.
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.
(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.
(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.
(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
(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.
(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.
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
(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
(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!
(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.
(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.
(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.
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.
(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.
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...
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).
(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.
(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.
(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!
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?
(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.
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
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!
(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
(In reply to VVD from comment #276) I'm sorry, I never used that and am completely unable to test it.
(In reply to Guido Falsi from comment #277) No problem - probably somebody else from this thread have interest and will look + commit. :-]
> 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"...
(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.
(In reply to Mikhail Teterin from comment #279) see comment #177 and comment #191
(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.
(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.
(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.
(In reply to Mario Lobo from comment #284) see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233301
(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.
(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.
(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.
(In reply to Mario Lobo from comment #288) No problem, I'm looking at bug 237472. Please give me time to do my testing.
(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