Can't find updateNIDrivers for NIDAQMX-18.1

[dnessett]

Hello,

I am trying to get the NI drivers installed under kernel (3.10.0-862.14.4.el7) to run under a new kernel (3.10.0-957.10.1.el7). I am getting a "libnipalu.so failed to initialize" error and from what I have read I need to run updateNIDrivers. Supposedly, under Centos7.5, this should be found in /usr/local/bin. However, it is not there. Is it located elsewhere? Do I need to download it separately?

Thanks,

Dan Nessett

[dnessett]

In an attempt to work around the problem, I booted the old kernel and using yum removed kernel-devel. This also removed ni-daqmx. I then booted the new kernel and used yum to reinstall kernel-devel and then ni-daqmx. Both of these installs worked.

However, I am still getting "libnipalu.so failed to initialize" when running software using the ni-daqmx C-library (itom with the nidaqmx plugin).

Dan Nessett

[GabeJ]

Does "lsmod" show any NI kernel modules loaded?

[dnessett]

---

@GabeJ wrote:

Does "lsmod" show any NI kernel modules loaded?

---

Nope.

[dnessett@localhost ~]$ lsmod | grep ni
[dnessett@localhost ~]$

(I also looked manually at lsmod output without the grep and could find nothing that looked like an ni kernel module).

From what I have read, the "libnipalu.so failed to initialize" message frequently occurs when the kernel version is different from the installed kernel headers version. But that is not the case in this instance:

[dnessett@localhost ~]$ yum list | grep kernel
abrt-addon-kerneloops.x86_64 2.1.11-52.el7.centos @base
kernel.x86_64 3.10.0-862.el7 @anaconda
kernel.x86_64 3.10.0-862.14.4.el7 @updates
kernel.x86_64 3.10.0-957.1.3.el7 @updates
kernel.x86_64 3.10.0-957.5.1.el7 @updates
kernel.x86_64 3.10.0-957.10.1.el7 @updates
kernel-abi-whitelists.noarch 3.10.0-957.10.1.el7 @updates
kernel-devel.x86_64 3.10.0-957.10.1.el7 @updates
kernel-headers.x86_64 3.10.0-957.10.1.el7 @updates
kernel-tools.x86_64 3.10.0-957.10.1.el7 @updates
kernel-tools-libs.x86_64 3.10.0-957.10.1.el7 @updates
texlive-l3kernel.noarch 2:svn29409.SVN_4469-43.el7 @base
erlang-kernel.x86_64 R16B-03.18.el7 epel
kernel-debug.x86_64 3.10.0-957.10.1.el7 updates
kernel-debug-devel.x86_64 3.10.0-957.10.1.el7 updates
kernel-doc.noarch 3.10.0-957.10.1.el7 updates
kernel-tools-libs-devel.x86_64 3.10.0-957.10.1.el7 updates
libreport-plugin-kerneloops.x86_64 2.1.11-42.el7.centos base
lirc-disable-kernel-rc.x86_64 0.9.0-21.el7.nux nux-dextop
lirc-disable-kernel-rc.noarch 0.10.0-16.el7 epel
php-symfony-http-kernel.noarch 2.8.12-2.el7 epel
texlive-l3kernel-doc.noarch 2:svn29409.SVN_4469-43.el7 base
[dnessett@localhost ~]$ uname -r
3.10.0-957.10.1.el7.x86_64
[dnessett@localhost ~]$

Dan

[GabeJ]

What does "sudo dkms autoinstall" produce?

[dnessett]

---

@GabeJ wrote:

What does "sudo dkms autoinstall" produce?

---

[dnessett@localhost ~]$ sudo dkms autoinstall
[sudo] password for dnessett:
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/ni1045tr/18.0.0f0/source/dkms.conf does not exist.
[dnessett@localhost ~]$

[dnessett]

My apologies. I should have done some more exploring and included the results in my last message.

I don't understand the architecture of the ni C software, but it is plain something is misconfigured. Here is some evidence:

