We have a rootfs which is read-only.
For files that needs to be updated, like "/etc/localtime"
we will create a symbolic link to a partition (/persistent) which
is retained between rootfs image updates.
/etc/localtime -> /persistent/etc/localtime
The original recipe will generate the real /etc/localtime of course.
To support the file beeing updated, the following needs to be done in a
rootfs postprocess.
mv /etc/localtime /update/etc/localtime
ln -sf /persistent/etc/localtime /etc/localtime
install -m 0644 /update/etc/localtime /persistent/etc/localtime
chown <user>:<group> /persistent/etc/localtime
The last two commands needs to be executed on the running system,
since /persistent is not part of the rootfs.
To ensure that the file can be updated is an ad-hoc activity for each
affected file. It would be better if there was a class where you declare
a file to be writeable, and then a post process
would move the file to /update (or similar) and create a symbolic link
SETTINGS ?= "/persistent"
=============================
inherit writeable
WRITEABLE = "/etc/localtime"
=============================
This would generate the first two commands for each listed file.
mv /etc/localtime /update/etc/localtime
ln -sf ${SETTINGS}/etc/localtime /etc/localtime
The file would also be added to a file indicating that it may need
to be copied to the ${SETTINGS}
Is it a good solution to modify "populate_volatiles.sh"
to support a second file parameter for the f (file) command
in the /etc/default/volatiles file?
Today the file create command looks like:
f <mode> <uid> <gid> <filename> <ignored>
An idea would be to have the following syntax:
f <mode> <uid> <gid> <filename> <source>
If <source> is a valid filepath, then copy this file to <filename>
If <source> is not a valid filepath, create <filename> using "touch"
This would break any build which has a "funny" volatiles file.
Otherwise a script called populate_persistent.sh could be
created with such an extension.
Comments?
BR
Ulf Samuelsson
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
