Tomasz CEDRO
2020-Apr-05 13:52 UTC
/usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
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? I wonder if that "Bad System Call" is caused by my Host tools or the CHROOT tools? It looks like the /scratch has its own compiled in tools not a copy from my 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? 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 -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Ruslan Garipov
2020-Apr-05 14:36 UTC
/usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
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 >
Ruslan Garipov
2020-Apr-05 14:59 UTC
/usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
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? I wonder > if that "Bad System Call" is caused by my Host tools or the CHROOT > tools? > > It looks like the /scratch has its own compiled in tools not a copy > from my host? > > # diff -u /usr/bin/fetch /scratch/usr/bin/fetch > Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differI'm sorry, I forgot to ask how do you call /usr/src/release/release.sh? Do you pass a configuration file to this script? By default /usr/src/release/release.sh checks out the source tree for the CURRENT branch (svn://svn.FreeBSD.org/base/head at rHEAD). In this case (if you doesn't change it) chrooted environment definitely will fail to run on STABLE and/or RELEASE. May be it's easy for you to use `make release` directly.> > >>> ===> 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? > > 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 >