> -----Original Message----- > From: openembedded-core-boun...@lists.openembedded.org <openembedded- > core-boun...@lists.openembedded.org> On Behalf Of Jonas Bonn > Sent: den 3 maj 2019 14:55 > To: Alex Kiernan <alex.kier...@gmail.com>; OE-core <openembedded- > c...@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.kier...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core