ni-kal dkms build fail on Pop!_OS 20.10

[outofculture]

Anyone else have ni-kal working on a 5.8.0 kernel? [Edit: I'm on Pop!_OS 20.10] Looks like the new kernel has some problems with nikal:

Setting up ni-kal (20.0.0.49152-0+f0) ...
Loading new nikal-20.0.0f0 DKMS files...
Building for 5.8.0-7625-generic
Building initial module for 5.8.0-7625-generic
ERROR (dkms apport): kernel package linux-headers-5.8.0-7625-generic is not supported
Error! Bad return status for module build on kernel: 5.8.0-7625-generic (x86_64)
Consult /var/lib/dkms/nikal/20.0.0f0/build/make.log for more information.
dpkg: error processing package ni-kal (--configure):
installed ni-kal package post-installation script subprocess returned error exit status 10

That referenced make.log file is attached.

[xyzzy42]

Same problem on Fedora 32 with kernel 5.8.14.

The first build error is because of kernel commit d56c0d45f0e27f814e87a1676b6bdccccbc252e9 that appeared in kernel 5.6, 7 months ago, which changed the arguments to proc_create_data().

It seems NI isn't keeping their kernel module up to date.

All I want to do is access a serial port, which uses an API that hasn't changed in decades.  It's ridiculous that it's necessary to load a proprietary binary-only kernel driver just to do this.  All other software on Linux can access serial ports just fine without needing extra kernel modules.

[outofculture]

---

Same problem on Fedora 32 with kernel 5.8.14.

Thanks for confirming. I'll update the thread title.

All I want to do is access a serial port, which uses an API that hasn't changed in decades.  It's ridiculous that it's necessary to load a proprietary binary-only kernel driver just to do this.  All other software on Linux can access serial ports just fine without needing extra kernel modules.

---

Seriously; I don't even want to access hardware, I'm just trying to install a library and header file to be able to work on a python wrapper. At a minimum, we need to disentangle all these packages.

Or if NI isn't going to be able to fix any of this, maybe we can just build a docker image that is known to work and use that, cumbersome though that may be.

[bstreiff]

---

@xyzzy42 wrote:

All I want to do is access a serial port, which uses an API that hasn't changed in decades.  It's ridiculous that it's necessary to load a proprietary binary-only kernel driver just to do this.

---

I can't speak to the ni-kal build failures, but what serial hardware are you trying to use? The PCI(e)/PXI(e) NI Serial devices are supported by the upstream 8250_pci driver, so they should be accessible with the standard Linux serial APIs.

[xyzzy42]

Docker wouldn't work.  It creates a containerized userspace but the kernel is still the host kernel.  So the NI proprietary kernel drivers still can't be used.  It would need to be a VM running an old Linux distro with a kernel that NI supports.

But trying to access non-virtualized hardware from inside a VM is generally terrible, so that wouldn't really work either.

In fact, since labview uses proprietary kernel drivers, even if one was using RHEL7 or something that was support, it would be impossible to install inside docker.

As a comparison, after updating to FC32, I had zero trouble getting GPS data over USB from an old Garmin GPS in QLandkarteGT.  That app was abandoned by its developers like 5+ years ago (shame, it's really nice).  So an app that hasn't been updated in years can build and use a USB GPS just fine on a current Linux distro, but the current version LabView can't access a serial port.  Maybe someone isn't doing things right?

[xyzzy42]

It's a FTDI based port, which works perfectly in Linux, but that doesn't matter.  To use it in Labview means one needs VISA.  And VISA needs the proprietary nipalk.ko kernel driver.  If the kernel driver isn't loaded, then loading libnipalu.so fails, and then Labview core dumps.

And that kernel module stopped working at least by kernel 5.6.

Basically, labview can't use standard Linux serial APIs, it needs a proprietary closed source kernel driver to access _anything_ with VISA.

[GabeJ]

---

@outofculture wrote:

---

Or if NI isn't going to be able to fix any of this

---

NI always does.  The focus is on support for more stable distributions (see the READMEs), so recently-released kernel support lags.  Those that need it sooner tend to update the source themselves.

[xyzzy42]

It's not that hard to port nikal to kernel 5.8.  I've now done that and got it sort of working.  The modules all load at least and nothing has crashed yet!  All the ktime functions are now GPL only, so that's going to be an issue for NI to solve if they won't make their modules GPL.

nikal is just a shim for the binary only nipalk module.  So if nipalk stops working there is no way to fix it except wait for NI.

The non-systemd start script for nipalps doesn't work with current distros either, so one needs to do something else to create the persistent data file and start nipalps.  And create /dev/nipalk, since they don't use udev and are still in the kernel 2.4 era with userspace helpers for device nodes.  I didn't think VISA 20 supposed anything that didn't have at least kernel 2.6 and udev.

Unfortunately for me, while labview no longer crashes when using visa, visaconf still doesn't work.  There's an error about being unable to load a dynamic library, but it doesn't say which one, so it's hard to know where to look.  It might be enough for the OP to get what he wants working if he doesn't need visaconf.

I was able to work around my issue.  While labview needs a proprietary kernel module to access standard serial ports, thankfully it can open an TCP socket without that.  So I used socat to connect my serial port to a socket, and now I can use the TCP open/send/receive elements with it.

[solaremperor]

I just happened upon the same issue on Ubuntu 20.04 LTS (Kernel 5.8.0-55-generic).

It seems to be across operating systems. I do agree with you that we need to be able to, at the very least, disentangle these packages. I want to be able to run nidaqmxconfig and add a few of PXI cards (PXI 6254, 6723, 6602) so I can develop custom C++ software.

Has there been any updates from NI on this?