[SOLVED] virtual box aborts on execute

anark10n · 2017-01-25 20:15:21

Hey there

So, as the title of the thread says, virtualbox aborts when I try to run it, with the following error:

Qt FATAL: Cannot mix incompatible Qt library (version 0x50700) with this library (version 0x50701)
Aborted

I've tried some of the solutions I was able to find with no luck. Anyone able to help with this would be much appreciated.

Last edited by anark10n (2017-01-27 18:43:32)

Tagne · 2017-01-25 20:30:54

What are your host and guests OS ?
Apparently Virtualbox tries to mix Qt libraries version 5.7.0 and 5.7.1
Is one of these versions installed on your host system ?
You have to find what is running each version of Qt in order to fix the problem...

seth · 2017-01-25 20:34:17

You ran a partial update? Or are invoking obscure repos?

anark10n · 2017-01-25 21:07:06

Tagne wrote:

What are your host and guests OS ?
Apparently Virtualbox tries to mix Qt libraries version 5.7.0 and 5.7.1
Is one of these versions installed on your host system ?
You have to find what is running each version of Qt in order to fix the problem...

Host OS is the latest arch linux. What I meant by abort after execution, is that when I hit enter after typing the command, virtualbox doesn't run at all. It outputs error above.
I have qt5-base 5.7.1-2 and qt5-x11extras 5.7.1-1. I can't remove either one as virtualbox depends on them. Don't have the any previous in my cache. Could that be the problem?

seth wrote:

You ran a partial update? Or are invoking obscure repos?

Would pacman alert me to partial update if it occured, because it didn't when I ran the update? Also, I don't have any custom repos.

Tagne · 2017-01-25 21:26:38

anark10n wrote:

Would pacman alert me to partial update if it occured, because it didn't when I ran the update? Also, I don't have any custom repos.

In doubt you should try

pacman -Syu

If it still doesn't work, you should inspect the dependencies by running

ldd <VirtualBoxExecutable> | grep qt

Be aware that the executable you run from the command line may call other executables, wich may also be the source of the problem.

seth · 2017-01-25 21:38:29

The problematic lib could also be a plugin.

If you did sth. like "pacman -Sy virtualbox", that counts as a partial update.
The safe way is to "pacman -S virtualbox" or "pacman -Syu virtualbox" (though i'll admit that i've "pacman -Sy" in a cron job to keep track on updatable packages and still install packages w/o a full update every now and then. It's "ok" as long as you're aware what you're doing, I guess)

"Weird" repos could already be "testing" or (worse) "staging", notably on bad order in the repo list.

Trilby · 2017-01-25 21:45:10

seth wrote:

though i'll admit that i've "pacman -Sy" in a cron job to keep track on updatable packages and still install packages w/o a full update every now and then. It's "ok" as long as you're aware what you're doing, I guess

For the second part, no, that really isn't ok ever. If you've managed to not be harmed by this it is not because you are sufficiently aware but that you've been sufficiently lucky. Suggesting otherwise is like saying playing Russian Roulette can be safe if you are skilled at the game: surviving 5 rounds is not skill, it is dumb luck with emphasis on the dumb.

As for the first part, there is no reason to do this. Use `checkupdates` which is made specifically for this purpose.

On topic: anark10n, have you installed virtualbox or any of it's plugins/dependencies manually (e.g., not via pacman)?

ayekat · 2017-01-25 21:59:23

anark10n wrote:

Would pacman alert me to partial update if it occured, because it didn't when I ran the update?

No, because pacman is perfectly fine with partial upgrades - it's just that Arch Linux isn't.

Which version of VirtualBox have you installed? Otherwise +1 also with my pre-posters (check for plugins, linked libraries (with `ldd`), and try a full system upgrade if necessary).

seth · 2017-01-25 22:09:10

Because if I install some leaf package many things could go wrong except "application won't start for an unresolvable lib or has some runtime issues for bad weak dependencies" and then I won't look at the update and compare that to my last system update and simply fix things?
I'm not doing partial updates of installed packages )ok, except youtube-dl ;-), let alone libs or kernel parts (even if i'd be able to fix the system from outside then)

"aware what you're doing" meant like "know how to stand the fire", certainly not like "magically be non-inflammable"

But thanks for the checkupdates hint (while simply keeping a second database might be more efficient on regular calls)

ayekat · 2017-01-25 22:13:48

seth wrote:

(while simply keeping a second database might be more efficient on regular calls)

ls /tmp/checkup-db-$(whoami)

(also, if you want to keep it persistent across reboots, check its `--help` output)

Last edited by ayekat (2017-01-25 22:14:03)

anark10n · 2017-01-26 06:12:20

@Tagne, I had tried the ldd before to try to find out which particular library was causing issues, but all it returned was:

	not a dynamic executable

@seth, I performed a full system upgrade at the time this started happening, and again when I exhausted all the methods I could find on how to solve this.

