dkms autorebuild vboxvideo fails on minimal linux guest -> fixed as of 13 Feb 2014 for version 4.2.x and later

[Gary Humenuk]

On a Linux guest with no X server installed, as expected, vboxvideo fails to build. Unfortunately, dkms attempts to rebuild all guest kernel modules including vboxvideo during every reboot. This adds a serious delay for each reboot and failure messages in the logs. The system should simply ignore vboxvideo if X is not installed.

Actual result: dkms rebuilds additions on every guest reboot

Expected result: dkms rebuilds additions only when kernel changes

Additional details on test system: VirtualBox 4.3.4 Host Fedora 19 x86_64 Guest CentOS 6.5 both i386 and x86_64

To reproduce exactly:

Install a CentOS 6.5 using the minimal selection

Do not update yet

Install gc bzip2 and kernel-devel for installed kernel.

Mount guest additions

mount /dev/sr0 /mnt

Install guest additions

cd /mnt; ./VBoxLinuxAdditions.run

reboot

update operating system to get latest kernel

reboot

Work Around: Add a check to /opt/VBoxGuestAdditions-4.3.2/src/vboxguest-4.3.2/Makefile to ignore vboxvideo if the X command is not installed.

Comment out the three vboxvideo related lines in /opt/VBoxGuestAdditions-4.3.2/src/vboxguest-4.3.2/dkms.conf

There is probably a better way. This worked for me.

[Gary Humenuk]

Modified Makefile for guest additions

[Gary Humenuk]

modified dkms.conf for guest additions

[Gary Humenuk]

Sorry, I can't see any way to correct the original text.

The line

Install gc bzip2 and kernel-devel for installed kernel.

should read

Install gcc bzip2 and kernel-devel for installed kernel.

[Michael Thayer]

This is not actually related to the X Window System. It is because the EL 6.5 family do not provide the drm headers in the kernel-devel package in the usual way. I fixed it with the following patch to the vboxvideo make file, which pulls the headers from /usr/include, the only place EL 6.5 installs them to:

@@ -31,6 +31,12 @@
 MOD_INCL   = $(addprefix -I$(KBUILD_EXTMOD),/ /include /r0drv/linux)
 # What on earth is this?
 MOD_INCL  += $(addprefix -I$(KBUILD_EXTMOD)/vboxvideo,/ /include /r0drv/linux)
+# Enterprise Linux 6.5 does not include the drm user API headers with the kernel
+# headers.
+MOD_INCL += $(foreach inc,$(KERN_INCL),\
+              $(if $(wildcard $(inc)/linux/utsrelease.h),\
+                $(if $(shell grep '"2.6.32.*el6.*"' $(inc)/linux/utsrelease.h),\
+		      -I/usr/include,),))
 MOD_DEFS  := -DRT_OS_LINUX -DIN_RING0 -DIN_RT_R0 \
 	     -DIN_SUP_R0 -DVBOX -DVBOX_WITH_HGCM -DLOG_TO_BACKDOOR -DIN_MODULE \
 	     -DIN_GUEST_R0

[Frank Mehnert]

This test build of the VBox 4.3.x Guest Additions contains the fix. Could you verify?

[angrod]

Error log from dkms build attempt

[angrod]

Frank,

I tested your build of the additions in a fresh VM with Cent 6.5 i386 minimal (no X by default). After installing all of the kernel dev packages and dkms, I tried installing the additions with VBoxLinuxAdditions.run, which errored out when trying to build the video module. I then rebooted several times, and each time the VM would try to rebuild the VBox modules and fail. I've attached pre-xorg.txt showing the make.log file from the failed build. Then I installed every x11 devel package I could find ("yum install xorg-x11-*-devel"; all told with dependencies, this added ~120MiB of files to the VM's disk) and rebooted again. Still dkms could not rebuild the modules at boot, so I reinstalled the addons completely from the iso. I saw no failures when reinstalling this time, but the system still tried to rebuild the modules (and failed) when I rebooted with exactly the same output as shown in pre-xorg.txt.

