Can't find updateNIDrivers for NIDAQMX-18.1

[dnessett]

---

@GabeJ wrote:

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.

---

Thanks for responding @GabeJ. Here is the output from yum list:

[dnessett@niDAQmx ~]$ yum list | grep kernel
abrt-addon-kerneloops.x86_64 2.1.11-52.el7.centos @anaconda
kernel.x86_64 3.10.0-957.el7 @anaconda
kernel.x86_64 3.10.0-957.12.2.el7 @updates
kernel-debug-devel.x86_64 3.10.0-957.12.2.el7 @updates
kernel-devel.x86_64 3.10.0-957.12.2.el7 @updates
kernel-headers.x86_64 3.10.0-957.12.2.el7 @updates
kernel-tools.x86_64 3.10.0-957.12.2.el7 @updates
kernel-tools-libs.x86_64 3.10.0-957.12.2.el7 @updates
erlang-kernel.x86_64 R16B-03.18.el7 epel
kernel-abi-whitelists.noarch 3.10.0-957.12.2.el7 updates
kernel-debug.x86_64 3.10.0-957.12.2.el7 updates
kernel-doc.noarch 3.10.0-957.12.2.el7 updates
kernel-tools-libs-devel.x86_64 3.10.0-957.12.2.el7 updates
libreport-plugin-kerneloops.x86_64 2.1.11-42.el7.centos base
lirc-disable-kernel-rc.noarch 0.10.0-16.el7 epel
php-symfony-http-kernel.noarch 2.8.12-2.el7 epel
texlive-l3kernel.noarch 2:svn29409.SVN_4469-43.el7 base
texlive-l3kernel-doc.noarch 2:svn29409.SVN_4469-43.el7 base
[dnessett@niDAQmx ~]$

As you can see: x86_64 3.10.0-957.12.2.el7 is the kernel headers version

uname -r  returns:

[dnessett@niDAQmx ~]$ uname -r
3.10.0-957.el7.x86_64
[dnessett@niDAQmx ~]$

I think the problem is in Centos 7 the kernel headers have additional versioning information (i.e., .12.2) that doesn't show up in the kernel version.

I tried your second solution and it indicated that everything was up-to-date:

[dnessett@niDAQmx ~]$ sudo yum install kernel kernel-devel
[sudo] password for dnessett:
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
epel/x86_64/metalink | 18 kB 00:00
* base: centos.sonn.com
* epel: mirror.prgmr.com
* extras: mirror.sjc02.svwh.net
* updates: repos.lax.quadranet.com
base | 3.6 kB 00:00
extras | 3.4 kB 00:00
ni-software-2018 | 3.6 kB 00:00
updates | 3.4 kB 00:00
Package kernel-3.10.0-957.12.2.el7.x86_64 already installed and latest version
Package kernel-devel-3.10.0-957.12.2.el7.x86_64 already installed and latest version
Nothing to do
[dnessett@niDAQmx ~]$

So, I think the problem is NI doesn't understand that, at least in Centos 7, uname -r doesn't return sufficient information to identify the kernel headers version

Dan

[dnessett]

Well, perhaps this is a bug in uname running under kernel.x86_64 3.10.0-957.12.2.el7. I booted (in a different partition) Centos 7 running 3.10.0-957.12.1.el7 and tried uname -r:

[dnessett@localhost ~]$ uname -r
3.10.0-957.12.1.el7.x86_64
[dnessett@localhost ~]$

This is correctly identifying the bits (12.1) in the kernel version number that are not there in 12.2.  Not sure what is going on, as I am not a kernel version number expert.

[dnessett]

I have reported this as a bug in kernel 3.10.0-957.12.2.el7.x86_64 on the Centos 7 forum (uname -r bug report).

[rashp8]

Hi,

Thank you for coming out and sharing your pain regarding DAQmx installation. I have had my share of struggle while installing DAQmx 18.1 on my system running Red Hat Linux version 7.6. Although I did not get any error while installing, whenever I connected NI hardware (PXIe-1073 Chassis), I was getting this Kernel Panic error. This chassis comes with MXI interface to connect with the computer. For almost a month I kept trying to atleast detect this in RHEL7.6. I asked for NI tech support and they said their R&D team is working on it. All they asked me do is uninstall/reinstall the driver, generate a report and forward that to them. I did it atleast 10 times, still the issue did not get resolved. Frustrated, I stopped hoping it would work on my PC. They hinted that the issue maybe because of MXI cable interface. I am wondering is your chassis is having MXI cable or is it having embedded controller?

P.S.--I have attached the Kernel Panic error screenshot for your reference.

[GabeJ]

---

@dnessett wrote:

I have reported this as a bug in kernel 3.10.0-957.12.2.el7.x86_64 on the Centos 7 forum (uname -r bug report).

---

I'm seeing the same thing as the responders to your bug report. On a fresh Centos 7.6 install, uname -r yields 3.10.0-957.el7.x86_64.  After doing a "yum install kernel" and rebooting to the new kernel, uname -r shows 3.10.0-957.12.2.el7.x86_64.  Something is going on that is causing you not to boot into the updated kernel.

Regardless, you should be able to install kernel-devel-3.10.0-957.el7.x86_64 in conjunction with your running kernel 3.10.0-957.el7.x86_64 to get the NI software up and running.

[GabeJ]

