|
[SOLVED]Problem with VirtualBox guest additions
Specifically, the non-OSE Debian packages virtualbox-guest-dkms, virtualbox-guest-utils and virtualbox-guest-x11, version 4.1.18. The packages work fine with stock Debian 32bit kernels. They do not work correctly with liquorix kernels, including the current 3.7.0-4.dmz.1-liquorix-686. The installation is in a non-OSE VirtualBox version 4.2.6 r82870.
After the liquorix kernel has been installed, I completely remove the previously listed 3 Debian packages and install Oracle's guest additions by clicking Devices > Install Guest Additions in the VirtualBox window. Then I run the VBoxLinuxAdditions.run executable in the (Debian wheezy) guest OS. After a reboot of the guest OS, the guest additions are functioning properly and mouse integration with the host is achieved. If the VirtualBox program is updated on the host, the (new) guest additions have to be installed in the guest OS to function again. I am trying to understand this behavior, and asking whether the liquorix kernel can be tweaked to accomodate the guest OS's virtualbox guest packages. I have saved the failed dkms build log. It is listed below. :: Code :: Building initial module for 3.7.0-4.dmz.1-liquorix-686
Error! Bad return status for module build on kernel: 3.7.0-4.dmz.1-liquorix-686 (i686) Consult /var/lib/dkms/virtualbox-guest/4.1.18/build/make.log for more information. DKMS make.log for virtualbox-guest-4.1.18 for kernel 3.7.0-4.dmz.1-liquorix-686 (i686) Fri Jan 25 02:52:08 CST 2013 make: Entering directory `/usr/src/linux-headers-3.7.0-4.dmz.1-liquorix-686' LD /var/lib/dkms/virtualbox-guest/4.1.18/build/built-in.o LD /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/built-in.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/VBoxGuest-linux.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/VBoxGuest.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/VBoxGuest2.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/GenericRequest.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/HGCMInternal.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/Init.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/PhysHeap.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/SysHlp.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/VMMDev.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/alloc-r0drv.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/initterm-r0drv.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/memobj-r0drv.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/mpnotification-r0drv.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/powernotification-r0drv.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/alloc-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/assert-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/initterm-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/memobj-r0drv-linux.o /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeMapUser’: /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/memobj-r0drv-linux.c:1451:38: error: ‘VM_RESERVED’ undeclared (first use in this function) /var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/memobj-r0drv-linux.c:1451:38: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [/var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest/r0drv/linux/memobj-r0drv-linux.o] Error 1 make[1]: *** [/var/lib/dkms/virtualbox-guest/4.1.18/build/vboxguest] Error 2 make: *** [_module_/var/lib/dkms/virtualbox-guest/4.1.18/build] Error 2 make: Leaving directory `/usr/src/linux-headers-3.7.0-4.dmz.1-liquorix-686' < Edited by djohnston :: Jan 29, 13, 19:54 > Back to top |
|||||
|
dkms failures are not in my opinion valid bug or issue reports.
dkms is built to work with the distribution packaged kernels, headers, and drivers, not third party kernels or other components. If you leave those well integrated systems and install other components that are not covered in debian proper, then you have to learn to fix things yourself. This is by the way why i never use dkms, it's just not worth it because I always run liquorix or other current kernels on my non stable systems, ie, testing/sid. If you install the vbox for wheezy directly from oracle, say, using svmi, which will do a real install using the actual current live deb file from oracle/vbox, and get the current guest additions as well, then run the guest additions installer in the guest, and if there is then a bug or failure, you'd probably file that bug report on the vbox forums, unless the issue was actually caused by a liquorix kernel configuration mistake. You can't file a dkms bug report because you aren't using dkms the way debian intends it to be used. i see dkms failures all the time here, and maybe it's time to post a sticky thread reminding people that dkms is not built for non debian pool packages in general, particularly not debian default methods. Just as a note, 3.7 kernels have changed one of the paths in the headers, and usually when things fail it's because the release doesn't yet test for those changed paths. For example, nvidia 304.64/173 does not test for those, nvidia 310/313 does. the new fglrx 13.1 also does not test for those paths, so those things need a patch. This has nothing to do with debian or dkms, it's just what happens when you use mismatched kernels/drivers etc and there's a change in some core paths or whatever. You'll see a recent thread from a liquorix 3.7/fglrx 13.1 user here in the forums for example where he shows how to patch the driver so it will install on 3.7: techpatterns.com/forums/about2242.html Back to top |
|||||
|
Thanks for your timely response. Can you clarify this part?
:: techAdmin wrote ::
This is by the way why i never use dkms, it's just not worth it because I always run liquorix or other current kernels on my non stable systems, ie, testing/sid. Are you saying I don't need dkms to install Oracle's vbox guest additions? The first part of the successful build log shows dkms is being used to build the kernel module. Here's that part of the /var/log/vboxadd-install.log from the guest OS. :: Code :: Uninstalling modules from DKMS
Attempting to install using DKMS Creating symlink /var/lib/dkms/vboxguest/4.2.6/source -> /usr/src/vboxguest-4.2.6 DKMS: add completed. Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area.... make KERNELRELEASE=3.7.0-4.dmz.1-liquorix-686 -C /lib/modules/3.7.0-4.dmz.1-liquorix-686/build M=/var/lib/dkms/vboxguest/4.2.6/build................... cleaning build area.... DKMS: build completed. For the record, Oracle's non-OSE VBox is running on PCLinuxOS host system. The guest is the Debian wheezy installation. And, as stated before, Oracle's guest additions do work in the Debian guest with the liquorix kernel. Do I need to create my own liquorix kernel patches, or are there pre-existing ones for use with Vbox guest additions? Back to top |
|||||
|
I'm saying that it's impossible to support any question that involves dkms.
You don't need dkms to build guestadditions in the guest, of course. Why would you? You just run the guestadditions executable in the guest after mounting it on boot which vbox makes trivial to do. If that direct install/upgrade works, you're fine, if it doesn't, you have to google the issue and see if it's a guest additions issue, a header issue with 3.7/3.8 kernels, or whatever else. Then when you have skipped all that dkms stuff, you can make a meaningful comment about what works and does not work, if something needs a patch or does not need a patch, because you aren't using another layer between the actual applications/drivers and the kernels. So when I say anything involving dkms can't really be supported, that's exactly what I mean. It doesn't mean dkms is good or bad, it just means nobody here can help you until you actually determine what the actual problem is, minus dkms. Then you'll be fine, or not, depending on what the actual problem is. liquorix doesn't need any patches, but something else might, hard to say. personally I don't upgrade my kernels in guest machines, I don't see the point, so I don't have to deal with any issues about reinstalling guest additions. I do of course upgrade my host system kernels, and I can tell you that vbox 4.2.6 works fine on 3.7 kernel. I guess I could test guest additions in a guest if I wanted to see, but it's not something that matters much to me. Back to top |
|||||
|
out of boredom and curiousity I tested an old vbox guest, debian sid, installed liquorix, rebooted, mounted the vbox guest additions iso, ran the installer, it complained about not finding headers (liquorix headers are installed, but the path issue might be active) but the module builds all went fine, and it's running on reboot:
:: Code :: sh ./VBoxLinuxAdditions.run
Verifying archive integrity... All good. Uncompressing VirtualBox 4.2.6 Guest Additions for Linux.......... VirtualBox Guest Additions installer Removing installed version 4.0.8 of VirtualBox Guest Additions... Removing existing VirtualBox non-DKMS kernel modules ...done. Building the VirtualBox Guest Additions kernel modules The headers for the current running kernel were not found. If the following module compilation fails then this could be the reason. Building the main Guest Additions module ...done. Building the shared folder support module ...done. Building the OpenGL support module ...done. Doing non-kernel setup of the Guest Additions ...done. Starting the VirtualBox Guest Additions ...done. Installing the Window System drivers Installing X.Org Server 1.10 modules ...done. Setting up the Window System to use the Guest Additions ...done. You may need to restart the hal service and the Window System (or just restart the guest system) to enable the Guest Additions. Installing graphics libraries and desktop services components ...done. :: Code :: inxi -bxx
System: Host: ds-1 Kernel: 3.7.0-4.dmz.1-liquorix-686 i686 (32 bit, gcc: 4.7.2) Desktop: KDE 4.6.5 (Qt 4.7.3) dm: kdm Distro: Debian GNU/Linux wheezy/sid Machine: System: innotek product: VirtualBox version: 1.2 Chassis: Oracle type: 1 Mobo: Oracle model: VirtualBox version: 1.2 Bios: innotek version: VirtualBox date: 12/01/2006 CPU: Single core AMD Athlon 64 X2 5000+ (-UP-) clocked at 2597.234 MHz Graphics: Card: InnoTek Systemberatung VirtualBox Graphics Adapter bus-ID: 00:02.0 chip-ID: 80ee:beef X.Org: 1.10.2.902 drivers: ati,vboxvideo (unloaded: fbdev,vesa) Resolution: 1024x768@60.0hz GLX Renderer: Rasterizer GLX Version: 2.1 Mesa 7.10.3 Direct Rendering: Yes Network: Card: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] driver: pcnet32 port: d020 bus-ID: 00:03.0 chip-ID: 1022:2000 Drives: HDD Total Size: 8.6GB (30.7% used) Info: Processes: 119 Uptime: 3 min Memory: 172.9/500.3MB Runlevel: 3 Gcc sys: 4.6.1 alt: 4.4/4.7 Client: Shell (bash 4.1.5 running in konsole) inxi: 1.8.34 as I said, using dkms is a waste of time when not using standard kernels or systems. I copied and pasted between the guest and the host so it's obviously working. dkms failures are of zero value as datapoints, period. If you have an issue, please do NOT post if you are using dkms, remove the dkms drivers for that component, do the install using the direct install method, using the latest installers from the actual source of the package, then, and only then, if they fail, can you conclude that something is wrong with anything. If I were to guess, I'd guess that the installer kicked out that headers not found error, which may have been caught by dkms as an actual error, and forced an exit, but that's just a guess, dkms is just another layer with its own possible set of mistakes and errors itself. Back to top |
|||||
|
Regarding the first post, it's normal for old guest additions to fail compiling on new kernels. Also, you should be matching your guest additions with the version installed. Your log says that you were building 4.1.18 on a 3.7 kernel with VirtualBox 4.2.6 installed. If that didn't fail, I would be puzzled.
Back to top |
|||||
|
:: damentz wrote :: Also, you should be matching your guest additions with the version installed. Your log says that you were building 4.1.18 on a 3.7 kernel with VirtualBox 4.2.6 installed.I would if I could. Debian testing repos don't offer the 4.2.6 guest additions. Hence, the reason for using the direct method. Thanks for the answer. Back to top |
|||||
|
:: techAdmin wrote :: You don't need dkms to build guestadditions in the guest, of course. Why would you? You just run the guestadditions executable in the guest after mounting it on boot which vbox makes trivial to do.Okay, thanks for the answer. :: techAdmin wrote :: Then when you have skipped all that dkms stuff, you can make a meaningful comment about what works and does not work, if something needs a patch or does not need a patch, because you aren't using another layer between the actual applications/drivers and the kernels.Wow. Sorry my comments are not up to your expectations. Back to top |
|||||
|
:: Quote :: I would if I could. Debian testing repos don't offer the 4.2.6 guest additions.You seem to be totally unaware that you can install the current vbox using the debian package from oracle. Google it: download virtualbox linux You also get guest additions from there. You essentially ignored everything I posted, which I think makes this chat a total waste of time. I even told you how to mount/run theguest additons run package. If you can't run simple stuff like this, why are you trying to use new kernels in the first place? Do debian testing repos offer liquorix? yet here you are, running liquorx, how can that be? follow the links, or just use svmi, which will do it all automatically, including grabbing the latest guest additions for you. There seems to be a communication problem here, let me make this clear, even though I already said it: Debian packages integrated components that are designed to work with debian packages. The second you installed liquoriix, you installed something that is cutting edge, and is not designed to work with standard debian packages like nvidia or virtualbox or virtual box guest additions. Why after all these posts you keep talking about debian packages is beyond me. Just as you left core debian to install liquorix, so too should you leave core debian to install the drivers and modules for that liquorix kernel. So we go to oracle to get the latest vbox debian deb files, you can even use their repo if youwant butI recommend against it, download and install the deb files and guest additions and install them. I'm not going to walk you through the process, it takes too long, downlaod and run svmi and it will grab all of it for you, or learn how to do it manually, either way is fine, what's not fine is your insistence on not learning how to operate your system when using latest kernel technologies. good luck, heh, I'd start reading and learning, sounds to me like you are trying to run before you have learned to walk. alternately give siduction a try, they package a lot of these things, nvidia, new kernels, maybe vbox, I don't know. have fun, and work on learning the basics before you bog down in things you don't really understand. Back to top |
|||||
|
(1) I believed dkms was necessary to install the vbox guest additions. I was ignorant. Misinformed. Incorrect. Wrong. The lesson is indelibly etched into my brain. It's something I will never forget, short of developing Alzheimer's.
(2) Yes, I know how to install guest additions in the guest using Oracle's VBoxLinuxAdditions.run script. I had successfully done that with the liquorix kernel prior to starting this thread. I should have made that point clearer. (3) I know I can enable Oracle's VBox repo in the guest. I chose the other method. (4) I realize that installing the cutting edge liquorix kernel from your repo is leaving the "comfort zone" of core wheezy/testing. Why would I do that? Because your kernel has zram support pre-enabled. The stock Debian kernels don't. I installed the zram config files by hand because Debian doesn't offer a deb package. That's the reason. (5) This thread was started out of my ignorance of the capabilities of and necessity for dkms. At 61 years of age, I may not be the fastest of learners, but once I do learn something, it stays with me. Whether posting in this thread was a waste of your time or not is a subjective decision only you can make. I thank you for your responses and help. The liquorix kernel, as well as the inxi, smxi, sgfxi and svmi utilities are excellent. Thank you for them all. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||