VBoxManage: error: Failed to initialize COM! NS_ERROR_FILE_TARGET_DOES_NOT_EXIST (0x80520006)

What an error! And the VirtualBox stopped loading anymore! This error:

myuser@srv ~ $ VBoxManage list vms
VBoxManage: error: Failed to initialize COM! (hrc=NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)

and here with the GIU, which offers a little bit more information about the error ID:
This error occurs despite the successfully loaded VirtualBox kernel modules!

main menu
VBoxManage: error: Failed to initialize COM! NS_ERROR_FILE_TARGET_DOES_NOT_EXIST (0x80520006)

The two errors are the same and hint there is a file missing (or files?)? In our case, after upgrading from virtualbox-bin (a binary package) to a virtualbox (a package, which actually builds the VirtualBox on the system) under Gentoo, but apparently, this error could occur to everyone, who tries to build yourself the VirtualBox bundle.

The solution is simple: just DO NOT CHANGE the installation path of the Virtualbox software, which by default is /opt/VirtualBox.

The path is hardcoded in the sources and cannot be changed! At present version 6.1.16, we could not find a build option to change it! Of course, the linking /opt/VirtualBox would do the trick to move the installation physically away from the /opt, but the path must be valid /opt/VirtualBox.

In Gentoo, the emerge default installation goes to “/usr/lib64/virtualbox“, so the maintainer of the package changed the path and Virtualbox stopped working! Or a user build it and install it in any other location should link the /opt/VirtualBox to the installation directory. For example, in Gentoo, the fix will be:

root@srv ~ $ ln -s /usr/lib64/virtualbox /opt/VirtualBox
root@srv ~ $ exit
myuser@srv ~ $ VBoxManage list vms
"gentoo_raw" {55346caf-04db-4d88-831a-111111111111}
"diskless" {44346caf-c952-5555-b8a3-111111111111}
"diskless-linux" {44346caf-424f-487f-ae8d-111111111111}
"centos7-netinstall" {44346caf-4e86-441b-8d1e-111111111111}

A simple link would bring back Virtualbox to live.

Bonus

Probably, there is a configuration file “xpti.dat” in two or more locations: ~/.config/VirtualBox/xpti.dat and ~/.VirtualBox/xpti.dat, which is generated on every start of a VirtualBox. In the file there are configuration lines like:
Keep on reading!

Gentoo kde-frameworks/kdewebkit failed compilation with Qt5WebKit could not be found because dependency is required

Updating the KDE Plasma Desktop in our Gentoo workstations this time failed with

CMake Error at /usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:48 (find_package):
  Found package configuration file:

    /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfig.cmake

  but it set Qt5WebKit_FOUND to FALSE so package "Qt5WebKit" is considered to
  be NOT FOUND.  Reason given by package:

  Qt5WebKit could not be found because dependency is required to have exact
  version 5.11.x.

It was strange because the previous emerge included the QT upgrade from old 5.11.2 to 5.12.1 and this dependency should have been resolved properly before:

emerge -vau $(qlist -IC|grep dev-qt|sort|uniq)

But apparently despite that the emerge built all QT libraries in dependency order the “dev-qt/qtwebkit” was built against the old QT libraries. And this is what is saying the above error!

The solution is really simple just rebuild the dev-qt/qtwebkit

root@srv ~ # emerge -va dev-qt/qtwebkit

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-qt/qtwebkit-5.212.0_pre20180120:5/5.212::gentoo  USE="X geolocation hyphen jit multimedia opengl printsupport qml -gles2 -gstreamer -nsplugin 
-orientation -webp" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] yes

Keep on reading!

PHP module compilation error – libtool: Version mismatch error

If you happen to get this error trying to build your own a PHP module (probably, because you need a newer version than the included one in the disto you use and because it is fairly easy):

libtool: Version mismatch error.  This is libtool 2.4.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
libtool: and run autoconf again.
make: *** [Makefile:181: geoip.lo] Error 63

Here is what you can do to recreate the configuration files for the build process:

