Building amd64 module for virtualbox-ose fails.

Bug #238259 reported by PaulSchulz
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
virtualbox-ose-modules (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

See: https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose-modules/+bug/237278

I have split this bug off as it is a different specific issue. There is currently no amd64 module package for virtualbox-ose-modules.

When attempting to follow the recommended workaround on amd64..

> A temporary fix, until the package is updated:
>
> sudo apt-get install virtualbox-ose-source
> sudo module-assistant update
> sudo module-assistant prepare
> sudo module-assistant a-i virtualbox-ose
> sudo /etc/init.d/vboxdrv restart
>
> Launch VirtualBox, and it should work.

The following error is seen..

{standard input}: Assembler messages:
{standard input}:437: Error: suffix or operands invalid for `pushf'
{standard input}:438: Error: suffix or operands invalid for `pop'
{standard input}:479: Error: suffix or operands invalid for `push'
{standard input}:480: Error: suffix or operands invalid for `popf'
{standard input}:4178: Error: suffix or operands invalid for `mov'
{standard input}:5251: Error: suffix or operands invalid for `mov'
kmk[4]: *** [/usr/src/modules/virtualbox-ose/SUPDRVShared.o] Error 1
kmk[3]: *** [_module_/usr/src/modules/virtualbox-ose] Error 2
kmk[3]: Leaving directory `/usr/src/linux-headers-2.6.24-18-generic'
kmk[2]: *** [vboxdrv] Error 2
kmk[2]: Leaving directory `/usr/src/modules/virtualbox-ose'
kmk[1]: *** [binary-modules] Error 2
kmk[1]: Leaving directory `/usr/src/modules/virtualbox-ose'
make: *** [kdist_build] Error 2

Revision history for this message
Marco Hunsicker (ubuntu-triemax) wrote :

I can confirm this issue. Fix would be welcome in order to be able to workaround the dependency issue without resorting to binaries

Revision history for this message
Grizzly (sven-witterstein) wrote : Relates to bug report in debian and is probably about this line

# Build the module
kmk all KSRC=/usr/src/linux KVER=2.6.24-19-generic KERN_DIR=/usr/src/linux ARCH=i386
kmk[2]: Entering directory `/usr/src/modules/virtualbox-ose'

I found this: http://gcc.gnu.org/ml/gcc/2007-02/msg00510.html

-> thus there must be some inline-assembler statements which get not translated right for 64bit, as there is no info passed to m-a that he should do it for 64bit?

I compared the m-a log to the build log for the 2.6.24-18 virtualbox-ose-module. here the information, that the build is for 64bit seems to be passed correctly.

I did not figure out how to get a *.deb with the module compiled myself - just lack of knowledge of commands needed...

Revision history for this message
Toni Hintikka (toni-hintikka) wrote :

I've got this kind of error:
 kmk -f debian/rules clean ↑
 │ kmk[1]: Entering directory `/usr/src/modules/virtualbox-ose' ▮
 │ kmk[1]: Nothing to be done for `clean'. ▒
 │ kmk[1]: Leaving directory `/usr/src/modules/virtualbox-ose' ▒
 │ kmk -f debian/rules kdist_clean kdist_config binary-modules ▒
 │ kmk[1]: Entering directory `/usr/src/modules/virtualbox-ose' ▒
 │ kmk -w -f debian/rules clean ▒
 │ kmk[2]: Entering directory `/usr/src/modules/virtualbox-ose' ▒
 │ kmk[2]: Nothing to be done for `clean'. ▒
 │ kmk[2]: Leaving directory `/usr/src/modules/virtualbox-ose' ▒
 │ kmk[1]: Nothing to be done for `kdist_config'. ▒
 │ for templ in ; do \ ▒
 │ cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.24-18-generic/g'` ; \ ▒
 │ done ▒
 │ for templ in `ls debian/*.modules.in` ; do \

when i try to do this

sudo module-assistant a-i virtualbox-ose

command.
How can I get virtuabox work on kernel 2.6.24-18-generic kernel on AMD64 Ubuntu?

Revision history for this message
Daniel Hahler (blueyed) wrote :

> How can I get virtuabox work on kernel 2.6.24-18-generic kernel on AMD64 Ubuntu?

Install virtualbox-ose-modules-generic.
It's available in the hardy-updates repository (although the new kernel itself came through hardy-security).

Revision history for this message
Toni Hintikka (toni-hintikka) wrote :

I did't test that virtualbox-ose-modules-generic, but kernel got updated on version 2.6.24-19-generic and there was right package ( virtualbox-ose-modules-2.6.24-19-generic ) for this kernel version. There still isn't version virtualbox-ose-modules-2.6.24-18-generic. Somehow version virtualbox-ose-modules-2.6.24-18-generic is skipped on AMD64 version.

Revision history for this message
Daniel Hahler (blueyed) wrote : Re: [Bug 238259] Re: Building amd64 module for virtualbox-ose fails.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Toni Hintikka wrote:

> Somehow version
> virtualbox-ose-modules-2.6.24-18-generic is skipped on AMD64 version.

According to
http://packages.ubuntu.com/hardy-updates/virtualbox-ose-modules-2.6.24-18-generic
it should be available.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIVvgwfAK/hT/mPgARAvXVAJ9yc0s4b++y+fybKIf5DZwmxAcpTACcCCLw
o9YH+EpGATxleKyMF4luwsM=
=iOPA
-----END PGP SIGNATURE-----

Revision history for this message
Lawrence Plug (ljplug) wrote :

I can confirm this issue, still, for kernel version 2.6.24-19.

There is a virtualbox-ose-modules-2.6.24-18-generic package, but not one for 2.6.24-19 for AMD64.

This build workaround (also posted when this bug was opened):

>
> sudo apt-get install virtualbox-ose-source
> sudo module-assistant update
> sudo module-assistant prepare
> sudo module-assistant a-i virtualbox-ose
> sudo /etc/init.d/vboxdrv restart
>

.. fails on the second last line.

kmk[4]: *** [/usr/src/modules/virtualbox-ose/SUPDRVShared.o] Error 1
kmk[3]: *** [_module_/usr/src/modules/virtualbox-ose] Error 2
kmk[3]: Leaving directory `/usr/src/linux-headers-2.6.24-19-generic'
kmk[2]: *** [vboxdrv] Error 2
kmk[2]: Leaving directory `/usr/src/modules/virtualbox-ose'
kmk[1]: *** [binary-modules] Error 2
kmk[1]: Leaving directory `/usr/src/modules/virtualbox-ose'
make: *** [kdist_build] Error 2

Revision history for this message
José M. López-Cepero (cepe) wrote :

I can also confirm this.

I'm using kernel 2.6.24-21-generic, for which the virtualbox-ose modules have not yet been compiled. When trying to use module-assistant I get the same errors as the first poster (assembly-related messages). This makes Virtualbox unusable in the 2.6.24-21 kernel.

As a temporary workaround, I was able to manually insert the module for 2.4.6-20-generic, which was still installed (since it is the latest dependency of the virtualbox-ose-modules-generic package) and it seems to work, by using the following command:

sudo insmod /lib/modules/2.6.24-20-generic/misc/vboxdrv.ko

dmesg reports success and the vbox machine seems to boot up and work OK.

Daniel Hahler (blueyed)
Changed in virtualbox-ose-modules:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
ironstorm (ironstorm-gmail) wrote :

I can confirm the same problem on AMD64. :(

Revision history for this message
Grizzly (sven-witterstein) wrote :

I have switched to the sun closed source package for now and dist-upgraded to intrepid development branch for the box running the VMs.
Thus, I cannot be of much help any more here. Maybe the new source from sun is buildable now? a lot of things have changed since. Off this bug ;-)

Revision history for this message
Traumflug (mah-jump-ing) wrote :

Not sure wether this hints to a fix for this bug, but I'm running VirtualBox OSE on AMD64 right now. Ubuntu version is Intrepid, VB version is 2.0.2.

Revision history for this message
undefined (undefined) wrote :

SHORT ANSWER:
apt-get install virtualbox-ose-source linux-headers-$(uname -r)
BUILD_TARGET_ARCH=amd64 m-a -k /usr/src/linux-headers-$(uname -r) build virtualbox-ose
dpkg -i /usr/src/virtualbox-ose-modules-$(uname -r)_*_amd64.deb

LONG ANSWER:
the problem, at least for virtualbox-ose-source 1.5.6-dfsg-6ubuntu1 in hardy, is that debian/rules (lines 38-48) does not set ARCH correctly (ie ARCH set to "i386" instead of "x86_64"). see attached patch for possible fix.

on all my amd64 machines (two running debian etch and one running ubuntu hardy; linux 2.6.22, 2.6.26, and 2.6.24 respectively) "uname -m" returns "x86_64". so line 40 (grep 86) evaluates to true and ARCH is set to i386. neither of the two remaining tests (lines 43 & 46) are true because module-assistant sets KVERS to "2.6.24-22-generic" which doesn't contain the architecture as a substring (ie "86" or "amd64"). so the binary-modules rule calls the module's Makefile with ARCH=i386.

in the module's Makefile, on lines 18-40, if BUILD_TARGET_ARCH is not already set, then ARCH (and "uname -m" if ARCH is not set, but not applicable in our case) is used to set BUILD_TARGET_ARCH. since ARCH=i386 is passed to the Makefile by debian/rules, the Makefile sets the BUILD_TARGET_ARCH to x86. this eventually defines RT_ARCH_X86 in the Makefile which causes 32-bit i386 assembly to be compiled with SUPDRVShared.c (unsuccessfully with 64-bit amd64 assembler) which causes the error and halts the build.

because in the Makefile BUILD_TARGET_ARCH is tested before ARCH and debian/rules does not set BUILD_TARGET_ARCH, but ARCH, my hack is to define BUILD_TARGET_ARCH (as "amd64") when calling module-assistant. but the more proper solution is to have debian/rules properly recognize the arch from "uname -m".

Revision history for this message
Vadim Peretokin (vperetokin) wrote :

Is this still an issue?

Revision history for this message
undefined (undefined) wrote :

this isn't an issue any longer for me, but not because the bug has been fixed (i doubt it as i have two bugs open for lucid which i've already created, tested, and provided patches for months ago), but because i've moved on to lucid, squeeze, and virtualbox-ose-source 3.2.10-dfsg-1 (backported from squeeze to lucid).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.