I just wanted to share a basic how-to for remotely updating a RIO using only SSH and bash commands. These have been put together from various snippets here in the discussions, and from my own experimenting. These may be used to develop a bash script or an Ansible playbook to update and manage your targets. If you use Ansible's raw module then you may even avoid having to install Python on the targets! Creating an image of current system: Spoiler (Highlight to read) Reboot target into safe or install mode via SSH: /etc/init.d/nisetbootmode force-install "just gettin' an image" && reboot Login via SSH again once target has rebooted. Create the image file: nisystemimage get -x tgz -f some_image_name.tar.gz This will take a few minutes to complete, and will complete silently. After it is done your image file should show up in your current folder (I usually just use the home folder). Copy image file to your host PC via SCP. From a terminal on your host PC run: scp admin@192.168.0.5:~/some_image_name.tar.gz desired/save/path/ There are multiple ways to copy a file from a target to your PC, this is just my own preference! Reboot the target. It should automatically boot back into run-mode. NOTE: This will delete the image file that you created since the safe-mode OS is volatile! If it does not automatically go back into run-mode, then SSH in and run: /etc/init.d/nisetbootmode force-runtime && reboot Reboot target into safe or install mode via SSH: /etc/init.d/nisetbootmode force-install "just gettin' an image" && reboot Login via SSH again once target has rebooted. Create the image file: nisystemimage get -x tgz -f some_image_name.tar.gz This will take a few minutes to complete, and will complete silently. After it is done your image file should show up in your current folder (I usually just use the home folder). Copy image file to your host PC via SCP. From a terminal on your host PC run: scp admin@192.168.0.5:~/some_image_name.tar.gz desired/save/path/ There are multiple ways to copy a file from a target to your PC, this is just my own preference! Reboot the target. It should automatically boot back into run-mode. NOTE: This will delete the image file that you created since the safe-mode OS is volatile! If it does not automatically go back into run-mode, then SSH in and run: /etc/init.d/nisetbootmode force-runtime && reboot Applying a system image: NOTE: Everything in the runtime OS will be overwritten, including the system password! Spoiler (Highlight to read) Reboot target into safe or install mode via SSH: /etc/init.d/nisetbootmode force-install "just setting an image" && reboot Copy image file to your target via SCP. From a terminal on your host PC run: scp path/to/image/some_image_name.tar.gz admin@192.168.0.5:~ There are multiple ways to copy a file to your target, this is just my own preference! Login via SSH again and apply the image: nisystemimage set -x tgz -f some_image_name.tar.gz -p preserve -s preserve This usually finishes within a minute or two. I usually get errors like "/dev/sda4 is not encrypted (not a luks device)" or "nilrtdiskcrypt_canopen: No such file or directory". Everything seems to work just fine despite these messages. Both the primary and secondary network adapter settings are preserved here. [Optional] Make sure SSH is still enabled in the new configuration. Run: nirtcfg --set section=SYSTEMSETTINGS,token=sshd.enabled,value=True Reboot the target. It should automatically boot back into run-mode. If it does not automatically go back into run-mode, then SSH in and run: /etc/init.d/nisetbootmode force-runtime && reboot Reboot target into safe or install mode via SSH: /etc/init.d/nisetbootmode force-install "just setting an image" && reboot Copy image file to your target via SCP. From a terminal on your host PC run: scp path/to/image/some_image_name.tar.gz admin@192.168.0.5:~ There are multiple ways to copy a file to your target, this is just my own preference! Login via SSH again and apply the image: nisystemimage set -x tgz -f some_image_name.tar.gz -p preserve -s preserve This usually finishes within a minute or two. I usually get errors like "/dev/sda4 is not encrypted (not a luks device)" or "nilrtdiskcrypt_canopen: No such file or directory". Everything seems to work just fine despite these messages. Both the primary and secondary network adapter settings are preserved here. [Optional] Make sure SSH is still enabled in the new configuration. Run: nirtcfg --set section=SYSTEMSETTINGS,token=sshd.enabled,value=True Reboot the target. It should automatically boot back into run-mode. If it does not automatically go back into run-mode, then SSH in and run: /etc/init.d/nisetbootmode force-runtime && reboot Updating the firmware/safe-mode OS: Spoiler (Highlight to read) Locate the firmware *.cfg file for your target on your PC (this should come with your installation of NI-RIO). These are usually located in C:\Program Files (x86)\National Instruments\Shared\Firmware\cRIO\Device_code\ where "Device_code" is "76D6" for a cRIO-9068 and "78E9" for a cRIO-9047. Copy the firmware file to your target via SCP. From a terminal on your host PC run: scp path/to/firmware/some_firmware.cfg admin@192.168.0.5:~ There are multiple ways to copy a file to your target, this is just my own preference! SSH into the target and run: niinstallsafemode some_firmware.cfg This may take a minute or two and usually gives "not a luks device" errors, but this is OK (maybe this only applies to those with encrypted disks?). Verify the installed firmware version by running: nisafemodeversion Locate the firmware *.cfg file for your target on your PC (this should come with your installation of NI-RIO). These are usually located in C:\Program Files (x86)\National Instruments\Shared\Firmware\cRIO\Device_code\ where "Device_code" is "76D6" for a cRIO-9068 and "78E9" for a cRIO-9047. Copy the firmware file to your target via SCP. From a terminal on your host PC run: scp path/to/firmware/some_firmware.cfg admin@192.168.0.5:~ There are multiple ways to copy a file to your target, this is just my own preference! SSH into the target and run: niinstallsafemode some_firmware.cfg This may take a minute or two and usually gives "not a luks device" errors, but this is OK (maybe this only applies to those with encrypted disks?). Verify the installed firmware version by running: nisafemodeversion Some notes: The niinstallsafemode and nisystemimage commands seem to be new with LV 2019, so you may not have these tools installed on your target. Testing was done using cRIO-9086 and 9047 targets running NI Linux Real-Time 4.14.87-rt49-cg-7.0.0f0. These and other command line tools are located in /usr/local/natinst/bin/. These tools also have little-to-no documentation. This combined with little mention of them in the white papers tells me that they may be unsupported! Use caution! An image that was created with RAD can be applied using nisystemimage. You just have to unzip the *.lvappimg file and extract the *.tar.gz file within it.

