At the moment mender.conf is always bundled with the root file system, so it is contained in all Mender Artifacts created as well.

However, there are several cases where it is not desirable to make all settings in mender.conf Artifact-dependent. For example:

• The partition layout (in particular which partitions the root file systems reside) may be different on different devices, so not a uniform setting during build time

• TenantToken is different for different Hosted Mender customers, so demo Artifacts should not contain them (or they would need to be built for every customer)

• The polling interval may depend on the device network interface (e.g. 3g, ethernet), which is not uniformly the same for each build across devices

The proposal:

Merge mender.conf from several locations, with lowering priority, in this order:

• /etc/mender/mender.conf

  • Settings that need to be overridden in an update. In many cases this might be entirely empty, but could be used for updating the server URL, for example.

• /var/lib/mender/mender.conf (/data)

  • Settings that are permanent for the system, such as RootfsA and RootfsB locations

Examples:

• If TenantToken is specified in both /var/lib/mender/mender.conf and /etc/mender/mender.conf then the latter one will be used

• If polling interval is only specified in /var/lib/mender/mender.conf that is the one that will be used

Acceptance criteria

• If a setting is in /etc/mender/mender.conf, this will be used

• If a setting is not in /etc/mender/mender.conf but is in /var/lib/mender/mender.conf, it will be used

• If a setting is in both locations, the one in /etc/mender/mender.conf will be used

• If /etc/mender/mender.conf does not exist, the settings in /var/lib/mender/mender.conf will be used

• If neither /etc/mender/mender.conf nor /var/lib/mender/mender.conf exists or contain the required settings (e.g. rootfs partitions), an error is produced and Mender stops

• The final settings are available in debug output from the Mender client