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