NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

System Deployment and Image Persistence

Continuing a discussion from the comments section of this document:

JackDunaway wrote:


... these tips about transferring files to/fro are precipitously close to the next set of SSH command tips I've been wanting to add to the doc. But I've not yet found a reliable solution worth sharing yet.

It deals with two topics -- system deployment/replication, and also using the device as a dev environment for compiling libraries (rather than cross-compiling) -- and both these topics need the ability to reliably transfer (and persist!) lots of files to and fro.

The RAD 5.5.2 application is helpful. But it's built upon NI System Configuration 5.6.0f1 API, which a bit buggy. Buggy, we can work with, no prob. It's the opaque nisyscfg.dll -- that makes "buggy" inconvenient, since we can't readily de-buggy it.

I'm interested to understand better how the layers of image persistence work on the device -- e.g., where the images are stored, what are their entry points for loading on bootup, how to replace these images on a running system and flag that the device should use new images on startup --- and the like. Basically, it would be helpful to know what nisyscfg.dll is doing, and if what it's doing could be automated through a direct shell script.

Anecdotally, we've got three layers of images that can be persisted:

  1. "firmware" -- I think more appropriately translates to "kernel" or "OS" for Linux RT ... ? Yet remains "firmware" to help transition from previous devices ... ?
  2. "NI Software and Drivers" -- I think this is sometimes called the "System Image" ... ?
  3. Application -- This is the layer of software that's persisted when we "set as startup application"

I've been spelunking around the shell scripts and environment variables that ship with the "firmware" and "NI Software" layers, and have a decent grasp. It's tough to verbalize specific questions on a specific topic, but boiling it down -- can we just get an idea of what's going on behind nisyscfg.dll?

(Ideally, even, its source could be shared through the same program as the kernel source.)

thanks!

Message 1 of 16
(10,899 Views)

Let's start with a simpler question.

Consider a formatted RIO which only has the firmware installed from MAX. Using an SFTP client, create a file in the root directory. Reboot the RIO -- after logging in again, the file is gone. Same thing with any edits to existing files -- their changes are reverted to the defaults of the original image.

How can we persist file system changes through power cycles? Is there a script or similar that must be run to commit a new image before rebooting?

0 Kudos
Message 2 of 16
(4,189 Views)

JackDunaway wrote:

Consider a formatted RIO which only has the firmware installed from MAX. Using an SFTP client, create a file in the root directory. Reboot the RIO -- after logging in again, the file is gone. Same thing with any edits to existing files -- their changes are reverted to the defaults of the original image.

How can we persist file system changes through power cycles? Is there a script or similar that must be run to commit a new image before rebooting?

If all you have installed is "firmware" then what you be booting to is the "safe-mode" image.  This is a RAM disk image that will not persist anything.  However, in safe-mode the flash is mounted at /mnt/userfs so any file you write there will be persisted across reboots.  If you later install software to the target, then you will boot into the normal state that the device is expected to run.  In that case the flash is mounted at the root so any files within that filesystem will be persisted.

Message 3 of 16
(4,189 Views)

In this scenario you're booted to safe mode, and in safe mode the root directory is on a RAM disk, so changes there won't persist. Files in /home/lvuser will persist, because that location is shared with the normal operating mode, and that is where I'd recommend you normally put your files. Unfortunately that directory might not exist until you install software (not just the firmware). If you have to do it on a freshly formatted target before installing anything, you could use /etc/natinst/share, but that's an internal location ("may change without notice" disclaimer applies) so I wouldn't recommend that. If you can clarify whether you actually need to persist files on a newly formatted target with nothing installed, or are just asking about persisting files in general, that would direct my next suggestion...

Message 4 of 16
(4,189 Views)

JackDunaway wrote:

I'm interested to understand better how the layers of image persistence work on the device -- e.g., where the images are stored, what are their entry points for loading on bootup, how to replace these images on a running system and flag that the device should use new images on startup --- and the like. Basically, it would be helpful to know what nisyscfg.dll is doing, and if what it's doing could be automated through a direct shell script.

Anecdotally, we've got three layers of images that can be persisted:

  1. "firmware" -- I think more appropriately translates to "kernel" or "OS" for Linux RT ... ? Yet remains "firmware" to help transition from previous devices ... ?
  2. "NI Software and Drivers" -- I think this is sometimes called the "System Image" ... ?
  3. Application -- This is the layer of software that's persisted when we "set as startup application"

