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

[ChenQi]

Hi Chris,

I'm now working on some bugs related to read-only rootfs.

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

Best Regards,
Chen Qi

On 07/25/2013 02:54 AM, Chris Larson wrote:
> Greetings all,
>
> I've recently been doing some work at Mentor Graphics on 
> read-only-rootfs, for our purposes, and have done some things which I 
> think may be of use. I'm looking for comments/thoughts on the approach 
> and potential use of a pattern generally, and also wish to discuss the 
> volatiles vs tmp files.d situation.
>
> I have recently created a `meta-ro-rootfs` layer to hold work in this 
> direction which is not yet in or-core. As is fairly usual, it's a 
> staging area between us and upstream, not a place for anything to live 
> permanently. What follows is a summation of the work done there thus far:
>
> - Created a 'systemd-tmpfiles' recipe for non-systemd builds, and also 
> for native
>
>   - Patched in --sysroot= support for systemd-tmpfiles, to facilitate 
> running it up front against the filesystem at do_rootfs time the way 
> read_only_rootfs_hook does with populate-volatiles
>
>   - Added an 'update-tmpfiles' script, which iterates over all files 
> in /etc/default/volatiles/, converting them to tmpfiles.d config 
> files, writing them into /usr/lib/tmpfiles.d/, and removing the 
> volatile config files
>
>   - Reduced the dependencies, via patches and EXTRA_OECONF, as much as 
> seemed to be viable
>
> - Split out 'systemd-tmpfiles' from 'systemd' package in the main 
> systemd recipe, equivalent to the standalone one, for builds with 
> `systemd` in DISTRO_FEATURES
>
> - Created a 'read-only-rootfs-systemd' bbclass, which appends the bits 
> to run both update-tmpfiles and systemd-tmpfiles against the 
> filesystem at do_rootfs time for systemd distros. This will need to be 
> altered to not remove the volatiles config files for non-systemd 
> *images*. I realize there are many use cases to consider in the 
> sysvinit vs systemd realm, and I haven't verified that all are 
> satisfied just yet, as systemd is our current priority for r/o rootfs.
>
> - Added a COMPLEMENTARY_GLOBS config (in the layer.conf for now, 
> though I may move it into the bbclass) which adds `pkg-volatile` for 
> each `pkg` to the rootfs if read-only-rootfs is enabled.
>
> - Implemented a prototype configuration for dbus which uses this to 
> support read-only-rootfs. In the main package, we install a dbus.conf 
> into /usr/lib/tmpfiles.d/ which ensures /var/lib/dbus exists for the 
> non-r/o case, without including the path in the package (as including 
> paths within volatile paths in a binary package will break things). In 
> the dbus-volatile package, I install a different dbus.conf to 
> /etc/tmpfiles.d/, which overrides the one in /usr/lib/tmpfiles.d/ 
> (yes, update-alternatives would have been an option too, and has a 
> certain amount of merit, as /etc/tmpfiles.d/ is supposed to be 
> reserved for use by the administrator), and this config ensures that 
> /var/volatile/lib/dbus is created and that /var/lib/dbus is a symlink 
> which points to it.
>
> I have confirmed that I can create a systemd image with 
> read-only-rootfs and read-only-rootfs-systemd inherited, and dbus is 
> able to write to the volatile /var/lib/dbus/ path.
>
> I think this is a step in the right direction, though clearly more 
> needs to be worked out, but this pattern of using override 
> volatile/tmpfiles configurations with an additional complementary 
> package should let us cleanly share binary packages between r/o and 
> non-r/o images.
>
> Now, regarding tmpfiles.d vs volatiles. This is a rather unpleasant 
> situation currently, as for a recipe to cleanly support both sysvinit 
> and systemd images, it needs not only both sysv init script and 
> systemd services (though admittedly the latter is optional with sysv 
> compat), it also needs to provide both a volatiles config and a 
> tmpfiles.d config if it needs volatile paths.
>
> The standalone systemd-tmpfiles recipe I've created has a fairly small 
> set of dependencies: intltool-native, dbus, libcap. Given this, I'd 
> like to propose transitioning away from populate-volatiles to 
> systemd-tmpfiles, even for non-systemd images. I think that the 
> update-tmpfiles shell script may be of use in a transition, but before 
> we even begin discussing a transition path, I'd like to request 
> comments on the notion of moving to it at all. Thoughts? Objections?
>
> Thanks,
> -- 
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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