Re: [OE-core] [PATCH v3 1/5] systemd: update 246 -> 247

["Peter Kjellerstedt" <peter.kjellerstedt@axis.com>]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 19 december 2020 12:19
> To: Luca Bocassi <luca.boccassi@gmail.com>; openembedded-
> core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH v3 1/5] systemd: update 246 -> 247
> 
> On Sat, 2020-12-19 at 11:03 +0000, Richard Purdie via
> lists.openembedded.org wrote:
> > On Sat, 2020-12-19 at 10:33 +0000, Richard Purdie via
> > lists.openembedded.org wrote:
> > >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1662/st
> eps/14/logs/stdio
> > >
> > > (there is a second issue there from other patches in master-next
> > > too).
> > >
> > > We do need a green build to be able to merge so this may depend on
> > > someone else looking into that reproducibility issue. I did try and
> > > give some hints in my previous email, I'd need to look at the code
> > > to
> > > be able to give any more pointers.
> >
> > Looking at the output in
> > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201219-
> fqxxqel9/packages/diff-html/
> >
> > you can see that the .text section in the binary changes size.
> > Ignoring
> > the offset changes, the actual change is the change in size of
> > the maybe_emit_login_defs_warning function from 256 to 275 bytes.
> >
> > That function is in the systemd sources in
> > git/src/sysusers/sysusers.c.
> >
> > It uses a variety of configuration options such as:
> >
> > SYSTEM_ALLOC_UID_MIN
> > SYSTEM_UID_MAX
> > SYSTEM_ALLOC_GID_MIN
> > SYSTEM_GID_MAX
> >
> > My best guess is that we're not setting one of these and its falling
> > back to a host system value which varies by host distro.
> >
> > Obviously we need to prove that and figure out the correct value for
> > OE
> > usage but its maybe a pointer as to the possible problem (or I could
> > be
> > totally wrong!).
> 
> I was far enough into this I kept going. The defaults for these are set
> in meson.build from:
> 
> foreach tuple : [['system-alloc-uid-min', 'SYS_UID_MIN', 1],  # Also see
> login.defs(5).
>                  ['system-uid-max',       'SYS_UID_MAX', 999],
>                  ['system-alloc-gid-min', 'SYS_GID_MIN', 1],
>                  ['system-gid-max',       'SYS_GID_MAX', 999]]
> 
> which if they're not set, looks at the host system /etc/login.defs file
> which is host contamination and is bad. On my ubuntu system, these
> aren't set by default. For Centos7 and 8:

Now this made me feel really stupid. We have had the following lines in our 
systemd_%.bbappend for years and I never got around to upstream them:

# FIXME: These are incorrectly determined by meson based on the host's
# /etc/login.defs file. If there is a way to get meson to do the right thing
# when configuring for cross compilation, then that should be upstreamed to
# systemd, otherwise this change should be upstreamed to OE.
EXTRA_OEMESON += "-Dsystem-uid-max=999 \
                  -Dsystem-gid-max=999"

Sorry about that.

> [rpurdie@centos8-ty-1 ~]$ grep SYS /etc/login.defs
> SYS_UID_MIN               201
> SYS_UID_MAX               999
> SYS_GID_MIN               201
> SYS_GID_MAX               999
> 
> so I think we have our trigger. I have a simply patch to specify
> defaults in the recipe which I think should resolve this. I'll add it
> to master-next and see if that helps.

Looking at your patch in master-next, I believe you should set 
-Dsystem-alloc-uid-min and -Dsystem-alloc-gid-min to 101 rather than 1 
to match what is in /etc/login.defs.

> Cheers,
> 
> Richard

//Peter