From owner-freebsd-hackers@freebsd.org Sun Mar 14 04:31:56 2021
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.nyi.freebsd.org (Postfix) with ESMTP id 86E1B570AC7
for <freebsd-hackers@mailman.nyi.freebsd.org>;
Sun, 14 Mar 2021 04:31:56 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4Dymq03Wq3z4dMS;
Sun, 14 Mar 2021 04:31:56 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from mousie.catspoiler.org (unknown [76.212.85.177])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
(Authenticated sender: truckman)
by smtp.freebsd.org (Postfix) with ESMTPSA id E3B3AAD4A;
Sun, 14 Mar 2021 04:23:08 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Date: Sat, 13 Mar 2021 20:23:06 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: problems building a release
To: Mark Millard <marklmi@yahoo.com>
cc: freebsd-hackers <freebsd-hackers@freebsd.org>
In-Reply-To: <tkrat.304b50b10f666282@FreeBSD.org>
Message-ID: <tkrat.645fdb73b10e60a7@FreeBSD.org>
References: <tkrat.1c0426e45b0db829@FreeBSD.org>
<B1EB0872-3BC4-424A-AC83-1D5184B9DA15@yahoo.com>
<tkrat.1fc12827aa92db3e@FreeBSD.org>
<8CE18E0A-8931-4C41-83B4-D30EEC049E6D@yahoo.com>
<tkrat.4f378e8f76c23887@FreeBSD.org>
<EF95616D-B070-424E-96C8-B00E96F392B5@yahoo.com>
<tkrat.304b50b10f666282@FreeBSD.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Disposition: INLINE
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Technical discussions relating to FreeBSD
<freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Mar 2021 04:31:56 -0000
On 13 Mar, Don Lewis wrote:
> On 13 Mar, Mark Millard wrote:
>>> On 2021-Mar-13, at 12:43, Don Lewis <truckman at FreeBSD.org> wrote:
>>>
>>> On 13 Mar, Mark Millard wrote:
>>>> . . .
>>>
>>> Thanks. All of this stuff is pretty confusing.
>>>
>>> If I specify MAKE_CONF in release.conf, it does affect the target build.
>>> In particular MODULES_OVERRIDE does the right thing.
>>>
>>> It seems like there should be a way to specify a make.conf and src.conf
>>> so that they get included in the release so that if the release is
>>> installed and then world and kernel are built it reproduces itself.
>>>
>>> I did manage to unmute release.sh and make so that the build is verbose,
>>> but the error I get when I specify TARGET and TARGET_ARCH in the
>>> make.conf is still a mystery. There doesn't seem to be a line buffering
>>> problem hiding things, this was captured from the terminal window with
>>> no redirections involved.
>>>
>>> ===> etc (installconfig)
>>> mkdir -p bootonly/usr/freebsd-dist
>>> cp MANIFEST bootonly/usr/freebsd-dist
>>> ln -fs /tmp/bsdinstall_etc/resolv.conf bootonly/etc/resolv.conf
>>> echo sendmail_enable=\"NONE\" > bootonly/etc/rc.conf
>>> echo hostid_enable=\"NO\" >> bootonly/etc/rc.conf
>>> echo debug.witness.trace=0 >> bootonly/etc/sysctl.conf
>>> echo vfs.mountroot.timeout=\"10\" >> bootonly/boot/loader.conf
>>> echo kernels_autodetect=\"NO\" >> bootonly/boot/loader.conf
>>> cp /usr/src/release/rc.local bootonly/etc
>>> sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_BO bootonly.iso bootonly
>>> sh /usr/src/release/i386/make-memstick.sh disc1 memstick.img
>>> Calculated size of `memstick.img.part': 624754688 bytes, 13074 inodes
>>> Extent size set to 32768
>>> memstick.img.part: 595.8MB (1220224 sectors) block size 32768, fragment size 4096
>>> using 1 cylinder groups of 595.81MB, 19066 blks, 13952 inodes.
>>> super-block backups (for fsck -b #) at:
>>> 192,
>>> Populating `memstick.img.part'
>>> Image `memstick.img.part' complete
>>> sh /usr/src/release/i386/make-memstick.sh bootonly mini-memstick.img
>>> Calculated size of `mini-memstick.img.part': 237436928 bytes, 13069 inodes
>>> Extent size set to 32768
>>> mini-memstick.img.part: 226.4MB (463744 sectors) block size 32768, fragment size 4096
>>> using 1 cylinder groups of 226.44MB, 7246 blks, 14592 inodes.
>>> super-block backups (for fsck -b #) at:
>>> 192,
>>> Populating `mini-memstick.img.part'
>>> Image `mini-memstick.img.part' complete
>>
>> The below notes are about what starts here:
>>
>>> make -C /usr/src/release release-done
>>> ELF interpreter /libexec/ld-elf.so.1 not found, error 8
>>> Abort trap
>>> ELF interpreter /libexec/ld-elf.so.1 not found, error 8
>>> Abort trap
>>> ELF interpreter /libexec/ld-elf.so.1 not found, error 8
>>> Abort trap
>>> ELF interpreter /libexec/ld-elf.so.1 not found, error 8
>>> Abort trap
>>> ELF interpreter /libexec/ld-elf.so.1 not found, error 8
>>> Abort trap
>>> ELF interpreter /libexec/ld-elf.so.1 not found, error 8
>>> Abort trap
>>> touch release
>>> true
>>
>> That is interesting as this turns out to be a fairly
>> simple context by the time that "make . . . release-done"
>> is echoed:
>>
>> QUOTE
>> release: real-release vm-release cloudware-release
>> ${MAKE} -C ${.CURDIR} ${.MAKEFLAGS} release-done
>> true
>>
>> release-done:
>> touch release
>> END QUOTE
>>
>> but by then "real-release vm-release cloudware-release"
>> completed and we see the touch and true after the messages.
>>
>> So it looks like the 6 "not found" messages are from
>> make's internal activities.
>>
>> It would be interesting to get a truss -f log (or some such)
>> of that "${MAKE} . . . release-done" out into to a file.
>> There should not be much other activity in the file generated.
>> That might expose the activity producing the "not found"
>> messages.
>>
>> Also interesting might be adding a "file /libexec/ld-elf.so.1"
>> command line to release: or adding other such context reporting
>> there, such as "uname -apKU" .
>
> scratch/libexec/ld-elf.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 14.0 (1400005), stripped
>
>
> Mystery solved. I ran "make -C /usr/src/release release-done" under
> the chroot with a bunch of debug flags. All of the errors were
> associated with references to GIT* make variables. Those are defined as
> as:
>
> Makefile.inc1:GITBRANCH!= ${GIT_CMD} -C ${.CURDIR} rev-parse --abbrev-ref HEAD 2>/dev/null | sed -e 's/\^\///'
> Makefile.inc1:GITREV!= ${GIT_CMD} -C ${.CURDIR} rev-parse --verify --short HEAD 2>/dev/null || true
> Makefile.inc1:GITCOUNT!= ${GIT_CMD} -C ${.CURDIR} rev-list --count HEAD 2>/dev/null || true
>
> so every reference would try to run git because of make's lazy variable
> evaluation. The installed version of git is an amd64 executable left
> over from earlier experiments.
When I cleaned out all the packages installed under /scratch, did a
'pkg-static bootstrap -f' and installed an i386 version of git, the
errors went away.
It doesn't look like I want to play with CHROOT_MAKEENV since I don't
want to muck with the chroot.
RELEASE(7) says:
MAKE_CONF The make.conf(5) to use for the release build. Defaults
to /dev/null to prevent polluting the release with local
system changes.
but it is clear that the TARGET and TARGET_ARCH settings there affect
the chroot build. The settings of MAKE_CONF and SRC_CONF are stored in
${CONF_FILES}, which is included in CHROOT_*MAKEFLAGS as well as
RELEASE_*MAKEFLAGS. The former should probably use the default /dev/null
values.