VBox guest fails to run on Linux host with host-kernel built with clang.

[DanglingPointer]

For one of my hosts, I'm recently trying out llvm/clang built linux kernel. After installing the kernel in the host and restarting it; the VBox Manager works but VM guests won't start.

Checking the vbox-setup.log shows that dkms is trying to build the vboxdrv modules using "gcc" explicitly and failing. Typical errors are

gcc: error: unrecognized command-line option ‘-Qunused-arguments’
gcc: error: unrecognized command-line option ‘-Qunused-arguments’
gcc: error: unrecognized command-line option ‘-mno-global-merge’
cc: error: unrecognized command-line option ‘-Qunused-arguments’
cc: error: unrecognized command-line option ‘-mno-global-merge’
cc: error: unrecognized command-line option ‘-mno-global-merge’
cc: error: unrecognized command-line option ‘-mno-global-merge’
cc: error: unrecognized command-line option ‘-mno-global-merge’g
c: error: unrecognized command-line option ‘-mno-global-merge’g
c: error: unrecognized command-line option ‘-fsplit-lto-unit’

I tried again using "update-alternatives" command to set "cc" to point to clang as a work around

$ cc --version; c++ --version
Ubuntu clang version 12.0.0-3ubuntu1~20.04.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Ubuntu clang version 12.0.0-3ubuntu1~20.04.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

But it still didn't work and produced the exact same errors in the vbox-setup.log. I suspect because somehow dkms is explicitly trying to build the modules using "gcc" instead of "cc".

Here is part of one line example from the log:

gcc -Wp,-MMD,/tmp/vbox.0/linux/.SUPDrv-linux.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/11/include ...

I'm not sure what to do next.

For now I have reverted to a Linux kernel host built using gcc which works perfectly. Please advice or fix the dkms setup so that it isn't hardcoded to use gcc. Perhaps figure out whether to use gcc or clang based off the host kernel somehow; or perhaps change the dkms setup to use "cc/c++" instead which is configured by "update-alternatives".

I am running Ubuntu 20.04 and the llvm/clang built kernel is 5.12.10

[DanglingPointer]

vbox-setup.log

[DanglingPointer]

Guest is Ubuntu 20.04 Linux

[galitsyn]

Thank you for reporting the issue. It should be fixed in VirtualBox 6.1.36. Please refer to https://www.virtualbox.org/wiki/Downloads page.

[DanglingPointer]

I am experiencing this problem AGAIN with Virtualbox 7.0.24 with host kernel built with clang with linux LTS kernel 6.12.x.

Virtualbox 7.0.24 works however with clang built host kernel LTS 6.6.x.

It appears there's been a regression. The fix has not been implemented for hosts built with clang and newer kernels.

[galitsyn]

Hi DanglingPointer,

I don't see the issue on my end. Strictly speaking the original issue was fixed long ago and if something new has popped up, a new ticket needs to be submitted.

What is the error message you are observing?

[DanglingPointer]

I have attached "host.linux-6.12.18.vbox-setup.log" to this ticket. It shows that it is trying to use GCC instead of clang (see attached file).

It does NOT happen with hosts built with LTS linux 6.6.x (currently on 6.6.81).

danglingpointer@Vault:~$ sudo /sbin/vboxconfig
[sudo] password for danglingpointer: 
vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
danglingpointer@Vault:~$

[galitsyn]

Hi DanglingPointer,

Any chance that /lib/modules/6.12.18/build/.config is missing or does not contain CONFIG_CC_IS_CLANG=y?

[DanglingPointer]

kernel config clearly shows that it has it...

danglingpointer@Vault:~$ cat /boot/config-6.12.18-danglingpointer-znver3-clang | grep "CONFIG_CC_IS_CLANG=y"
CONFIG_CC_IS_CLANG=y
danglingpointer@Vault:~$ 

However the "/lib/modules" host path has these respectively for 6.12.18 and for 6.6.81. The former fails with guests; the latter works with guests.

