problems building a release

Don Lewis truckman at FreeBSD.org
Sun Mar 14 04:31:56 UTC 2021


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.





More information about the freebsd-hackers mailing list