<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 24, 2013 at 2:47 PM, Colin Walters <span dir="ltr"><<a href="mailto:walters@verbum.org" target="_blank">walters@verbum.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, 2013-07-24 at 11:54 -0700, Chris Larson wrote:<br>
<br>
> - Patched in --sysroot= support for systemd-tmpfiles, to facilitate<br>
> running it up front against the filesystem at do_rootfs time the way<br>
> read_only_rootfs_hook does with populate-volatiles<br>
<br>
</div>How are you handling /run? Is it still a tmpfs in your model? If so<br>
are you excluding tmpfiles.d snippets which reference /run at rootfs<br>
time?<br></blockquote><div><br></div><div style>Still a tmpfs, yes. I haven't excluded them at this time, which means right now it ends up with the tmpfs paths populated with content that won't be seen at runtime, due to being under the tmpfs mount. I'm not certain whether that's a problem or not, but it's absolutely something to think about.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It strikes me that a less invasive way to achieve readonly rootfs is<br>
to symlink /var -> /run/var. Or are you doing that already?<br>
<br>
Then you'd probably want to just run through any tmpfiles which<br>
reference /etc and /usr.<br></blockquote><div><br></div><div style>That's not a bad idea, and I haven't tried that yet myself. One concern with this is, with the current setup, retaining existing regenerated bits in the filesystem would be just a matter of tweaking the tmpfiles configuration, whereas doing so if you link the entirety could be more troublesome. One example of a file that lives in /var but isn't volatile is the asound.state file shipped by alsa-state for some machines. Another is the package management database, which while r/o if the rootfs is r/o, can still have value.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
> - Implemented a prototype configuration for dbus which uses this to<br>
> support read-only-rootfs.<br>
<br>
</div>Err...for what? /var/run/dbus/system_bus_socket? You should just<br>
have /var/run -> /run, and that's solved.<br></blockquote><div><br></div><div style>or-core already has /var/run -> /run, so indeed, that's not an issue.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it's for /var/lib/dbus/machine-id, likewise that should on modern<br>
systems just be a symlink to /etc/machine-id.<br>
<br>
Though you do need to figure out whether you want a statically<br>
configured machine ID, or to have one generated dynamically at boot.<br>
These both have tradeoffs; basically, whatever you're doing for the<br>
random seed you should probably also do for the machine ID.</blockquote></div><br>It was indeed for the machine-id. I didn't really look closely at exactly what was being dealt with, as I just wanted an example to show that the approach with the additional -volatile package with the override config was going to pan out. :)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Personally, I think that the best approach is for such things to generate on boot every time, and treat shipping pre-generated content (possibly just to improve boot time) as a separate task which a distro could take on. That way everything works, and isn't exposed to any downsides of using pregenerated content which is the same for all devices by default, unless opted in. Another example of this would be the ssh host keys. I'm certainly open to discussing the tradeoffs of the alternatives, though.</div>
<div class="gmail_extra">-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div></div>