Kernel configure problem when installing NIDAQmx 3.2 on fedora 15

[AstroClimber]

Hi I encountered the kernel configuration problem when I try to install the driver NIDAQ_mx BASE 3.2 on Fedora 15 which has 2.6.43 kernel. Here is the error

******************************** ERROR ****************************************

* Kernel source in /lib/modules/2.6.43.8-1.fc15.x86_64/source does not appear to be

* configured for the 2.6.43.8-1.fc15.x86_64 kernel.

* Configuration of kernel source is required to continue installation.        *

* Refer to the README file for the product you are installing for information *

* about configuring your kernel source.                                       *

******************************** ERROR ****************************************

Installation aborted.

And this problem seem to be addressed in the README.txt file by NI, but that's direct to SUSE linux only. So all the steps they told me to do is not feasible in Fedora. Do you or anyone have any suggestion for me to get through this?

Q2: During installation I get a message similar to the following one:

    "Kernel source does not appear to be configured for the running kernel.

     Configuration of kernel source is required to continue installation."

    I do have kernel sources installed; is there anything else that needs to

    be done?

A2: This problem has been seen on SUSE LINUX Professional 9.1 running the 2.6.5

    kernel or newer versions of SUSE LINUX Professional. However, it is possible

    that other distributions will require similar steps to resolve this problem.

    On SUSE LINUX Professional complete the following steps:

    1. Ensure you have installed kernel-source and kernel-syms packages

       corresponding to the version of the currently running kernel. The version

       of the currently running kernel can be determined by issuing the command

       `uname -r`.

    2. Change the directory to the /usr/src/linux-<version> directory, where

       <version> corresponds to the currently running kernel version.

    3. Run "make cloneconfig" as root to configure the sources for the

       currently running kernel.

    4. Run "make modules_prepare" as root to prepare the headers for

       compilation.

    5. THIS STEP IS STRICTLY OPTIONAL. Completing this step removes the

       warning:

       WARNING: Symbol version dump /usr/src/linux/Module.symvers is missing,

                modules will have CONFIG_MODVERSIONS disabled.

       Run "make modules" as root to compile all modules and generate

       Module.symvers; this step may take 30 minutes or more to complete.

    6. Run the INSTALL script for the NI-DAQmx Base software for Linux from this

       directory.

Thanks in advanced

[BradM]

As I recall, in RedHat-esque distros, the packages to install to get the kernel headers are kernel-devel and kernel-headers. On a terminal, issue the command

$ yum search kernel

and install the promising-looking packages (note that you will need root priviledges to install packages)

[AstroClimber]

It seems like i have had these two packages installed already. When I tried to install them, it said nothing to do to them:

Package kernel-devel-2.6.43.8-1.fc15.x86_64 already installed and latest version

Nothing to do

Package kernel-headers-2.6.43.8-1.fc15.x86_64 already installed and latest version

Nothing to do

[BradM]

That means the folders are there in /lib/modules/? What fails or otherwise is the issue? The steps seem reasonable, note that they do call out that similar steps may fix other linux distros or versions.

[AstroClimber]

Sorry, I forgot to post the error message. I added that in the original post

And the problem is that when I tried to run 'make cloneconfig' in the directory /usr/src/kernels/2.6.43.8-1.fc15.x86_64, I got this

make[1]: *** No rule to make target `cloneconfig'.  Stop.

make: *** [cloneconfig] Error 2

[BradM]

Well, that would cause the issue that you are seeing. That said, you could achieve the same behavior by copying either the config for your running kernel (usually kept at /boot/, some kernels are configured to actually provide a /proc/config.gz file that contains the currently-booted kernel's configuration, if you have that you could gunzip that file to get the configuration as well) to the headers directory, renaming it ".config" in that directory.

The error is basically complaining that it can't find a kernel configuration for the header files that you've specified. Simply providing the configuration for the currently-running kernel in the location that it is expecting it to be in should be sufficient to get things moving.

[AstroClimber]

Which one is the headers directory you are refereing to?
And the config file you suggested me to copy from /boot, I saw a file named "config-2.6.43.8-1.fc15.x86_64" and a file named ".config", which one is it that I need to copy to the headers directory?

Thanks

[BradM]

There's a reasonable chance that the .config file is a symlink to the config-2.6... file or vice-versa. As for the header directory, it's whatever directory thata contains the headers for the particular version of the kernel that you are running, which according to the messages that you posted seems to be  /lib/modules/2.6.43.8-1.fc15.x86_64/source

[AstroClimber]

Thanks BradM for the help.

Unfortunately after I copy and change teh file's name over to .config to the the header directory, it doe snot seems to work either. I have checked the kernel-devel and kernel-headers, and they are all installed to the correct kernel version as the one returned by "uname -r".

Do you think I need to go into the config file itself can change the parameters myself, even though it said the file is automatically generated and direct me not to change it?

[BradM]

I wuold not recommend going ito the config and changing values as that would give the external daq module an incorrect view of how your running kernel is configured and would likely result in an unloadable module.

Unfortunately, without a bit more detail other than "it does not seem to work either" I can't really help further. Does it continue to fail in the same manner?