VirtualBox

Ticket #16772 (closed defect: fixed)

Opened 5 months ago

Last modified 3 months ago

VirtualBox No Longer Installs On 32bit Slackware Current

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

Description

After recent changes to Slackware current 32bit, VirtualBox will no longer install. I use the VirtualBox-5.1.22-115126-Linux_x86.run 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...
vboxdrv.sh: 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
/sbin/vboxconfig
as root.
vboxdrv.sh: 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

vbox-install.log.zip Download (19.7 KB) - added by mtv 5 months ago.
vbox install log compressed (zip vbox-install.log.zip vbox-install.log)

Change History

comment:1 Changed 5 months ago by frank

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

Changed 5 months ago by mtv

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

comment:2 Changed 5 months ago by mtv

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

comment:3 Changed 5 months ago by frank

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 Changed 5 months ago by mtv

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 Changed 5 months ago by frank

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 Changed 5 months ago by jghodd

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 Changed 5 months ago by eworm

We already have a bug report for Arch Linux:  https://bugs.archlinux.org/task/54252

comment:8 Changed 5 months ago by benjarobin

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 Changed 5 months ago by benjarobin

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 5 months ago by benjarobin (previous) (diff)

comment:10 Changed 5 months ago by frank

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 Changed 4 months ago by frank

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 Changed 3 months ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fix is part of 5.1.24.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use