phpize
aclocal
libtoolize --force
autoheader
autoconf
./configure
make

This sequence of commands (probably without the phpize, because it is PHP specific) could save you in similar situations with similar error in other source code not related to PHP.
Keep on reading!

Compilation failure with Value too large for defined data type in Gentoo

It has happened several times for the last 10 years, a program to fail during the configure stage with a strange error:

checking whether we are cross compiling...  * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/libsandbox.c:check_syscall():968: failure (Value too large for defined data type):
 * ISE: fopen_wr(conftest.out)
        abs_path: (null)
        res_path: /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13-abi_x86_32.x86/conftest.out
configure: error: in `/var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13-abi_x86_32.x86':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

It’s like the “./conftest” is made and the execution failed?

Last package it happened was when trying to build

sys-apps/sandbox-2.13

but it is not especially related to this Gentoo package or even to Gentoo!

And the debug.log is not informative neither:

configure:3793: ./conftest
/usr/lib32/libsandbox.so(+0xb238)[0xf7738238]
/usr/lib32/libsandbox.so(+0xb2c7)[0xf77382c7]
/usr/lib32/libsandbox.so(+0x40b1)[0xf77310b1]
/usr/lib32/libsandbox.so(+0x421e)[0xf773121e]
/usr/lib32/libsandbox.so(fopen+0x55)[0xf7733e45]
./conftest(+0x4a1)[0x565754a1]
/lib32/libc.so.6(__libc_start_main+0xf6)[0xf7561956]
./conftest(+0x508)[0x56575508]
/proc/23882/cmdline: ./conftest 

/var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/configure: line 3795: 23882 Aborted                 ./conftest$ac_cv_exeext
configure:3797: $? = 134
configure:3804: error: in `/var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13-abi_x86_32.x86':
configure:3806: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

After some debugging it turned out the problem was the

XFS filesystem

The root was formatted with XFS and therefore

/var/tmp/portage

where all the compilation occurred was on a xfs formatted partition!
It is easy to resolve the issue, just mount your “/var/tmp/portage” on another filesystem, if you do not have any spare devices or places with other filesystem, you could always mount it using

tmpfs

(using your memory for the directory) like this:

mount -t tmpfs -o size=4096m tmpfs /var/tmp/portage/

You can adjust the size with “size” parameter, but most of the program require a way below 4G of space. And do not forget mounting your build directory in the tmpfs speeds up the emerge process significantly!

And probably it is a good idea before mounting it to delete all old sub-directories, because they can take much space and they are left there after failed compilations of packages.

rm -R /var/tmp/portage/*

PS: It was the same with compilation of

sys-devel/gcc-7.3.0

configure: updating cache ./config.cache
 * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/libsandbox.c:check_syscall():968: failure (Value too large for defined data type):
 * ISE: fopen_wr(conftest.val)
        abs_path: (null)
        res_path: /var/tmp/portage/sys-devel/gcc-7.3.0/work/build/x86_64-pc-linux-gnu/32/libgomp/conftest.val
configure: error: unsupported system, cannot find sizeof (omp_lock_t)
make[2]: *** [Makefile:20106: configure-stage1-target-libgomp] Error 1
make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.3.0/work/build'
make[1]: *** [Makefile:22189: stage1-bubble] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.3.0/work/build'
make: *** [Makefile:22521: bootstrap-lean] Error 2
 * ERROR: sys-devel/gcc-7.3.0::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=sys-devel/gcc-7.3.0::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/gcc-7.3.0::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-devel/gcc-7.3.0/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-devel/gcc-7.3.0/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-devel/gcc-7.3.0/work/build'
 * S: '/var/tmp/portage/sys-devel/gcc-7.3.0/work/gcc-7.3.0'
 * 
 * Please include /var/tmp/portage/sys-devel/gcc-7.3.0/work/gcc-build-logs.tar.bz2 in your bug report.
 * 

>>> Failed to emerge sys-devel/gcc-7.3.0, Log file:

The problem is the same, compiling on

XFS filesystem