FreeBSD CI Weekly Report 2020-05-17
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-05-17 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-05-11 to 2020-05-17. During this period, we have: * 1977 builds (94.6% (+2.5) passed, 5.4% (-2.5) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 236 test runs (41.1% (+17.4) passed, 33.9% (-1.1) unstable, 25.0% (-16.3) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 33 doc and www builds (97.0% (+17.6) passed, 3.0% (-17.6) failed) Test case status (on 2020-05-17 23:59): | Branch/Architecture | Total | Pass | Fail| Skipped | | --- | -- | -- | --- | | | head/amd64 | 7828 (+46) | 7737 (+45) | 1 (+1) | 90 (0) | | head/i386 | 7826 (+46) | 7725 (+43) | 0 (0) | 101 (+3) | | 12-STABLE/amd64 | 7542 (+21) | 7484 (+24) | 0 (0) | 58 (-3) | | 12-STABLE/i386 | 7540 (+21) | 7471 (+18) | 0 (0) | 69 (+3) | | 11-STABLE/amd64 | 6883 (0) | 6830 (-3) | 0 (-1) | 53 (+4) | | 11-STABLE/i386 | 6881 (0) | 6829 (+13) | 0 (-14) | 52 (+1) | (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-20200517 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * (new) lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * (head, stable/12, stable/11) 2 tests start failing after llvm10 import * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 Will be fixed after r360807 merged to stable/12. ## 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 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (0), 579 failures (0), 806 skipped (0) ## 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 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.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger
FreeBSD CI Weekly Report 2020-05-10
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-05-10 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-05-04 to 2020-05-10. During this period, we have: * 2003 builds (92.1% (-1.5) passed, 7.9% (+1.5) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 283 test runs (23.7% (-44.5) passed, 35.0% (+6.9) unstable, 41.3% (+37.6) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 68 doc and www builds (79.4% (-5.2) passed, 20.6% (+5.2) failed) Test case status (on 2020-05-10 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | -- | | --- | | head/amd64 | 7782 (+4) | 7692 (+7) | 0 (0)| 90 (-3) | | head/i386 | 7780 (+4) | 7682 (+6) | 0 (0)| 98 (-2) | | 12-STABLE/amd64 | 7521 (0) | 7460 (-3) | 0 (-2) | 61 (+5) | | 12-STABLE/i386 | 7519 (0) | 7453 (0) | 0 (-2) | 66 (+2) | | 11-STABLE/amd64 | 6883 (0) | 6833 (-1) | 1 (+1) | 49 (0) | | 11-STABLE/i386 | 6881 (0) | 6816 (-14) | 14 (+14) | 51 (0) | (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-20200510 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## News * Several non-x86 jobs for -head are added: * https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/ * https://ci.freebsd.org/job/FreeBSD-head-armv7-test/ * https://ci.freebsd.org/job/FreeBSD-head-mips64-test/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-test/ Most of the work are done by trasz@ These jobs will be scheduled to run at least once a day after the dedicated VM host has been setup. ## Fixed test cases * lib.libproc.proc_test.symbol_lookup Fixed in https://svnweb.freebsd.org/changeset/base/360979 ## Fixed and fixed test cases * lib.atf.* and libexec.atf.* on stable/11 Failed after llvm9 merged, fixed after build https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2662/ with fixeds merged. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * (head, stable/12, stable/11) 3 tests start failing after llvm10 import * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 Will be fixed after r360807 merged to stable/12. ## 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 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (0), 579 failures (0), 806 skipped (0) ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 *
Re: State of encrypted-almost-everything on ZFS in 2020
16.05.2020 16:51, Thomas Zander via freebsd-stable wrote:
> Hi,
>
> can the following be done these days?
> - Encrypted ZFS root pool on RAID-Z
> - Supply the key for the encrypted root pool during boot via USB thumb drive
> - No keyboard is attached to the machine
> - No /boot on the thumb drive, just the key
> - I don't mind if /boot is encrypted or not (the use case is not to
> protect against nation state attackers)
> - Bonus points if I can use bectl
>
> Every single posting regarding this topic I can find always comes down to
> either
> a) One needs /boot on the thumb drive, or
> b) One uses a keyboard and supplies a passphrase instead of a keyfile.
Note that root pool does not need to be original boot pool.
It is possible to share your disks between two different ZFS pools:
small first unencrypted boot pool that boots normally and starts plain shell
script
that reads the key from any storage you prefer to decrypt and attach
second encrypted pool. Then set vfs.root.mountfrom to second pool with kenv(1)
and use re-rooting (reboot -r) to re-start booting from now-available encrypted
pool.
This is how to share disks with GEOM_RAID:
1. Cut first N megabytes of each disk to form N-way mirror using "Promise"
on-disk volume label format:
graid label -S ${N}M Promise r0 RAID1 /dev/da0 /dev/da1 /dev/da2 ...
This gives you /dev/raid/r0 device, use it to create unencrypted non-redundant
ZFS boot pool,
as GEOM_RAID provides (mirrored) redundancy.
2. Allocate tail of each drive to set of SINGLE graid volumes:
graid label Promise r1 SINGLE /dev/da0
graid label Promise r2 SINGLE /dev/da1
graid label Promise r3 SINGLE /dev/da2
...
This gives you devices /dev/raid/r1, /dev/raid/r2 etc. Use them as vdevs to
create your encrypted RAID-Z.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: State of encrypted-almost-everything on ZFS in 2020
Hi, thank you for the quick response. I think I have a good overview of the state of affairs now, thanks! On Sat, 16 May 2020 at 18:46, Allan Jude wrote: > > - Encrypted ZFS root pool on RAID-Z > > Yes, this has been supported in a few varieties for a few major versions now ... and it's a cool feature, no doubt! Unfortunately, it requires me to supply a password via keyboard, as you explain below, so it does not match my use case. > > - Supply the key for the encrypted root pool during boot via USB thumb drive > > - No keyboard is attached to the machine > > - No /boot on the thumb drive, just the key > > This feature was never implemented for GELIBoot. Currently the bootstrap > code only supports a manually entered passphrase. Thanks for clarifying this! > > - I don't mind if /boot is encrypted or not (the use case is not to > > protect against nation state attackers) > > If you use an unencrypted /boot (as opposed to GELIBoot), then I think > you might be able to use the thumb drive approach to hold the key. You > would need to set the correct loader.conf variables to read the key from > the thumbdrive. It might be easier if the key is written raw into a > partition than if it is on a filesystem since it won't be mounted at > that point. Okay, that sounds like not all hope is lost :-) So, something like this might work IIUC: - Have a small (e.g. 16kB) GPT partition on the USB thumb drive, using geom_label, accessible as /dev/label/foo - dd the key onto /dev/label/foo - Have this in loader.conf: geli_label_crypted_keyfile0_load="YES" geli_label_crypted_keyfile0_type="label/crypted:geli_keyfile0" geli_label_crypted_keyfile0_name="/dev/label/foo" > > - Bonus points if I can use bectl > > However, if you use an unencrypted /boot, then you lose bectl and boot > environments, since the kernel is not part of the root filesystem. That's okay, having. bectl would be nice, but secondary. > > I'd like to have a setup where essentially nothing is stored on the > > USB drive except the keyfile. > > I proposed some ideas on how to do this at BSDCan a few years ago, but > have never had the time or financial backing to develop the feature. I am sorry to hear that. One would expect this was not an unconventional use case. Thanks so much for the response, I'll play with the raw partition idea over the next few days and will report back how it went. Best regards Riggs ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
