From nobody Thu Apr 13 09:42:57 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pxvl80qM1z44d8s for ; Thu, 13 Apr 2023 09:43:00 +0000 (UTC) (envelope-from danilo@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pxvl73hM4z3MbL for ; Thu, 13 Apr 2023 09:42:59 +0000 (UTC) (envelope-from danilo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681378979; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A777V/OQMH/wCXiERmZs+VcN4EZtzYLfOJ7lG5UajCk=; b=gAWJ0dz8MDHb2/+gSgZkMxaKBPZh6eu4MH/i/PmolrsqLZtf047R/i8ZGVXasNiAkCmDHL hk1FdDabaLgkm3Kz8u19JsAqBo4siDV/UEJ68hhdOUdtYp9/UnNqwq4S5pQzprfN+LrA+6 BhNe5hRfLQAqioyk34NhNqzEzRyw/74bLFGlOEtcCFYZOg0TWJr4ISnzuovvLfABICuTZA 28AeDGGbMNqN5TgcH4nA/yyJqlbIFCYhZ4J5QJ29lT23lFj+iVmKaMljO/WVfuiUSFYnj0 sDIYYMjiech9TKMW0OwEYUMhuubFCnUO++8VL1Vk61iXqjCSOMUWpnPfxt3WfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681378979; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A777V/OQMH/wCXiERmZs+VcN4EZtzYLfOJ7lG5UajCk=; b=DKVTt2oPJdr9nrtZwUMLJU1AB15XkbwvqqJWagz6DULDjj3+mh9BtRkjFQOqrol9rna3+E K1kISxfMY8ww14vX14vR6d6ol5lLiUvLZRp51yhBKbj1ZDzi2yuCcezKDicbj0kIif2gFh DhGUybtUZ277pG2xEGd8guSZHo8B5/ZvlNGfbB9tX2VlQ7+8cz8ZFotgOHQSXORtSCEwiM lrAIFz+Dy+BEck9PLBHkOSCe9Da1K6VRclpd93+jXnsn5kPN1YutA3Ij6DzxKDf1EEnga7 zRBA14oXCD9lRU5pk5Hgyc/4+4a+uDmKBQEWWirbm8SsBrV7NpvGAJNvAxBPxQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681378979; a=rsa-sha256; cv=none; b=K/vIoqRF1LV/YQrdFDznneYp3q/tEaMmgMoHkySseOA3LopHA4CPPKe/XtKp5lfnJ2Iky2 DMZgYybEgaTlQIF2u//OsvgFAbvWnoDto1LNI2WMgyT9OIs6klgolUFeSju7a/xrulJcKV s1+4ULnMF6CEb5N32sClRKNZYVDY3jcOfLGN+OMI4lxTKPHi05SOlSlPctou7Pw17ffIeO x5HXEhnTV7jonl2APXLUZb0pHbXVCe6yghX5JmXzrtdHD192CDWsFKu6RFfwhf3be9TjkX PChlXyVZVHLr3d/F7ri9ABB0ZMwFClAZxnRiSDqZ2hQ3TqvOH8CtMcorybqI/A== Received: from [192.168.5.80] (unknown [37.228.205.220]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: danilo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Pxvl71L8bzbr0 for ; Thu, 13 Apr 2023 09:42:59 +0000 (UTC) (envelope-from danilo@FreeBSD.org) Message-ID: Date: Thu, 13 Apr 2023 10:42:57 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: freebsd-current@freebsd.org References: Content-Language: en-US From: Danilo Egea Gondolfo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 13/04/2023 06:28, Mark Millard wrote: > From: Charlie Li wrote on > Date: Wed, 12 Apr 2023 20:11:16 UTC : > >> Charlie Li wrote: >>> Mateusz Guzik wrote: >>>> can you please test poudriere with >>>> https://github.com/openzfs/zfs/pull/14739/files >>>> >>> After applying, on the md(4)-backed pool regardless of block_cloning, >>> the cy@ `cp -R` test reports no differing (ie corrupted) files. Will >>> report back on poudriere results (no block_cloning). >>> >> As for poudriere, build failures are still rolling in. These are (and >> have been) entirely random on every run. Some examples from this run: >> >> lang/php81: >> - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development >> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf ${STAGEDIR}/${PREFIX}/etc >> - consumers fail to build due to corrupted php.conf packaged >> >> devel/ninja: >> - phase: stage >> - install -s -m 555 >> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja >> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin >> - consumers fail to build due to corrupted bin/ninja packaged >> >> devel/netsurf-buildsystem: >> - phase: stage >> - mkdir -p >> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/netsurf-buildsystem/makefiles >> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/netsurf-buildsystem/testtools >> for M in Makefile.top Makefile.tools Makefile.subdir Makefile.pkgconfig >> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ >> cp makefiles/$M >> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/netsurf-buildsystem/makefiles/; >> \ >> done >> - graphics/libnsgif fails to build due to NUL characters in >> Makefile.{clang,subdir}, causing nothing to link > Summary: I have problems building ports into packages > via poudriere-devel use despite being fully updated/patched > (as of when I started the experiment), never having enabled > block_cloning ( still using openzfs-2.1-freebsd ). > > In other words, I can confirm other reports that have > been made. > > The details follow. > > > [Written as I was working on setting up for the experiments > and then executing those experiments, adjusting as I went > along.] > > I've run my own tests in a context that has never had the > zpool upgrade and that jump from before the openzfs import to > after the existing commits for trying to fix openzfs on > FreeBSD. I report on the sequence of activities getting to > the point of testing as well. > > By personal policy I keep my (non-temporary) pool's compatible > with what the most recent ??.?-RELEASE supports, using > openzfs-2.1-freebsd for now. The pools involved below have > never had a zpool upgrade from where they started. (I've no > pools that have ever had a zpool upgrade.) > > (Temporary pools are rare for me, such as this investigation. > But I'm not testing block_cloning or anything new this time.) > > I'll note that I use zfs for bectl, not for redundancy. So > my evidence is more limited in that respect. > > The activities were done on a HoneyComb (16 Cortex-A72 cores). > The system has and supports ECC RAM, 64 GiBytes of RAM are > present. > > I started by duplicating my normal zfs environment to an > external USB3 NVMe drive and adjusting the host name and such > to produce the below. (Non-debug, although I do not strip > symbols.) : > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > > I then did: git fetch, stash push ., merge --ff-only, stash apply . : > my normal procedure. I then also applied the patch from: > > https://github.com/openzfs/zfs/pull/14739/files > > Then I did: buildworld buildkernel, install them, and rebooted. > > The result was: > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 > > The later poudriere-devel based build of packages from ports is > based on: > > # ~/fbsd-based-on-what-commit.sh -C /usr/ports > 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) devel/freebsd-gcc12: Bump to 12.2.0. > Author: John Baldwin > Commit: John Baldwin > CommitDate: 2023-03-25 00:06:40 +0000 > branch: main > merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > n613214 (--first-parent --count for merge-base) > > poudriere attempted to build 476 packages, starting > with pkg (in order to build the 56 that I explicitly > indicate that I want). It is my normal set of ports. > The form of building is biased to allowing a high > load average compared to the number of hardware > threads (same as cores here): each builder is allowed > to use the full count of hardware threads. The build > used USE_TMPFS="data" instead of the USE_TMPFS=all I > normally use on the build machine involved. > > And it produced some random errors during the attempted > builds. A type of example that is easy to interpret > without further exploration is: > > pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) > > A fair number of errors are of the form: the build > installing a previously built package for use in the > builder but later the builder can not find some file > from the package's installation. > > Another error reported was: > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > For reference: > > [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] Queued: 476 Built: 252 Failed: 11 Skipped: 213 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 00:37:52 > > I started another build that tried to build 224 packeges: > the 11 failed and 213 skipped. > > Just 1 package built that failed before: > > [00:04:58] [09] [00:04:15] Finished databases/sqlite3@default | sqlite3-3.41.0_1,1: Success > > It seems to be the only one where the original failure was not > an example of complaining about the missing/corrupted content > of a package install used for building. So it is an example > of randomly varying behavior. > > That, in turn, allowed: > > [00:04:58] [01] [00:00:00] Building security/nss | nss-3.89 > > to build but everything else failed or was skipped. > > The sqlite3 vs. other failure difference suggests that writes > have random problems but later reads reliably see the problem > that resulted (before the content is deleted). > > > After the above: > > # zpool status > pool: zroot > state: ONLINE > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > da0p8 ONLINE 0 0 0 > > errors: No known data errors > > # zpool scrub zroot > # zpool status > pool: zroot > state: ONLINE > scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 22:15:39 2023 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > da0p8 ONLINE 0 0 0 > > errors: No known data errors > > > === > Mark Millard > marklmi at yahoo.com > > Hi, I'm having a funny issue here and I'm wondering if it is related. When building one of my ports I will, eventually, not always, get a file full of zeros as a result. The build will create copies of crispy-setup and, every once in a while, one of them will be a blob of zeros: I'm running the recent ZFS update but I never upgraded my pool: FreeBSD capeta 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n262091-eed92455e600: Tue Apr 11 16:06:42 IST 2023 danilo@capeta:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 cp crispy-setup crispy-doom-setup --- crispy-heretic-setup --- cp crispy-setup crispy-heretic-setup --- crispy-hexen-setup --- cp crispy-setup crispy-hexen-setup --- crispy-strife-setup --- cp crispy-setup crispy-strife-setup $ ls -l work/stage/usr/local/bin/crispy-*-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-doom-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-heretic-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-hexen-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-strife-setup $ file work/stage/usr/local/bin/crispy-*-setup work/stage/usr/local/bin/crispy-doom-setup:    ELF 64-bit LSB executable... work/stage/usr/local/bin/crispy-heretic-setup: ELF 64-bit LSB executable... work/stage/usr/local/bin/crispy-hexen-setup:   data work/stage/usr/local/bin/crispy-strife-setup:  ELF 64-bit LSB executable... $ hexdump work/stage/usr/local/bin/crispy-hexen-setup 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 00e1760