Since the end result with dkms was the same regardless of whether x11 was installed or not, I finally went back to a clean minimal install, installed dkms and the kernel headers. This time, before I installed the additions I applied the procedure in this post (slightly adjusted for my current kernel version): ​https://forums.virtualbox.org/viewtopic.php?p=273755&sid=4f40725125d68867aa1ffe08294c9b58#p273755. Again the installer failed to install the window system drivers, which is not unexpected. However, on reboot, dkms did NOT try to rebuild anything. From what I can tell, Michael's patch was applied to the Makefile for vboxvideo, so all of this leads me to conclude that the patched makefile did not have the intended effect.

[Michael Thayer]

angrod, could you please attach the file "/var/log/vboxadd-install.log"? Make sure that the last version of the Additions which you installed was the version which was supposed to be fixed. Thanks.

[angrod]

Log files from the addition installation, both with and without the symlinking described.

[angrod]

Screenshot of mounted additions ISO.

[angrod]

Sorry for the delay - I hadn't realized you'd replied (I've looked for a way to notify me by email on a reply to a ticket, but haven't found it. Is this supported?). I've attached log files and a screenshot of the mounted additions file which I downloaded from the link provided in comment:3. The log file archive includes the logs from both the version of the VM where I symlinked the drm headers and the one where I did not. I hope this helps; let me know if I can do anything else to assist.

[Michael Thayer]

You should automatically get e-mail notification for tickets you have commented on, not sure why it isn't working for you. Could you please also attach "/var/lib/dkms/vboxguest/4.3.7/build/make.log" from a non-symlinked virtual machine?

[Gary Humenuk]

Thank you for all the work of both michael and angrod.

I'm sorry I took so long getting back to this. I've been ill.

I just checked again with VBoxGuestAdditions-4.3.6 and still see a problem.

I'll attach the boot.log and /var/lib/dkms/vboxguest/4.3.6/build/make.log

I notice my make.log is very similar to angrod's 4.3.7 make.log

My work around still works for me.

I also was not getting automatic notification. I think it was because I had not set my preferences correctly.

[Gary Humenuk]

I just added the guest additions to a CentOS 5.10 minimal system with dkms. What is interesting is that reboots work fine. There is no /var/lib/dkms/vboxguest/4.3.6/build/make.log and no errors in the logs I could find.

[Michael Thayer]

Sorry for the delay. Please try this build.

https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_4.3.7-92250.iso

[angrod]

Michael,

I'll try to test with this build over the weekend. I've kept my test VMs around for this issue, so it should be relatively easy to test.

[Gary Humenuk]

I just tested the 4.3.7092250 additions on my minimal Fedora 19 VM.

It did not try to build video additions and gave the lovely:

Installing the Window System drivers
Could not find the X.Org or XFree86 Window System, skipping.

exactly as we hoped.

A reboot did not cause dkms to rebuild the additions.

I did a yum-update which updated the kernel from 3.11.7-200 to 3.12.9-201 The boot log does not seem to show kernel updates, however, /var/lib/dkms/vboxguest/4.3.7/3.12.9-201.fc19.x86_64/x86_64/ shows the current date and proper time.

I am attaching boot.log.20140217 and /var/lib/dkms/vboxguest/4.3.7/3.12.9-201.fc19.x86_64/x86_64/log/make.log as vbox.dkms.make.log.20140217 for reference.

[Michael Thayer]

On Red Hat based systems with DKMS installed, updating the kernel should cause DKMS modules to be recompiled immediately, not on next reboot. Is that not what happened on your system?

[Gary Humenuk]

I thought I remembered seeing it rebuilding during the boot.

According to the timestamps the build finished about 11:07. That would have been during the update. The reboot did not start until 11:09 so it must have worked the way you said.

Aha! I just watched yum-update kernel* on my 32 bit minimal VM and it worked exactly as you say. The contents of /var/lib/dkms/vboxguest/4.3.7 were updated just as the kernel update finished.

As far as I am concerned this is a proper solution. I expect it will be out in the regular 4.3.8 release.

Well done and thank you all.

[Frank Mehnert]

Fix is part of VBox 4.3.8.

[Gary Humenuk]

I can verify that the fix is good in 4.3.8 on my (almost) minimal virtual machines.