You don't quite have the break-down correct.

1.  "Firmware" -- this consistes of two things, the safe-mode ramdisk image and the default FPGA bitfile which implements system peripherals.

2.  "NI Software and Drivers" -- This actually includes the entire OS that will be running when the device is used in normal operation.

3.  Application -- This can be deployed through LabVIEW or through MAX (if you make a CDF of it).  In either case once it is deployed, if you "Get System Image" this will include the application.

Get System Image and Set System Image images specifically do not include the "Firmware" portion of the software.  It does include basically everything else, including things you write to the flash.

As for trying to understand the behavior of the syscfg operations (based on context, I presume you are referring specifically about Get System Image and Set System Image), then you may want to look at the /usr/local/natinst/bin/nisystemimage script (while booted in safe-mode).

Message 5 of 16
(4,189 Views)

[Re: Safe Mode] Yes, I made a mistake and oversimplified the question -- the "fresh" RIO shouldn't be defined as only having firmware, but also a fresh install of "NI myRIO 13.1". Which gives us a bootmode of "runtime" and not "safemode", which would explain the volatile behavior. My bad!

So here's a new question with a new setup: ...

___

EDIT: minutes later... My device must have been in some funk for several days now (judging from

/sbin/fw_printenv -n bootcount -- I've been troubleshooting and rebooted >100times trying to figure out what's going on!). It's apparently been booting from the RAM disk this whole time. In the process of internalizing your posts and trying to rephrase a new quesion, I reverted to 1.0.0f1 firmware then back to 1.0.1f0, and it's working as I would expect! Having formatted and reinstalled the new firmware many times now, that alone was not sufficient -- it needed to flip back to the old, then back to the new.

On a perhaps related topic -- can you advise on what triggers "Improper Installation" mode, or where to find logs on what when wrong? (This is sometimes caused by performing actions with opkg)

0 Kudos
Message 6 of 16
(4,189 Views)

Improper Installation means some critical services (like the system web server) couldn't start. You're venturing off the beaten path a bit with opkg installs, but we can try to figure out what happened. Have a look at /etc/init.d/nivalidatestartup (in run mode) to see what services we consider "critical" and then watch for those at boot time -- my strong guess would be you'll see that SystemWebServer failed to start. As to what could cause that, I'd really be interested to know the sequence of what opkg's you installed relative to when the Improper Installation error occurred. Maybe there is an opkg that conflicts with SWS, for example if you installed something that includes a web server (or is a web server)?

Message 7 of 16
(4,189 Views)

JackDunaway wrote:

On a perhaps related topic -- can you advise on what triggers "Improper Installation" mode, or where to find logs on what when wrong? (This is sometimes caused by performing actions with opkg)

From looking in /etc/init.d/nisafemodereason in safe-mode:

if [ -s $CONFIG_OLD ]; then

   # non-empty config.old means an install failed

   REASON=$IMPROPER

If MAX did not successfully complete the installation and remove the /etc/natinst/share/config.old file, you will get this message.

Message 8 of 16
(4,188 Views)

That's also a possibility, although that case should be immediately apparent on the first boot after the failed MAX install, and not occur later due to opkg installs.

Message 9 of 16
(4,188 Views)

ScotSalmon wrote:

... SystemWebServer failed to start ...

Aha -- good information. I'd like to start another conversation on the configuration of AppWeb, but can you summarize in a nutshell -- is it a hard requirement to have the SystemWebServer, or is it possible/acceptable to uninstall/uninclude it, accepting known tradeoffs such as no longer being able to use WIF, perhaps parts of MAX, etc...? How about when you deploy a VI or RTEXE from a LVProj -- is the SystemWebServer needed here?

DAQjr wrote:

If MAX did not successfully complete the installation and remove the /etc/natinst/share/config.old file, you will get this message

I'll check into this also -- though it might not be the cause, since MAX happily reported having installed successfully. Specifically, it happened after beginning to set up the device as a build environment with updated Angstrom feeds, the package packagegroup-core-buildessential-dev and the "infamous" operation opkg flag ok libc6

0 Kudos
Message 10 of 16
(4,189 Views)