Rootfs update module - keep existing file from active partition in new partition

General Discussions
,
1

Hello community,

what’s the best way to keep a persistent file, which is stored in the home path, after a rootfs update?

I want to keep an existing configuration file from an active partition and move it to the new active partition? What’s the best way without using a separate persistent partition?

Thank you in advance
cheers,
PFGO

2

I am not sure if I understand the question.
But you have to move all the persistent data to /data which is persistent data partition so that they don’t get overwritten after an update

3

Ok but where should I define it? in the update-module?

4

I think this link should answer your question.

You might have to create a state script.

5

Sorry but I don’t really understand it.

So should I create an own update module, which copies the persistent file from the active partition to the persistent data partition and after the upgrade process, it should copy the file from the persistent data partition, back to the new active partition?

6

Can you be a little more specific about what configuration you are trying to keep persistent between updates? Maybe share some examples/outputs for me to help you out?

7

@PFGO this simplest approach is to simply put the config file somewhere in /data and then use a symlink in the home path if you need it there. This will work transparently with a full rootfs update since the newly installed image will also have the symlink pointing into the data partition.

If that does not work then you can use state scripts to implement this. You could, for instance us a DownloadEnter script to backup the existing copy and then an ArtifactCommit_Enter script to restore it just before committing the update.

Drew

1 Like
8

@drewmoseley thank you for the answer.

Is the state “DownloadEnter” also called when I use mender standalone deployment?

9

@thesillywhat I think drewmoseley gave me the correct answer for this. I will try to implement it with the state scripts.

In short summary:
I’ve a node-red instance running on the device and there is a persistent context file, which stores some variables for the node-red application. I need to keep those variables after the upgrade process. But the context file is not always present, only in some cases. So I think it’s the best way to use a shell script to check if the file exists before the upgrade and then copy it back to the correct path.

Otherwise I should have to think on a complete new design for the system. To use the /data partition for all persistent files. Which seems to be the correct way for me. But it would require a huge change in the system, and needs to be tested for a lot of days. And for now I don’t have time to do it. But for a correct system design, it should be done in the near future.

Thank you

10

No the DownloadEnter only works when running in managed mode. When running in standalone mode, you need to have some other scripting that detects an update is available and launches Mender so presumably you can back the file up there when you detect an update but before calling Mender.

Drew

11

Ok thank you for the answers! Great community - thumbs up.

I will focus on the correct way, and migrate the configuration files to the persistent /data partition.

By the way is there an overview, which shows what states are supported by which mode (standalone/managed)?

2 Likes
12

Looks like I was wrong; Download is executed in standalone mode. See https://docs.mender.io/artifact-creation/state-scripts#standalone-mode

Drew

13

OK I tried it but I get the following Error:

--script /home/username/build/mender-convert/state-scripts/Download_Enter_00
	scripter: unsupported script state: Download

Edit:
Ok, I’ve found following information in the code:

var availableScriptType = map[string]bool{
	// Idle, Sync and Download scripts are part of rootfs and can not
	// be a part of the artifact itself; Leaving below for refference...
	//"Idle":                   true,
	//"Sync":                   true,
	//"Download":               true,
	"ArtifactInstall":        true,
	"ArtifactReboot":         true,
	"ArtifactCommit":         true,
	"ArtifactRollback":       true,
	"ArtifactRollbackReboot": true,
	"ArtifactFailure":        true,
}

And also I’ve found the information in the documentation for version 2.3:
https://docs.mender.io/2.3/artifacts/state-scripts#root-file-system-and-artifact-scripts

And it also has been answered here:

Just for information :slight_smile:

14

There are some examples here: https://github.com/mendersoftware/mender/tree/master/examples/state-scripts

Personally, I did something like this, but put my state script in the artifact, under the state ArtifactInstall_Enter. It made more sense to me that the new rootfs that is being installed knows what it wants to keep from the old one. If you use Download_Enter or Download_Leave, the state script lives in the ORIGINAL rootfs, NOT in the artifact. So this means that the current rootfs decides to write stuff to the new rootfs, which didn’t make sense in my use case.

1 Like
15

Hello @hacapa,

thank you I also ended up in using the script in the ArtifactInstall_Enter state.

The state scripts are very great! Thank you for the help :slight_smile:

cheers,
PFGO