[OE-core] [OE-Core][PATCH v6 0/6] systemd stateless configuration

Fri May 3 15:02:37 UTC 2019

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org <openembedded-
> core-bounces at lists.openembedded.org> On Behalf Of Jonas Bonn
> Sent: den 3 maj 2019 14:55
> To: Alex Kiernan <alex.kiernan at gmail.com>; OE-core <openembedded-
> core at lists.openembedded.org>
> Subject: Re: [OE-core] [OE-Core][PATCH v6 0/6] systemd stateless
> configuration
> 
> Hi Alex,
> 
> On 03/05/2019 10:37, Alex Kiernan wrote:
> > On Thu, May 2, 2019 at 10:10 PM Alex Kiernan <alex.kiernan at gmail.com>
> > wrote:
> >>
> >> This patch set is largely Jonas Bonn's to move towards a "stateless"
> >> configuration:
> >>
> >>    These patches make some modifications to systemd with the long-
> >>    term goal of being able to run OE in systemd's "stateless" 
> >>    configuration.  "Stateless" boils down to building an image 
> >>    with empty /etc and /var directories so that volatile (tmpfs) 
> >>    filesystems can be mounted there; this requires that the 
> >>    system subsequently be able to populate these directories 
> >>    dynamically, which systemd mostly takes care of if things are
> >>    done right.
> >>
> >>    In these patches:
> >>    i)   Don't include machine-id in writable images so that 
> >>         systemd can run its first-boot machinery
> >>    ii)  Move systemd configuration files out of /etc
> >>    iii) Allow systemd to dynamically enable services and 
> >>         populate /etc/systemd/system via the presets mechanism
> >>
> >>    There's a long way to go to get to a working "stateless"
> >>    configuration.  Getting to a "volatile" system (just empty 
> >>    /var) should be easier and I'll post patches moving things in 
> >>    that direction shortly.
> >>
> >> However as a result of the systemd 242 upgrade, which includes
> >> 01d2041e41f4 ("meson: stop creating enablement symlinks in /etc 
> >> during installation"), services such as systemd-networkd are no 
> >> longer enabled in images.
> >>
> >> This patch set fixes this problem in addition to satisfying the 
> >> goal of moving towards "stateless" configurations.
> >>
> >> The issue with respect to image testing during CI was caused by
> >> systemd-time-wait-sync.service being enabled due to the lack of
> >> a default preset policy:
> >>
> >> https://www.freedesktop.org/wiki/Software/systemd/Preset/#howto
> >>
> >> Changes in v6:
> >> - switch configuration to simple overrides in /usr/lib/systemd/*.conf.d
> >> - make systemd RRECOMMENDS rather than RDEPENDS on systemd-conf
> >> - don't exit in postinst as when that executes we're actually a
> >>    concatenation of all fragments
> >> - validate SYSTEMD_AUTO_ENABLE is `enable` or `disable`
> >> - rewrite systemctl-native in Python
> >> - moved systemctl preset-all to IMAGE_PREPROCESS so it runs after ROOTFS,
> >>    run for all images, not just read-only
> >>
> >> Changes in v5:
> >> - rebased for systemd 242
> >> - install default preset distribution policy of "enable nothing"
> >>
> >> Alex Kiernan (3):
> >>    systemd-conf: simplify creation of machine-specific configuration
> >>    systemctl-native: Rewrite in Python supporting preset-all and mask
> >>    image: call systemctl preset-all for images
> >>
> >> Jonas Bonn (3):
> >>    systemd: don't build firstboot by default
> >>    systemd: do not create machine-id
> >>    systemd: create preset files instead of installing in image
> >>
> >>   meta/classes/image.bbclass                    |   9 +-
> >>   meta/classes/rootfs-postcommands.bbclass      |   6 +
> >>   meta/classes/systemd.bbclass                  |  41 +-
> >>   .../systemd/systemd-conf/journald.conf        |   3 +
> >>   .../systemd/systemd-conf/logind.conf          |   2 +
> >>   .../systemd/systemd-conf/system.conf          |   2 +
> >>   .../systemd/systemd-conf/system.conf-qemuall  |   3 +
> >>   meta/recipes-core/systemd/systemd-conf_242.bb |  61 +--
> >>   .../systemd/systemd-systemctl/systemctl       | 476 ++++++++++--------
> >>   .../systemd/systemd/99-default.preset         |   1 +
> >>   meta/recipes-core/systemd/systemd_242.bb      |  26 +-
> >>   11 files changed, 360 insertions(+), 270 deletions(-)
> >>   create mode 100644 meta/recipes-core/systemd/systemd-conf/journald.conf
> >>   create mode 100644 meta/recipes-core/systemd/systemd-conf/logind.conf
> >>   create mode 100644 meta/recipes-core/systemd/systemd-conf/system.conf
> >>   create mode 100644 meta/recipes-core/systemd/systemd-conf/system.conf-qemuall
> >>   create mode 100644 meta/recipes-core/systemd/systemd/99-default.preset
> >
> > Sigh...
> >
> > this still has issues - if you boot with `ro` on the kernel command
> > line and without an initramfs, then / is read-only when systemd
> > starts and it basically refuses to do anything:
> >
> > [    7.222134] systemd[1]: No hostname configured.
> > [    7.227266] systemd[1]: Set hostname to <localhost>.
> > [    7.232622] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only.
> > [    7.241750] systemd[1]: Booting up is supported only when:
> > [    7.247362] systemd[1]: 1) /etc/machine-id exists and is populated.
> > [    7.253752] systemd[1]: 2) /etc/machine-id exists and is empty.
> > [    7.259757] systemd[1]: 3) /etc/machine-id is missing and /etc is writable.
> >
> > Note this has nothing to do with read-only-rootfs, this is just a
> > regular boot... that said a bunch of things that were broken now
> > work, so it's progress!
> >
> > I'm leaning towards having systemctl-native touch /etc/machine-id
> > when it runs, unless you explicitly ask for stateless in
> > DISTRO_FEATURES... patches to follow.
> 
> The paradigm that systemd follows is that /etc is _always_ writable.
> The read-only rootfs that OE produces with a read-only /etc is
> pathological from systemd's point of view (as is your 'ro' kernel
> parameter example).  The way to handle this is to:
> 
> i) mount a tmpfs over /etc
> ii) move the contents of /etc to /usr/share/factory/etc at buildtime
> and
> have tmpfiles.d snippets that take care of populating /etc at runtime

That is probably the way to handle it for a stateless system. 
However, even without stateless, having /etc being writable is 
almost a necessity when using systemd. In our case, we mount 
an overlayfs on top of /etc to make it writable (before 
systemd is started). As I do not see us switching to a stateless 
system any time soon, I believe it would be good to be able to 
differentiate between the tree variants for how /etc is used: 
read-only, writable and stateless. Today the only DISTRO_FEATURE 
is read-only-rootfs, which is not really relevant for /etc.

> I have a set of patches that does this, but it's all pretty fragile at
> this point in time.  It scans /etc at buildtime, moves files and links
> to factory/{var,etc}, sets up tmpfiles.d snippets for files and
> directories.  Doing this, however, somewhat requires for things that
> _can_ be set up at runtime to be so; what remains in /etc should only
> be
> stuff that doesn't set itself up at runtime _yet_.  For this reason,
> I'm
> inclined to say that you _don't_ want to leave the /etc/systemd/system
> nor /etc/machine-id files in the image.
> 
> /Jonas
> 
> > Alex Kiernan

//Peter