<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 24, 2013 at 7:51 PM, ChenQi <span dir="ltr"><<a href="mailto:Qi.Chen@windriver.com" target="_blank">Qi.Chen@windriver.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>You can get more information from the bug link below. The related
bugs are listed in the blocks list of this bug.<br>
<a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=4103" target="_blank">https://bugzilla.yoctoproject.org/show_bug.cgi?id=4103</a><br>
You can also review the patchset for these bugs on <br>
<pre><a href="http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/read-only-rootfs-in-live-images" target="_blank">http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/read-only-rootfs-in-live-images</a></pre>
<br>
I'm really interested on this topic. From my understanding, this
RFC mainly focuses on read-only rootfs support for systemd based
images, right?<br></div></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
I've read though this thread carefully, but still can't get a
clear picture about this RFC.<br>
Could you please give me a link to your patchset, if convenient?</div></blockquote></div><br>To summarize the RFC:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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.<br>
</div><div class="gmail_extra" style>- 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.</div>
<div class="gmail_extra" style>- <a href="https://github.com/MentorEmbedded/meta-ro-rootfs">https://github.com/MentorEmbedded/meta-ro-rootfs</a> has our work so far on the above.</div><div class="gmail_extra" style>- Proposing the need to consolidate tmpfiles.d and volatiles.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>- Next steps, from my perspective:</div><div class="gmail_extra"><br></div><div class="gmail_extra" style> - 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.</div>
<div class="gmail_extra" style> - 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.</div>
<div class="gmail_extra"> - 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.<br>
-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics </div></div>