Issues installing NI-VISA drivers on Ubuntu 22.04

[kd.nguyen]

Hi, I'm running into issues installing the NI-VISA drivers on Ubuntu 22.04. I've been following these instructions and have successfully installed the repository, but on step 5 with installing the driver packages, I'm running into errors. When installing NI-VISA, it installs a bunch of other dependencies, and ni-visa-passport-pxi and ni-visa-passport-pxi-dkms throws errors during installation. Further investigation into the logs and crash reports show that the module NiViPciK/.../build/nikal.h contains a "#include <stdbool.h>" that could not be found. I've tried installing clang and reinstalling gcc to no luck. 

Does anyone have insight how the module is usually built and how to fix the issue?

[maschmidt]

I'm running into this same issue, fresh install of Ubuntu 22.04 with 2023Q1 drivers. I can confirm that gcc knows where to find stdbool.h by running: `gcc -print-prog-name=cc1plus` -v and same with just 'cc1', which both show the expected location: /usr/lib/gcc/x86_64-linux-gnu/11/include.

I am using gcc version 11.3.0:

~$ gcc --version
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and I can compile and run a hello-world.c program that includes stdbool.h, so the error message is either misleading or incomplete. I can see that stdbool.h is the first header included in nikal.h so probably something is going wrong before then with the build.

I also notice this error message when I try to do: sudo apt install ni-visa

dpkg: error processing package ni-visa-passport-pxi-dkms (--configure):
installed ni-visa-passport-pxi-dkms package post-installation script subprocess returned error exit status 10

So it appears that it's trying to either load or create a dynamic kernel module during installation.

The full contents of the crash report file (/var/crash/ni-visa-passport-pxi-dkms.0.crash) are:

ProblemType: Package
DKMSBuildLog:
DKMS make.log for NiViPciK-22.5.0f69 for kernel 5.19.0-35-generic (x86_64)
Mon Mar 20 06:21:01 PM EDT 2023
Making NiViPciK.ko
warning: the compiler differs from the one used to build the kernel
The kernel was built by: x86_64-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
You are using: gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
COPY /var/lib/dkms/NiViPciK/22.5.0f69/build/NiViPciK-bin.o
CC [M] /var/lib/dkms/NiViPciK/22.5.0f69/build/NiViPciK-interface.o
In file included from /var/lib/dkms/NiViPciK/22.5.0f69/build/NiViPciK-interface.c:7:
/var/lib/dkms/NiViPciK/22.5.0f69/build/nikal.h:13:10: fatal error: stdbool.h: No such file or directory
13 | #include <stdbool.h>
| ^~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:257: /var/lib/dkms/NiViPciK/22.5.0f69/build/NiViPciK-interface.o] Error 1
make[1]: *** [Makefile:1850: /var/lib/dkms/NiViPciK/22.5.0f69/build] Error 2
make: *** [Makefile:76: NiViPciK.ko] Error 2
DKMSKernelVersion: 5.19.0-35-generic
Date: Mon Mar 20 18:21:02 2023
Package: ni-visa-passport-pxi-dkms 22.5.0.49221-0+f69
PackageVersion: 22.5.0.49221-0+f69
SourcePackage: ni-visa-passport-pxi-dkms
Title: ni-visa-passport-pxi-dkms 22.5.0.49221-0+f69: NiViPciK kernel module failed to build

[Mason.Chou]

Have the same issue too. Using 2023Q1 drivers on Ubuntu 22.04.

Hopefully someone in NI can look into this and fix it.

[Mason.Chou]

So I did some hacking today and found two workarounds (one that "works on my machine", other is theoretical).

The main issue that's causing this is the lack of stdbool.h, stderr.h and stddef.h in the kernel header files. Normally for code that resides in kernel space, you are suppose to be using the kernel variant: <linux/types.h>, <linux/stderr.h>, <linux/stddef.h>

There's a header file called nikal.h which is importing the userspace headers instead of the kernel. 

This seems to be a common problem other drivers are also facing. Started on Linux kernel 5.16 (see this post)

WARNING: THERE ARE RISK INVOLVED IN THESE WORKAROUNDS. USE ONLY ON MACHINES THAT YOU ARE COMFORTABLE WITH CRASHING.

NO TESTS WAS PERFORMED ON THESE WORKAROUNDS AND REALLY NI SHOULD BE DEPLOYING A  FIX.  

Workaround 1 (works on my machine):

The workaround I've done is to modify nikal.h to and replace the header files to the kernel variants. Basically do the following:

/**  This header file declares the NI Kernel Abstraction Layer for Linux

    Copyright 2001-2022,
    National Instruments Corporation.
    All rights reserved.

    originated:  19.mar.2001
**/

