[Buildroot] [PATCH 0/4] systemd: sort out the conflict between var factory and tmpfiles (branch systemdify-var)

[yann.morin at orange.com]

Norert, All,

On 2022-10-17 16:50 +0200, Norbert Lange spake thusly:
> Am Mo., 17. Okt. 2022 um 16:11 Uhr schrieb <yann.morin at orange.com>:
> > On 2022-10-17 14:12 +0200, Norbert Lange spake thusly:
> > > Am Sa., 15. Okt. 2022 um 23:23 Uhr schrieb Yann E. MORIN
> > > <yann.morin.1998 at free.fr>:
> > [--SNIP--]
> > > > The solution we implemented in Buildroot is to generate a factory for
> > > > /var, and register that as tmpfiles, at build time, and mount a tmpfs on
> > > > the then-empty /var at runtime, so that systemd-tmpfiles populates /var
> > > > on boot. Having a tmpfs means /var is repopulated from a clean state at
> > > > each boot, and people who want a persistent /var have to provide their
> > > > own mechanism to mount their actual filesystem instead.
> > > Here the issue is, that the logic will never be complete, I will
> > > have to dig up old threads, but it fails with various combinations
> > > of symlinks.
> > The thing is, out of the box, Buildroot needs a working situation.
> Yes, my argument would be a technical better solution.

But so far, we do not have that technically better solution, so we need
to fix things that are arctually broken.

[--SNIP--]
[--SNIP--]
> > Now, please understand that some people are very happy with using a /var
> > factory, and some are even happy that /var is being mounted as a tmpfs
> > too.
> Would they be unhappy if everything works as it did before?

By "works as it did before", do you mean "using a var factory that was
not broken for them"? Yes, I am being teasing.

We'd have to evaluate the alternative proposal when we see it, if that
can replace the existing solution.

> > That is assuming that one will use an initramfs. For example, in my
> > systems, I do not use one, and I do not want to use one.
> No, initramfs is optional

Ah, but you had so far only talked about using an initramfs to prepare
an overlay, so I assumed your solution was tied to using an initramfs.
If it's not, then let's see it.

[--SNIP--]
> > However, in my case I expressely do not want to use an initramfs: my
> > rootfs is a squashfs mounted on an initrd. I also have a tmpfs mounted on
> > /var, as I am very happy that /var gets factory value at boot (my
> > resilient data is accessed in some other ways).
> I am not sure if initrd/initramfs means something different here.

initrd is a blockdevice in memory. The filesystem one puts in there can
be any filesystem that could be otherwise stored on another blockdevice.

initramfs is a filesystem in memory, like a tmpfs. The initramfs is
read-write.

> > > The recurring attempts to discuss this ended in [1].
[--SNIP--]
> > And finally, I believe it may even address more complex situations,
> > where people will provide their own fakeroot-script to do the
> > preparatory works.
> 
> My own usecase is that  use the buildroot as pristine rootfs and then
> slice it up as
> necessary. But just to get this out of the way.
> 
> More importantly, I would propose a simpler, yet more robust solution
> than the var factory.
> 
> For this, the files in the attached archive have to end up in
> /lib/systemd/system.

Did you forget to attach something, by chance?

> What this does:
> Before the time /var is supposed to be accessed, an tmpfs will be
> mounted in /run,

We already have that: /run is automatically mounted by systemd, no?

> and the /var folder will be shifted around to end up in an overlayfs
> *below* this tmpfs.

What do you mean by "shifted"?

> The bind-mount is done with a systemd mount unit, means if you have mounts
> *in /var or below* those will be correctly ordered.

Yeah, switching away from the fstab is good.

> -   No initramfs necessary
> -   No duplicate files in the var factory and tmpfs (unless they are
> modified of course). So your suashed files stay compressed.
> -   No tricky autogenerated tmpfiles
> -   Would be possible to do something similar in other init systems
> 
> The only downside would be the reliance on overlayfs - technically you
> could also
> adopt that solution to copy stuff into the tmpfs.
> 
> Besides my obvious biases there are technical arguments to be had.

We all have biases, me ot the last. :-)

My technical arguments for this series are:
  - it is currently kinda-broken
  - var factory works until proven otherwise
  - so we need to fix them

I'll be sure to do as unbiased a review as possible for your proposal
when I see it. ;-)

> > PS. Please note that there are two different Yann in this thread: me at
> > work using Buildroot, and Yann at home, one of the maintainers. Look at
> > the email to be sure who's talking (not that I-at-work talk in the name
> > of my employer either).
> > I try to segregate the two identities as much as I can, but sometime
> > there is some overlap, like here.
> > YEM.
> 
> Not making things much clearer ;)

If it can comfort you, it is not much clearer in my own head either!  ;-)

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.