Opened 7 years ago

Closed 6 years ago

#16772 closed defect (fixed)

VirtualBox No Longer Installs On 32bit Slackware Current

Reported by: mtv Owned by:
Component: installer Version: VirtualBox 5.1.22
Keywords: Cc:
Guest type: all Host type: Linux


After recent changes to Slackware current 32bit, VirtualBox will no longer install. I use the script to install. Have tried going back to earlier versions of VirtualBox but these don't work either so fairly sure its an upgrade to a package that causes problem. Don't know if it is the bump in kernel version (4.9.28) or the upgrade to gcc-7.1.0. Either way it's possible this will be seen in other distributions at some point.

When running the script I get the following diagnostics...

Verifying archive integrity... All good.
Uncompressing VirtualBox for Linux installation.............
VirtualBox Version 5.1.22 r115126 (2017-04-28T15:48:48Z) installer
Removing previous installation of VirtualBox 5.1.14 r112924 from /opt/VirtualBox
Installing VirtualBox to /opt/VirtualBox
Python found: python, installing bindings... failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.

There were problems setting up VirtualBox. To re-start the set-up process, run
as root. failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.

and dmesg shows several lines with:

vboxdrv: Unknown symbol __udivmoddi4 (err 0)

As a result of this there is no kernel driver installed and no guests can be launched.

Attachments (1) (19.7 KB ) - added by mtv 7 years ago.
vbox install log compressed (zip vbox-install.log)

Download all attachments as: .zip

Change History (13)

comment:1 by Frank Mehnert, 7 years ago

Please attach the /var/log/vbox-install.log file. To me it looks like you have not matching kernel / kernel sources.

by mtv, 7 years ago

Attachment: added

vbox install log compressed (zip vbox-install.log)

comment:2 by mtv, 7 years ago

Have attached file requested. Had to zip it as it is too big for file upload.

comment:3 by Frank Mehnert, 7 years ago

No error in the installation log but you need to use the exact same gcc compiler for compiling your kernel and for compiling the VBox modules. Form your description I read that you upgraded your compiler recently.

comment:4 by mtv, 7 years ago

A new kernel version was added at the same time as the upgrade to gcc 7.1.0. The kernel version has been upgraded twice since then. I'm fairly sure that the Slackware maintainer would have built the kernel with the same gcc version. To make sure I did the following:

I did a fresh install of Slackware current as of May 16th on a test system and tried installing VirtualBox. It failed with the same error.

I then downloaded kernel version 4.9.29 (did have 4.9.28 installed) and built it. I used make modules_install and confirmed that his copied the headers into /lib/modules. I then added the new kernel into /boot. I then booted into that freshly built kernel. I confirmed it was running with uname -r. I then rebuilt Virtualbox using the run script. It failed with the same error. The /var/log/vbox-install.log had the new kernel version all through it.

comment:5 by Frank Mehnert, 7 years ago

It must be still a problem of your Slackware environment. The VBox modules are built according to the Linux kernel build rules. If the VBox modules built on your environment lack the reference to any libgcc symbol (__udivmoddi4 is provided by libgcc) then the same would happen with any externally compiled Linux kernel module.

comment:6 by jghodd, 7 years ago

I am seeing the same issue but on the other side of the coin. I'm running a 64-bit version of virtualbox (5.1.22) on the host side, with a 32-bit guest. The guest is throwing the same error - vboxguest: Unknown symbol udivmoddi4 (err 0) - and will not boot up. Modprobing vboxguest or vboxsf throws the same error.

I was able to rebuild the modules after adding a slightly modified version of udivmoddi4.c (originating from the host source code and modified to incorporate the 'quad' types) and manually installing the modules. This worked, and I now have a running 32-bit guest again.

In my case, I'm running Arch Linux with kernel 4.11.3. It's interesting to note that virtualbox-5.1.22 ran just fine with linux-4.11.2. However, I cannot say with any certainty that it might not have been the latest gcc update to 7.1.1 that didn't cause the problem - the gcc update roughly corresponded with the kernel update.

I'd be happy to open a bug report with Arch if I can get some direction as to where this issue might actually be. Is it with the virtualbox build, the kernel build, or the compiler build? Or somewhere else entirely? Whose issue is this?

comment:7 by Christian Hesse, 7 years ago

We already have a bug report for Arch Linux:

comment:8 by Benjamin ROBIN, 6 years ago

This is *not* a problem with the environment, but a "bug" inside VirtualBox. Well this is just that VirtualBox was never built with GCC 7.

In order to "link" the vboxguest module, VirtualBox provide the source of some of the libgcc function, since these functions are not provided by the kernel. For example _ _udivdi3 is already provided here: src/VBox/Runtime/common/math/gcc/udivdi3.c

GCC 7 is a little bit clever (or maybe _ _udivmoddi4 is new), this function is called for the associated line: vboxguest/common/string/strformat.c:206: u64 /= uiBase;

comment:9 by Benjamin ROBIN, 6 years ago

Why the proper function declared in linux/math64.h are not used when relevant, instead of including part of libgcc inside the virtualbox kernel module (for example common/math/gcc/udivdi3.c) ?

Last edited 6 years ago by Benjamin ROBIN (previous) (diff)

comment:10 by Frank Mehnert, 6 years ago

benjarobin, thanks for your investigation, your findings make sense. To answer your questions why the functions from linux/math64.h are not used: There functions are Linux-specific while the stuff in common/string/strformat.c is used on all hosts.

We are working on a fix.

comment:11 by Frank Mehnert, 6 years ago

Fix is part of the most recent repository, also the latest available 5.1.x test builds have the fix. The changes are in r67293, r67294, r67295, r67296, r67297 and r67298.

comment:12 by Frank Mehnert, 6 years ago

Resolution: fixed
Status: newclosed

Fix is part of 5.1.24.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use