<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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?</div><div class=""><br class=""></div><div class=""><div class="">My attempts at doing this up to this point are detailed below the sig.</div></div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Thomas</div><div class=""><br class=""></div><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Another attempt was appending the base-files recipe to add these files to the <i class="">volatiles</i> 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 <i class="">populate-volatiles.sh</i> 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.</div><div class=""><br class=""></div><div class="">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 <i class="">volatiles</i> 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.</div></body></html>