PXE Boot Linux RT for PXI

[RVallieu]

Took the newly built img.d and put it on my PXE Server

reboot Client

Client PXIe-8840QC broadcasts DHCP id request

Server responds

Client - gets the proper IP based on MAC from the DHCPd file

Server finds the correct pxelinux.cfg file based on IP address

This calls the correct pxelinux.0 file to load the files

Loading img.d/bzImage kernel           <- this loaded correctly on the Client

Loading /img.d/init failed: Bad File Number         <- Loading the initrd failed

My init file is 3.2G in size - which might be too big.

I did not run the dnsmasq steps as we had TFTP and DHCP already working to pxe boot other clients.

Our current PXE boot systems mount the root file system over nfs on the server and use small initrd/initramfs files.

I will have to see what is on my root file system on the disk - as I believe it was commissioned with ALL of the repository packages so they could be installed by opkg as I found I needed them when testing things out.  Maybe moving things around so they won't be captured will shrink my initrd enough.

[RVallieu]

I swapped the append line to after the kernel line in the pxelinux.cfg and rebooted - don't know if the swapped order made it work or it was coincidental, but when it pxe booted again it did try and load the file.

This time it progressed for a long time until I was informed that the image was too big to load into memory.

[Haris_Okanovic]

How much RAM do you have in your PXIe-8840QC?

If it's the minimal 4GB, then a 3.2GB iniramfs (uncompressed) is definitely too big. The entire image has to live in memory in this boot scheme, in addition to the kernel image plus working space for drivers and applications. Consider slimming down the image by removing unneeded software or perhaps upgrade RAM. The documentation suggests 8840's can take up to 8GB, which should be enough.

[RVallieu]

It's only 4 GB memory right now.  I will try and see if we can procure an 8GB module.

I'm also trying to uninstall some unused packages - but opkg is being a pain.  I'll keep posted

[RVallieu]

What is the minimum initramfs file structure that needs to be loaded and that we can use with an nfs mounted root drive?

I will also be purchasing RAM to go from the other direction.

[Haris_Okanovic]

If you build a kernel image with CONFIG_ROOT_NFS=y, then you don't need an initramfs at all. You can direct Linux to obtain an IP and boot an NFS share via cmdline args. Check out nfsroot.txt in the kernel documentation for details:

https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt

This option isn't enabled in the default NI Linux RT kernel image, but you can obtain the source from Github and build an alternate image yourself.

2019 NI Linux RT kernel source: https://github.com/ni/linux/tree/nilrt/19.1/4.14

Alternately, you may be able to use a modified NILRT initramfs with only LabVIEW installed to minimize size. Write a bash script at /init to configure Ethernet, mount a network share, and exec switch_root. Be sure to disable the network manager in the NFS image, else it could break the connection to your server. Tbh, I think this is much harder than the kernel-only approach above.

!! These are just a couple of ideas. I haven't tested either one. !!

What are you installing in the image to get a 3.2 GB initramfs? What software/driver do you need for your application?

Maybe I can help you slim it down to avoid NFS boot.

[RVallieu]

Really all I need are LabVIEW RT, DAQmx drivers, Timing driver with support for 6683H, VISA for Serial and GPIB, and the Serial drivers.

I know I can remove some of the packages that were installed, such as Veristand.

I was trying to remove a bunch of packages yesterday, but opkg remove and opkg remove --autoremove are giving me a "Solver error -nothing provides the needed fuse-utils".  Being a disconnected system its not easy to upgrade packages if that is the underlying issue.  I might need network shared variable support in the future, and FPGA runtime support, but won't be FPGA compiling on this machine for sure.

I checked to see if I could use MAX to do the remove, but it showed the same error Solver error: nothing provides requested fuse-utils, which makes sense as all it does is call into the system and issue the same commands. 

I will look into the building of the kernel with CONFIG_ROOT_NFS=y

Thank you.

[Haris_Okanovic]

Most of your packages got there via some dependency, which means simple remove/autoremove won't work since opkg won't violate dependencies by default. You can override this behavior with "force-depends". For example, running `opkg remove --force-depends ni-tdms` removes TDMS support even though LabVIEW still depends on it and remains present. Take caution doing this as it can lead to various problems at runtime!

Re fuse-utils: It sounds like there's a missing dependency in something opkg is trying to install. Can you explicitly install then remove it by running `opkg update`, `opkg install fuse-utils`, then `opkg remove fuse-utils`?

[RVallieu]

This is a disconnected system that is not allowed on the network - OPKG Update isn't able to pull anything directly.

[RVallieu]

I downloaded the latest opkg and am running it through the virus checker and will see if I can install it on the system.

BUT - I found where the size of the bloated image was originating - ALL the repo ipk were on the HD and rolled into the image, and once I modified the make-netboot-initramfs.sh file to exclude that location the initramfs built was under 450MB.

I have the system booting over PXE net boot, and it is starting up and running my EXE - it even has the Embedded UI enabled since that is how it was configured when I built the image.  

I am still going to probably upgrade my RAM to 8GB - and we'll think about going the route of building our own kernels for using NFS, but right now I can continue on in my testing.  

THANK YOU!  Your help is greatly appreciated.  If I go to NI Week this year I will buy you a beer.