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

[Norbert Lange]

Am Mo., 17. Okt. 2022 um 18:00 Uhr schrieb <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.

I tried to bring that in for ages. Probably just have cooked up a patch instead.

>
> [--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.

Nah, it was always in respect of not messing around to much with the
filesystem itself.

I consider managing patch-series time consuming, so I'd like to discuss
the way this should be structured before.

This could be one completely separate package for example, allowing
different solutions.

>
> [--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.

Ok, I am using those pretty much interchangeable,
just some block you tell the bootloader to load, either cpio or filesystem.

>
> > > > 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?

Was attached in my post before - now 2 mails back. gonna add it
again for convienience.

>
> > 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?

mounts a tmpfs in /run/varoverlay, own directory.
/run is guaranteed to be writable and available before any systemd
unit is started.

>
> > and the /var folder will be shifted around to end up in an overlayfs
> > *below* this tmpfs.
>
> What do you mean by "shifted"?

you have to bind-mount /var to another directory, so you can use it as lower fs.
/run/varoverlay/lower <- /var

then.. you mount an overlayfs *at* /var where you need to reference the original
folder with /run/varoverlay/lower

/var <- overlay of  /run/varoverlay/upper (tmpfs) and
/run/varoverlay/lower( orignal /var )

>
> > 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.

fstab wouldnt allow for the needed dependencies.

>
> > -   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. ;-)

Gonna take me few days. should be easy to test tough with the provided files,
just throw them into the buildroot filesystem overlay.

Helps if you make some assessment where they should fit. the
systemd package is already bloated enough.

>
> > > 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!  ;-)

Good to know, so we can discuss on even terms.

regards, Norbert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: overlay_var.tar.xz
Type: application/x-xz
Size: 692 bytes
Desc: not available
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20221017/dc0325d8/attachment-0001.xz>