$ uname -srvKU FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n264135-510fd8313800: Thu Jul 13 08:07:28 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 1400093 1400093 $ VBoxManage --version 6.1.46r158378 $ VBoxManage startvm bar --type gui Waiting for VM "bar" to power on... VBoxManage: error: The virtual machine 'bar' has terminated unexpectedly during startup with exit code 1 (0x1) VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine John groenveld@acm.org
Exact this error was fixed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270189 by force build VB with llvm14 from ports. And I see your posts in PR 270189.
(In reply to Vladimir Druzenko from comment #1) I confirmed that make package is correctly calling clang-14 on current CURRENT. My WAG is that current llvm14 also produces a VirtualBox that produces that error. $ pkg info llvm14 llvm14-14.0.6_1 Name : llvm14 Version : 14.0.6_1 Installed on : Mon Jul 17 11:28:27 2023 EDT Origin : devel/llvm14 Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : lang devel Licenses : REGEX and PD and MIT and LLVM2 and LLVM and BSD3CLAUSE Maintainer : brooks@FreeBSD.org WWW : https://llvm.org/ Comment : LLVM and Clang Options : BE_AMDGPU : on BE_FREEBSD : off BE_NATIVE : off BE_STANDARD : on BE_WASM : on CLANG : on COMPILER_RT : on DOCS : on EXTRAS : on FLANG : on GOLD : on LIT : on LLD : on LLDB : on MLIR : on OPENMP : on PYCLANG : on Shared Libs required: libxml2.so.2 libpython3.9.so.1.0 liblua-5.3.so libedit.so.0 Shared Libs provided: libomptarget.so libomptarget.rtl.amdgpu.so libomp.so libmlir_runner_utils.so.14 libmlir_c_runner_utils.so.14 libmlir_async_runtime.so.14 liblldb.so.14 libclang_rt.ubsan_standalone-x86_64.so libclang_rt.ubsan_standalone-i386.so libclang_rt.ubsan_minimal-x86_64.so libclang_rt.ubsan_minimal-i386.so libclang_rt.tsan-x86_64.so libclang_rt.dyndd-x86_64.so libclang_rt.asan-x86_64.so libclang_rt.asan-i386.so libclang.so.13 libclang-cpp.so.14 libarcher.so libRemarks.so.14 libMLIR.so.14 libLTO.so.14 libLLVM-14.so Annotations : FreeBSD_version: 1400093 cpe : cpe:2.3:a:llvm:llvm:14.0.6:::::freebsd14:x64:1 repo_type : binary repository : FreeBSD Flat size : 1.47GiB Description : The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker), LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure these are built on. WWW: https://llvm.org/ John groenveld@acm.org
There is an error with OpenSSL 3 in base: vboxheadless --startvm fbsd14 VBoxHeadless: Error -610 in supR3HardenedMainInitRuntime! VBoxHeadless: dlopen("/usr/local/lib/virtualbox/VBoxRT.so",) failed: /usr/local/lib/virtualbox/VBoxRT.so: Undefined symbol "ERR_load_ERR_strings"
Rebuilding the port with security/openssl31 workarounds this issue. However, the correct fix would be to provide implementations for these functions in base SSL. Or stub them out in the header.
Before OpenSSLv3, it's just a macro which calls "ossl_err_load_ERR_strings". The macro went away but the function itself is still there. It's referenced in src/VBox/Runtime/common/crypto/iprt-openssl.cpp
(In reply to Gleb Popov from comment #4) Just confirmation that openssl31 does get this working again. All of my active VMs boot properly with 6.1.46. Thanks!
Created attachment 244125 [details] patch to support openssl31 on fbsd14 Built and tested on fbsd14: $ uname -srvKU FreeBSD 14.0-ALPHA1 FreeBSD 14.0-ALPHA1 amd64 1400094 #0 main-n264678-136fc495615f: Fri Aug 11 08:18:04 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 1400094 1400094 John groenveld@acm.org
Doesn't libvncserver (if enabled in conf) need to also be linked to openssl31? If it is linked to the default (base) openssl, my VMs fail to start. This does not impact poudriere builds, only pots builds.
I'm not really sure what's going on in the vbox build, but it has references to ERR_load_ERR_strings in several subdirectories corresponding to different OpenSSL versions: src/libs/openssl-3.0.7/openssl-mangling.h src/libs/openssl-3.0.9/openssl-mangling.h src/libs/openssl-3.1.0/openssl-mangling.h
(In reply to Gleb Popov from comment #4) Can you check if it works with security/openssl30? This is the LTS version and corresponds to what is in the base system. This should help determine if it's a problem with the way we built/imported OpenSSL 3.0, or if it's related to 3.0 vs 3.1.
(In reply to Ed Maste from comment #10) It worked: # git diff diff --git a/emulators/virtualbox-ose/Makefile b/emulators/virtualbox-ose/Makefile index 45eac8c9e2b3..40e8e0922838 100644 --- a/emulators/virtualbox-ose/Makefile +++ b/emulators/virtualbox-ose/Makefile @@ -1,6 +1,6 @@ PORTNAME= virtualbox-ose PORTVERSION= 6.1.46 -PORTREVISION?= 1 +PORTREVISION?= 2 CATEGORIES= emulators MASTER_SITES= https://download.virtualbox.org/virtualbox/${PORTVERSION}/ DISTFILES= VirtualBox-${PORTVERSION}${EXTRACT_SUFX} ${GUESTADDITIONS} @@ -192,6 +192,11 @@ KMK_FLAGS+= -j${MAKE_JOBS_NUMBER} .include <bsd.port.pre.mk> +# FreeBSD on/after 1400092/9ead001d5b42 requires openssl30, see Bug #272580 +.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400092 +BUILD_DEPENDS+= openssl:security/openssl30 +.endif + .if ${OPSYS} == FreeBSD && \ (${OSVERSION} < 1300513 || ${OSVERSION} >= 1400000 && ${OSVERSION} < 1400026) EXTRA_PATCHES+= ${PATCHDIR}/extrapatch-src_VBox_Devices_PC_DevFwCommon.cpp $ VBoxManage --version 6.1.46r158378 $ ldd /usr/local/lib/virtualbox/VBoxManage|grep ssl libssl.so.12 => /usr/local/lib/libssl.so.12 (0x3c7b12b59000) libssl.so.30 => /usr/lib/libssl.so.30 (0x3c7b1792c000) John groenveld@acm.org
> emulators/virtualbox-ose: VMs won't run on 14.0-CURRENT Can anyone suggest a more descriptive summary line? Thanks (In reply to groenveld from comment #0) > $ VBoxManage startvm bar --type gui > Waiting for VM "bar" to power on... > VBoxManage: error: The virtual machine 'bar' has terminated unexpectedly during startup with exit code 1 (0x1) > VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine Here: % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-ALPHA1 FreeBSD 14.0-ALPHA1 amd64 1400094 #3 main-n264811-d1d7a273707a-dirty: Thu Aug 17 03:33:54 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400094 1400094 % VBoxManage --version 6.1.46r158378 % VBoxManage startvm Windows --type gui Waiting for VM "Windows" to power on... VM "Windows" has been successfully started. % d1d7a273707a: <https://github.com/freebsd/freebsd-src/commit/d1d7a273707a> > share/examples/tests: fix comments after $FreeBSD$ removal
(In reply to Ed Maste from comment #10) Yes, it works, and it is indeed an import problem. I wrote about it there, but got no replies: https://lists.freebsd.org/archives/freebsd-current/2023-August/004261.html
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e5e6a865358df439021caee7a0c85c086b4a11be commit e5e6a865358df439021caee7a0c85c086b4a11be Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-08-18 18:28:42 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-08-18 18:56:22 +0000 libcrypto: add err_all_legacy.c to the build It provides the ERR_load_*_strings routines, which are deprecated as of 3.0 but are used by various ports. PR: 272580 Reviewed by: kbowling Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41505 secure/lib/libcrypto/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Gleb Popov from comment #13) Apologies; can you confirm that it works after base e5e6a865358d?
(In reply to Ed Maste from comment #15) Just updated to main-n264565 and rebuilt virualbox with no ports openssl installed. Works normally and my Win10 VM runs normally. Glad to get openssl31 out of there! Thanks!
Thanks everyone for the details on this issue, and apologies for the src-induced breakage.