Good news: it not seems to break functionnality at this time.
[root@ena-testbed-01 cdrom]# sh ./VBoxLinuxAdditions.run Verifying archive integrity... All good. Uncompressing VirtualBox 4.1.18 Guest Additions for Linux......... VirtualBox Guest Additions installer Removing installed version 4.1.18 of VirtualBox Guest Additions... Removing existing VirtualBox DKMS kernel modules [ OK ] Removing existing VirtualBox non-DKMS kernel modules [ OK ] 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. The missing package can be probably installed with yum install kernel-uek-devel-2.6.39-200.29.2.el6uek.x86_64 Building the main Guest Additions module [ OK ] Building the shared folder support module [ OK ] Building the OpenGL support module [ OK ] Doing non-kernel setup of the Guest Additions [ OK ] ... ...
Are the repos in problem?
[root@localhost ~]# uname -a Linux localhost.localdomain 2.6.39-200.29.2.el6uek.x86_64 #1 SMP Sat Jul 14 10:50:56 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# yum info kernel-uek kernel-uek-devel kernel-uek-headers Loaded plugins: security Installed Packages Name : kernel-uek Arch : x86_64 Version : 2.6.39 Release : 200.29.2.el6uek Size : 99 M Repo : installed From repo : ol6_UEK_latest Summary : The Linux kernel URL : http://www.kernel.org/ License : GPLv2 Description : The kernel package contains the Linux kernel (vmlinuz), the core of any : Linux operating system. The kernel handles the basic functions : of the operating system: memory allocation, process allocation, device : input and output, etc. Name : kernel-uek-devel Arch : x86_64 Version : 2.6.39 Release : 200.29.2.el6uek Size : 27 M Repo : installed From repo : ol6_UEK_latest Summary : Development package for building kernel modules to match the kernel URL : http://www.kernel.org/ License : GPLv2 Description : This package provides kernel headers and makefiles sufficient to build modules : against the kernel package. Name : kernel-uek-headers Arch : x86_64 Version : 2.6.32 Release : 300.32.1.el6uek Size : 2.2 M Repo : installed From repo : ol6_latest Summary : Header files for the Linux kernel for use by glibc URL : http://www.kernel.org/ License : GPLv2 Description : Kernel-headers includes the C header files that specify the interface : between the Linux kernel and userspace libraries and programs. The : header files define structures and constants that are needed for : building most standard programs and are also needed for rebuilding the : glibc package.
Dude wrote:It's also OK that the version of kernel-headers mismatches with the kernel itself. We ship kernel-headers for the RHCK (2.6.32) which can also be used by the UEK/UEK. However, if we shipped kernel-uek-headers for 2.6.39, it would break stuff compiled against RHCK/UEK.
I can confirm that. Although normally you cannot simply remove kernel-uek-headers since it is required by glibc-headers and gets automatically installed by yum when installing gcc, which is required to build the Virtualbox Guest Additions anyway.
blavoie wrote:It's finally, really OK. :)
But I don't know if it's finally, really, ok...
I thought too that versions between these packages must match... Maybe because my RHEL/CentSOS background..Yes, it is. None of the products actually use the kernel headers.
Then, the final answer is even if virtualbox module complains at compile time, it's safe to continue this way?
Maybe a bit of ignorance by me, but what happens if kernel source changed on the newer version (2.6.39) and that headers on (2.6.32) are mismatching with the former?Nothing at all. The kernel source is not installed on your machine. :)
Should I return to RHEL/CENTOS for my tests?Nope, especially considering ASMlib is not supported on either of those (for the 6.x version).
Dude wrote:Read further:
+"Kernel headers are backwards compatible, but not forwards compatible."+
Kernel headers are backwards compatible, but not forwards compatible. This means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel.Thus, we provide the older kernel headers so that they run on both the older and newer kernels. If we provided the newer kernel headers, a program built may not work on an older (i.e. RHCK or UEK) kernel.
Dude wrote:Crash kernels are very useful for Root Cause Analysis of kernel panics. And the older RHEL kernel is useful for 3rd party vendors that only provide binary drivers for their hardware and only for the RHCK.
Although I wonder why someone would need a crash kernel or want to use the original, older RHEL kernel. ;-)
Dude wrote:hdparm is pretty useless in a VM, particularly on a Type 2 hypervisor which has to deal with the Host OS buffering as well. You're better off running ORION or SLOB against those disks to get an actual Direct I/O usage benchmark. You also want to ensure the "Use Host I/O Cache" is disabled on your virtual IDE and SATA controllers.
# hdparm -t /dev/sde1