|
OK, I somehow understood the erroneous installation behaviour of VBox (found it in the linux.debian.user Google group):
:: Quote :: Due to a change in the kernel Makefile, "make kernelrelease" no longer gets the kernel release from include/config/kernel.release , but instead uses scripts/setlocalversion . This causes problems because the extra
stuff added to EXTRAVERSION by --append-to-version is no longer there when you run "make kernelrelease". The Linux Makefile change was made in commit 7b8ea53d. I don't know whether this should be considered a bug in kernel-package or the kernel. The kernel is no longer preserving the value of EXTRAVERSION passed on the make command line when make is subsequently invoked, whereas it previously did. But then, the kernel people don't seem to care much about stable interfaces, so perhaps kernel-package should adapt somehow. For now, I'm going to revert 7b8ea53d in my tree so I can get VirtualBox installing again (it compares $(uname -r) to $(make kernelrelease)), but this should probably be fixed somewhere. DAMENTZ, PLEASE! Could you please put all the patches back? I experiment with them, especially I compile from time to time a more stable kernel using only bfq and autogroup patches. Would also like to test sqlb (new allocator). Thank you in advance! Back to top |
|||||
|
:: TheExplorer wrote :: OK, I somehow understood the erroneous installation behaviour of VBox (found it in the linux.debian.user Google group):
:: Quote :: Due to a change in the kernel Makefile, "make kernelrelease" no longer gets the kernel release from include/config/kernel.release , but instead uses scripts/setlocalversion . This causes problems because the extra
stuff added to EXTRAVERSION by --append-to-version is no longer there when you run "make kernelrelease". The Linux Makefile change was made in commit 7b8ea53d. I don't know whether this should be considered a bug in kernel-package or the kernel. The kernel is no longer preserving the value of EXTRAVERSION passed on the make command line when make is subsequently invoked, whereas it previously did. But then, the kernel people don't seem to care much about stable interfaces, so perhaps kernel-package should adapt somehow. For now, I'm going to revert 7b8ea53d in my tree so I can get VirtualBox installing again (it compares $(uname -r) to $(make kernelrelease)), but this should probably be fixed somewhere. DAMENTZ, PLEASE! Could you please put all the patches back? I experiment with them, especially I compile from time to time a more stable kernel using only bfq and autogroup patches. Would also like to test sqlb (new allocator). Thank you in advance! Ok, I reverted the patch (and another) from the kernel that was also present in 2.6.36. In the meantime, you can try using dkms. Why you would manually build VBox's kernel module on every new kernel is beyond me. And what are you talking about? If you're referring to git.zen-kernel.org - Jan Steffen's and I agreed to remove all the patches that are more than one stable kernel version old. That means if 2.6.38 comes out in the future, then I'll delete the 2.6.36 specific branches. Many of the patches that those special branches aimed to fix are now incorporated into the newer stable kernels. There's no reason to run the older ones unless you're using a proprietary module that doesn't support it yet. And even then, if your module is habitually not supporting even the last stable kernel, it's time to find a new piece of hardware or be eternally frustrated. Even fglrx users can run one stable kernel version old these days once the appropriate patches are found. Lastly, the new slqb allocator doesn't offer easily measurable or behavioral changes to the kernel. I wouldn't want to risk destabilizing the kernel over a 1% performance throughput increase. Back to top |
|||||
|
:: Quote :: Why you would manually build VBox's kernel module on every new kernel is beyond me. I simply have no dkms since I've never needed it because I use official NVidia drivers (sometimes stable, sometimes try beta ones) and official VBox (not OSE version from Debian repos). I just uninstalled dkms long ago. Ok, I can try it if you insist and if it works OK. :: Quote :: Jan Steffen's and I agreed to remove all the patches that are more than one stable kernel version old. That means if 2.6.38 comes out in the future, then I'll delete the 2.6.36 specific branches.What I mean is the current 2.6.37 kernel. It would be ridiculous to ask you to keep the old patches. Your /sources/patches/ directory suddenly became empty and all I need (and I'm sure many others out there also) is always actual 2.6.37 patches like bfq, autogrouping etc. which you apply. Back to top |
|||||
|
:: TheExplorer wrote :: I simply have no dkms since I've never needed it because I use official NVidia drivers (sometimes stable, sometimes try beta ones) and official VBox (not OSE version from Debian repos). I just uninstalled dkms long ago. Ok, I can try it if you insist and if it works OK.I use official NVidia drivers and official VBox too and I've installed dkms to work with VBox (on Ubuntu). Back to top |
|||||
|
What exact dkms-* package did you install?
Back to top |
|||||
|
:: TheExplorer wrote :: What exact dkms-* package did you install?Only "dkms" (http://packages.ubuntu.com/maverick-updates/dkms). When I install/purge one kernel, vboxdrv automatically insert/delete its driver from kernel using dkms. Or I can force the update: :: Code :: $ sudo /etc/init.d/vboxdrv setup
* Stopping VirtualBox kernel modules * done. * Uninstalling old VirtualBox DKMS kernel modules * done. * Trying to register the VirtualBox kernel modules using DKMS * done. * Starting VirtualBox kernel modules * done. I hope this helps. Back to top |
|||||
|
www.virtualbox.org/wiki/Linux_Downloads
Read the instructions for debian based distributions. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||