[OE-core] RFC: meta-ro-rootfs approach and volatiles vs tmpfiles.d

[Chris Larson]

On Wed, Jul 24, 2013 at 7:51 PM, ChenQi <Qi.Chen at windriver.com> wrote:

> You can get more information from the bug link below. The related bugs are
> listed in the blocks list of this bug.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4103
> You can also review the patchset for these bugs on
>
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/read-only-rootfs-in-live-images
>
>
> I'm really interested on this topic. From my understanding, this RFC
> mainly focuses on read-only rootfs support for systemd based images, right?
>

It does, but only because of the reliance upon tmpfiles.d's ability to
override config files (the foo-volatile .conf will override the non-r/o foo
package tmpfiles.d config). An alternative approach would be to use
update-alternatives to manage the volatile configuration, and then it could
use either tmpfiles.d or volatiles, but the approach (Providing a r/o
volatile config in a foo-volatile package, and using COMPLEMENTARY_GLOBS to
get them installed for read-only-rootfs) should work, I think, regardless.


> I've read though this thread carefully, but still can't get a clear
> picture about this RFC.
> Could you please give me a link to your patchset, if convenient?
>

To summarize the RFC:

- I think the best approach to use the same set of packages for both
non-r/o and for r/o is to use a complementary package which overrides the
main package configuration to set up the additional links necessary to move
bits into volatile paths. I think that implementing it in this way has
value as opposed to the implementation in "initscripts: use a uniform way
to handle directories in read-only rootfs", as it uses the same mechanism
for read-only as is used for non-read-only, the only difference is the
configuration used and the fact that it gets run at do_rootfs time rather
than at boot, and it means no read-only bits are in the filesystem unless
read-only-rootfs is in IMAGE_FEATURES.
- To support systemd images with read-only-rootfs, we need to be able to
populate tmpfiles.d based on its config files at do_rootfs time the way we
do with populate-volatiles, or we need to duplicate all tmpfiles.d configs
to volatile configs. I chose the former, by enabling a standalone build of
systemd-tmpfiles-native and adding it to the read_only_rootfs_hook.
- https://github.com/MentorEmbedded/meta-ro-rootfs has our work so far on
the above.
- Proposing the need to consolidate tmpfiles.d and volatiles.

- Next steps, from my perspective:

    - We need to agree on a pattern to follow for the read only rootfs
support for individual pieces of recipes, as we need to work through them
individually. Currently we have two possibilities on the floor, the
/etc/default/readonly/ approach advocated by Chen Qi, and the overriding
the volatiles/tmpfiles.d config file approach advocated by myself.
    - We need a plan of attack to avoid the need to duplicate tmpfiles.d
and volatiles configuration. I was leaning toward using systemd-tmpfiles
for both sysvinit and systemd, but others have advocated moving to
tmpfiles.d configuration but using a homerolled script to implement it.
Either would be a step in the right direction: moving away from volatiles
config files in favor of tmpfiles.d config files.
    - We need a coherent, consistent mechanism for the user to choose
whether a given file or files will be pregenerated at build time (e.g. ssh
host keys, machine id) or generated every time at boot, for applicable
cases.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130730/ab631bac/attachment-0002.html>