Bug 270189
| Summary: | emulators/virtualbox-ose: guest machines are no longer usable: Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3). | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Graham Perrin <grahamperrin> |
| Component: | Individual Port(s) | Assignee: | Vladimir Druzenko <vvd> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | arrowd, cmt, cy, d8zNeCFG, grahamperrin, groenveld, intellisun, michael, philippe.michel7, pr, rkoberman, vvd, xxjack12xx |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(vbox) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| URL: | https://www.freshports.org/emulators/virtualbox-ose/ | ||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266907 https://reviews.freebsd.org/D40254 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270094 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272580 |
||
| Attachments: | |||
Bug 234878 comment 134 (2021-02-09) from Christoph Moench-Tegeder is remarkable. Can any of that help with things now? Thanks (In reply to Graham Perrin from comment #1) Thank you for the pointer! It appears to be an issue with llvm15. Hack below. John groenveld@acm.org # uname -srv FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n261408-c581962414ed: Thu Mar 9 08:11:08 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC # pkg install llvm14 # cd /usr/ports # git diff diff --git a/emulators/virtualbox-ose-kmod/Makefile b/emulators/virtualbox-ose-kmod/Makefile index 1e31a951bd58..775904eab876 100644 --- a/emulators/virtualbox-ose-kmod/Makefile +++ b/emulators/virtualbox-ose-kmod/Makefile @@ -1,3 +1,5 @@ +CC= clang14 +CXX= clang++14 PORTNAME= virtualbox-ose PORTVERSION= 6.1.36 CATEGORIES= emulators diff --git a/emulators/virtualbox-ose/Makefile b/emulators/virtualbox-ose/Makefile index 3adb68b1f5fa..3a941307c1fb 100644 --- a/emulators/virtualbox-ose/Makefile +++ b/emulators/virtualbox-ose/Makefile @@ -1,3 +1,5 @@ +CC= clang14 +CXX= clang++14 PORTNAME= virtualbox-ose PORTVERSION= 6.1.36 PORTREVISION= 1 Created attachment 240856 [details]
Makefile patch for virtualbox-ose and virtualbox-ose-kmod
virtualbox-ose-kmod builds but virtualbox-ose fails with:
/wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.36/src/VBox/Devices/PC/ipxe/src/core/settings.c:289:8: error: fields must have a constant size: 'variable length array in structure' extension will never be supported
char name[ strlen ( name ) + 1 /* NUL */ ];
^
11 warnings and 1 error generated.
(In reply to groenveld from comment #2) Appears the issue has been resolved with current CURRENT. Rebuilding virtualbox-ose-kmod with stock llvm worked for me. John groenveld@acm.org # uname -srv FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n261544-cee09bda03c8: Thu Mar 16 08:11:20 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC # cd /usr/ports # git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean # git diff # (In reply to groenveld from comment #4) No... virtualbox-ose-kmod builds with stock llvm and virtualbox-ose builds with llvm14. Sorry for the bad info. John groenveld@acm.org # git status On branch main Your branch is up to date with 'origin/main'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: emulators/virtualbox-ose/Makefile no changes added to commit (use "git add" and/or "git commit -a") # git diff diff --git a/emulators/virtualbox-ose/Makefile b/emulators/virtualbox-ose/Makefile index 3adb68b1f5fa..3a941307c1fb 100644 --- a/emulators/virtualbox-ose/Makefile +++ b/emulators/virtualbox-ose/Makefile @@ -1,3 +1,5 @@ +CC= clang14 +CXX= clang++14 PORTNAME= virtualbox-ose PORTVERSION= 6.1.36 PORTREVISION= 1 Created attachment 241099 [details] Compressed log from 2023-03-25_01h05m08s (In reply to groenveld from comment #5) Build of virtualbox-ose failed, here, probably because of the different version of clang: % which clang /usr/bin/clang % /usr/bin/clang --version FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git llvmorg-15.0.7-0-g8dfdcc7b7bf6) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin % ---- If I use 15 instead of 14 at the head of the patched Makefile: CC= clang15 CXX= clang++15 PORTNAME= virtualbox-ose … – then build fails as shown at <https://reviews.freebsd.org/P566>. Full log attached. % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #35 main-n261613-2b4b3789f877: Sun Mar 19 04:09:06 GMT 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400083 1400083 % Without patches both kmod and base port build correctly, as of 1400085, but when virtualbox is executed the same error pops ups (Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3). NS_ERROR_FAILURE (0x80004005)). The module can be built with CC=clang14 and CXX=clang++14 but if you do so the module does not load and the following is shown: kernel: kldload: unexpected relocation type 42, symbol index 918 kernel: link_elf_obj: symbol __stack_chk_guard undefined kernel: linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type And then virtualbox fails with kernel: pid 10213 (VirtualBoxVM), jid 0, uid 1004: exited on signal 6 virtualbox-ose does not builds with CC=clang14 and CXX=clang++14. Created attachment 241524 [details] Screenshot: the error dialogue (In reply to pr from comment #7) > … base port build correctly, as of 1400085, but when virtualbox is > executed the same error pops ups (Failed to construct device 'VMMDev' > instance #0 (VERR_INTERNAL_ERROR_3). NS_ERROR_FAILURE (0x80004005)). … The same here. The error (pictured) when I attempt to start a guest. root@mowa219-gjp4-8570p-freebsd:~ # uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #38 main-n262032-5e2e3615d91f: Fri Apr 7 18:54:28 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400085 1400085 root@mowa219-gjp4-8570p-freebsd:~ # What can be done to progress this bug? I encountered the same problem when I upgraded to FreeBSD 13.2 STABLE with LLVM 15.0.7. I managed to start the virtual machines by editing the .vbox files of each machine and removing the <GuestProperties> section. Of course vboxheadless/vboxwebsrv services or VirtualBOX GUI must be stopped before editing the files. Please make a back-up before any changes. (In reply to intellisun from comment #9) (In reply to intellisun from comment #10) Hi, unfortunately this workaround does not work here (14.0 current). (In reply to pr from comment #11) To add another data point, the "workaround" given in #9 and #10 does work for me. $ uname -aKU FreeBSD tms.home.galassi.us 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n255171-68a69739cb90 GENERIC amd64 1302505 1302505 $ Re: bug 266907 comment 32, with the additional lines (only) from <https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241618&action=diff#b/emulators/virtualbox-ose/Makefile_sec2> in the Makefile for virtualbox-ose, I get: … /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.36/src/VBox/Devices/PC/ipxe/src/core/settings.c:289:8: error: fields must have a constant size: 'variable length array in structure' extension will never be supported char name[ strlen ( name ) + 1 /* NUL */ ]; ^ 11 warnings and 1 error generated. kmk: *** [/wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.36/out/freebsd.amd64/release/obj/iPxeBaseBin/src/core/settings.o] Error 1 … Looks like this bug has split into two totally separate issues. The initial post and one about problems building with LLVM15 failing. The initial problem is not a build problem... it's an issue of the guest generating a fatal error just after the guest window appears, but before loading. That is what I saw. This is true for both Windows and Linux VMs. First, I am running 14.0 main-n261962-41236539d8dd-dirty from 9-Apr. The problem appeared after the rebuild of both virtualbox-ose and virtualbox-ose-kmod after the PORTREVISION bump for the update of math/mpc back on Apr-25. Other ports were updated at the same time including some qt5 ports. If I delete the GuestProperties section of the .vbox file, it looks to be starting. The VM loads, but seems to take a long time to do so... almost 4 minutes. It then aborts. After reboot, it boots up normally and seems to be running as if nothing had happened. I should also note that I just deleted the content of GuestProperties, but left an empty section. i.e. I left the <GuestProperties> and </GuestProperties> in place. Good luck! It get worse. My VMs came up once, but now VMs abort after a short interval. It seemed like every reboot crashed mre quickly and did not re-add GuestProperties. Died too quickly after a couple of boots. (In reply to rkoberman from comment #14) > … 14.0 main-n261962-41236539d8dd-dirty from 9-Apr … Try updating the OS and copies of repos, then apply the (VirtualBox 6.1.44) patch at bug 266907 comment 44. After building and installing emulators/virtualbox-ose, I opened a saved Windows 10 guest, ran it for a while, used Windows to shut down. Host: % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #39 main-n262604-7ee4066db129: Thu Apr 27 21:56:38 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400088 1400088 After updating to 6.1.44 via the patch from bug 266907, it looks like everything is now working. Both VMs I use regularly are starting up correctly, though Windows 10 VM had to do an automatic repair. Thanks for getting a resolution to this problem, especially to Graham. I do want to mention that the patch failed on one hunk of he patch to Makefile on both virtualbox-ose and virtualbox-ose-kmod. The failure was on the first hunk to update the VERSION and delete the PORTREVISION. No idea why it failed, but it was an easy edit to update two characters and delete a line. All significant parts of hte patch applied cleanly. (In reply to rkoberman from comment #17) Thanks, but really, I can't take credit. Try the patch at bug 266907 comment 45, if this (too) does not apply cleanly then please double-check that your copy of the ports tree is up-to-date with the latest branch. It seems like original issue on FreeBSD 13.2 with the patch running 6.1.44 still occurs with Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3). Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap FreeBSD jack.musirc.com 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n255195-b8cca0cdc0c1 JACK amd64 (In reply to Jack from comment #19) > It seems like original issue on FreeBSD 13.2 … To avoid any possible misunderstanding: * the original issue (comment 0) was on FreeBSD 14.0-CURRENT. Observations involving 13.2-STABLE began at comment 9. (In reply to Jack from comment #19) > FreeBSD jack.musirc.com 13.2-STABLE FreeBSD 13.2-STABLE > stable/13-n255195-b8cca0cdc0c1 JACK amd64 uname -KU What are the version numbers in your case? Thanks (In reply to Graham Perrin from comment #20) And what is the output: $ /usr/bin/cc -v Stock 13.2 includes llvm14. John groenveld@acm.org (In reply to Graham Perrin from comment #20) uname -KU 1302505 1302505 Comment 19 was my scenarios as well except the removal of the <GuestProperties> section did not help. (In reply to groenveld from comment #21) /usr/bin/cc -v FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git llvmorg-15.0.7-0-g8dfdcc7b7bf6) Target: x86_64-unknown-freebsd13.2 Thread model: posix InstalledDir: /usr/bin This is the most recent git checkout of 13.2 stable. @Jack: As is, the patch with its ${OSVERSION} >= 1400079 condition is inadequate for 13.2. You probably still compile with the base system clang15.
For 13-stable 1302505 is fine but the value for 13.2-release or for the commit where base llvm was updated to version 15 might be a little lower.
@Graham Perrin: Building on 13-stable, fails with the "/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.44/src/VBox/Devices/PC/ipxe/src/core/settings.c:289:8: error: fields must have a constant size: 'variable length array in structure' extension will never be supported" you mention in earlier comments (with 6.1.36 though).
Any idea why you don't have the issue later on ? The message looks more like a compiler limitation than a difference between 13 and 14 base systems.
(In reply to Philippe Michel from comment #24) Is there an easy way to test in the port Makefile what version /usr/bin/cc? John groenveld@acm.org (In reply to Philippe Michel from comment #24) Current indications are: a) I have build problems only when using poudriere b) the problems might be specific to my use (or misuse) of poudriere. Re: bug 266907 comment 43, I should no longer pollute either of these bug reports with diagnoses. Instead, a few hours ago, I spun off to #poudriere in IRC. For Matrix users who are already in the channel: <https://matrix.to/#/!eCdFflIvvJGwaaEGbq:libera.chat/$kadHgWrbwbEdSg23udE-lOp7MZ9yOt23RRe7pVrDuCk?via=libera.chat&via=matrix.org> (In reply to Graham Perrin from comment #26) Whether the port is configured to be built with the Guest Additions included or not seems to explain this. Apparently the ipxe stuff, where the fancy structs unsupported by clang14 are used, is included only in the former case. Regarding the use of ports compilers, it seems somewhat unlikely that clang16 would accidentaly fix the regression introduced by clang15. Moreover it would be an even more onerous dependency than clang14. On the other hand gcc12 would be free (it is already needed by kBuild that is needed by virtualbox-ose) and is probably already used to build virtualbox by some linux distributions. (In reply to Philippe Michel from comment #27) > Whether the port is configured to be built with the Guest Additions > included or not seems to explain this. … Not in my case. Re: comment 26, I _really_ want to take my peculiar build failures away from this more general bug report. Join me in IRC? Or would you prefer the freebsd-virtualization email list? Thanks (In reply to Graham Perrin from comment #28) > … freebsd-virtualization email list? Better: <https://github.com/freebsd/poudriere/discussions/1049> > emulators/virtualbox-ose build failures in poudriere on > FreeBSD 14.0-CURRENT · freebsd/poudriere · Discussion #1049 (In reply to Philippe Michel from comment #24) Yes, my revision is still using the base system 15.0.7 to compile virtualbox. If I try to use llvm14 from ports, compilation succeeds but I get what comment #7 gets when trying to use virtualbox kernel: kldload: unexpected relocation type 42, symbol index 918 kernel: link_elf_obj: symbol __stack_chk_guard undefined kernel: linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type Created attachment 241915 [details]
virtualbox 6.1.44 building on current
With this patch you can get usable binaries under current.
CAVEAT: this is a "quick'n'dirty" fix, is not good code, does not follows any good practice, do not use in production, is WIP, you can turn your life in a nightmare, it is not tested, objects in mirror are closer than they appear, ecc...
Furthermore does not build with poudriere.
(In reply to pr from comment #31) > … this patch … current. > … does not build with poudriere. Re: <https://github.com/freebsd/poudriere/issues/1050#issuecomment-1530934320>, do you get the same three warning lines? If so, please join me there. (In reply to pr from comment #31) This patch works for me on 13.2-STABLE after making it so 13.2 uses llvm14. As for comment #32, you'll need to install llvm14 first. Created attachment 241924 [details] poudriere friendly patch that uses clang14 (In reply to Graham Perrin from comment #32) From my understanding, setting CC and CXX in Makefile should not be the way to go. It's ok just for testing. I'd relay on USES, please check the attached patchset which, BTW, works with poudriere. This might also close your github conversation, please check. If someone can confirm usability on 13.x I would also remove the check on OSVERSION. TODO: improve the stability for patches of settings.c and httpcore.c (In reply to Jack from comment #33) > … you'll need to install llvm14 first. Already done; there was the BUILD_DEPENDS+= line under <https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241866&action=diff#b/emulators/virtualbox-ose/Makefile_sec2>. (In reply to pr from comment #34) Thanks, I'll try this. (In reply to pr from comment #34) Confirmed: build succeeds in poudriere on 14.0-CURRENT. Whilst work continues on the additional patch files, can you add to bug 266907 a patch that focuses on updates alone? The urgency there is that versions prior to 6.1.44 have security vulnerabilities. Thanks (In reply to pr from comment #34) > … If someone can confirm usability on 13.x Usability of anything in particular? I have 13.2-RELEASE on an old notebook, however it's so old that (if I recall correctly) whilst the manager application can run, guests can not (VT-x is not available). I have a FreeBSD-provided .vhd of 13.2-STABLE 1302505 in a guest on my everyday computer, however I can't recall whether it's possible to run a VM in a VM. (In reply to pr from comment #34) Glancing at the Porter's Handbook this *might* be preferred conditional to force LLVM14 on 13.2-STABLE and 14.0-CURRENT: .if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1302505 BUILD_DEPENDS+= clang14:devel/llvm14 USES+= llvm:max=14,build .endif .if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400079 BUILD_DEPENDS+= clang14:devel/llvm14 USES+= llvm:max=14,build .endif I yield to more experienced porters here. John groenveld@acm.org (In reply to groenveld from comment #38) I could not get the make to respect my preferred LLVM without this though I have no setting make.conf(5) Here's an update conditional that does work on 14.0-CURRENT and 13.2-RELEASE: # hack for Bug 270189 .if ${OPSYS} == FreeBSD && ${OSREL} == 13.2 && ${OSVERSION} >= 1302505 BUILD_DEPENDS+= clang14:devel/llvm14 USES+= llvm:max=14,build CC= clang14 CXX= clang++14 .endif .if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400079 BUILD_DEPENDS+= clang14:devel/llvm14 USES+= llvm:max=14,build CC= clang14 CXX= clang++14 .endif Handbook says make should respect CC?= and CXX?= but it didn't for me. John groenveld@acm.org Created attachment 242010 [details] poudriere friendly patch that uses clang14 (improved but still WIP) Ok, here's a patchset that builds and creates usable binaries in both 13.2 and current. Upstream uses Variable Length Arrays (VLA) in structs which is not supported by clang https://stackoverflow.com/questions/12058760/undocumented-gcc-extension-vla-in-struct So I made a quick'n'dirty fix by coercing VLA members to a fixed size. This is ok for testing but exposes the code to failures and overflow attacks as there are no boundary checks. Upstream seems to stick to gcc, so if we decide to use clang we do it at our own risk. Alternatives (better to worse): 1) compile virtualbox with gcc. 2) ask upstream not to use VLA, if anyone has hooks please take action. 3a) make a reliable patchset by adding the appropriate checks on the fixed sizes fields, or 3b) by making them dynamic. 1) this is not a bad idea, especially because it would protect us from any future incompatibilities between gcc and clang. Furthermore gcc12 is already an indirect dependency of virtualbox, so we can also speed compile time up in those scenarios that do not need clang from ports. Furthermore, sooner or later, clang 14 will be obsoleted, so we will have to find a solution when this will happen, if we stick to clang. 2) seems reasonable but I have no idea how upstream will react. If 2) is not viable, 3x) represents a long-term solution but will require monkey-patching to catch up with upstream every time they pull out a new version (a too common activity in the FreeBSD community). They are already at 7.0.8 and we are stuck at 6.1.36 -> 6.1.44. What do you think? (In reply to groenveld from comment #38) (In reply to groenveld from comment #39) My patchset uses USES which works ok: USES+= llvm:min=11,max=14 basically this line allows to remove the check on the OSVERSION because will use the latest available llvm from ports, just ensuring that it is higher than 10 (causing issues before 1300109) and lower than 15 (causing issues now). FYI: there is no need to add an explicit BUILD_DEPENDS because USES takes care of this. Also there is no need to specify that this is a build depend, because this is the default. At the same time I respect the previous check on the compiler later on in the Makefile. Actually there were two such checks I merged into one to keep things clearer. Created attachment 242011 [details]
Fixes previous patch
Sorry, cannot merge the checks on OSVERSION, had to undo the last step. Use this patch instead.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266907#c62 So: is it fails to run on FreeBSD 14 even with llvm14? (In reply to Vladimir Druzenko from comment #42) It runs on CURRENT when built with llvm14. $ VBoxManage --version 6.1.44r156814 $ uname -srvKU FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n262885-b6d3a9644d5c: Thu May 11 08:19:58 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 1400088 1400088 John groenveld@acm.org (In reply to groenveld from comment #43) Can you please check this "patch" for Makefile: .if ${CHOSEN_COMPILER_TYPE} == clang # 1) llvm10 in FreeBSD before r364284 miscompiles virtualbox 6.1 causing errors. # 2) llvm15 in FreeBSD miscompiles virtualbox 6.1 causing errors: # https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270189 # force llvm14 from ports .if (${OSVERSION} < 1203502 || ${OSVERSION} >= 1300000 && ${OSVERSION} < 1300109 \ ${OSVERSION} >= 1302505 && ${OSVERSION} < 1400000 || ${OSVERSION} >= 1400079) \ && ${OPSYS} == FreeBSD .if ${LLVM_DEFAULT} < 11 || ${LLVM_DEFAULT} > 14 VBOX_LLVM_VER?= 14 .else VBOX_LLVM_VER?= ${LLVM_DEFAULT} .endif USES+= llvm:${VBOX_LLVM_VER},build CC= clang${VBOX_LLVM_VER} CXX= clang++${VBOX_LLVM_VER} .endif PATCH_DEPENDS+= ${LOCALBASE}/share/kBuild/tools/GXX3.kmk:devel/kBuild EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk .endif Created attachment 242215 [details]
Refactors patch to apply cleanly against the latest commit
This is a refactored patch which will apply cleanly against the latest commit.
(In reply to Cy Schubert from comment #45) Why we need llvm14 from ports for 13.1, 13.2 and 12.4? (In reply to Vladimir Druzenko from comment #46) I don't know. I just refactored but haven't tested it with or without. I can test without but I do have a lot of other more important FreeBSD work on my plate (Heimdal in base upgrade). And not only does it take my time it also takes my machine resources I'm using to debug the Heimdal upgrade regressions. (In reply to Cy Schubert from comment #47) If somebody can test on 14 (on 12.3, 12.4, 13.0 and 13.1 too, but not so important) then I can create patch using all information from this PR (I don't have a host with 14). (In reply to Cy Schubert from comment #47) Worked on 14.0-CURRENT. I don't have 13.2-STABLE where the stock LLVM is now also 15. John groenveld@acm.org (In reply to groenveld from comment #49) I'm building it on one of my 14-CURRENT machines in a 14-CURRENT jail normally used for Heimdal 1.5.2 --> 7.8.0 upgrade testing. Just built on 14.0-CURRENT #12 main-n262908-c16e08e5f324-dirty: Thu May 11 17:01:29 PDT 2023 Still has the original problem at the opening pf this ticket: The window for the VM opens for about a second and then dies with the "Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3)." message. I can still build and run fine with the very first patch to VB, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270189#c18, now marked as obsolete. (In reply to rkoberman from comment #51) The refactored patch works here. cwsys# pkg info virtualbox-ose-kmod virtualbox-ose virtualbox-ose-kmod-6.1.44 virtualbox-ose-6.1.44_1 cwsys# kldload vboxnetadp cwsys# uname -a FreeBSD cwsys 14.0-CURRENT FreeBSD 14.0-CURRENT #116 komquats-n262977-f409f11bc556: Mon May 15 14:06:57 PDT 2023 root@cwsys:/export/obj/opt/src/git-src/amd64.amd64/sys/BREAK amd64 cwsys# (In reply to rkoberman from comment #51) This one: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240856&action=diff ? (In reply to Cy Schubert from comment #52) Why we need patches: EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c ? Port build without errors on 13.2 with llvm14 from base. Are patches required only for build with llvm15? Who can test virtualbox-ose-kmod-legacy and virtualbox-ose-legacy on 14? And what about virtualbox-ose-additions and virtualbox-ose-additions-legacy on 14 - do they fail if build with llvm15 too? (In reply to Vladimir Druzenko from comment #54) Looking at the patches, I doubt it. Instead of doing compile time math to calculated the size of affected arrays, the patches are setting them to fixed sizes. The author of the patch, pr@aoek.com, likely brought in upstream patches that fix some kind of problems. (Remember, I only refactored the patch to still apply after the last commit.) Also remember PR/266907, which also updated vbox to 6.1.44, broke 14-CURRENT. The refactoring of pr@aoek.com's patch allowed it to apply to the updated vbox. You could apply pr@aoek.com's patch instead by git revert the commit that updated the patch, apply pr@aoek.com's patch, commit it, and finally squash the two commits (using git rebase) thereby creating a brand new patch. This is what I did, in a private branch of course. Should the vbox team approve this patch I would simply merge the vbox branch into main (after rebasing it with main) and pushing it. (In reply to Cy Schubert from comment #56) > Also remember PR/266907, which also updated vbox to 6.1.44, broke 14-CURRENT It was already broken, even before the .44 update. The breakage happened due to some changes in base/kernel. (In reply to Gleb Popov from comment #57) Well, actually: I run very recent -CURRENT, updating frequently to verify any changes to the kernel don't affect software I maintain in base. I have never had any breakage due to kernel changes that were not fixed by a simple rebuild of the virtualbox-ose-kmod sources. Reports of brokenness under 14-CURRENT are exaggerated because no one thinks of simply rebuilding the sources. Maybe virtualbox-ose PORTREVISION bump to force a rebuild when kernel sources change affecting the ABI. Add me to the vbox team and I can periodically bump PORTREVISION when needed. The posted patch, refactored by yours truly to apply on top of the latest virtualbox-ose commit, fixes the 14-CURRENT runtime issue caused by PR/266907. (In reply to Cy Schubert from comment #58) Can you confirm that 6.1.36 build and work fine on latest 14 without any changes in ports? (In reply to Vladimir Druzenko from comment #59) Yes, 6.1.36 worked on the latest 14-CURRENT just prior to upgrading it to 6.1.44. I use it to test ipfilter in a VM. When virtualbox-ose did panic the kernel I simply rebuilt the kmod. It was good as new then. (In reply to Cy Schubert from comment #60) I ask other question. Did you rebuild 6.1.36 on recent 14-CURRENT - both emulators/virtualbox-ose and emulators/virtualbox-ose-kmod without changes in ports and it build and work without errors? (In reply to Vladimir Druzenko from comment #61) Yes. (In reply to Cy Schubert from comment #58) > Reports of brokenness under 14-CURRENT are exaggerated because no one thinks of simply rebuilding the sources. We're all developers and ports committers here, so this is the first obvious thing that comes to mind. I build packages for myself in Poudriere and always rebuild everything form scratch after a world/kernel upgrade. I also do `pkg install -f` for every kmod I have installed to make sure they are updated even if the package version didn't change. But like I said, .36 didn't work for me with the same symptoms as .44. (In reply to Gleb Popov from comment #63) This is why I suggested bumping PORTREVISION following a kernel upgrade that broke that caused a panic, to force a package build. On the flip side, there are no 14-CURRENT package builders. Binary packages built for 13.2, regardless of the package, may not work with 14. I don't know why virtualbox-ose 6.1.36 didn't work for you on 14-CURRENT while it did work for me on 14-CURRENT. And, the patch in this PR allows it to continue to work for me following the 6.1.44 upgrade on 14-CURRENT. slippy$ uname -a FreeBSD slippy 14.0-CURRENT FreeBSD 14.0-CURRENT #119 komquats-n262999-bdd47177528b: Wed May 17 06:42:34 PDT 2023 root@cwsys:/export/obj/opt/src/git-src/amd64.amd64/sys/BREAK amd64 slippy$ (In reply to Cy Schubert from comment #64) Can you do it just now? I see several messages about "it doesn't work" even for 6.1.36. P.S. Patch with use llvm14 is in progress and testing. Probably be ready in few days - test builds are very long. (In reply to Cy Schubert from comment #64) (In reply to rkoberman from comment #14) > The VM loads, but seems to take a long time to do so... almost 4 minutes.' What are the hardware differences in the machines? (In reply to Vladimir Druzenko from comment #65) As is my build (in a jail on my sandbox machine). I removed the llvm max:14 to test building on llvm15. Unfortunately, it doesn't use llvm in 14-CURRENT. It's building devel/llvm15. Better than llvm14 but suboptimal. (In reply to Alex Bylund from comment #66) It currently works on an Acer Laptop with Intel and on my AMD hardware in the basement. When running on the AMD hardware in the basement, DISPLAY is set to the laptop's Xserver. The VMs are bridged to both my LANs in the basement, appearing as hosts on the network, allowing me to test ipfilter (currently ftp proxy through the DMZ through forwarded NAT to another VM inside the network). (In reply to Vladimir Druzenko from comment #53) Found a significant problem... for some reason that I am baffled by, the patching failed. I have now successfully applied the patch and virtualbox is working correctly on 14. Sorry for the report. (In reply to rkoberman from comment #69) Let me know if anyone, again, has trouble applying the patch. I will refactor again. The process I used was, git pull --rebase git switch -c newbranch git revert THE_VBOX_6.1.44_COMMIT git apply < THE_PREVIOUS_PATCH_IN_THIS_PR fix any conflicts and commit git rebase -i HEAD~2 -- This is to squash the revert and application of the patch into a single update patch. git format-patch -1 -- I posted the output of this to this PR. (In reply to Gleb Popov from comment #63) Just for the record, the error first appeared for me after updating of multiple ports after the update to math/mpc. I updated 54 ports that day, most (all?) as a result of the mpc update. During that time, I was running a kernel built on March 5, so there was no kernel rebuild involved, so it seems VERY unlikely that a kernel update triggered this issue. (In reply to Cy Schubert from comment #70) I am baffled as to why this patch failed to work, but I believe I did something wrong that should be obvious, but I can't see it. I downloaded the refactored patch and: # cd /usr/ports # patch < ~oberman/virtualbox-ose.diff Patch asked for the file to patch for all patches other than virtulbox-ose/Makefile and the two extrapatches. I entered the file name, though I didn't understand why that was needed. It then failed to apply all 4 patches to Makefile and places the two extrafiles in /usr/ports. I found the Makefile.rej files in /usr/ports. After a lot of attempts, the patch installed correctly with: # cd /usr/ports/emulators # patch -p2 < ~oberman/virtualbox-ose.diff At this point, the patch was successful and, after building the patched port, everything worked. I would suggest using 'git diff' to generate patches, but I fail to see why I had problems with the patch applying correctly or see anything wrong with the diff file as downloaded. (In reply to Cy Schubert from comment #70) Applies cleanly here: # uname -srvKU FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n262885-b6d3a9644d5c: Thu May 11 08:19:58 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 1400088 1400088 # (cd /usr/src && git pull && git checkout b6d3a9644d5c) # cd /usr/ports && git clean -f && git reset --hard && git pull && git status HEAD is now at 38f54301414a textproc/jade: fix build with clang 16 Already up to date. On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean # patch < /root/schubert.diff # cd /usr/ports/emulators/virtualbox-ose && make package Thank you! John groenveld@acm.org (In reply to Cy Schubert from comment #58) > … Reports of brokenness under 14-CURRENT are exaggerated because > no one thinks of simply rebuilding the sources. … Build from source was my first thought with/before comment 0. (In reply to Alex Bylund from comment #66) > (In reply to Cy Schubert from comment #64) > (In reply to rkoberman from comment #14) > >> The VM loads, but seems to take a long time to do so... almost 4 minutes.' > > What are the hardware differences in the machines? Ignoring (for a moment) any hardware difference, please note this (from comment 14): >> … delete the GuestProperties section … (In reply to Graham Perrin from comment #75) Thanks, my main thought was different hardware support/configuration. I will be testing guest-additions on an amd64 14-CURRENT VM running on an amd64 14-CURRENT host later this weekend. (In reply to Graham Perrin from comment #75) Did that and it almost worked. The instant crashes stopped and I was able to start both Windows and Linux VMs. Then things got weird. Windows crashed after a while. After a couple of reboots Windows required a "system repair". Linux was worse in that it failed more quickly after each reboot. After three reboot, it crashed before I could even log in. I was forced to rebuild that VM from scratch. Fortunately, the virtual disc was still mountable on the new VM, so I lost nothing but time. In any case, I deleted the port (6.1.36), installed the proposed patch to run .44 from Comment #18 and ran with that until I was able to get patch , now committed, which is working fine for me. Looks to me that GuestServices was a red herring that hid the problem but led to a worse situation. (In reply to Gleb Popov from comment #57) Are the different versions known, or how to find? When/where the break happened. I'm thinking specifically new hardware. /usr/src/sys/# git log (In reply to Cy Schubert from comment #77) I created bug #271515 to track the virtualbox-ose-additions crash on 14.0-CURRENT. John groenveld@acm.org I'm unable to find out, but these commits are suspicious, 15cebe3d637f70abd1ee95e2745d6676d9b1e7dd 5d805962ca9347bbf62750452c4c980decb94793 47d61162396bac8a7320a6768f218b192dd19ee1 1d9e8a9e60953b148a036b39d1fe7037fdbb40a3 Which are part of bhyve and NVMe Nov 28 2022. From 12.3 to 13.0 a change somewhere in NVMe was made. Created attachment 242284 [details] Screenshot of the error dialogue (In reply to Graham Perrin from comment #74) Confirming that virtualbox-ose-6.1.44 and virtualbox-ose-kmod-6.1.44 built from source – _without_ patching for this bug 270189 – _are_ bugged as described in the summary line. % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #40 main-n262942-e0e24ae5d658-dirty: Sat May 13 23:51:09 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400088 1400088 % poudriere jail -i -j main Jail name: main Jail version: 14.0-CURRENT 1400088 Jail arch: amd64 Jail method: src=/usr/src Jail mount: /usr/local/poudriere/jails/main Jail fs: august/poudriere/jails/main Jail updated: 2023-05-14 01:26:26 Jail pkgbase: disabled % (Jail updated from source.) (In reply to Alex Bylund from comment #81) Suspicious with regard to this bug 270189 (not involving guest additions, or with regard to bug 271515 (for guest additions)? Comment on attachment 242215 [details]
Refactors patch to apply cleanly against the latest commit
Good.
With this patch, a Windows 10 guest ran fine for a few hours (until I closed and saved).
Comment on attachment 242011 [details]
Fixes previous patch
Is this patch obsolete?
(In reply to Graham Perrin from comment #85) I used to get this error on amd64 14-CURRENT without the patch. The patch posted by pr@aoek.com (refactored by me to apply on top of the 6.1.44 commit) fixes VMMDEV problem for me (on 14-CURRENT). Graham, are you running 14-CURRENT? uname -a please. (In reply to Cy Schubert from comment #86) > Graham, are you running 14-CURRENT? Yes, please see comment 0 (1400082 when I opened this report), comment 16, comment 20, comment 36, comment 82 (1400088). > uname -a please. Comments 0 and 82. José Pérez, quoted in comment 0, mentioned 1400079, but not full output from uname -a. Please, check patch here: https://reviews.freebsd.org/D40254 I don't have 14 for testing. Build emulators/virtualbox-ose-kmod without additional patches and emulators/virtualbox-ose with patch from review. On 12.4, 13.1 and 13.2 build same as without this patch. Build fine with llvm from base on 12.4 (llvm13), 13.1 (llvm13), 13.2 (llvm14), and with llvm15 on all 3 releases and WITHOUT patches:
EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c
EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c
How to reproduce build error that needs these patches?
(In reply to Vladimir Druzenko from comment #89) Build it on a CURRENT system. The extrapatches to nothing on any release system, but are required on the upcoming 14.0. (In reply to rkoberman from comment #90) With what llvm? 15 from base? 14 from ports? llvm15 from ports build without errors on any release. AFAIK, arrowd@ build on 14 with llvm14 from ports without patches and without errors. (In reply to Vladimir Druzenko from comment #91) The fix for 14.0 is NOT the same as the fix for 12 and 13. Current (14.0) builds with no errors, but will not run without the extrapatches. While I'm unsure whether LLVM14 is required for 14.0, it is always used. From the Makefile: -# llvm10 in FreeBSD before r364284 miscompiles virtualbox 6.1 causing errors. -# force llvm11 from ports -.if ${OPSYS} == FreeBSD && ${OSVERSION} < 1300109 -BUILD_DEPENDS+= clang${VBOX_LLVM_VER}:devel/llvm${VBOX_LLVM_VER} -CC= clang${VBOX_LLVM_VER} -CXX= clang++${VBOX_LLVM_VER} -VBOX_LLVM_VER?= 11 -.endif +CONFIGURE_ARGS+= --with-gcc="clang${LLVM_VERSION}" --with-g++="clang++${LLVM_VERSION}" PATCH_DEPENDS+= ${LOCALBASE}/share/kBuild/tools/GXX3.kmk:devel/kBuild EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk +EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c +EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c +.else +CONFIGURE_ARGS+= --with-gcc="${CC}" --with-g++="${CXX}" .endif (In reply to rkoberman from comment #92) Oops. Several diff lines folded due to bad cut n paste. Here are, I hope, the unwrapped lines CONFIGURE_ARGS+= --with-gcc="clang${LLVM_VERSION}" --with g++="clang++${LLVM_VERSION}" PATCH_DEPENDS+= ${LOCALBASE}/share/kBuild/tools/GXX3.kmk:devel/kBuild EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c .else CONFIGURE_ARGS+= --with-gcc="${CC}" --with-g++="${CXX}" (In reply to rkoberman from comment #92) > Current (14.0) builds with no errors, but will not run without the extrapatches. I read all comments here, but see this statement 1st time. > While I'm unsure whether LLVM14 is required for 14.0, it is always used. From the Makefile: Default LLVM in ports is 15 now. Something wrong is with your patch - 2 times: "+CONFIGURE_ARGS+=". And without USES+=llvm ${LLVM_VERSION} is undefined. So with your patch on 14 the port will be compiled with llvm15 from base. (In reply to Vladimir Druzenko from comment #94) Mst important, it is NOT my patch. It was posted by groenveld and refactored by Cy. have not played with the port for a few days and I suspect that your mempcpy likely fixed the issue with all versions except 14 (and, maybe, 13-stable). If I get a little time, I'll try on 14-CURRENT from May 11 and see hw it goes. (In reply to Graham Perrin from comment #85) > Is this patch obsolete? Since <https://reviews.freebsd.org/D40254> is open for review, I think it will make sense to obsolete the two prior patches here. Comment on attachment 242011 [details] Fixes previous patch Instead: <https://reviews.freebsd.org/D40254>. Comment on attachment 242215 [details] Refactors patch to apply cleanly against the latest commit Instead: <https://reviews.freebsd.org/D40254>. Just tested the current virtualbox-ose on 14.0 and and it fails, though in a different way. VM stats up but, aftr a few minutes, it aborted. This is what I was seeing on an earlier patch before the EXTRAPATCH files were added. It seems to fail more quickly every boot. My Linux VM got to the point that it crashed before allowing a login. I had to reinstall. My Windows VM did a system recovery and is still working. With the latest commit with D40245, VB is running well. I have been using my Windows VM for over 2 hours with no issues. (In reply to rkoberman from comment #99) Build with llvm15 from base and without 2 new EXTRAPATCHES? What if build with: 1. llvm15 from base and with 2 new EXTRAPATCHES? 2. llvm14 from ports and without 2 new EXTRAPATCHES? Build with llvm15 and 2 new EXTRAPATCHES builds and runs well. Build with llvm14 from ports without new EXTRAPATCHES builds but dies unpleasantly after a short time Both cases built on ammd64 Alder Lake system on main-n262908-c16e08e5f324. (In reply to rkoberman from comment #102) Thanks a lot! To rule out environmental problems, who else can perform the same check and confirm rkoberman's result? (In reply to rkoberman from comment #102) > … main-n262908-c16e08e5f324. Was that 1400088 or 1400089 at the time of the commit (2023-05-11)? <https://docs.freebsd.org/en/books/porters-handbook/versions/#versions-14> currently stops at 1400086. (In reply to Vladimir Druzenko from comment #103) virtualbox-ose and virtualbox-ose-kmod patched with <https://reviews.freebsd.org/D40254?id=122409> (2023-05-25) and built on n262942-e0e24ae5d658 have been trouble-free for me with: * GENERIC-NODEBUG e0e24ae5d658 (2023-05-13, 1400088) * GENERIC c2c9ac88c2bb (2023-05-26, 1400089) % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n263189-c2c9ac88c2bb-dirty: Sat May 27 01:04:23 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400089 1400089 % (In reply to rkoberman from comment #102) (In reply to Graham Perrin from comment #105) So you got different results… Waiting results from other CLEAN experiments. (In reply to Vladimir Druzenko from comment #106) Worked here: $ VBoxManage --version 6.1.44r156814 $ uname -srvKU FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n263139-baef3a5b585f: Thu May 25 08:14:14 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 1400088 1400088 $ pkg info virtualbox-ose virtualbox-ose-6.1.44_1 Name : virtualbox-ose Version : 6.1.44_1 Installed on : Tue May 30 10:34:21 2023 EDT Origin : emulators/virtualbox-ose Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : emulators Licenses : GPLv2 Maintainer : vbox@FreeBSD.org WWW : https://www.virtualbox.org/ Comment : General-purpose full virtualizer for x86 hardware Options : AIO : on ALSA : off DBUS : on DEBUG : off DOCS : on GUESTADDITIONS : off NLS : on OPUS : off PYTHON : off QT5 : on R0LOGGING : off UDPTUNNEL : on VDE : off VNC : on VPX : off WEBSERVICE : on X11 : on Shared Libs required: libxml2.so.2 libxcb.so.1 libvncserver.so.1 libpng16.so.16 libcurl.so.4 libXt.so.6 libXext.so.6 libXcursor.so.1 libX11.so.6 libSDL-1.2.so.0 libQt5X11Extras.so.5 libQt5Widgets.so.5 libQt5PrintSupport.so.5 libQt5OpenGL.so.5 libQt5Gui.so.5 libQt5Core.so.5 libGL.so.1 Annotations : FreeBSD_version: 1400088 cpe : cpe:2.3:a:oracle:vm_virtualbox:6.1.44:::::freebsd14:x64:1 Flat size : 169MiB Description : Oracle VM VirtualBox is a hosted hypervisor for x86 virtualisation. Supported guests include BSD, Haiku, Linux, OS/2, ReactOS, Solaris and Windows. Guest Additions are available from: emulators/virtualbox-ose-additions For the Extension Pack: FreeBSD is not a supported host platform. Installation of the Pack will not extend the feature set. WWW: https://www.virtualbox.org/ John groenveld@acm.org No problems here on a recent 14-CURRENT. (In reply to groenveld from comment #107) What patched did you apply and what LLVM did you use for build VB? (In reply to Cy Schubert from comment #108) Without any patches and with llvm from base? (In reply to Vladimir Druzenko from comment #110) Yes, unpatched LLVM from base. I used the emulators/virtualbox-ose patch from https://reviews.freebsd.org/D40254. (In reply to Vladimir Druzenko from comment #109) I applied the patch from D40254. $ fetch -o D40254.diff "https://reviews.freebsd.org/D40254?download=true" # (cd /usr/ports/ && git reset --hard && git pull) # (cd /usr/ports && patch < D40254.diff) John groenveld@acm.org (In reply to Cy Schubert from comment #111) Patch at https://reviews.freebsd.org/D40254 force use llvm14 from ports on recent 14-CURRENT (${OSVERSION} >= 1400079). (In reply to Vladimir Druzenko from comment #113) I built mine using a local poudriere. I already have llvm14 installed for other reasons as well. I didn't look any further than simply testing it with a VM. (In reply to groenveld from comment #112) llvm14 from ports without EXTRAPATCHES from previous version of the patch. Can you test with llvm15 from base and with EXTRPATCHES? This patch: https://reviews.freebsd.org/D40254?id=122357 with commented out lines in Makefile: BUILD_DEPENDS+= clang${VBOX_LLVM_VER}:devel/llvm${VBOX_LLVM_VER} CC= clang${VBOX_LLVM_VER} CXX= clang++${VBOX_LLVM_VER} Thanks. (In reply to Vladimir Druzenko from comment #113) I confirmed using dtruss that the patch correctly invokes LLVM14 from ports. John groenveld@acm.org (In reply to Vladimir Druzenko from comment #115) root@mowa219-gjp4-8570p-freebsd:~ # poudriere ports -u [00:00:00] Updating portstree "default" with git+https... done root@mowa219-gjp4-8570p-freebsd:~ # nano /tmp/D40254.id122357.diff root@mowa219-gjp4-8570p-freebsd:~ # git -C /usr/local/poudriere/ports/default apply -v /tmp/D40254.id122357.diff /tmp/D40254.id122357.diff:47: space before tab in indent. const char *name ) { /tmp/D40254.id122357.diff:48: space before tab in indent. struct { /tmp/D40254.id122357.diff:49: space before tab in indent. struct autovivified_settings autovivified; /tmp/D40254.id122357.diff:52: space before tab in indent. } *new_child; /tmp/D40254.id122357.diff:53: space before tab in indent. struct settings *settings; Checking patch emulators/virtualbox-ose/Makefile... error: while searching for: .endif .if ${CHOSEN_COMPILER_TYPE} == clang # llvm10 in FreeBSD before r364284 miscompiles virtualbox 6.1 causing errors. # force llvm11 from ports .if ${OPSYS} == FreeBSD && \ (${OSVERSION} < 1203502 || ${OSVERSION} >= 1300000 && ${OSVERSION} < 1300109) #BUILD_DEPENDS+= clang${VBOX_LLVM_VER}:devel/llvm${VBOX_LLVM_VER} #CC= clang${VBOX_LLVM_VER} #CXX= clang++${VBOX_LLVM_VER} VBOX_LLVM_VER?= 11 .endif PATCH_DEPENDS+= ${LOCALBASE}/share/kBuild/tools/GXX3.kmk:devel/kBuild EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk .endif .if ${PYTHON_MAJOR_VER} >= 3 error: patch failed: emulators/virtualbox-ose/Makefile:217 error: emulators/virtualbox-ose/Makefile: patch does not apply Checking patch emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c... error: emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c: already exists in working directory Checking patch emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c... error: emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c: already exists in working directory root@mowa219-gjp4-8570p-freebsd:~ # (In reply to Graham Perrin from comment #117) I think the patch doesn't take into account the last couple of commits to the port. … so, my test feedback at comment 105 was inadvertently based on patching including remnants, from a previous test, of the two extra files. Sorry. ---- Still, after removing those two remnants, the patch no longer applies: root@mowa219-gjp4-8570p-freebsd:~ # cd /usr/local/poudriere/ports/default/ root@mowa219-gjp4-8570p-freebsd:/usr/local/poudriere/ports/default # rm emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c root@mowa219-gjp4-8570p-freebsd:/usr/local/poudriere/ports/default # rm emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c root@mowa219-gjp4-8570p-freebsd:/usr/local/poudriere/ports/default # cd root@mowa219-gjp4-8570p-freebsd:~ # git -C /usr/local/poudriere/ports/default reset --hard HEAD HEAD is now at fae20865e6 ftp/sftpgo: Fix plist root@mowa219-gjp4-8570p-freebsd:~ # git -C /usr/local/poudriere/ports/default apply -v /tmp/D40254.id122357.diff /tmp/D40254.id122357.diff:47: space before tab in indent. const char *name ) { /tmp/D40254.id122357.diff:48: space before tab in indent. struct { /tmp/D40254.id122357.diff:49: space before tab in indent. struct autovivified_settings autovivified; /tmp/D40254.id122357.diff:52: space before tab in indent. } *new_child; /tmp/D40254.id122357.diff:53: space before tab in indent. struct settings *settings; Checking patch emulators/virtualbox-ose/Makefile... error: while searching for: .endif .if ${CHOSEN_COMPILER_TYPE} == clang # llvm10 in FreeBSD before r364284 miscompiles virtualbox 6.1 causing errors. # force llvm11 from ports .if ${OPSYS} == FreeBSD && \ (${OSVERSION} < 1203502 || ${OSVERSION} >= 1300000 && ${OSVERSION} < 1300109) #BUILD_DEPENDS+= clang${VBOX_LLVM_VER}:devel/llvm${VBOX_LLVM_VER} #CC= clang${VBOX_LLVM_VER} #CXX= clang++${VBOX_LLVM_VER} VBOX_LLVM_VER?= 11 .endif PATCH_DEPENDS+= ${LOCALBASE}/share/kBuild/tools/GXX3.kmk:devel/kBuild EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk .endif .if ${PYTHON_MAJOR_VER} >= 3 error: patch failed: emulators/virtualbox-ose/Makefile:217 error: emulators/virtualbox-ose/Makefile: patch does not apply Checking patch emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c... Checking patch emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c... root@mowa219-gjp4-8570p-freebsd:~ # cd /usr/local/poudriere/ports/default/ root@mowa219-gjp4-8570p-freebsd:/usr/local/poudriere/ports/default # rm emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c rm: emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_core_settings.c: No such file or directory root@mowa219-gjp4-8570p-freebsd:/usr/local/poudriere/ports/default # rm emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c rm: emulators/virtualbox-ose/files/extrapatch-src_VBox_Devices_PC_ipxe_src_net_tcp_httpcore.c: No such file or directory root@mowa219-gjp4-8570p-freebsd:/usr/local/poudriere/ports/default # Created attachment 242510 [details]
This should work.
This patch is a local patch applied on top of D40254 (two commits in my local tree) fixing the build.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e6b21a9e3f0a605c06d54737a8ff4d6db82dabe5 commit e6b21a9e3f0a605c06d54737a8ff4d6db82dabe5 Author: Vladimir Druzenko <vvd@FreeBSD.org> AuthorDate: 2023-06-01 14:44:38 +0000 Commit: Vladimir Druzenko <vvd@FreeBSD.org> CommitDate: 2023-06-01 14:53:00 +0000 emulators/virtualbox-ose: on 14 "Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3)" Force llvm from ports from 11 to 14 - by default it'll pick 14. Use VBOX_LLVM_VER in make.conf to define different llvm. PR: 270189 Reviewed by: cy, grahamperrin Tested by: cy, grahamperrin, groenveld@acm.org, rkoberman@gmail.com Approved by: arrowd Differential Revision: https://reviews.freebsd.org/D40254 emulators/virtualbox-ose/Makefile | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) A commit in branch 2023Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a26a1d677383f569c833afc39e0db01d3e7a67ab commit a26a1d677383f569c833afc39e0db01d3e7a67ab Author: Vladimir Druzenko <vvd@FreeBSD.org> AuthorDate: 2023-06-01 14:44:38 +0000 Commit: Vladimir Druzenko <vvd@FreeBSD.org> CommitDate: 2023-06-01 14:57:11 +0000 emulators/virtualbox-ose: on 14 "Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3)" Force llvm from ports from 11 to 14 - by default it'll pick 14. Use VBOX_LLVM_VER in make.conf to define different llvm. PR: 270189 Reviewed by: cy, grahamperrin Tested by: cy, grahamperrin, groenveld@acm.org, rkoberman@gmail.com Approved by: arrowd Differential Revision: https://reviews.freebsd.org/D40254 (cherry picked from commit e6b21a9e3f0a605c06d54737a8ff4d6db82dabe5) emulators/virtualbox-ose/Makefile | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) (In reply to commit-hook from comment #122) Thanks, everyone! vvd@ if you'd like to close this (long) bug report as fixed, please do. I guess, any work towards making good with llvm15 can happen elsewhere. (In reply to Graham Perrin from comment #123) Looking at the vendor commits, it would be safe to say that LLVM16 will be imported into CURRENT RSN. Thanks to all for patches, tests and reports! |
After momentary appearance of a window to the guest, a dialogue appears. Example: ---- Failed to open a session for the virtual machine UBCD. 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} ---- % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #34 main-n261465-22bf2a479f68: Sun Mar 12 05:18:09 GMT 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400082 1400082 % ---- Similarly, from <https://lists.freebsd.org/archives/freebsd-emulation/2023-February/000431.html>: > emulators/virtualbox-ose-kmod does not build and does not work on > 14.0-CURRENT 1400079 > > … > > When I launch any guest I get this error: > > Failed to construct device 'VMMDev' instance #0 (VERR_INTERNAL_ERROR_3). > > …