ni.com checkout is currently experiencing issues.
Support teams are actively working on the resolution.
ni.com checkout is currently experiencing issues.
Support teams are actively working on the resolution.
05-24-2022 04:14 PM
Do other tools (nilsdev, system-report) work properly?
05-24-2022 04:15 PM
Negative, I tried nilsdev --verbose to try a different tool and got the same error message.
05-25-2022 11:46 AM - edited 05-25-2022 11:47 AM
Ah - we might have missed a step and this may be the solution:
https://access.redhat.com/solutions/47028
How can I ensure certain kernel modules are included in the initrd or initramfs in RHEL?
05-25-2022 01:27 PM
Ok this seems to have worked but the final solution has me baffled.
We built the new initramfs and added a /etc/dracut.conf.d/newsystem-dracut.conf with the space delimited list of NI modules to include.
We built this list from the lsmod list of the working disk booted RHEL 7.9 system that has no problem with the HW drivers and runs the code perfectly well.
Tried then doing the pxe boot with the new initramfs with those drivers as being verified as installed in the image through
lsinitrd /boot/initramfs-newsystem.img
When we pxe booted the system - it again failed to load the DAQmx driver.
Then we looked the list of installed drivers from my OTHER disk booted system and noticed that the pxe boot initramfs image was missing ni-serial module.
Went to the RHEL 7.9 system, did the yum install of niserial
Went back and added that to the dracut.conf.d file - and then rebuilt the initramfs with that added and took a new rsync copy of the file system for the NFS.
PXE boot again...
This time the system WORKED! I will reboot PXE boot again and verify.
I am very confused as to why this would work, when the original RHEL 7.9 disk boot image DOES NOT HAVE niserial module installed but the EXE works fine and can call DAQmx.
But - I'll take the win.
05-25-2022 02:25 PM
I had a hard time following all of that!
Maybe adding ni-serial was just a red herring and it was just the act of rebuilding the initramfs that did...something?
Also, by default all NI kernel modules should be excluded from initramfs (see /usr/lib/dracut/dracut.conf.d/50-exclude-ni-drivers.conf), as there are often problems when the drivers are in initramfs.
05-25-2022 03:05 PM - edited 05-25-2022 03:12 PM
Well we built the initramfs twice today and only when including the drivers did it work this time... hmm.
Is that exclusion file you reference found on NI Linux RT?
We're on RHEL 7.9 - booting into GNOME so we can run Desktop and use that to run the EXE automatically since we're still having issue with the RHEL running LabVIEW Embedded Run-time.
05-25-2022 03:19 PM - edited 05-25-2022 03:19 PM
@RVallieu wrote:
Well we built the initramfs twice today and only when including the drivers did it work this time... hmm.
🤷
Is that exclusion file you reference found on NI Linux RT?
The configuration file is only installed on RPM-based distributions (openSUSE & RHEL/CentOS in NI's case), so not on Ubuntu and not on NI Linux RT.
05-25-2022 03:22 PM - edited 05-25-2022 03:37 PM
Now I am very confused as we're on RHEL 7.9 and that file is nowhere to be found on the entire system.
Perhaps there was an issue with our original LabVIEW installation onto our RHEL 7.9 machine, but we had no indication that something was wrong, no problems in LabVIEW Dev environment, building EXEs, etc. until we went to do this pxe boot and ran into the issue of the driver not loading.
I don't pretend to know enough to know the difference between:
1. RHEL loading from hard disk initramfs and then loading from disk root file system
and
2. pxe boot initramfs and loading root file system as NFS
as to the different requirements that might exist for the initramfs inclusiongs.
05-25-2022 04:21 PM
What versions of NI drivers are you using? I don't think the initramfs exclusion went in until the 2021 Q3 driver stack.
05-25-2022 04:23 PM
Ah sorry, left that bit of info out -
LabVIEW 2019 SP1 and LabVIEW Device Drivers 2019