[dnessett@localhost 18.0.0f0]$ pwd
/var/lib/dkms/ni1045tr/18.0.0f0
[dnessett@localhost 18.0.0f0]$ ls
3.10.0-862.el7.x86_64 source

[dnessett@localhost 18.0.0f0]$ ls -al
total 12
drwxr-xr-x. 3 root root 4096 Oct 29 15:06 .
drwxr-xr-x. 4 root root 4096 Apr 27 15:52 ..
drwxr-xr-x. 3 root root 4096 Oct 29 15:06 3.10.0-862.el7.x86_64
lrwxrwxrwx. 1 root root 26 Oct 29 14:50 source -> /usr/src/ni1045tr-18.0.0f0

The soft link to /usr/src/ni1045tr-18.0.0f0 is blinking, indicating it doesn't exist.

[dnessett@localhost 18.0.0f0]$ cd /usr/src
[dnessett@localhost src]$ ls
debug nicmrk-18.1.1f0 niesrk-18.1.1f0 nimru2k-18.2.2f0 nipxicidk-18.0.1f0 niraptrk-18.1.1f0 nistc2k-18.1.1f0 nixsrk-18.1.1f0
kernels nicntdrk-18.0.1f0 nifslk-18.1.1f0 nimsdrk-18.1.1f0 nipxifpk-18.0.1f0 niscdk-18.1.1f0 nistc3rk-18.1.1f0 Python-3.7.0
ni1045tr-18.0.1f0 nicondrk-18.1.1f0 nihorbrk-18.1.1f0 nimxdfk-18.2.3f0 nipxigpk-18.0.1f0 nisdigk-18.1.1f0 nistcrk-18.1.1f0 Python-3.7.0.tgz
nicdcck-18.1.1f0 nidimk-18.2.2f0 nikal-18.2.0f0 nimxik-18.0.1f0 nipxim2-18.0.1f0 nismbus-18.0.1f0 niswdk-18.1.1f0
nicdrk-18.1.1f0 nidmxfk-18.1.1f0 nilmsk-18.1.1f0 niorbk-18.2.3f0 nipxiocp-18.0.1f0 nismbusw-18.0.1f0 nitiork-18.1.1f0
nicmmk-18.0.1f0 nidsark-18.1.1f0 nimdbgk-18.2.3f0 nipalk-18.2.1f0 nipxirmk-18.0.1f0 nissrk-18.1.1f0 niwfrk-18.1.1f0
[dnessett@localhost src]$

ni1045tr-18.0.1f0 exists in /usr/src, which suggests the ni software has been updated, but the directory structure hasn't (i.e., /var/lib/dkms/ni1045tr/18.0.0f0 should be /var/lib/dkms/ni1045tr/18.0.1f0 and softlinks adjusted appropriately.

[dnessett]

No one seems able to help, but I will plod ahead in case someone (anyone?) is out there listening. It appears an old version of nidaqmx was installed and not properly removed. Let me state for the record, that I have always used yum to install packages and have never manually fooled around with any ni software.

Here is the current ni software installed:

[dnessett@localhost ~]$ yum list | grep nida
libnidaqmx.x86_64 18.1.0.49155-0+f3 @ni-software-2018
libnidaqmx-devel.x86_64 18.1.0.49155-0+f3 @ni-software-2018
libnidaqmx-doc.noarch 18.1.0.49155-0+f3 @ni-software-2018
libnidaqmx-labview.x86_64 18.1.0.49152-0+f0 ni-software-2018

Once again here is the error I get from dkms autoinstall:

[dnessett@localhost ~]$ sudo kdms autoinstall
[sudo] password for dnessett:
sudo: kdms: command not found
[dnessett@localhost ~]$ sudo dkms autoinstall
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/ni1045tr/18.0.0f0/source/dkms.conf does not exist.

For some reason dkms is looking for a configuration file associated with 18.0.0f0, not with the installed version 18.1.0.49155-0+f3.

The version ni-daqmx thinks it is running is neither of these:

[dnessett@localhost ~]$ cat /usr/share/ni-daqmx/nidaqmx.version
18.1.1f0