---

@rashp8 wrote:

P.S.--I have attached the Kernel Panic error screenshot for your reference.

---

Have you updated to the latest NI Software stack?  That stack trace looks like problems with the HARDENED_USERCOPY kernel feature that was enabled beginning in RHEL/CentOS 7.6.  Those problems should have been resolved in the latest NI driver stack revision.

[dnessett]

Hi GabeJ,

Thanks for the info. However, "yum install kernel" didn't work for me:

[dnessett@niDAQmx ~]$ uname -r
3.10.0-957.el7.x86_64
[dnessett@niDAQmx ~]$ sudo yum install kernel
[sudo] password for dnessett:
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: repos.lax.quadranet.com
* epel: mirror.prgmr.com
* extras: mirrors.ocf.berkeley.edu
* updates: repos.lax.quadranet.com
Package kernel-3.10.0-957.12.2.el7.x86_64 already installed and latest version
Nothing to do
[dnessett@niDAQmx ~]$ uname -r
3.10.0-957.el7.x86_64
[dnessett@niDAQmx ~]$

When you say you did a fresh install of Centos 7.6, do you mean you installed from the ISO file? That is what I did. Since others can get the right version from uname -r, I was beginning to suspect the ISO file is the problem. Did you install from the Centos 7.6 ISO file or from an earlier version and then "yum instll kernel". If the former, then the ISO file isn't the problem, unless my copy is corrupted.

Regards,

Dan

[GabeJ]

---

@dnessett wrote:

Thanks for the info. However, "yum install kernel" didn't work for me:

I wouldn't expect it to.  You already have various versions of the kernel installed (kernel.x86_64 3.10.0-957.el7 and the latest, kernel.x86_64 3.10.0-957.12.2.el7) per your earlier post.  Since you already have the latest installed, yum install kernel will do nothing.  What I'm saying is that you are somehow not booted to the most recent kernel.  When you boot the system, are you given a menu that will allow you to select among the various installed kernel versions?

What I was saying is that, if for some reason you aren't able to boot to kernel.x86_64 3.10.0-957.12.2.el7 and are stuck in kernel.x86_64 3.10.0-957.el7, you should install the version of kernel-devel that corresponds to the kernel version you are running, which is kernel.x86_64 3.10.0-957.el7.  What does yum install kernel-devel-`uname -r` report?  Does it also do nothing?

When you say you did a fresh install of Centos 7.6, do you mean you installed from the ISO file?

Yes. I installed from the CentOS 7.6 x64 ISO into a Hyper-V VM. uname -r showed 3.10.0-957.el7.x86_64.  I did yum install kernel to install the latest kernel version.  When I rebooted the boot menu gave me the option of booting into kernel 3.10.0-957.el7.x86_64 or kernel 3.10.0-957.12.2.el7.x86_64.  I selected 3.10.0-957.12.2.el7.x86_64, and uname -r then showed 3.10.0-957.12.2.el7.x86_64.

[dnessett]

---

@GabeJ wrote:

---

Yes. I installed from the CentOS 7.6 x64 ISO into a Hyper-V VM. uname -r showed 3.10.0-957.el7.x86_64.  I did yum install kernel to install the latest kernel version.  When I rebooted the boot menu gave me the option of booting into kernel 3.10.0-957.el7.x86_64 or kernel 3.10.0-957.12.2.el7.x86_64.  I selected 3.10.0-957.12.2.el7.x86_64, and uname -r then showed 3.10.0-957.12.2.el7.x86_64.

---

OK, I think I have found the problem, but I don't know how to fix it. I multi-boot the machine on which I installed CentOs 7.6 and control the grub2 menu from another CentOs installation running an older version of the kernel (12.1). When I run grub2-mkconfig, it isn't picking up the 12.2 kernel on the partition in which is installed 7.6 (12.2). Here is the output of grub2-mkconfig:

=============

[dnessett@localhost ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
[sudo] password for dnessett:
Generating grub configuration file ...
Found background: /boot/Windbuchencom.tga
Found linux image: /boot/vmlinuz-3.10.0-957.12.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-957.12.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-957.10.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-957.10.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-957.5.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-957.5.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-957.1.3.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-957.1.3.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-862.14.4.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-862.14.4.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-74546d29fe0647aab72add633b8d3390
Found initrd image: /boot/initramfs-0-rescue-74546d29fe0647aab72add633b8d3390.img
Found Dell Utility Partition on /dev/sda1
Found Ubuntu 14.04.1 LTS (14.04) on /dev/sda2
Found Windows 8 (loader) on /dev/sda3
Found Ubuntu 14.04.1 LTS (14.04) on /dev/sdb2
Found Ubuntu 14.04.1 LTS (14.04) on /dev/sdb5
Found CentOS Linux release 7.6.1810 (Core) on /dev/mapper/centos-root
done
[dnessett@localhost ~]$

=============

As you can see, it found CentOS 7.6, but only one kernel. /dev/mapper/centos-root is where "/" is mounted. This seems to be a change, as normally I would expect it to say  /dev/sdb8 (which is the partition on which I loaded CentOS 7.6). Anyway, mkconfig running on a different OS doesn't seem to find the different kernels available on other partitions (or perhaps I misunderstand something. I am not an expert on grub2-mkconfig).

[dnessett]

Fixed. See Solution on CentOS forum.