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

[ChenQi]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130731/ebfe966f/attachment-0002.html>