[Openembedded-architecture] Correct method to employ volatile c configuration files in an RO filesystem

[Thomas Goodwin]

Before I go off the deep-end any farther: is there then a best practices or typical design pattern for establishing certain files to be volatile/user configurable in an otherwise read-only filesystem for OE?

My attempts at doing this up to this point are detailed below the sig.

Regards,

Thomas


My mounted root FS is read-only and I have some recipes with configuration files that would be better end-user configurable prior to deploying the embedded device.  The end-user’s tasks would be for example copy the SD image, edit a couple of files on the boot partition, and then boot the embedded device.  The files in question are /etc/hosts, /etc/network/interfaces, and /etc/omniORB.cfg.  My build environment is based on Daisy.

So far what I’ve tried has been appending the associated recipes with tasks to install a soft link that at the time of installation would be broken (i.e., pointed off at /media/FAT for example).  The resulting link never gets deployed to the root filesystem however no matter how I try to shoehorn it into the package.

Another attempt was appending the base-files recipe to add these files to the volatiles list so that they would be deployed as links.  The original recipes owning those files were then directed to deploy the files to the boot partition and an init script was installed to copy the files over the volatile counterparts on startup.  However the “real” files ended up still being deployed, and the populate-volatiles.sh script gave several errors as it had trouble with the link locations since I had to specify them as “../etc/hosts” etc. so that the recipe would build.

Some of these configuration files can be pointed to /var/volatile if necessary, however my goal for this solution is to retain the replaced configuration files in their “normal” locations so that users aren’t having to hunt them down.  So toward that end I’m now looking at replicating the base-files volatiles behavior without directly employing that recipe, again followed up with my own init script to merge the user’s changes with the volatile versions on startup.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20160307/799b2de7/attachment-0002.html>