On 07/31/2013 02:17 AM, Chris Larson wrote:
On Wed, Jul 24, 2013 at 7:51 PM, ChenQi <Qi.Chen@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.

Hi Chirst,

I've read the patches. But I haven't tried them out yet because currently I can't afford the time ....
From my understanding, the core concept is to use COMPLEMENTARY_GLOBS for *-volatile packages, and these  -volatile packages basically contain config files whose major purpose is to create appropriate links at rootfs time,  and these packages will be installed only if 'read-only-rootfs' is in IMAGE_FEATURES. Right?

- 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,

When I first came up with approach, I expected that there should be a bunch of packages that might need this. But it turned out that in OE-core, only the initscripts package needed this. So let's call it a fall-back approach. If some package *really* needs this, then we write a config file under /etc/default/readonly. By really, I mean, maybe some packages could simply be patched to work in a read-only rootfs. And note that I added a function in read-only-rootfs-hook.sh which is used to check whether a specific directory is on a read-only partition. This is because it's possible that users may use customized fstab which, for example, mounts a writable media over /var. We should take this situation into consideration.

That's also partly the reason that I dropped my 'lighttpd: xxx' patch. Moving its log location to some volatile storage to omit errors at system boot-up doesn't make the situation any better, because the /www directory is still not writable. So I would assume that if a user if using a read-only rootfs and he's using his system to hold a web, he should at least have some writable storage to store the data.


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,

I have very limited knowledge on systemd and sysvinit, but still I'm not sure about this change.
In my opinion, maybe we should make sysv and systemd have as little effect on each other as possible.
I'm afraid that this change will bring some potential problems that are not spotted at first.

Best Regards,
Chen Qi

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