danglingpointer@Vault:/lib/modules$ ls -lah ./6.12.18-danglingpointer-znver3-clang/
total 7.3M
drwxr-xr-x  3 root root 4.0K Mar 13 09:35 .
drwxr-xr-x 16 root root  12K Mar 13 09:34 ..
lrwxrwxrwx  1 root root   59 Mar 12 23:40 build -> /usr/src/linux-headers-6.12.18-danglingpointer-znver3-clang
drwxr-xr-x 13 root root 4.0K Mar 13 09:35 kernel
-rw-r--r--  1 root root 1.7M Mar 12 23:40 modules.alias
-rw-r--r--  1 root root 1.6M Mar 12 23:40 modules.alias.bin
-rw-r--r--  1 root root 9.7K Mar 12 23:40 modules.builtin
-rw-r--r--  1 root root  11K Mar 12 23:40 modules.builtin.alias.bin
-rw-r--r--  1 root root  12K Mar 12 23:40 modules.builtin.bin
-rw-r--r--  1 root root  91K Mar 12 23:40 modules.builtin.modinfo
-rw-r--r--  1 root root 100K Mar 12 23:40 modules.builtin.ranges
-rw-r--r--  1 root root 860K Mar 12 23:40 modules.dep
-rw-r--r--  1 root root 1.2M Mar 12 23:40 modules.dep.bin
-rw-r--r--  1 root root  337 Mar 12 23:40 modules.devname
-rw-r--r--  1 root root 262K Mar 12 23:40 modules.order
-rw-r--r--  1 root root 2.8K Mar 12 23:40 modules.softdep
-rw-r--r--  1 root root 707K Mar 12 23:40 modules.symbols
-rw-r--r--  1 root root 860K Mar 12 23:40 modules.symbols.bin
danglingpointer@Vault:/lib/modules$ ls -lah ./6.6.81-danglingpointer-znver3-clang/
total 7.0M
drwxr-xr-x  4 root root 4.0K Mar 13 14:08 .
drwxr-xr-x 16 root root  12K Mar 13 09:34 ..
lrwxrwxrwx  1 root root   58 Mar  8 16:04 build -> /usr/src/linux-headers-6.6.81-danglingpointer-znver3-clang
drwxr-xr-x 14 root root 4.0K Mar  8 21:02 kernel
drwxr-xr-x  2 root root 4.0K Mar 13 14:07 misc
-rw-r--r--  1 root root 1.6M Mar 13 14:08 modules.alias
-rw-r--r--  1 root root 1.6M Mar 13 14:08 modules.alias.bin
-rw-r--r--  1 root root 9.4K Mar  8 16:04 modules.builtin
-rw-r--r--  1 root root 9.8K Mar 13 14:08 modules.builtin.alias.bin
-rw-r--r--  1 root root  12K Mar 13 14:08 modules.builtin.bin
-rw-r--r--  1 root root  82K Mar  8 16:04 modules.builtin.modinfo
-rw-r--r--  1 root root 835K Mar 13 14:08 modules.dep
-rw-r--r--  1 root root 1.1M Mar 13 14:08 modules.dep.bin
-rw-r--r--  1 root root  337 Mar 13 14:08 modules.devname
-rw-r--r--  1 root root 255K Mar  8 16:04 modules.order
-rw-r--r--  1 root root 2.5K Mar 13 14:08 modules.softdep
-rw-r--r--  1 root root 722K Mar 13 14:08 modules.symbols
-rw-r--r--  1 root root 871K Mar 13 14:08 modules.symbols.bin
danglingpointer@Vault:/lib/modules$

[galitsyn]

Let me rephrase. Could you please confirm that file /lib/modules/$(uname -r)/build/.config exists and contains CONFIG_CC_IS_CLANG=y?

[DanglingPointer]

6.12.18 --> has no .config file

6.6.81 --> has .config file

danglingpointer@Vault:/lib/modules$ cat /lib/modules/6.12.18-danglingpointer-znver3-clang/build/
arch/           include/        Makefile        Module.symvers  scripts/        tools/          
danglingpointer@Vault:/lib/modules$ cat /lib/modules/6.6.81-danglingpointer-znver3-clang/build/
arch/           .config         include/        Makefile        Module.symvers  scripts/        tools/          
danglingpointer@Vault:/lib/modules$ cat /lib/modules/6.6.81-danglingpointer-znver3-clang/build/.config | grep "CONFIG_CC_IS_CLANG"
CONFIG_CC_IS_CLANG=y
danglingpointer@Vault:/lib/modules$ 

Interesting! How do we get .config in that directory? Is that a kernel config option that has changed for modules specifically for 6.12.x ? We're not doing anything specific to add .config to the modules directory for 6.6.x. Basically using the same commands to build the linux kernel for both versions.

[galitsyn]

Problem you are observing is not related to VirtualBox. Please install kernel and modules properly. Closing.

[DanglingPointer]

As I'm sure this will affect thousands of users using hosts built with clang on LTS kernels (6.12.x).

Putting the solution here... There's been a change to .../linux-6.12.x/scripts/package/install-extmod-build

It has basically lost the final couple of lines that exists in the previous LTS major version 6.6.x.

# copy .config manually to be where it's expected to be
cp "${KCONFIG_CONFIG}" "${destdir}/.config"

This is a linux kernel issue and not VBox. Linux Kernel team need to fix this. Above was basically downloaded unaltered from kernel.org.

Workaround is to manually add the .config file to the modules folder as specified above by galitsyn.