#ifndef     ___nikal_h___
#define     ___nikal_h___

// Correct imports for kernel-space code.
#include <linux/types.h> 
#include <linux/stdarg.h>
#include <linux/stddef.h>

// Original imports, comment this out or removal entirely.
// #include <stdbool.h>
// #include <stdarg.h>
//#include <stddef.h>

Issue with this, is that nikal.h is used throughout multiple packages and you would have to manually change the nikal.h on each package/driver. Here's a bash script that can help you find all nikal.h that you would need to fix.

```bash

cd /var/lib/dkms

find -L . -type f -wholename "*/source/nikal.h"

```

What I did was take the modified nikal.h from /var/lib/dkms/nikal/*/source and copied it to the other packages. This is probably a bad idea, but in my mind, nikal.h should be the same in all packages.

Afterwards, you should be able to run sudo apt install or sudo dkms autoinstall to build and install the drivers. Note that you would have to do this every time an update for a package occurs (unless NI fixes this issue).

Workaround 2 (in theory):

In theory, you should be able to copy or link the user space header files to kernel space. From the many posts I've read, Linux kernel developers has been against this and stresses on the importance of separating user space and kernel space (hence why we are running into this issue now).

If you don't want to modify NI's source code, you could ignore this warning.

Your gcc installation (/usr/lib/gcc/*/*/include) has the header files that are missing (stdbool.h, stdarg.h, stddef.h). I'm not sure where you would copy/symlink those files though. Maybe you can start with /usr/include and then go try /lib/modules/*/build/include? 

[maschmidt]

Mason, thanks for digging into this, much appreciated. Unfortunately, if this level of hacking is required to get them to work on perhaps the most popular Linux distribution in the world, then it seems that the NI Linux drivers are just not ready for production use.

I'm going to forward this thread to my NI sales rep to see if we can get an engineer to look into this issue, and I'll update this thread when I hear back.

[dousley]

Most NI drivers on Linux use an internal abstraction layer called NI-KAL. KAL had exposure to this issue from the kernel bump and released a fix in 2022Q4. But any drivers that didn't rebuild and re-release in 2022Q4 or 2023Q1 still use an older version  of KAL and are therefore still exposed to the issue. 

NI-VISA is one of those drivers. It's about to rerelease (probably within 2-3 weeks) and will have the updated NI-KAL (and therefore the fix). The 488.2 driver and the NI-Sync driver are the only ones that will still be broken as they haven't had a release since the fix in NI-KAL and aren't having a new release in 2023Q2. 

---

This is what we are in the process of vetting as a solid workaround for the remaining affected drivers:

After running

sudo apt install <ni-driver> 

(or equivalent yum or zypper command)

Edit the /usr/src/{driver}-{version}/Kbuild (or /usr/src/ni-sync-pxi6683-{version}/src/Makefile) file and add the following under the existing EXTRA_CFLAGS lines:
EXTRA_CFLAGS += -isystem $(shell $(CC) -print-file-name=include)

Then rerun
sudo apt install <ni-driver> 

(or equivalent yum or zypper command)

---

Sorry I didn't see this post sooner, it's a known issue that we were overly slow to get published. We're slowly making progress toward the goal of having this type of issue fixed, or at the least have a public bug report and a workaround, before a problematic kernel gets pulled into the default Ubuntu installer. I think this is one that we knew about well enough in advance to get published into the known issues list for the Linux Device Drivers months ago, but just didn't have the process in place to make sure it was published. We are in discussions to make sure that doesn't continue to happen.

For discussion with other Linux users from NI, please check out the NI Linux User Group and forum. It can also be a good place to provide feedback on the way you'd like to see things working differently.

Daniel Ousley

NI Product Manager - Linux HW & SW

[maschmidt]

Thanks very much for the detailed response, much appreciated, and looking forward to the next release. Also very interested to see what NI has planned as a longer term solution to avoid issues like this in the future. Thanks again

[EFalcione]

I ran in to this same problem. I ended up reverting to an older version of Ubuntu (with an older kernel version) in order to get the install to work.

Here's what worked for me:

1) I imaged my computer with Ubuntu 20.04.5 from August 2022, which I downloaded from here.

2) Settings -> about -> os name shows Ubuntu 20.04.5 LTS

3) Type uname -r in the terminal to view your kernel version - mine is 5.15.0-69-generic

4) download NIDAQMX drivers version 2022 Q2

5) follow instructions from here to install the drivers - ***but don't do step 1 under the Ubuntu drop down because that might update your kernel to an incompatible version***

After installing necessary python packages, I was able to successfully run the basic example from this website and get an analog read from my DAQ:

import nidaqmx
with nidaqmx.Task() as task:
    task.ai_channels.add_ai_voltage_chan("Dev1/ai0")
    task.read()