@ayekat. virtualbox version is 5.1.14-1

Trilby · 2017-01-26 11:41:28

Most of the virtualbox files under /usr/bin are shell scripts or sym links to shell scripts. The main executable is /usr/lib/virtualbox/VirtualBox, you need to run ldd on that.

EDIT: Wait, what??

anark10n wrote:

@ayekat. virtualbox version is 5.1.14-1

That version is only in community-testing, yet your qt libs are not testing versions. So this is exactly what everyone has suspected all along.

Are you using (do you intend to continue using) testing? Post your pacman.conf please.

anark10n · 2017-01-27 16:20:35

Trilby wrote:

Most of the virtualbox files under /usr/bin are shell scripts or sym links to shell scripts. The main executable is /usr/lib/virtualbox/VirtualBox, you need to run ldd on that.
EDIT: Wait, what??
anark10n wrote:
@ayekat. virtualbox version is 5.1.14-1
That version is only in community-testing, yet your qt libs are not testing versions. So this is exactly what everyone has suspected all along.
Are you using (do you intend to continue using) testing? Post your pacman.conf please.

My mistake, it's not 5.1.14-1 but 5.1.12-2. here's my pacman.conf:

#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives

#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir     = /
#DBPath      = /var/lib/pacman/
#CacheDir    = /var/cache/pacman/pkg/
#LogFile     = /var/log/pacman.log
#GPGDir      = /etc/pacman.d/gnupg/
#HookDir     = /etc/pacman.d/hooks/
HoldPkg     = pacman glibc
#XferCommand = /usr/bin/curl -C - -f %u > %o
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
#UseDelta    = 0.7
Architecture = auto

# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg   =
#IgnoreGroup =

#NoUpgrade   =
#NoExtract   =

# Misc options
#UseSyslog
#Color
#TotalDownload
CheckSpace
#VerbosePkgLists

# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel    = Required DatabaseOptional
LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required

# NOTE: You must run `pacman-key --init` before first using pacman; the local
# keyring can then be populated with the keys of all official Arch Linux
# packagers with `pacman-key --populate archlinux`.

#
# REPOSITORIES
#   - can be defined here or included from another file
#   - pacman will search repositories in the order defined here
#   - local/custom mirrors can be added here or in separate files
#   - repositories listed first will take precedence when packages
#     have identical names, regardless of version number
#   - URLs will have $repo replaced by the name of the current repo
#   - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
#       [repo-name]
#       Server = ServerName
#       Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#

# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.

#[testing]
#Include = /etc/pacman.d/mirrorlist

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

#[community-testing]
#Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.

#[multilib-testing]
#Include = /etc/pacman.d/mirrorlist

[multilib]
Include = /etc/pacman.d/mirrorlist

# An example of a custom package repository.  See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs

Here's the output of ldd /usr/lib/virtualbox/VirtualBox

	linux-vdso.so.1 (0x00007ffc241b0000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f2bdaefc000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f2bdacf8000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f2bda95a000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000055efb25ca000)

Scimmia · 2017-01-27 16:25:20

The error you mentioned is usually because you have some old, unsupported packages around. Check pacman -Qm.

anark10n · 2017-01-27 18:43:14

Scimmia wrote:

The error you mentioned is usually because you have some old, unsupported packages around. Check pacman -Qm.

This pointed on me the right track. I had forgotten I had qt5-stylegplugins installed and needed to upgrade that. Thanks a lot.

Arch Linux

#1 2017-01-25 20:15:21

[SOLVED] virtual box aborts on execute

#2 2017-01-25 20:30:54

Re: [SOLVED] virtual box aborts on execute

#3 2017-01-25 20:34:17

Re: [SOLVED] virtual box aborts on execute

#4 2017-01-25 21:07:06

Re: [SOLVED] virtual box aborts on execute

#5 2017-01-25 21:26:38

Re: [SOLVED] virtual box aborts on execute

#6 2017-01-25 21:38:29

Re: [SOLVED] virtual box aborts on execute

#7 2017-01-25 21:45:10

Re: [SOLVED] virtual box aborts on execute

#8 2017-01-25 21:59:23

Re: [SOLVED] virtual box aborts on execute

#9 2017-01-25 22:09:10

Re: [SOLVED] virtual box aborts on execute

#10 2017-01-25 22:13:48

Re: [SOLVED] virtual box aborts on execute

#11 2017-01-26 06:12:20

Re: [SOLVED] virtual box aborts on execute

#12 2017-01-26 11:41:28

Re: [SOLVED] virtual box aborts on execute

#13 2017-01-27 16:20:35

Re: [SOLVED] virtual box aborts on execute

#14 2017-01-27 16:25:20

Re: [SOLVED] virtual box aborts on execute

#15 2017-01-27 18:43:14

Re: [SOLVED] virtual box aborts on execute

Board footer