NFS copy of filesystem used with pxeboot doesnt load daqmx device drivers

[GabeJ]

Do other tools (nilsdev, system-report) work properly?

[RVallieu]

Negative, I tried nilsdev --verbose to try a different tool and got the same error message.

[RVallieu]

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?

[RVallieu · Accepted solution]

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.

[GabeJ]

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.

[RVallieu]

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.

[GabeJ]

---

@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.

[RVallieu]

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.

[GabeJ]

What versions of NI drivers are you using?  I don't think the initramfs exclusion went in until the 2021 Q3 driver stack.

[RVallieu]

Ah sorry, left that bit of info out - 

LabVIEW 2019 SP1 and LabVIEW Device Drivers 2019