[jrrk]

As some people said stdbool.h no longer works in kernel code from 5.16.x kernel onwards, you can revert to an earlier kernel by adding this line to /etc/default/grub:

GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.15.0-58-generic"

you then need to run 'sudo update-grub' to update the boot loader config, and reboot. You should see a message similar to this after rebooting when 'name -a' is typed:

Linux user-NUC10i7FNK 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Now the frustrating thing is, it still doesn't work. This is because the headers for kernel 5.19 are still installed and kms still tries to build for that kernel even though it is not active. You can solve this problem using '

sudo apt remove linux-hwe-5.19-headers-5.19.0-41' or whatever unwanted header package you have (which you can find out using 'ls -l /usr/src/linux-headers-*')

Hope this helps somebody

[nsulmol]

Hello all,

I tried the approach described by Daniel Ousley, but unfortunately it did not resolve all issues (and I personally prefer Mason Chou's approach, although it may very well be less safe!).

I am not a fan of the official patch fix (appending the EXTRA_CFLAGS to each appropriate library), because:

1. It is not a universal fix:
   1. It uses 'shell', which assumes your linux version is using shell and not bash (or zsh or fzf, for example).
   2. It assumes your failing libraries contains a Kbuild and/or Makefile already prepared (and instructs you to go to /usr/src). On my machine, there was no Kbuild or Makefile in /usr/src, only in /var/lib/dkms/<libname>/<libversion>/source. From my understanding, this is expected, as dkms should build in the /var/lib/ location, and leave source untouched in /usr/src (but I may be wrong). In my case, I also did not have EXTRA_CFLAGS in the Makefile (and did not seem to have a Kbuild set up), so I manually ran ./configure after modifying it to append the EXTRA_CFLAGS.
2. It is painstaking to do this for all files, as you have to find the appropriate EXTRA_CFLAGS and manually fix it where needed. (There is probably a scripted way to do this, but it was easier for me to script the alternative solution).

Additionally, this did not resolve all issues, because there is *an additional fix* needed if you are using a kernel >= 5.17. As can be seen here: since then the struct PDE_DATA was renamed pde_data. Nikal.c uses this struct, so without fixing it, the kernel module cannot be compiled.

This is what I did to build on my system, following Mason Chou's initial guidance.

The same disclaimer applies: this is a personally tested approach, and is provided as-is. You should use the official NI fix if you want any guarantee it will work.

Note: the above instructions will assume Ubuntu 22.04 and as such will use apt / bash. Please adapt these as needed for your distro.

1. Install your kernel headers:
   #+begin_src bash
     sudo apt install linux-headers-$(uname -r)
   #+end_src
2. Perform the initial install (this will fail):
   #+begin_src bash
     sudo apt install ./ni-ubuntu2004-drivers-2022Q4.deb
     sudo apt update
     sudo apt install ni-488.2
   #+end_src
3. Fix the kernel code:
   1. Fix nikal.c:
      
      1. Find nikal.c, it should be in /usr/src/nikal_xxxx/. We will want to modify it, but will need sudo privileges (so open it in your preferred editor with sudo rights).
      2. After #define ___nikal_c___, add a line: #define PDE_DATA pde_data.
   2. Fix nikal.h:

      1. Find a version of nikal.h to change (they will be located in *many* kernel modules). I preferred to grab the version in ni-488.2, as it had comments not visible in the other ones (or at least, in nikal). Open this with sudo rights.

      2. Comment out the first 3 #include lines:
         #+begin_src
         // Wrong / broken includes for kernel-space
         //#include <stdbool.h>
         //#include <stdarg.h>
         //#include <stddef.h>
         #+end_src

      3. Add the following kernel equivalent lines:
         #+begin_src
         // Correct imports for kernel-space code.
         #include <linux/types.h>
         #include <linux/stdarg.h>
         #include <linux/stddef.h>
         #+end_src

      4. Replace all faulty nikal.h files with this one:

         For this, we will list all nikal.h's in /usr/src/, and then copy the one we just modified into it.

         #+begin_src bash
         sudo find /usr/src/ -name "nikal.h" -execdir cp /usr/src/ni488k-22.8.0f116/nikal.h . \;
         #+end_src

         Note: you may need to replace the ni-488 directory with yours, if the version number is different.

         ---

4. Finalize the install:
   1. Re-run install:
      #+begin_src bash
        sudo apt install ni-488.2
      #+end_src
   2. Finalize (according to general instructions):
      #+begin_src bash
        sudo dkms autoinstall
      #+end_src
   3. Reboot your PC!

I hope this helps someone else. Thanks to Daniel Ousley and Mason Chou, as I would have been completely lost without the guidance.

Thank you,
- nsulmol