2024 firmware too bloated for sbRIO

[Mads]

Issue:
Basic Real-Time firmware now (2024) requires 70% of the available disk on sbRIO-9607, instead of just 36% e.g. in LabVIEW 2020! Leaving too little to even retrieve an image of the device.

Background:
Testing LabVIEW 2024Q1 32bit I successfully deployed one of our applications currently maintained in LabVIEW 2020/22 to one of our sbRIO-9607s (unable to compile in 64 bit version, but that's another issue...), but was unable to take an image of the device afterwards. The issue it turned out was that the primary drive only had 80 MB of space left (after installing our RT application). This has never been an issue on a fresh install before though so I began to look at how a formatted sbRIO gets filled up by the firmware....

Details:

2020
With Firmware version 8.8.0f0 (LabVIEW 2020) the necessary firmware left 246 of 387 MB free...so the firmware took up 141 MB, as seen here:

2024
The system image for 2024Q1 on the same device with just the recommended packages (unnecessarily pushes VISA Remote, System link client etc. on it) grabs 270 MB, most of  the drive.
With just 117 MB left, before adding our own application(!), retriving images is no longer possible due to lack of available temporary storage.

Skipping the unnecessary recommended packages though we still end up with the firmware taking up 269 MB(!) and too little space on the drive to retrive images of it (RT app adds 20MB too).

Solution?

Is there anything we can do to get around this (reduce the required size preferably...), or are we forced to stay with an older version of LabVIEW with these sbRIO targets?

Not having much space for the RT application and its files is bad enough (storage can be added, but some things should be put on the primary drive...). But not being able to retrieve images of the controllers is even worse.

 

 

[Mads]

Running on older firmware / OS and drivers is not an option either. LabVIEW 2024 will not deploy apps to those.

[Mads]

I'm just talking to myself so far here it seems🤔...but anyway; the real jump seems to have come when you could no longer choose to install "cRIO" on the target, but had to choose a "system image".

The 2021 system image stripped down takes 262 MB, which is about double what it used to be before that (just 111 MB in 2018, 126 MB in 2019....).

With just 387 MB available on a blank sbRIO-9607 it was a problem already then, I just only noticed it now when considering upgrading to the 2024 image.☹️

[rolfk]

Thanks for testing this. One thing to remember when my last application for the sbRIO-9651 ever is considered for upgrade: Don't go beyond 2020! (It was developed in 2018 and still is).

[James_McN]

I feel like at somepoint NI did start including more packages pre-installed in the image that were commonly used.

It might be worth comparing the opkg list output and seeing what has changed.

[Mads]

It seems you are right James,

60 or so python packages included whether you want it or not for example 😲

Getting rid of them is not straight forward though as other packages, among them parts of the sys-api, seems to depend on python now (could be that those are not critical though..who knows).

I did a forced remove of the python packages though just to see and that got rid of 58 MB (!). I have not yet tested how that affects the system though. 

[Christina_R]

Unfortunately, I believe you're running into a known issue from LabVIEW RT 2021 (1506353).

[Mads]

Ok, so it's in a known issues list...(why is it not kept in the known issues for 2022-2024, when the affected targets are still otherwise "supported"?) but will not be resolved and there is no workarounds (no way to skip any opkg packages without losing the ability to run the RT app OK?)?

If this was just due to the convenience of using Python for some functions that disk space loss was a high cost... 😞

[Michael_Strain]

Hi Mads,

The issue is caused by a mix of some components moving to use Salt under the hood and us moving away from our custom driver installation thing to the more industry standard DKMS.  These both happened at the same time and bloated the install.

We do have an internal KB and workaround for the issue. The workaround is not ideal though, it will leave opkg in a not great state dependency wise, and you won't be able to modify software from MAX.  If you want to modify software from MAX again, you will need to boot safemode, format runmode, and reinstall it.  It will let you get your working system down to <50% of used disk space and be able to take an image.

TITLE: Cannot retrieve image from Zynq based sbRIO or cRIO

Details:

The base software install set for Zynq based targets exceeds 256MBs as of the 20.0+ versions.  On some Zynq targets, the disk is only 512MBs.  Creating an image for these targets requires at least half of the disk space on the target to be free to store the image while it is created.

Workaround:

Customers can manually uninstall software that they don't intend to use or is only needed during installation before creating an image.  Below are some suggestions of packages that can be safely uninstalled.  Note: we might recommend uninstalling some dependencies without installing the components that depend on them.  If there is a need to install software again after this, its highly recommended that the customer format the target and reinstall from the base system image.

Checking available space:

Customers can SSH into targets and run the "df /" command to check how much space is available:

admin@NI-sbRIO-9637-030b41eb:~# df /

Filesystem           1K-blocks      Used Available Use% Mounted on

ubi1:rootfs             396056    277928    118128  70% /

Note, the rootfs on these devices is compressed, so removing items might not free up as much space as expected.  Use% should be <50% before taking an image.

Packages that can be safely removed:

Driver install dependencies:

Explanation: Kernel build dependencies are used for driver installation and compiling against the kernel.  Since we are not updating the kernel after installation or compiling new kernel modules, they are no longer required.

opkg remove gcc gcc-dev gcc-symlinks cpp kernel-dev kernel-devsrc libgcc-s-dev shared-mime-info binutils binutils-dev *ncurses* libfmi-dev libbfd bison-dev bison flex-dev flex-libf1 flex libstdc++-dev *perl* libmpc3 libmpfr4 --force-remove --nodeps

Frees: ~80MB

Python 3 and Systemlink / Skyline dependencies:

Explanation: Unused if not using Systemlink or python 3 directly (systemlink is based on python3/salt and nisyscfg sometimes invokes salt under the hood)

opkg remove *python3* ni-skyline-tag-client ni-skyline-file-client ni-skyline-message-client ni-sysmgmt-salt-minion-support ni-sysmgmt-sysapi-expert salt-minion salt-common libmpc-dev libmpfr-dev libdbus-glib-1-2 ni-arch-gen

Frees: ~77MB

Unused kernel modules

Explanation: This checks what modules are currently loaded and uninstalls unused ones.

cat /proc/modules  | awk '{print "kernel-module-"$1"-[0-9]"}' | sed 's/_/-/g' > modules-in-use.txt
opkg list-installed | grep kernel-module- | awk '{print $1}' | grep -v -f modules-in-use.txt | xargs opkg remove --nodeps

Frees: ~7MB

[Mads]

Thanks for the detailed reply Michael🙂

Test done so far
Before getting that recipe I did this on an sbRIO-9607 running RT System Image 22.8/firmware 24.0.0f131-x64:

• removed all python packages (opkg remove python*)
• having first removed the packages that blocked it because of dependencies:
  • salt-minion
  • ni-sysmgmt-sysapi-expert
  • ni-arch-gen

Results:

• I am now able to image the device. (One side-effect I think I noticed though is a lack of some of the progress feedback during the image creation (using RAD), but it still worked.)
• I am not sure what you include in the definition of "modify software from NI Max"(?). But I am still able to add software components on it from NI Max (2022 version) e.g..
• The RT application seems to be running OK (not heavily tested yet, but it runs and its TCP-based client-server interface seems to be indicate that the application is running normally.
  
  The software reported in NI Max on this device is:
  
  

I have not tried to do this on a target with a 2024 system image yet though...And I have not tried your recipe yet (the warned side-effects seem worse than for what I tested, but then I do not know fully what the effects of my changes are 😨...).

It would be nicer to safely be able to move all development along to 2024 instead of having partially stick to 2020 just for the sake of these sbRIO targets.