[Buildroot] [PATCH 19/20] system: make systemd work on a read-only rootfs

[Yann E. MORIN]

Arnout, All,

On 2017-07-25 00:44 +0200, Arnout Vandecappelle spake thusly:
> On 24-07-17 17:45, Yann E. MORIN wrote:
> > On 2017-07-24 00:18 +0200, Arnout Vandecappelle spake thusly:
> >> On 18-07-17 19:25, Yann E. MORIN wrote:
[--SNIP--]
>  Thinking out of the box: can we make /var a symlink to /tmp/var, and avoid
> creating a tmpfs on /var at all? Since /tmp/var doesn't exist, "C! /tmp/var"
> should work, no? Or did that cause journald to bail out?

Worth a try, of course. But still we'd need hoks of some kind to allow
package to install in /var at build time, and move that to factory at
the end of the build, while still preserving the ability to be able to
rebuild stuff without requiring a 'make clean'.

[--SNIP symlinks in /var--]
>  There is unfortunately no way to fix this. If the package is smart, it does
> calculates the relative path based on the real path of the source and
> destination. If the package is stupid, it just assumes ../something. Whatever we
> do, one of them will break... The only safe approach would be to put stuff in
> /factory instead of /usr/share/factory.

But that is not where systemd-tmpfiles will look at...

Unless you meant we have /factory during the build, then move it at the
moment we aggregaate the images, and move it back (moving the problem
from handling /var to handling /factory instead) ?

[--SNIP--]
> > Not really, because systemd-tmpfile will look in exactly the factory
> > path to find the source of the copy/link. See the exerpt I pasted above.
> > 
> > So, given this entry, for example:
> > 
> >     C /var/foo - - - -
> > 
> > systemd-tmpfiles will see if it can find /usr/share/factory/foo not
> > /usr/share/factory/var/foo
> 
>  Weird, the way I read both the man page and the source code seem to suggest
> that "C /var/something" will copy from /usr/share/factory/var/something... But I
> guess you tested that so I must be misreading the source code.

And of course you are right.

It just happened that my testing was borked because systemd (or one of
its minions like journald) would create the required directory structure
and files they need, so I did not see mine were not copied over. Now I
have another test that does not use those "standard" files, and I'll add
it to the testing infra.

So yes, it should be /usr/share/factory/var/foo to populate /var/foo.

Which led to another bug, which is that tmpfiles should be in
/etc/tmpfiles.d/ and not in /etc/systemd/tmpfiles.d/

I've now fixed that.

However (thinking aloud now), I have another tentative to do, which
instead of creating a symlink for /var at runtime, would just creat it
as a direcotry as expected.

Then the hooks would simply "mv /var /usr/share/factory/var; mkdir /var",
create the tmpfiles entries, aggregate the image(s), the rm -rf /var; mv
/usr/share/factory/var /var".

This is probably much simpler than moving the entries one by one.

The only drawback in this case would be a package that already creates a
factory/var/foo entry. It would end up in /var/foo afterwards... :-/
So I think the /var symlink is better, in fact, so I'll keep that.

Thanks! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'