(I.e., it thinks it is running 18.1.1, whereas the yum list thinks 18.1.0 is installed.

At this point, I would like to clean out all nidaqmx files and try to reinstall it. I have tried using yum remove, but it seems to leave things hanging around. If there is anyone out there that can tell me how to manually clean up the directory structure (after running yum remove), I would greatly appreciate it.

[dnessett]

OK, I'm just acting like a good neighbor here, since no one from NI seems to monitor this forum, or if they do, they don't reply. I gave up trying to figure out how to fix the messed up NIDAQMX installation on my system. I grabbed some disk space, created a new partition and loaded Centos 7.6 on it. I then followed the instructions at http://www.ni.com/download/ni-linux-device-drivers-2018/7664/en/ and http://www.ni.com/product-documentation/54754/en/ and installed a fresh copy of the NI software (18.1.1.49153-0+f1) on my new squeaky clean OS installation. Everything seemed to install properly, but when I ran sudo dkms autoinstall, it vomited the following error messages:

[dnessett@niDAQmx Downloads]$ sudo dkms autoinstall
[sudo] password for dnessett:
Error! echo
Your kernel headers for kernel 3.10.0-957.el7.x86_64 cannot be found at
/lib/modules/3.10.0-957.el7.x86_64/build or /lib/modules/3.10.0-957.el7.x86_64/source.
Error! echo
Your kernel headers for kernel 3.10.0-957.el7.x86_64 cannot be found at
/lib/modules/3.10.0-957.el7.x86_64/build or /lib/modules/3.10.0-957.el7.x86_64/source.

[Lots more of these] ......

The problem is our friends at NI don't seem to understand the kernel versioning system used in Centos 7 (not that I do, but one would think they would test their pkgs before publishing them and notice things don't work too well). Anyway, I looked at "lib/modules/3.10.0-957.el7.x86_64" and noticed that the build entry (a softlink) was blinking, which means it referenced a non-existent directory. Specifically, /usr/src/kernels/3.10.0-957.el7.x86_64. So, I looked at /usr/src/kernels and found this:

[dnessett@niDAQmx kernels]$ ls
3.10.0-957.12.2.el7.x86_64 3.10.0-957.12.2.el7.x86_64.debug
[dnessett@niDAQmx kernels]$

dkms wasn't finding /usr/src/kernels/3.10.0-957.el7.x86_64 because the kernel version was 3.10.0-957.12.2.el7.x86_64. Now, I have no idea what all the little doo-dads comprising the kernel version mean, but when I changed the softlink lib/modules/3.10.0-957.el7.x86_64/build to /usr/src/kernels/3.10.0-957.12.2.el7.x86_64, dkms worked just fine.

As I said, I decided to be a good neighbor and document this in case someone else runs into the same problem. However, I suspect the NI folks aren't really up to the task they have set for themselves and other problems are likely to crop up that won't be solved in this way.

In case some reading this think I am being a bit snotty, I did software development before retiring and one of the cardinal principles of the firms I worked for was "TEST BEFORE YOU SHIP". A simple test would have revealed this problem and it seems this is not part of the development process at NI.

[GabeJ]

The NI software depends on the kernel-devel package.  As you've found, the version of this needs to match that of your running kernel.  If you have no installed kernel-devel package, the kernel-devel package that gets pulled in from CentOS will be the latest version published in the CentOS repositories for that version (7.6) of the distribution.  If you do already have a kernel-devel package, it will satisfy the dependency and will not be updated.  In either case, if the resulting installed kernel-devel doesn't match the running kernel, this results in the failure that you saw.

There are a couple of solutions that don't involve symlinking to the wrong version of the kernel headers:

• Install the matching version of kernel-devel e.g., yum install kernel-devel-`uname -r`
• Update both kernel and kernel-devel to the latest versions e.g., yum install kernel kernel-devel

The first solution is lighter weight, but it depends on the availability of that version of kernel-devel.  I've seen occasional instances where CentOS has made older kernel and kernel-devel packages completely unavailable.