Several of us internal NI developers are absolutely chuffed at this thread. Thank you. Also thanks for demonstrating that some customers are using ansible. I do feel obliged to ask how tied you are to ansible, because SystemLink is all salt-based, and you are generally going to have a smoother supportability experience if you can hitch your sails to that instead. Applying a system image: NOTE: Everything in the runtime OS will be overwritten, including the system password! Two caveats: User-installed FPGA bitfiles (i.e. which are configured to run at startup) are not saved/restored. IIRC, the higher-level system imaging primitives exposed by NI System Configuration (and RAD) take care of that separately. If you have any private keys installed (used for the webserver and a couple of other things), they are not going to be encrypted; you might consider using `openssl enc` or `gpg --symmetric` or something to protect the image at rest, if you have sensitive information. IIRC, NI System Configuration/RAD solves this by leaving sensitive content out of the tarball and encrypting it separately in the lvappimg. Spoiler (Highlight to read) Login via SSH again once target has rebooted. Create the image file: nisystemimage get -x tgz -f some_image_name.tar.gz Copy image file to your host PC via SCP. From a terminal on your host PC run: scp admin@192.168.0.5:~/some_image_name.tar.gz desired/save/path/ Login via SSH again once target has rebooted. Create the image file: nisystemimage get -x tgz -f some_image_name.tar.gz Copy image file to your host PC via SCP. From a terminal on your host PC run: scp admin@192.168.0.5:~/some_image_name.tar.gz desired/save/path/ This will fail if the image is too large. One workaround is to save the image to the runmode filesystem (/mnt/userfs). This is what NI System Configuration does. This brings up the unfortunate complication that you need to prevent nisystemimage from saving off its own output image. You can accomplish this by using the `-b <path>` option to add a blacklist entry; any path equal to <path> or which is a subdirectory of <path> will not be saved into images or restored from images. But since you're already on a Unix host, you could instead just pipe it: ssh admin@target "nisystemimage get -x tgz" > image.tar.gz And do the likewise thing on restore. The main drawback with this approach is that if the file transfer fails, your runmode is hosed; but since you're already in safemode, you should be able to recover from this. The niinstallsafemode and nisystemimage commands seem to be new with LV 2019, so you may not have these tools installed on your target. AFAIK, nisystemimage and niinstallsafemode have existed since LV 2014. So I'm not sure how you came to this conclusion. Testing was done using cRIO-9086 and 9047 targets running NI Linux Real-Time 4.14.87-rt49-cg-7.0.0f0. The general nisystemimage process should continue to work, IIRC, for the vast majority of NI Linux RT controllers which use the "old" (non-opkg-based) MAX install process. For opkg-based installs, which includes PXI and SystemLink, it might work, but is not tested and is discouraged — configuration management is meant to be done through SystemLink and/or salt. It definitely won't work at all for NXG. Offhand, I am aware of no proscriptions against niinstallsafemode, except the usual ones (it's completely unsupported when used directly; if it fails you will need to call NI support to iron things out; etc.) These and other command line tools are located in /usr/local/natinst/bin/. These tools also have little-to-no documentation. This combined with little mention of them in the white papers tells me that they may be unsupported! Use caution! You can say that again! An image that was created with RAD can be applied using nisystemimage. You just have to unzip the *.lvappimg file and extract the *.tar.gz file within it. Yes — with the caveats mentioned above about how NI System Configuration does its own thing about sensitive content. IIRC, the principal side effect of applying a system image directly is that system passwords will probably not be updated.

NI Linux Real-Time Discussions

Target update via SSH (LV 2019+)

Solved!

It would be nice if piping the image to your local drive was an in-built feature...and implemented in RAD. I posted this request / idea some time ago in the idea exchange:

https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Streaming-image-data-Image-creation-without...

Mads Toppe
Modbus Test Master - developed in LabVIEW