/usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Ruslan Garipov]

On 4/5/2020 6:52 PM, Tomasz CEDRO wrote:
> Hello Ruslav and thank you for your feedback! :-)
> 
> On Sun, Apr 5, 2020 at 3:07 PM Ruslan Garipov wrote:
>> On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
>>> 1. Is it a good build / testing environment? Maybe there is a simpler
>>> / better way to cross compile binaries and test on another machine?
>>> Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
>>> should work both with 12.1-RELEASE and 12-STABLE right?
>> Both machines have the same architecture, therefore it is not a cross
>> build, I believe.  For my direct builds (both build and consumer
>> machines are x86-64) I use the procedure described in the handbook
>> (``23.6. Tracking for Multiple Machines''[1]).
> 
> I know that method, thank you :-) But I also want to try out the
> binary release, which seems a bit more flexible to have just
> everything in one place, may be used to install on an external machine
> without NFS access, etc :-)
> 
> It would be also nice to know the time cost of those two methods, so I
> want to verify :-)
> 
> 
>>> 3. During /usr/src/release/release.sh I get following error as pasted
>>> below. Does release.sh update /usr/ports just as it snaps from svn or
>>> it will use the /usr/porst that are just there and I need to provide
>>> /usr/ports in a state that will be bindled into a /scratch release?
>> A quote from release(7) man page:
>>
>> release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
>>
>> Therefore, release(7) "ignores" /usr/ports and uses
>> ${CHROOTDIR}/usr/ports.  My build machine doesn't have access to the
>> Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
>> provide ports tree into the ${CHROOTDIR}/usr/ports before
>> I will call /usr/src/release/release.sh.
> 
> Okay, so the build uses totally separate CHROOT in /scratch?
Yes.

> I wonder
> if that "Bad System Call" is caused by my Host tools or the CHROOT
> tools?
By the chrooted environment within the ${CHROOTDIR} I believe.
Otherwise you would get the same error on "host".

> 
> It looks like the /scratch has its own compiled in tools not a copy
> from my host?
Yes, release(7) builds and installs clean userland into the ${CHROOTDIR}
(DESTDIR=${CHROOTDIR}), and doesn't copy it from the "host".

> 
> # diff -u /usr/bin/fetch /scratch/usr/bin/fetch
> Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differ
> 
> 
>>> ===>   docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
>>> ===>  License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> ===>  Extracting for pkg-1.14.2
>>> ===>  License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
>>> ===>  Refetch for 1 more times files:  freebsd-pkg-1.14.2_GH0.tar.gz
>>> ===>  License BSD2CLAUSE accepted by the user
>>> => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
>>> => Attempting to fetch
>>> https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
>>> freebsd-pkg-1.14.2_GH0.tar.gz                 Bad system call (core dumped)
>> /usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
>> installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
>>
>> As for why fetch(1) fails with bad system call under chrooted
>> environment -- I don't know.  I failed on a port fetching only if I
>> hadn't provided all necessary distfiles.  You have checksum error
>> message which is causing refetching of the ports-mgmt/pkg port.
>> Therefore, I believe
>> ${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
>> file system (remained from a previous fetch try?)...  May be you should
>> try fetch(1) from the chrooted environment manually, to get any content?
> 
> This "Bad System Call" stops me from proceeding. I did place by hand
> the required package in the right place, then it built ok, then I got
> that "Bad System Call" again on install :-(
> 
> How can I get the debug symbols in /scratch binaries?
You need to provide custom src.conf or/and make.conf to release(7).

I, actually, provide make.conf, src.conf and kernel config (not for the
debug symbols; just for tuning the target release).

> 
> So far I can just show:
> [New LWP 100764]
> Core was generated by `/usr/bin/fetch -Fpr -S 3405355
> http://distcache.FreeBSD.org/ports-distfiles/free'.
> Program terminated with signal SIGSYS, Bad system call.
> #0  0x00000008003c1bca in ?? ()
> (gdb) bt
> #0  0x00000008003c1bca in ?? ()
> #1  0x000000080031d144 in ?? ()
> #2  0x000000080031d260 in ?? ()
> #3  0x0000000000000008 in ?? ()
> #4  0xb650b69b3fd03fb8 in ?? ()
> #5  0x00007fffffffdd40 in ?? ()
> #6  0x00007fffffffe64c in ?? ()
> #7  0x0000000800e1d000 in ?? ()
> #8  0x00000000002091e0 in ?? ()
> #9  0x00007fffffffdc80 in ?? ()
> #10 0x00007fffffffdc40 in ?? ()
> #11 0x000000080031d2f9 in ?? ()
> #12 0x0000000800e1d000 in ?? ()
> #13 0x00007fffffffdd40 in ?? ()
> #14 0x0000000000000000 in ?? ()
> 
> 
> Thank you! :-)
> Tomek
>