h3. Symptom
----
Debian, Suse, and other distributions with recent 2.6.29 and higher kernels, package their kernel headers in a new architecture-specific manner, which breaks compatibility with earlier established methods of building modules for kernels.
Prior to CDP 4, attempting to build kernel modules on these Linux distributions can prove unsuccessful.
This is the excerpted output from one attempt. In our example here, we use r1soft-cki, but this applies for r1soft-setup in CDP as well.
\\
{code}
root@box~# /usr/bin/r1soft-cki
Checking for binary module
..
No binary module found
Gathering kernel information
Gathering kernel information complete.
Creating kernel headers package
Checking '/usr/src/linux-headers-2.6.32-5-common-xen' for kernel headers
Found headers in 'linux-headers-2.6.32-5-common-xen'
Compressing...
uploading kernel package 100% 3863KB 3.8MB/s 00:01
Starting module build...
............................gathering required information...
sending request for kernel module...
kernel module installer failed. (0):
chroot chroot make
make[1]: Entering directory `/'
~~~~~~
make: Entering an unknown directory
make: *** /usr/src/linux-headers-2.6.30-1-common: No such file or directory. Stop.
make: Leaving an unknown directory
make[4]: *** [all] Error 2
~~~~~~
{code}
h1.
h1. Cause
----
This issue is known to affect Debian, Suse, and other distros using separate architecture-specific module directories in their header packages. Thanks to Chris at Interspire.com for working closely with us to discover a resolution.
The Debian developers have removed the common/architecture specific symlinks for the kernel headers in 2.6.29 and higher, which has broken parts of the kernel module building process, including the R1Soft CDP Agent module:
(refer to here: [http://bugs.debian.org/cgi-bin/bugrepaort.cgi?bug=521515])
Basically, there are now two kernel module directories, both of which contain necessary files:
drwxr-xr-x 4 root root 4096 2010-01-20 05:43 linux-headers-2.6.32-trunk-amd64
drwxr-xr-x 4 root root 4096 2010-01-20 05:47 linux-headers-2.6.32-trunk-common
h2.
h1. Resolution
----
Copying the contents of these two directories into a temporary directory, with the proper makefile chosen, will allow the r1soft-cki process to compile a module successfully:
\\
{code}
cd /usr/src/
rsync -avz /usr/src/linux-headers-2.6.32-5-xen-amd64/ r1build/
rsync -avz /usr/src/linux-headers-2.6.32-5-common-xen/ r1build/
{code}
\\
Now, point the r1soft-cki utility to use your temporary directory, with the following flags added to the command:
*CDP2*
{code}
# /usr/bin/r1soft-cki --get-module --kernel-dir /usr/src/r1build
{code}
*CDP3 *
{code}
# /usr/bin/r1soft-setup --get-module --kernel-dir /usr/src/r1build
{code}\\
\\
\\
After a successful build, you can delete the temporary directory, restart the agent, and enjoy Continuous Data Protection\!
{code}
rm -r /usr/src/r1build
{code}
*CDP2*
{code}
/etc/init.d/buagent restart
{code}
*CDP3*
{code}
/etc/init.d/cdp-agent restart
{code}
----
Debian, Suse, and other distributions with recent 2.6.29 and higher kernels, package their kernel headers in a new architecture-specific manner, which breaks compatibility with earlier established methods of building modules for kernels.
Prior to CDP 4, attempting to build kernel modules on these Linux distributions can prove unsuccessful.
This is the excerpted output from one attempt. In our example here, we use r1soft-cki, but this applies for r1soft-setup in CDP as well.
\\
{code}
root@box~# /usr/bin/r1soft-cki
Checking for binary module
..
No binary module found
Gathering kernel information
Gathering kernel information complete.
Creating kernel headers package
Checking '/usr/src/linux-headers-2.6.32-5-common-xen' for kernel headers
Found headers in 'linux-headers-2.6.32-5-common-xen'
Compressing...
uploading kernel package 100% 3863KB 3.8MB/s 00:01
Starting module build...
............................gathering required information...
sending request for kernel module...
kernel module installer failed. (0):
chroot chroot make
make[1]: Entering directory `/'
~~~~~~
make: Entering an unknown directory
make: *** /usr/src/linux-headers-2.6.30-1-common: No such file or directory. Stop.
make: Leaving an unknown directory
make[4]: *** [all] Error 2
~~~~~~
{code}
h1.
h1. Cause
----
This issue is known to affect Debian, Suse, and other distros using separate architecture-specific module directories in their header packages. Thanks to Chris at Interspire.com for working closely with us to discover a resolution.
The Debian developers have removed the common/architecture specific symlinks for the kernel headers in 2.6.29 and higher, which has broken parts of the kernel module building process, including the R1Soft CDP Agent module:
(refer to here: [http://bugs.debian.org/cgi-bin/bugrepaort.cgi?bug=521515])
Basically, there are now two kernel module directories, both of which contain necessary files:
drwxr-xr-x 4 root root 4096 2010-01-20 05:43 linux-headers-2.6.32-trunk-amd64
drwxr-xr-x 4 root root 4096 2010-01-20 05:47 linux-headers-2.6.32-trunk-common
h2.
h1. Resolution
----
Copying the contents of these two directories into a temporary directory, with the proper makefile chosen, will allow the r1soft-cki process to compile a module successfully:
\\
{code}
cd /usr/src/
rsync -avz /usr/src/linux-headers-2.6.32-5-xen-amd64/ r1build/
rsync -avz /usr/src/linux-headers-2.6.32-5-common-xen/ r1build/
{code}
\\
Now, point the r1soft-cki utility to use your temporary directory, with the following flags added to the command:
*CDP2*
{code}
# /usr/bin/r1soft-cki --get-module --kernel-dir /usr/src/r1build
{code}
*CDP3 *
{code}
# /usr/bin/r1soft-setup --get-module --kernel-dir /usr/src/r1build
{code}\\
\\
\\
After a successful build, you can delete the temporary directory, restart the agent, and enjoy Continuous Data Protection\!
{code}
rm -r /usr/src/r1build
{code}
*CDP2*
{code}
/etc/init.d/buagent restart
{code}
*CDP3*
{code}
/etc/init.d/cdp-agent restart
{code}