<div dir="ltr"><div style>Greetings all,</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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:</div>
<div style><br></div><div style>- Created a 'systemd-tmpfiles' recipe for non-systemd builds, and also for native<br></div><div style><br></div><div style> - 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</div>
<div style><br></div><div style> - 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</div>
<div style><br></div><div style> - Reduced the dependencies, via patches and EXTRA_OECONF, as much as seemed to be viable</div><div style><br></div><div style><div>- Split out 'systemd-tmpfiles' from 'systemd' package in the main systemd recipe, equivalent to the standalone one, for builds with `systemd` in DISTRO_FEATURES</div>
<div><br></div><div style>- 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.</div>
<div style><br></div><div style>- 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.</div>
<div style><br></div><div style>- 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.</div>
<div style><br></div><div style>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.</div><div style>
<br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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?</div>
<div style><br></div><div style>Thanks,</div></div>-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div>