Thanks, We want most of /etc to be read-only for security reasons, and the overlayfs will make the whole of /etc writeable.
I tried mount —bind /etc/timezone /persistent/etc/timezone, and it complained that they were not directories. Bind mounting /etc again will make all of /etc writeable. Symlinking to /persistent is fine, so the question is what an acceptable method is to have a simple way of ensuring that a certain file is converted to that symlink. Best Regards, Ulf Samuelsson +46 722 427 437 10 juni 2018 kl. 01:36 skrev Peter Kjellerstedt <peter.kjellerst...@axis.com>: >> -----Original Message----- >> From: yocto-boun...@yoctoproject.org [mailto:yocto- >> boun...@yoctoproject.org] On Behalf Of Ulf Samuelsson >> Sent: den 9 juni 2018 11:51 >> To: yocto@yoctoproject.org >> Subject: [yocto] How handle files needing updates in read-only >> filesystem >> >> 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 > > Since a lot of files in /etc typically need to be writable, one way to > handle this is by using an overlayfs for /etc. That is what we do and > it works very well. > > An alternative, more along your suggestion, is to use bind mounts. The > advantage of using a bind mount instead of a symbolic link is that it > will look as a normal file. > > You should look into the volatile-binds recipe and the VOLATILE_BINDS > variable. It is used to handle directories that need to be writable. > It will create systemd service files that copies the non-volatile > directory to the volatile directory (if it does not already exists), > and the bind mounts it back. > > I am not sure volatile-binds works out-of-the-box for files, but I > believe it does. If not, it should not be too hard to modify it so > that it can handle files as well. > > //Peter > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
