svn commit: r336019 - in head: . usr.sbin/config

[Kyle Evans]

On Fri, Jul 6, 2018 at 1:08 AM, Bryan Drewery <bdrewery at freebsd.org> wrote:
> On 7/5/18 6:53 PM, Kyle Evans wrote:
>> On Thu, Jul 5, 2018 at 8:11 PM, Kyle Evans <kevans at freebsd.org> wrote:
>>> Author: kevans
>>> Date: Fri Jul  6 01:11:06 2018
>>> New Revision: 336019
>>> URL: https://svnweb.freebsd.org/changeset/base/336019
>>>
>>> Log:
>>>   config(8): De-dupe hint/env vars within a single file
>>>
>>>   r335653 flipped the order in which hints/env files are concatenated to match
>>>   the order in which vars are processed by the kernel. This is the other
>>>   hammer to drop.
>>>
>>>   Use nv(9) to de-dupe entries within a single `hint` or `env` file, using the
>>>   latest value specified for a key. This leaves some duplicates if a variable
>>>   is specified in multiple hint/env files or via `envvar` in a kernel config,
>>>   but the reversed order of concatenation (from r335653) makes this a
>>>   non-issue as the latest-specified version will be seen first.
>>>
>>>   This change also silently rewrote hint bits to use the same sanitization
>>>   process that ian@ wrote for r335642. To the kernel, hints and env vars are
>>>   basically the same thing through early boot, then get merged into the
>>>   dynamic environment once kmem becomes available and the dynamic environment
>>>   is created. They should be subjected to the same restrictions.
>>>
>>>   libnv has been added to -legacy for the time being to support the build of
>>>   config(8) with the new cnvlist API.
>>>
>>>   Tested with:  universe (11 host & 12 host)
>>>   MFC after:    1 month
>>>
>>
>> This seems to be causing pretty consistent config(8) failures on CI,
>> kernels with neither hints nor environment variables, that neither of
>> my universe builds nor any of my post-commit builds can reproduce. Can
>> anyone else reproduce these failures that might be willing to give me
>> a hint as to what kind of setup causes this?
>>
>> 01:47:58 cd /usr/src/sys/arm/conf;
>> PATH=/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/bin:/usr/obj/usr/src/arm.armv7/tmp/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
>>  config  -d /usr/obj/usr/src/arm.armv7/sys/GENERIC  -I
>> '/usr/src/sys/arm/conf' '/usr/src/sys/arm/conf/GENERIC'
>> 01:47:58 config: /usr/src/sys/arm/conf/GENERIC: No error: 0
>>
>
> I've seen this error with broken ABI. The -I${SRCTOP}/sys on the config
> build may be contributing to the problem since sys/stat.h is ino64 and
> the builder may not be.  Really should not be bringing in the source
> sys/ directory for any of the early host tool phases. There's some hack
> patterns to bring in a limited amount of headers but in this case the
> headers should be getting staged somewhere already.
> Note legacy:
> ${MAKE} DIRPRFX=${_tool}/ DESTDIR=${WORLDTMP}/legacy includes; \
>
> So -IWORLDTMP/legacy/sys should find the nv headers. This is already
> included via:
> tools/build/mk/Makefile.boot:CFLAGS+=   -I${WORLDTMP}/legacy/usr/include
> Which is brought in for bootstrap-tools though via:
> MAKEFLAGS="-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS}"
>

Ahh, that explains it. I did a little bit of a dirty hack in r336026
to install the needed libnv headers with libnv- otherwise, we'd still
be relying on the host libnv headers since sys/ bits don't normally
get pulled in with `make includes` (from the look of it). It feels
wrong to have a userland lib installing headers into
${INCLUDEDIR}/sys, but I think that's a libnv problem. This should fix
the observed problem with CI for the time being.