error installing world from R/O src and obj
Attempting to install r353380 (amd64) with src and obj mounted via NFS. The world has just been built albeit with NO_CLEAN=1. Getting this: ... ===> lib/clang (install) ===> lib/clang/libllvm (install) ===> lib/clang/libclang (install) ===> lib/clang/liblldb (install) ===> lib/clang/headers (install) clang-tblgen -gen-arm-fp16 -I /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic -d arm_fp16.h.d -o arm_fp16.h /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic/arm_fp16.td clang-tblgen: error opening arm_fp16.h.d:Read-only file system *** Error code 1 Stop. The command is: make installworld __MAKE_CONF=/dev/null SRCCONF=/dev/null DB_FROM_SRC=1 DESTDIR=/mnt -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error installing world from R/O src and obj
On 11/10/2019 12:05, Andriy Gapon wrote: > > Attempting to install r353380 (amd64) with src and obj mounted via NFS. > The world has just been built albeit with NO_CLEAN=1. > Getting this: > ... > ===> lib/clang (install) > ===> lib/clang/libllvm (install) > ===> lib/clang/libclang (install) > ===> lib/clang/liblldb (install) > ===> lib/clang/headers (install) > clang-tblgen -gen-arm-fp16 -I > /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic -d > arm_fp16.h.d -o arm_fp16.h > /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic/arm_fp16.td > clang-tblgen: error opening arm_fp16.h.d:Read-only file system > *** Error code 1 > > Stop. > > The command is: > make installworld __MAKE_CONF=/dev/null SRCCONF=/dev/null DB_FROM_SRC=1 > DESTDIR=/mnt > It seems that buildworld NO_CLEAN=1 is not regenerating that header for some reason. The command was: make buildworld -s -j12 __MAKE_CONF=/dev/null SRCCONF=/dev/null NO_CLEAN=1 If I do make buildenv and then cd lib/clang/headers/ and run make there, I see this: $ make clang-tblgen -gen-arm-fp16 -I /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic -d arm_fp16.h.d -o arm_fp16.h /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic/arm_fp16.td But afterwards: $ ls -l /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h* -rw-r--r-- 1 avg wheel 36361 21 Jun 15:12 /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h -rw-r--r-- 1 avg wheel100 11 Oct 12:16 /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h.d The .h.d file has a fresh timestamp, but .h is still old. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error installing world from R/O src and obj
On 11/10/2019 20:51, Dimitry Andric wrote: > On 11 Oct 2019, at 11:24, Andriy Gapon wrote: >> >> On 11/10/2019 12:05, Andriy Gapon wrote: >>> >>> Attempting to install r353380 (amd64) with src and obj mounted via NFS. >>> The world has just been built albeit with NO_CLEAN=1. >>> Getting this: >>> ... >>> ===> lib/clang (install) >>> ===> lib/clang/libllvm (install) >>> ===> lib/clang/libclang (install) >>> ===> lib/clang/liblldb (install) >>> ===> lib/clang/headers (install) >>> clang-tblgen -gen-arm-fp16 -I >>> /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic -d >>> arm_fp16.h.d -o arm_fp16.h >>> /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic/arm_fp16.td >>> clang-tblgen: error opening arm_fp16.h.d:Read-only file system >>> *** Error code 1 >>> >>> Stop. >>> >>> The command is: >>> make installworld __MAKE_CONF=/dev/null SRCCONF=/dev/null DB_FROM_SRC=1 >>> DESTDIR=/mnt >>> >> >> It seems that buildworld NO_CLEAN=1 is not regenerating that header for some >> reason. >> The command was: make buildworld -s -j12 __MAKE_CONF=/dev/null >> SRCCONF=/dev/null >> NO_CLEAN=1 >> >> If I do make buildenv and then cd lib/clang/headers/ and run make there, I >> see this: >> $ make >> clang-tblgen -gen-arm-fp16 -I >> /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic -d >> arm_fp16.h.d -o arm_fp16.h >> /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic/arm_fp16.td >> >> But afterwards: >> $ ls -l >> /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h* >> -rw-r--r-- 1 avg wheel 36361 21 Jun 15:12 >> /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h >> -rw-r--r-- 1 avg wheel100 11 Oct 12:16 >> /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h.d >> >> The .h.d file has a fresh timestamp, but .h is still old. > > The files should be generated when "make depend" is run, but are your > NFS server and client clocks in sync? Usually this kind of thing is > caused by time differences. Yes, they are in sync. Could it be that clang-tblgen for some reason does not overwrite the existing file? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
how to configure RaidZ pool for anon FTP
Hi: I would appreciate suggestions for how to accomplish the following. I would like to setup an anon FTP server on a local network. I plan to use one disk with UFS for booting and running the OS, and would like to use 4 disks in a RaidZ pool as the space for uploading and downloading files via FTP (/var/ftp/) from the local network only. Also, I remember several years ago there was a very simple and easy way to get anon FTP working. I think the command was bsdinstall, and then you could choose an option that would set up anon FTP. Does that still exist, what is the procedure to configure it now? Any suggestions for how to configure this would be greatly appreciated, thanks in advance. Regards ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error installing world from R/O src and obj
On 11 Oct 2019, at 11:24, Andriy Gapon wrote: > > On 11/10/2019 12:05, Andriy Gapon wrote: >> >> Attempting to install r353380 (amd64) with src and obj mounted via NFS. >> The world has just been built albeit with NO_CLEAN=1. >> Getting this: >> ... >> ===> lib/clang (install) >> ===> lib/clang/libllvm (install) >> ===> lib/clang/libclang (install) >> ===> lib/clang/liblldb (install) >> ===> lib/clang/headers (install) >> clang-tblgen -gen-arm-fp16 -I >> /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic -d >> arm_fp16.h.d -o arm_fp16.h >> /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic/arm_fp16.td >> clang-tblgen: error opening arm_fp16.h.d:Read-only file system >> *** Error code 1 >> >> Stop. >> >> The command is: >> make installworld __MAKE_CONF=/dev/null SRCCONF=/dev/null DB_FROM_SRC=1 >> DESTDIR=/mnt >> > > It seems that buildworld NO_CLEAN=1 is not regenerating that header for some > reason. > The command was: make buildworld -s -j12 __MAKE_CONF=/dev/null > SRCCONF=/dev/null > NO_CLEAN=1 > > If I do make buildenv and then cd lib/clang/headers/ and run make there, I > see this: > $ make > clang-tblgen -gen-arm-fp16 -I > /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic -d > arm_fp16.h.d -o arm_fp16.h > /usr/devel/svn/quick-head/contrib/llvm/tools/clang/include/clang/Basic/arm_fp16.td > > But afterwards: > $ ls -l > /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h* > -rw-r--r-- 1 avg wheel 36361 21 Jun 15:12 > /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h > -rw-r--r-- 1 avg wheel100 11 Oct 12:16 > /usr/obj/usr/devel/svn/quick-head/amd64.amd64/lib/clang/headers/arm_fp16.h.d > > The .h.d file has a fresh timestamp, but .h is still old. The files should be generated when "make depend" is run, but are your NFS server and client clocks in sync? Usually this kind of thing is caused by time differences. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: DRM-current-kmod is still a problem at r353339
On 2019-10-10 13:44, Mateusz Guzik wrote: > Probably whitespace issues from copypasting. I used dpaste since > people.freebsd.org was down. > > It's up, so: > https://people.freebsd.org/~mjg/pmap-fict3.diff > That patch worked for me also. The patch applied clean when I used 'wget' to retrieve vs. saving a file from my web browser. Thanks for the quick fix. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD CI Weekly Report 2019-10-06
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-10-06 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-09-30 to 2019-10-06. During this period, we have: * 2129 builds (99.4% (+0.8) passed, 0.6% (-0.8) failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 333 test runs (81.7% (+10.2) passed, 18.3% (-1.7) unstable) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 42 doc builds (100% passed) Test case status (on 2019-10-06 23:59): | Branch/Architecture | Total | Pass | Fail| Skipped | | --- | -- | -- | --- | | | head/amd64 | 7589 (+1) | 7526 (+1) | 0 (0) | 63 (0) | | head/i386 | 7587 (+1) | 7515 (+1) | 0 (0) | 72 (0) | | 12-STABLE/amd64 | 7482 (+8) | 7441 (+11) | 0 (0) | 41 (-3) | | 12-STABLE/i386 | 7480 (+8) | 7434 (+13) | 0 (0) | 48 (-3) | | 11-STABLE/amd64 | 6849 (0) | 6808 (+3) | 0 (0) | 41 (-3) | | 11-STABLE/i386 | 6847 (0) | 6770 (+3) | 34 (0) | 43 (-3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20191006 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * [FCP 20190401-ci_policy: CI policy](https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md) is in "feedback" state, please check and provide comments on -fcp@ and -hackers@ mailing lists. * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.amd64.arrays.t_dtrace_contrib.tst_uregsarray_d * Fixed in head https://svnweb.freebsd.org/changeset/base/353107 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~18 failing and ~97 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.netpfil.pf.forward.v4 (i386 only) * sys.netpfil.pf.forward.v6 (i386 only) * sys.netpfil.pf.set_tos.v4 (i386 only) https://bugs.freebsd.org/239380 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * sys.netpfil.common.tos.pf_tos (i386 only) https://bugs.freebsd.org/240086 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: *
