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

[Chris Larson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130724/333caf3a/attachment-0002.html>