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

[Bryan Drewery]

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}"


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20180705/c6e1ccb0/attachment.sig>