Installing NI4882 and NIVISA to Ubuntu 8.10

[dicky yu]

Hi, sorry if I posted this to the wrong forum board (don't know why I could not register to this board: NI Home ->Communities -> Groups -> Linux Users -> Discussions).

I need to install NI4882 and NIVISA into my Ubuntu box (I used BlankOn 4.0 which is a derivative of Ubuntu 8.10). I tried to follow mtblanc's guidance to no avail. nikal.ko could be loaded using modprobe, but nipalk and gpibprtk modules could not be found.

in the spirit of trial and error, I tried the method suggested someone (sorry, I did not manage to find the post again) to reinstall the rpm packages manually 1 by 1 by this sequence: nipali-2.4.0-f0.i386.rpm, nispyi-2.6.0.f0.i386.rpm, labview-rte82-rte-8.2.1-2.i386.rpm, ni4882betai-2.5.1-b1.i386.rpm.
the installation was performed in following manners:
 alien --scripts -d *.rpm
 dpkg -i *.deb
 rpm -ivh *.rpm --nodeps

however,the nipalk and gpibprtk still could not be loaded. when I called gpibexplorer, the GUI appeared for a while and then closed. The error message is:
  libnipalu.so failed to initialize
  Perhaps you need to run updateNIDrivers
  Aborted

when I ran updateNIDrivers, seems that only nikal.ko was updated. hence when I called gpibexplorer again (after rebooting the pc), I still got the same result.
For your reference, I attached the result of running niSystemReport.

Understand that I have used the officially unsupported Linux distribution for this purpose. But considering that some members of this forum have successfully installed NI softwares/drivers/applications in Ubuntu, I really appreciate any suggestion that might work on my system.

Thanks,
Dicky

[Shawn B.]

Hey Dicky,

Running the included INSTALL scripts does more than simple installing the included rpms, which is why converting the rpms to deb packages does not result in a working install.  In theory it is possible to run those extra steps manually after you install each of the deb packages.  I attempted to explain what needs to be done in this post.

Shawn Bohrer

National Instruments

[dicky yu]

Hi Shawn,

Thanks for your response.

I could confirm your suggestion to use the included INSTALL script could work for NI-488.2-beta-25.1b1 on a fresh Ubuntu9.04, provided that nikal had been intsalled (I used nikali1.10beta). Oh, how I wish I knew this sequence from the beginning.

But it seems that in my current system (Ubuntu8.10) I somehow messed up this sequence hence only nikal.ko could be loaded. I installed the packages from various sources (nikal, NI4882, NIVISA) and sometimes even forced to overwrite different package versions. Not sure if that is th reason, but now I am unable to cleanly uninstall those packages.

When I checked /usr/local/natinst, I have following unversioned modules:

./nipal/src/objects/nipalk-unversioned.o
./nikal/etc/clientkdb/nipal/nipalk-unversioned.o
./.nicore/src/objects/niorbk-unversioned.o
./.nicore/src/objects/nidimk-unversioned.o
./ni4882/src/objects/gpibprtk-unversioned.o

Running "<rpmBaseName>InstallerUtility.sh <rpmBaseName>PostInstall" only produced 1 symbolic link (nipal) in /usr/local/natinst/nikal/etc/clientkdb/.

Performing updateNIDrivers still only update the nikal module. Therefore the problem still remains the same.

Referring to your communication with Anshul Jain, will you suggest to install the packages from NI-VISA4.4 instead of NI-VISA4.5?

But considering that I can install nikal1.10 and NI4882 normally on a fresh system, I doubt that step is necessary.

Thanks and regards,

Dicky

[Shawn B.]

---

dicky yu wrote:

When I checked /usr/local/natinst, I have following unversioned modules:

./nipal/src/objects/nipalk-unversioned.o
./nikal/etc/clientkdb/nipal/nipalk-unversioned.o
./.nicore/src/objects/niorbk-unversioned.o
./.nicore/src/objects/nidimk-unversioned.o
./ni4882/src/objects/gpibprtk-unversioned.o

Running "<rpmBaseName>InstallerUtility.sh <rpmBaseName>PostInstall" only produced 1 symbolic link (nipal) in /usr/local/natinst/nikal/etc/clientkdb/.

Performing updateNIDrivers still only update the nikal module. Therefore the problem still remains the same.

---

Just to double check you did run:

. <rpmBaseName>InstallerUtility.sh

<rpmBaseName>PostInstall

for each rpm?  Also note the leading ". " which you left off in your quote.  That "sources" the script adding the <rpmBaseName>PostInstall function to your shell.  If you forget the ". " nothing will happen.  Oh and this will need to be done as root, you may need to "sudo su" on Ubuntu.

You mentioned updateNIDrivers still only updates the nikal.ko module.  Are you sure nipalk.ko wasn't produced?  Try running:

find /lib/modules/$(uname -r)/kernel/natinst/

If you did follow the steps above and it still didn't work then I'm guessing the problem is that your /bin/sh is a link to /bin/dash (the Ubuntu default) and our scripts still require bash.  I would recommend running:

sudo ln -sf /bin/bash /bin/sh

Then re-run all of the InstallerUtillty.sh/PostInstall steps, followed by updateNIDrivers.

To answer your last question I wouldn't worry about the specific versions of everything you installed.

Shawn Bohrer

National Instruments

[muellerp]

Hi Shawn,

I'm trying to do this on Debian Lenny, 2.6.26 kernel.

But I can not solve this issue.

Sources:

NI-488.2-beta-2.5.1b1.tar.gz  NIKAL110.isoNI-VISA-4.5.1.iso

Commands:

 find /lib/modules/$(uname -r)/kernel/natinst
/lib/modules/2.6.26-2-686/kernel/natinst
/lib/modules/2.6.26-2-686/kernel/natinst/nikal
/lib/modules/2.6.26-2-686/kernel/natinst/nikal/nikal.ko
/lib/modules/2.6.26-2-686/kernel/natinst/nipal
/lib/modules/2.6.26-2-686/kernel/natinst/nipal/nipalk.ko

I can load nipal and nikal.

but doing 

# NIvisaic
FATAL: Module NiViPciK not found.
FATAL: Module gpibprtk not found.
Aborted

So modules are missing.

#find /usr/local/natinst/ -name "*InstallerUtility.sh"
/usr/local/natinst/.nicore/bin/nidimiInstallerUtility.sh
/usr/local/natinst/nikal/bin/nikaliInstallerUtility.sh
/usr/local/natinst/nipxi/bin/nipxirmiInstallerUtility.sh
/usr/local/natinst/ni4882/bin/ni4882betaiInstallerUtility.sh
/usr/local/natinst/nipal/bin/nipalkiInstallerUtility.sh
/usr/local/natinst/nipal/bin/nipaliInstallerUtility.sh

#ln -sf /bin/bash /bin/sh

# . /usr/local/natinst/.nicore/bin/nidimiInstallerUtility.sh
# nidimiPostInstall
bash: : command not found
bash: /file: No such file or directory
# . /usr/local/natinst/ni4882/bin/ni4882betaiInstallerUtility.sh
# ni4882betaiPostInstall
bash: : command not found
bash: : command not found
ln: creating symbolic link `/etc/inf/ni488.inf': No such file or directory
bash: /bin/readInfFiles: No such file or directory

Can you help me to find out what is missing?

Best regards and thank you in advance peter

[Shawn B.]

Hey Peter,

I just took a look in the *InstallerUtility.sh scripts and the problem is that they expect you to first run the nipalkiInstallerUtility.sh PostInstall step.  Then in the same shell run all of the other scripts.  That should fix your remaining missing kernel modules.

Additionally I also realized there is one more *InstallerUtility.sh script that isn't under /usr/local/natinst:

 /usr/local/vxipnp/bin/nivisaInstallerUtility.sh

Shawn Bohrer

National Instruments

[dicky yu]

Hi Shawn,

Sorry that I skipped some info to simplify and clear up my message (although it finally deviates my purpose):

-I ran all those commands as root

-Last time I have run ln -sf /bin/bash /bin/sh prior to running the INSTALL script for NI4882. And I checked the property of /bin/sh, it is still pointing to /bin/bash

- I ran the ". <rpmBaseName>InstallerUtility.sh <rpmBaseName>PostInstall" one by one, but I forgot the exact sequence I did (based on your reply to Peter, seems the sequence is critical?). What I can remember is that I skipped nikali and started with nipali and nipalk. Following is the result of executing updateNIDrivers:

Configuring for linux kernel version 2.6.27-14-generic.
 
********************************* NOTE *********************************
Using kernel headers found in /lib/modules/2.6.27-14-generic/build.
If this does not correspond to the location of the 2.6.27-14-generic headers,
then define KERNELHEADERS in your environment to point to the location
of the kernel headers, define KERNELTARGET as the version of the
kernel for which to compile, and then rerun ./configure.
********************************* NOTE *********************************
 
Kernel has reparent_to_init(): no
Number of arguments for do_munmap(): 3
pte_offset function: /bin/grep: /lib/modules/2.6.27-14-generic/build/include/asm/asm-x86: No such file or directory
pte_offset_kernel()
Levels in page table: 4
Kernel has remap_pfn_range: yes
USB altsetting name: cur_altsetting
Kernel has usb_get_intf(): yes
Kernel has intf_cache member in usb_host_config: yes
Kernel has ep[] members in usb_device: yes
Kernel exports usb_set_configuration(): no
Units of USB_CTRL_GET_TIMEOUT: msec
Kernel has owner member in usb_driver: no
Kernel has put_page_testzero(): yes
Kernel has mutex method: yes
Kernel has kthread: yes
Kernel has config.h: no
Kernel has ioctl32.h: no
IRQ handlers have pt_regs: no
Kernel has work_struct and delayed_work: yes
Kernel supports fault method in vm_operations_struct: yes
 
Storing configuration in Makefile.in
If the values stored are incorrect they can be changed before running make.
 
Uninstalling NI-KAL (nikal): done
/bin/rm -rf objects
Updating NI-KAL:
 NI-KAL successfully updated.
Updating client modules:
Rebooting is required to ensure that National Instruments drivers
have been successfully updated.
Would you like to reboot now? [yes|no]

There was message about pte_offset function, saying that "No such file or directory", but in fact I found that file /lib/modules/2.6.27-14-generic/build/include/asm/asm-x86 exists in my system. Again, it reported that only NI-KAL was updated, while none of client modules was listed.

Following is the result of find /lib/modules/$(uname -r)/kernel/natinst after rebooting mu system:

/lib/modules/2.6.27-14-generic/kernel/natinst
/lib/modules/2.6.27-14-generic/kernel/natinst/nikal
/lib/modules/2.6.27-14-generic/kernel/natinst/nikal/nikal.ko

On the other hand, the content of clientkdb folder is only:

/usr/local/natinst/nikal/etc/clientkdb
/usr/local/natinst/nikal/etc/clientkdb/nipal
/usr/local/natinst/nikal/etc/clientkdb/nipal/nipalk-unversioned.o

Do you think it is necessary to try to do updateNIDrivers manually one by one? If that is the case, please kindly share the method of doing that.

Thanks and best regards,

Dicky

[Shawn B.]

---

dicky yu wrote:

pte_offset function: /bin/grep: /lib/modules/2.6.27-14-generic/build/include/asm/asm-x86: No such file or directory
pte_offset_kernel()

---

This should be fixed in NI-KAL 1.10, but it doesn't look like it caused any problems.

---

Following is the result of find /lib/modules/$(uname -r)/kernel/natinst after rebooting mu system:

/lib/modules/2.6.27-14-generic/kernel/natinst
/lib/modules/2.6.27-14-generic/kernel/natinst/nikal
/lib/modules/2.6.27-14-generic/kernel/natinst/nikal/nikal.ko

On the other hand, the content of clientkdb folder is only:

/usr/local/natinst/nikal/etc/clientkdb
/usr/local/natinst/nikal/etc/clientkdb/nipal
/usr/local/natinst/nikal/etc/clientkdb/nipal/nipalk-unversioned.o

---

Hmm, in theory updateNIDrivers should have made nipalk.ko but it appears it did not.  I looked at the scripts and updateNIDrivers expects to find symbolic links under /usr/local/natinst/nikal/etc/clientkdb.  Maybe that isn't a link on your system?  What does this return:

find /usr/local/natinst/nikal/etc/clientkdb/ -type l

If that still shows nipalk-unversioned.o then I don't know why updateNIDrivers wouldn't create nipalk.ko.  Really for any of the *-unversioned.o modules you should be able to manually create a symbolic link under /usr/local/natinst/nikal/etc/clientkdb/ that points to the *-unversioned.o file and then run updateNIDrivers to create the *.ko kernel module.

If you are interested in debugging this a little yourself most of the kernel module setup occurs in  /usr/local/natinst/nikal/bin/nikalKernelInstaller.sh which is just a shell script.  When debugging shell scripts I find it useful to edit the interpreter line at the top of the script to append the "-x" option for example:

#!/bin/bash

to

#!/bin/bash -x

That will cause every line of the shell script to be printed with all variables replaced with their values.  This allows you to see exactly what is happening.  So if you modify nikalKernelInstaller.sh to have the "-x" option and then run updateNIDrivers it may give you a better idea why nipalk.ko is not getting created on your system.

Shawn Bohrer

National Instruments

[dicky yu]

Seems that for every package (nikal, nipal, nispy) I had multiple versions of packages installed. Based on niSystemReport, the loaded nikal was version 1.9. Reinstalling nikali 1.10 did not help since the client modules were still not updated.

To simulate a clean system, I uninstall nipalk and nipal by dpkg -r <packageName> and rpm -e <rpmBaseName> --allmatches --nodeps. Doing so on nikal did not work, I need to unload the module using modprobe -r nikal prior to uninstalling the package.

I reinstall following packages manually using dpkg and rpm:

- nikali1.10, modprobe nikal was OK

- nipalk2.4.0

- nipali2.4.0

modifying nikalKernelInstaller.sh according to Shawn's suggestion, this time there's a progress that gpibprtk.ko and nipalk.ko were produced. Even when I revert back to "#!/bin/bash", the update process still succeed:

Uninstalling NI-KAL (nikal): done
/bin/rm -rf objects
Updating NI-KAL:
 NI-KAL successfully updated.
Updating client modules:
 gpibprtk.ko successfully updated.
Rebooting is required to ensure that National Instruments drivers
have been successfully updated.
Would you like to reboot now? [yes|no] 

Unfortunately, I still cannot load the 2 modules. The error message is as follows:

WARNING: Error inserting nipalk (/lib/modules/2.6.27-14-generic/kernel/natinst/nipal/nipalk.ko): Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting gpibprtk (/lib/modules/2.6.27-14-generic/kernel/natinst/ni4882/gpibprtk.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Attached is a portion of niSystemReport that mentions about the unknown symbolic version. Should I revert back to nipali2.0.0 (which is included in NI4882betai25) to fix this?

Thanks

Dicky

[Shawn B.]

Hey Dicky,

It looks like you are making some progress.  The NI kernel modules depend on symbols (functions) that are exported from the other modules.  So gpibprtk.ko -> nipalk.ko -> nikal.ko.  Your nipalk_unkown_symbol.txt file has multiple lines similar to:

[   67.176090] nipalk: no symbol version for nNIKAL100_unregisterPCIDriver
[   67.176109] nipalk: Unknown symbol nNIKAL100_unregisterPCIDriver

This means that nipalk.ko is looking for the nNIKAL100_unregisterPCIDriver function that should be exported by nikal.ko.  The "no symbol version for" part means that your kernel was built with CONFIG_MODVERSIONS=y which creates a checksum for each symbol to perform a binary compatibility check.  NI-KAL 1.10 was the first version of NI-KAL to actually support building NI kernel modules with moversions support enabled.  It appears that nikal.ko loaded on your system and the output you provided from updateNIDrivers looks like you are using NI-KAL 1.10 so everything looks good so far.

The output you provided from updateNIDrivers shows that it updated nikal.ko and gpibprtk.ko but did not update nipalk.ko.  Since nipalk.ko was not updated by updateNIDrivers with NI-KAL 1.10 installed nipalk.ko will fail to load since it was not built with modversions support.  You need to make sure that there is a symbolic link under /usr/local/natinst/nikal/etc/clientkdb that points to each *-unversioned.o file.  For example with nipalk-unversioned.o you should see:

ls -l /usr/local/natinst/nikal/etc/clientkdb/nipal/nipalk-unversioned.o
lrwxrwxrwx  1 root root 57 Mar 21  2008 /usr/local/natinst/nikal/etc/clientkdb/nipal/nipalk-unversioned.o -> /usr/local/natinst/nipal/src/objects/nipalk-unversioned.o

Shawn Bohrer

National Instruments