[Buildroot] [PATCH 00/24 v2] system: properly handle systemd as init system (branch yem/systemd-skeleton)

[Yann E. MORIN <yann.morin.1998@free.fr>]

Thomas, All,

On 2016-07-06 23:49 +0200, Thomas Petazzoni spake thusly:
> On Wed, 22 Jun 2016 21:07:41 +0200, Yann E. MORIN wrote:
> >       system: sysvinit only selects busybox-show-others if busybox is enabled
> We decided collectively to not merge this, as other packages would have
> to be changed, and the benefit is not very big.

Yes, I replaced it with a patch that adds a comment for this variable.

> >       system: provide no default for custom skeleton path
> Generally agreed, but I'm waiting for a respin since there were some
> comments.
> >       system: move the rootfs skeleton choice
> Looks good as well, waiting for the respin (it depends on the previous
> patch).
> >       system: do not handle network settings for custom skeleton
> Ditto.
> >       system: do not set hostname and issue for custom skeleton
> Also looks good, but waiting for the respin, since it depends on the
> previous patches.

Yep, I'll respin shortly, it's almost ready.

> >       core/pkg-generic: allow packages to declare target-finalize hooks
> >       packages: use the <PKG>_TARGET_FINALIZE_HOOKS
> Both merged. For the latter, a follow-up patch is needed to also use
> the new mechanism in the toolchain package.

Already done here, will be part of the respin.

> >       package/skeleton: split into sysv and custom skeleton
> >       package/skeleton: make it a virtual package
> >       package/skeleton-sysv: split into skeleton-common
> >       system: split skeleton
> >       package/skeleton-systemd: new package
> >       system/systemd: needs timezone
> 
> OK, so this is the first big thing that remains: splitting the skeleton
> into multiple parts. If I summarize your solution, it consists in
> splitting the skeleton in several parts:
> 
>  * 'skeleton', which becomes a virtual package that depends on the
>    actual skeleton.
> 
>  * 'skeleton-custom', which is used when a custom skeleton is selected,
>    and does pretty much nothing except copy the custom skeleton
> 
>  * 'skeleton-common', which contains the common parts of the systemd
>    and sysv skeleton
> 
>  * 'skeleton-sysv', which depends on skeleton-common and contains the
>    sysv specific parts of the skeleton. In practice, this only contains
>    the /var sub-directories, /etc/fstab, the /etc/resolv.conf symbolic
>    link (which is the same in systemd, so it's not a real difference),
>    and the /dev sub-directories.
> 
>  * 'skeleton-systemd', which depends on skeleton-common, but does not
>    copy itself some skeleton, as it instead just creates a bunch of
>    directories and files. In practice, the only thing useful that it
>    does is create a /etc/fstab file.
> 
> In addition, a 'skeleton-net' part is created, which is not a package,
> but just a placeholder with the ifupdown configuration, used by both
> the sysv init case, and the systemd-without-networkd case.
> 
> At the very least, I believe:
> 
>  - the skeleton-net thing should be moved into a ifupdown-config package
> 
>  - the skeleton-systemd should be simplified to not create directories
>    that already exist in skeleton-common
> 
>  - the /etc/resolv.conf file should be kept in the common skeleton
> 
> Once this is done, I continue to wonder if this multiple skeleton
> mechanism is really needed:
> 
>  - the skeleton-systemd package does essentially nothing, except
>    creating the fstab, which the systemd package could do.
> 
>  - the skeleton-sysv package also doesn't do much, and it could be done
>    in the existing initscripts package.
> 
> Really, the only thing that bothers me is that "initscripts" isn't a
> very good name for a package that also installs other things than init
> scripts. Perhaps naming it "sysv-base" or something would be clearer.
> 
> But maybe before taking a decision on this we simply need to see a
> respin that does the first cleanups suggested above, so that we can
> have a clearer vision of where things are going. The idea of skeleton
> as a virtual package is also not bad, especially if we can get rid of
> the weird skeleton-net situation, and really have
> skeleton-{common,sysv,custom,} be real packages.

I'm not going to do any change right now, to let the dust settle.
Once others have commented one way or another, I'll do the requested
changes.

> >       fs: add pre- and post-command hooks
> >       system: make systemd work on a read-only rootfs
> >       system: allow DHCP interface with systemd-networkd
> 
> This is the second big thing: allow a systemd rootfs to be read-only.
> The crux of the problem is that when /var is read-only, systemd
> automatically mounts a tmpfs on /var, which defeats our traditional

Nit: systemd *expects* /var to be a tmpfs (or at least that it be
writable). It does not do the mount; we do it explicitly in the fstab.

> mechanism to handle read-only rootfs.
> 
> The solution that Yann has designed consists in having /var be a
> symlink to /usr/share/factory in the systemd skeleton. This way, during
> the Buildroot build, all the packages that create stuff in /var end up
> installing their stuff in /usr/share/factory. And then, thanks to the
> pre/post hooks in the FS infrastructure, the code creates some tmpfiles
> description for systemd for each file in /usr/share/factory and
> replaces /var with a directory. This way, when systemd boots, it mounts
> a tmpfs in /var and copies all the files from /usr/share/factory
> to /var.
> 
> I am a bit annoyed by the complexity of this, and the "black magic"
> involved, but on the other hand, I don't really see a better solution.
> 
> Another thing that bothers me is that then the solution to handle the
> read-only rootfs problem then becomes radically different between the
> sysv case and the systemd case. Maybe this is expected since the init
> systems are so different.

And now that I had time to think about it, there is even another issue
that I forgot to talk about: this relies on whether the user asked that
the rootfs be remounted R/W at boot (BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW).

If that is that case, we currently still offer a way to build
filesystems that are inherently R/O (cramfs, iso9660, squashfs...) I
would suggest that we hide those filesystems in that case.

Yet, when the option is not selected does not mean that we should not
allow a R/W filesystem either (the user may well want to boot a R/O ext4
but remount it for local upgrades, like a GPS database for example).

But surely, when the users asks / to be remounte R/W at boot, we *know*
we can't use a R/O filesystem.

> But on the other hand, our existing mechanism to handle a read-only
> rootfs in sysv land is not great: we create /var/log as a symlink
> to /tmp, and /tmp is mounted as a tmpfs. This works fines if
> applications just create files in /var/log. But if an application at
> build time create a directory in /var/log, such as /var/log/daemond, it
> might expect to find it at runtime, which will not be the case.
> The /usr/share/factory solution solves this problem.
> 
> So, should we move to this /usr/share/factory solution also for sysv
> init ?

I'm OK with that, except we'd have to provide that mechanism ourselves
fot sysv init.

> Yann, what about:
> 
>  (1) Getting a series that has just the respin of the preparatory
>      patches ;

Yep.

>  (2) Separate the "skeleton re-org" series from the "systemd read-only
>      rootfs" series, so that we can progress on those topics one by
>      one ?

Well, "systemd on read-only rootfs" anyway depends on "systemd
skeleton-or-whatever-we're-gonna-do". ;-) But yes, I can do that.

Thanks for the great summary. I'll copy it for the next cover-letter I
need to send for this series. ;-)

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