From nobody Mon Mar 3 07:05:04 2025 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 4Z5qZX5rNlz5nrff for ; Mon, 03 Mar 2025 07:05:08 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z5qZW4S0qz42gD for ; Mon, 03 Mar 2025 07:05:07 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unixarea.de header.s=blu3434000 header.b=P0dODs0L; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=unixarea.de ; s=blu3434000; h=Content-Transfer-Encoding:Content-Type:MIME-Version: Reply-To:Message-ID:Subject:To:From:Date:Sender:Cc:Content-ID: Content-Description:In-Reply-To:References; bh=9/ZbleIK/PJe4rKPmytQ4ZY5+r7H9ZVW27XVhumDxs4=; b=P0dODs0LIFhJO+D8VVubdX2Hyv wT5my6uW9vaYMN3jNnly4wdDz3AwYMO02w1e3Tbo43p/xi5Ml/Ezu/UJSMi1dKI9fXYTm1vkZ58w5 hTBlo1nzesFFAQVUYvNwNLtCwU1AcZx+BC/belEj5gVTwUtfNTdNJv1r7ZzHeaHF+w4HmRalqX105 yFJFMEN6EDITdd6//DPg1icZWjgoKD+lEBZiR0ak7hto7W2oRdE927oMBbtdRulnE4WHjV6pVhMQZ Pu4In77ukD7ys/zkb4xcP7qoXcXx5hN/QeMKDkI+5qz1+buR8M/mgv0/sLhH/WffjxkAqMnx112dy hWfqNAJQ==; Received: from [62.216.210.102] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tozrM-008ZyH-S3 for freebsd-current@freebsd.org; Mon, 03 Mar 2025 08:05:04 +0100 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 523754Jl001370 for ; Mon, 3 Mar 2025 08:05:04 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 523754iY001369 for freebsd-current@freebsd.org; Mon, 3 Mar 2025 08:05:04 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 3 Mar 2025 08:05:04 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Creating poudriere jail fails with libmd.so.6 not found Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails in HTML will not be read! Please, only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 62.216.210.102 X-Spamd-Result: default: False [-1.47 / 15.00]; RBL_SENDERSCORE_REPUT_6(1.00)[178.254.4.101:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.985]; NEURAL_HAM_SHORT(-0.98)[-0.981]; NEURAL_HAM_LONG(-0.91)[-0.908]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[unixarea.de:+]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[unixarea.de:s=blu3434000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[unixarea.de]; HAS_XAW(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de]; HAS_XOIP(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:178.254.4.101]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; RCVD_VIA_SMTP_AUTH(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4Z5qZW4S0qz42gD X-Spamd-Bar: - I tried to create a new jail in my CURRENT from March 1 This fails with: # poudriere jail -c -j 150-CURRENT -m src=3D/usr/src [00:00:00] Creating 150-CURRENT fs at /usr/local/poudriere/jails/150-CURREN= T... done [00:00:01] Copying /usr/src to /usr/local/poudriere/jails/150-CURRENT/usr/s= rc... done [00:02:31] Starting make installworld --- installworld --- make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using= cached toolchain metadata from build at jet on Sat Mar 1 20:51:42 CET 2025 --- _installcheck_world --- -------------------------------------------------------------- >>> Install check world started on Sun Mar 2 22:04:40 CET 2025 -------------------------------------------------------------- --- installworld --- mkdir -p /tmp/install.APjSa9v82y progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date e= cho egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed se= rvices_mkdb sh sort strip sysctl test time true uname wc tzsetup makewhatis= ; do if progpath=3D`env PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/= obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/b= in:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.= amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/o= bj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bi= n which $prog`; then echo $progpath; else echo "Required tool $prog not = found in PATH ("/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64= =2Eamd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr= /src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legac= y/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd6= 4.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin")." >&2; exi= t 1; fi; done); if [ -z "" ] ; then libs=3D$(ldd -f "%o %p\n" -f "%o %p= \n" $progs 2>/dev/null | sort -u | grep -Ev '\[.*]' | while read line; do = $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo "Requi= red library $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs= /tmp/install.APjSa9v82y Required library libmd.so.6 not found. *** [installworld] Error code 1 make[1]: stopped making "installworld" in /usr/src make[1]: 1 error make[1]: stopped making "installworld" in /usr/src make: stopped making "installworld" in /usr/src [00:02:32] Error: /usr/local/share/poudriere/jail.sh:installworld:12:Failed= to 'make installworld' [00:02:32] Error while creating jail, cleaning up. [00:02:32] Removing 150-CURRENT jail... done [00:02:34] Cleaning 150-CURRENT data... done I investigated the problem and the old libmd.so.6 is used by some binaries in /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/mtree which the 'make buildworld' copied to this place from the underlying old system: # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/mtree | grep libmd.s= o.6 libmd.so.6 =3D> not found (0) # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/sort | grep libmd.so= =2E6 libmd.so.6 =3D> not found (0) # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/mtree /usr/obj/usr= /src/amd64.amd64/tmp/legacy/usr/sbin/sort -r-xr-xr-x 1 root wheel 65392 Aug 6 2023 /usr/obj/usr/src/amd64.amd64/tm= p/legacy/usr/sbin/mtree -r-xr-xr-x 1 root wheel 62544 Aug 6 2023 /usr/obj/usr/src/amd64.amd64/tm= p/legacy/usr/sbin/sort Aug 6, 2023 the 14-CURRENT was setup where I built the now 15-CURRENT on March 2: # uname -a FreeBSD jet 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n275738-7ee310c80ea7:= Sun Mar 2 01:13:00 CET 2025 guru@jet:/usr/obj/usr/src/amd64.amd64/sys= /GENERIC amd64 What would be the correct way to fix this? Re-run 'make buildworld' again? Or copying the shared lib libmd.so.6 into place? matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176= -38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Mon Mar 3 11:06:41 2025 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 4Z5wxR3yNLz5pFG6 for ; Mon, 03 Mar 2025 11:06:51 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (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 (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z5wxP6bGLz3R8y for ; Mon, 03 Mar 2025 11:06:49 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.18.1/8.18.1) with ESMTPS id 523B6gYB091280 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 3 Mar 2025 12:06:42 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.18.1/8.18.1/Submit) id 523B6g1B091279 for freebsd-current@freebsd.org; Mon, 3 Mar 2025 12:06:42 +0100 (CET) (envelope-from fuz) Date: Mon, 3 Mar 2025 12:06:41 +0100 From: Robert Clausecker To: freebsd-current@freebsd.org Subject: Re: Creating poudriere jail fails with libmd.so.6 not found Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Spamd-Result: default: False [-0.98 / 15.00]; NEURAL_SPAM_LONG(0.88)[0.880]; NEURAL_HAM_MEDIUM(-0.87)[-0.871]; NEURAL_HAM_SHORT(-0.69)[-0.689]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[fuz]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[fuz.su]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4Z5wxP6bGLz3R8y X-Spamd-Bar: / Hi Matthias, Am Mon, Mar 03, 2025 at 08:05:04AM +0100 schrieb Matthias Apitz: > I tried to create a new jail in my CURRENT from March 1 > This fails with: >=20 > # poudriere jail -c -j 150-CURRENT -m src=3D/usr/src >=20 > [00:00:00] Creating 150-CURRENT fs at /usr/local/poudriere/jails/150-CURR= ENT... done > [00:00:01] Copying /usr/src to /usr/local/poudriere/jails/150-CURRENT/usr= /src... done > [00:02:31] Starting make installworld > --- installworld --- > make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Usi= ng cached toolchain metadata from build at jet on Sat Mar 1 20:51:42 CET 2= 025 > --- _installcheck_world --- > -------------------------------------------------------------- > >>> Install check world started on Sun Mar 2 22:04:40 CET 2025 > -------------------------------------------------------------- > --- installworld --- > mkdir -p /tmp/install.APjSa9v82y > progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date= echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed = services_mkdb sh sort strip sysctl test time true uname wc tzsetup makewhat= is ; do if progpath=3D`env PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/bin:/us= r/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr= /bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd6= 4.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr= /obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/= bin which $prog`; then echo $progpath; else echo "Required tool $prog no= t found in PATH ("/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd= 64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr= /src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legac= y/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd6= 4.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin")." >&2; exi= t 1; fi; done); if [ -z "" ] ; then libs=3D$(ldd -f "%o %p\n" -f "%o %p= \n" $progs 2>/dev/null | sort -u | grep -Ev '\[.*]' | while read line; do = $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo "Requi= red library $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs= /tmp/install.APjSa9v82y > Required library libmd.so.6 not found. > *** [installworld] Error code 1 >=20 > make[1]: stopped making "installworld" in /usr/src > make[1]: 1 error >=20 > make[1]: stopped making "installworld" in /usr/src >=20 > make: stopped making "installworld" in /usr/src > [00:02:32] Error: /usr/local/share/poudriere/jail.sh:installworld:12:Fail= ed to 'make installworld' > [00:02:32] Error while creating jail, cleaning up. > [00:02:32] Removing 150-CURRENT jail... done > [00:02:34] Cleaning 150-CURRENT data... done >=20 > I investigated the problem and the old libmd.so.6 is used by some > binaries in /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/mtree > which the 'make buildworld' copied to this place from the underlying old > system: >=20 > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/mtree | grep libmd= =2Eso.6 > libmd.so.6 =3D> not found (0) > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/sort | grep libmd.= so.6 > libmd.so.6 =3D> not found (0) > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/mtree /usr/obj/u= sr/src/amd64.amd64/tmp/legacy/usr/sbin/sort > -r-xr-xr-x 1 root wheel 65392 Aug 6 2023 /usr/obj/usr/src/amd64.amd64/= tmp/legacy/usr/sbin/mtree > -r-xr-xr-x 1 root wheel 62544 Aug 6 2023 /usr/obj/usr/src/amd64.amd64/= tmp/legacy/usr/sbin/sort >=20 > Aug 6, 2023 the 14-CURRENT was setup where I built the now 15-CURRENT on > March 2: >=20 > # uname -a > FreeBSD jet 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n275738-7ee310c80ea= 7: Sun Mar 2 01:13:00 CET 2025 guru@jet:/usr/obj/usr/src/amd64.amd64/s= ys/GENERIC amd64 >=20 > What would be the correct way to fix this? Re-run 'make buildworld' > again? Or copying the shared lib libmd.so.6 into place? The simplest solution is to clear the object directory and do a fresh world= build. libmd.so.6 was turned into libmd.so.7 as part of a recent API change. It s= hould also work to link libmd.so.7 to libmd.so.6. Yours, Robert Clausecker --=20 () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments From nobody Mon Mar 3 12:03:44 2025 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 4Z5yCB371Kz5pL1S for ; Mon, 03 Mar 2025 12:03:50 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z5yC84zqcz3WZX for ; Mon, 03 Mar 2025 12:03:48 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unixarea.de header.s=blu3434000 header.b=P0U1aCAb; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=unixarea.de ; s=blu3434000; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Reply-To:Message-ID:Subject:To:From:Date:Sender:Cc: Content-ID:Content-Description; bh=T4V5lGT0TUjreAm7LK0rp2TOVAiW9utU1FaWmbbnwuQ=; b=P0U1aCAbFn0LqY42pp1/+WHldL QvrQI0e8pEmCNUOS1keD1OKYtdoMSoQ/8ajSwxjkIzCcXnahfZqJ0TBNvfcLy0WhMkYLBmh3TgqKT VDPLsVwfe/+ya/24WBq7zGX28Jw7dmKFdgPqQ0d0VsaBMpopSoCA5WojsD07WSlo9wI7LaCHNU4v5 Tv/ccfzEZGpxlzNQdMtti8Saxik+19E2SZ8dZ8KwMthnarPGYQzCZ72ZTo+DdO+reiZJ47DiKeJVu ywJUOTZZ+AhhuWHjB6im7L8UmhaKewYQej/EVZ7vfQjaZK2IAbT8cVxjWnLMhnQpcs0q4WVm1STOi /abaJBtg==; Received: from [212.222.85.178] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tp4WQ-004ncz-HH for freebsd-current@freebsd.org; Mon, 03 Mar 2025 13:03:46 +0100 Date: Mon, 3 Mar 2025 13:03:44 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: No working interface bce0 after updating to CURRENT of March 1 Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 14.0-CURRENT 1400094 (amd64) X-message-flag: Mails in HTML will not be read! Send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 212.222.85.178 X-Spamd-Result: default: False [-1.32 / 15.00]; RBL_SENDERSCORE_REPUT_6(1.00)[178.254.4.101:from]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_LONG(-0.93)[-0.929]; MID_RHS_NOT_FQDN(0.50)[]; ONCE_RECEIVED(0.20)[]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[unixarea.de:+]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; R_DKIM_ALLOW(0.00)[unixarea.de:s=blu3434000]; DMARC_NA(0.00)[unixarea.de]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de]; HAS_XOIP(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:178.254.4.101]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4Z5yC84zqcz3WZX X-Spamd-Bar: - I've had since ages these two lines in /etc/rc.conf: ifconfig_bce0="inet 192.168.178.5 netmask 255.255.255.0" ifconfig_bce1="inet 192.168.178.6 netmask 255.255.255.0" defaultrouter="192.168.178.1" The box has two RJ-45 ports and the only used one was the first, bce0. I changed the lines now to ifconfig_bce0="inet 192.168.178.5 netmask 255.255.255.0" # ifconfig_bce1="inet 192.168.178.6 netmask 255.255.255.0" defaultrouter="192.168.178.1" plugged in the cable again into the first port and all is fine, but unclear why it worked before the update to a recent CURRENT. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Mon Mar 3 15:51:27 2025 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 4Z63GF2Zkcz5phGX for ; Mon, 03 Mar 2025 15:51:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z63GF0PBjz3thW for ; Mon, 03 Mar 2025 15:51:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=XyAypSAV; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1741017102; bh=qMa3LN9+Pfexja+EfcPffeZ3Ewz/lI/p/x1a/x9+gmA=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=XyAypSAV4eVqn6N/puxtJRlmoWRVOPiDz1l+e07eMemfNx6pIfrQCS5ZpWr2oUgQ0v4THHJzikaVZW0Ky2lMd95oSQFnIguBGOd5uhk+TOa7HiOx4fO1PydzcqgewmEqmI+aRqaqREOq8pT0eua/l9WXFWigbq9nqr4jUA5Ny3W07SrMl7FHjMLODWVk0+vwCVYnfQ4D7dIK5RjpS/c9HlqtcFEMozMeQf94oGWFB10CaZt6SqkFQFK2G70emLFDxHLUB2ZpL60PCcvFT9uL3Ud1M8MM8VaZorCDnFZa4EBZ2/iMhYBgXCaS8T8U34KUjQx03875+070FdDE2FlCLg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1741017102; bh=WZ6PU1Q2qqSfKzlWQW8wlj8qvTb1qyPP/5Pg52sPoHh=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=VSlZRGMTXX7Zfk0ZFJaFq+OhpAZxKL1ZuTYE7HQKTYCJIMVO+sIDIwuwcsoz2G7nBTd9gn9K0xYGTsUPdgPwMJj1bQy4GoVTJbn89Qx+JNl561xkwGsQsvyE1qaPCSRXyqoeF6lr60zO45Anz4tbcL389z3y9qos+joahfYJn/TQB2xLWa7e409QzADKdR2a3usAo7LLpyj53FIywGjMwEF5lgbG/bm9G6U+sOdHw5vcidOBI9bR67NK9xAG3OftT+m6okIEZMCJErwhe8/8pordnX93UsU9DiPqOngwAzGqt45elEJ5p2fI30+RzIn4JDBxdIodw/m0gXN8ALzcUg== X-YMail-OSG: VT.Pr3oVM1lwW7Te_4teQC1nuaDoHcvwiIu7U7ANrrTQufY75k.Fde9ak9ouxoV e1h82g8dqnAEP7VsZLoQW8fb8T6jK6gX60DsKc4b.raI143KkJYafTVfoScKmKQ2rMv9jYd8Cq9c i94Vti6jSHOFr3yedm_rc9We5okfd0orrhrxpVJMz5tnxVHNuTP9q3NOS6IUJ5FvhBZ3PURXksvq DvKGX5m_t_OFQP0i4NCIy2rFUP9Ck194E3v8eWSMbaBVqAp3Op76CL85wrlzedo_79KkYD2O4FJS 2KoimxzUQakwKgwxUAAUJGskDWNbWqyERjj.OgI3OobcgwjrdoTnpbqzuUbqTh2apT7_6ey_HMKl 6714WQvDVD_5ADgOpPXkZ0EJG94VT9BI6KMhzUQ..l7yvesNxSxWz1heFtxfsBbpn7tzpS5rSbuw Fsih.a2M9je9aHkijC09E8DPyuMu_9b_2oAC3A4YxT9dVtJKE0M1nuFNOux5l4ftTetAsWG9aC78 D7dUQUtQZrBLoSCfxlCSzDWwcXtyYhyYLuEPs.Rtnq2ejYJdjcxM1g4LM5SGFX.XjChkU6u.OcVV gaojIGvpq_hv7Dw01.qYgprcL0j8NL1JreFj11oEa5hSv4GzbnhVF9mIAiMdZ9d5FVth0KN8G6Xz b0lig.CCilI0YnX5pXwSa_N92rBpnyYx1tRAfgTKRey7puBDdjXSOsY7AVj2ySLotfqFeHjE5Cgg jzfYMjI80g1ZkmJHahuIrEZg_KmwmQi3WZHzZT9ijQtViQ5QWXrTowpODaRlQO7AB_qN.il6GcyU D6euwmfi6OB5KOokct6cp1gdksSKrCcSB7hW3JogqdzJUZshChc8zUA0tNTWd1_MffHY0h2UJkbC r5OhGLerNpWRTN6pdXfhflcEJ5uUZec8PXsC6qQJ0JThxl73iN6jpA5p0P5_B_xq3yrXqFpudtuX Q0trTX5Luuf2MhF7HEhXb.Y05UE.05tGh_USz8fSM6mQspGEfsbmZtGxlEVU2bBmaSTZ4xp5.e.2 vw3sGLpoPR58N4l4E7T13WZRE_ML_PcBcQUEvUDhkkSoAUpNA7wkolBXnMghHhhCmzs4NMg58UAz H1jg9xVQG947vuBC8RiA05uqa05CQmaAlIYfNu7keEPdl3JxDQunrYsOzueFH_ivAYkMKsL6frfn qk_YSHUhPtVlfmLhDR99Eu.o9mJzHylHYRdwDaxRu9BcdIWSnah9hiwO.fcP6Y.eXfXcSsPZ_nyJ WeroByQAU.8NKHV2638NDQD0eIjDBjBy8.AYr8TwLmgmD_VTf26WpWAnJ436FeUyGLK7B29Qrtyc OkA58OmwJMq7KtJwmdEdzYNiEDXmNtirjg2q3DlN9CX3pMmY84bFcfXSXWpTrgQvHtzPjYEk.z1j nL.Q4rVVVKOzNANVpmLuGBnHAA2PMjOATs7xZZKrzJ36iHSmjxvJuBsotwK7rf8TuZeuktfvh8n_ leoCXW2wCIUgm.PxZd9PRJ9yOdTl1HJ3UFl6Xo4O5gcRGZTTonzHf7geX8W1vIFMuNKycrr.NjuJ mFPp_2rt_mqyzi6QvLpMtSB_UfuJM.iXwR2LJMenwY8m9XfOHslq1m3SupdFNoFgbEjLsJPIGGmT 9Jiub40Cb6I.c1hKctO7BBftuqiWohoTa1vgyAY198.XoJXhmiUU1ZZnEwOzRXzdKnox_rtJDIQr vtcmosYSPmn39Z0GB3zjHkXPvAXgQZR2xPP1gAJb8wN8u2Cvc4S41Ws.fsCdhYdCrliq1nSOaqTg Sg3SxkNF6QMaksMh2rgL..4Wv0eB6S2Xzch4KsSgyDbUYWJ7UXEafeVJXe0e01YGqifGt.G04Qwu 44h1UmSJZE_j_ISyaTZBOtZrqLazALovVPuEmwm8CNjsH2O96L6fSJkJZz0B0JqWZn9lQLv.0IOs Z.5QaK8GKNkbMyxdsfiA24qzKiG1vLP.QjZyBiinBp1HjL7J3CCmweTEFP75mqtjciRo8EZpnU3y AR5B4K2GWE5ve5u1hi2KTx.YwwwjLi2hM4FZGUvGTvj4JclhBlmuk47SOMiWvIYVVHsjzWEwfN6Q UM4I.BV_qd7Y_6eITAbU0TqwBgGO8F5iQtNl76U5lHbk9_XdqUDuKBx3cPG0GKMow6EjZ9tpT4ln QtVB90vPysnTCKyPGeifhp9oB7xwZRulSDN8hfSDG7ICI71tFimtCsmtccl.rLUSs7l_zECdruXW 4Uakl9NKsnlIFwgpOismD7yJjagi5e9icpTsqIBXl22YMWfqQbbrMhfDsEVaEPexQBkFD79K0tsU 5csAiTw-- X-Sonic-MF: X-Sonic-ID: 7af4a43a-5022-4723-a164-8ebff8507351 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 Mar 2025 15:51:42 +0000 Received: by hermes--production-gq1-75cc957d6c-f8j6m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID db9d37e7259e8f89d9a8346be7deccde; Mon, 03 Mar 2025 15:51:38 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: Creating poudriere jail fails with libmd.so.6 not found Message-Id: Date: Mon, 3 Mar 2025 07:51:27 -0800 Cc: Bryan Drewery To: Robert Clausecker , FreeBSD Current X-Mailer: Apple Mail (2.3826.400.131.1.6) References: X-Spamd-Result: default: False [-4.15 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.83:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.91)[-0.908]; NEURAL_HAM_SHORT(-0.75)[-0.746]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4Z63GF0PBjz3thW X-Spamd-Bar: ---- Robert Clausecker Date: Mon, 03 Mar 2025 11:06:41 UTC=20 Hi Matthias, > Am Mon, Mar 03, 2025 at 08:05:04AM +0100 schrieb Matthias Apitz: > > I tried to create a new jail in my CURRENT from March 1 > > This fails with: > >=20 > > # poudriere jail -c -j 150-CURRENT -m src=3D/usr/src > >=20 > > [00:00:00] Creating 150-CURRENT fs at = /usr/local/poudriere/jails/150-CURRENT... done > > [00:00:01] Copying /usr/src to = /usr/local/poudriere/jails/150-CURRENT/usr/src... done > > [00:02:31] Starting make installworld > > --- installworld --- > > make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line = 1: Using cached toolchain metadata from build at jet on Sat Mar 1 = 20:51:42 CET 2025 > > --- _installcheck_world --- > > -------------------------------------------------------------- > > >>> Install check world started on Sun Mar 2 22:04:40 CET 2025 > > -------------------------------------------------------------- > > --- installworld --- > > mkdir -p /tmp/install.APjSa9v82y > > progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp = date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm = sed services_mkdb sh sort strip sysctl test time true uname wc tzsetup = makewhatis ; do if progpath=3D`env = PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/t= mp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd6= 4.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bi= n:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64= /tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin which $prog`; = then echo $progpath; else echo "Required tool $prog not found in PATH = ("/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/us= r/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd= 64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/us= r/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/= legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin")." >&2; exit 1; fi; = done); if [ -z "" ] ; then libs=3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs = 2>/dev/null | sort -u | grep -Ev '\[.*]' | while read line; do $line; if = [ "$2 $3" !=3D "not found" ]; then echo $2; else echo "Required library = $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs = /tmp/install.APjSa9v82y > > Required library libmd.so.6 not found. > > *** [installworld] Error code 1 > >=20 > > . . . > > What would be the correct way to fix this? Re-run 'make buildworld' > > again? Or copying the shared lib libmd.so.6 into place? >=20 > The simplest solution is to clear the object directory and do a fresh = world build. > libmd.so.6 was turned into libmd.so.7 as part of a recent API change. = It should > also work to link libmd.so.7 to libmd.so.6. As I remember, libmd.so.6 vs. libmd.so.7 could have the following problem with managing the vintage of pkg used during an update sequence: If pkg was not yet also updated, it had a direct dependency as listed in ldd output (from before the update when the file could be found): libmd.so.6 =3D> /lib/libmd.so.6 but it also had the following dependency visible in "ldd -a" output for it: liblzma.so.5 =3D> /usr/lib/liblzma.so.5 This leads to another libmd.so reference. Note: pkg is not part of the system that is upgraded when the system is upgraded. After the system update, liblzma.so.5 (which is upgraded when the system in upgraded) in turn no longer had a libz.so.6 reference but instead: libmd.so.7 =3D> /lib/libmd.so.7 Thus, overall, pkg ended up with both: libmd.so.6 =3D> not found (0) libmd.so.7 =3D> /lib/libmd.so.7 or, if BACKUP_LIBRARIES=3Dtrue was in use for PkgBase, there ended up being 2 libmd.so bindings around, which of itself is also problem such that they can not both be in use. pkg-static, of course, does not have this problem. But some scripting in use references pkg instead of pkg-static and so is subject to this kind of breakage when system updates happen. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Mar 4 15:36:35 2025 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 4Z6ftN2Xl6z5qFXw for ; Tue, 04 Mar 2025 15:36:44 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z6ftM2tcpz3tlv for ; Tue, 04 Mar 2025 15:36:43 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stevengharms.com header.s=protonmail header.b=fJpQ3awT; dmarc=none; spf=pass (mx1.freebsd.org: domain of sgharms@stevengharms.com designates 185.70.40.136 as permitted sender) smtp.mailfrom=sgharms@stevengharms.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevengharms.com; s=protonmail; t=1741102599; x=1741361799; bh=yzg8ac6b9lXAXsNy/jAvjG75dKUaWjpOQDvEjbVXKTE=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=fJpQ3awT3WsqtA4i29Mwp6nR79OLZiVf8PuPh6VV8xajpkM4tQ85TqmD/ICOcQWlM u5FsHXArhFp1MzNFJgEUqxpK3NX583KL23gukBWU77pLeGofhUeYEoLlfrtAf4sa5T mDzvc88bCoI7W7W9HKacDMspI5sL4teVDWduFfe0= Date: Tue, 04 Mar 2025 15:36:35 +0000 To: "freebsd-current@freebsd.org" From: "Steven Harms (High-Security Mail)" Subject: Inaccuracies in 15.0-CURRENT documentation versus wayland+sway in practice Message-ID: Feedback-ID: 16996530:user:proton X-Pm-Message-ID: 16a51394773da0f9aaf6b3c83b668ce98c2cbe2a 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 Content-Type: multipart/alternative; boundary="b1=_5W785Oj63tRwXHVzW8zX020d8Kp65UjdikL29MNxc" X-Spamd-Result: default: False [-4.41 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[185.70.40.136:from]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_LONG(-0.98)[-0.982]; NEURAL_HAM_SHORT(-0.93)[-0.930]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; R_DKIM_ALLOW(-0.20)[stevengharms.com:s=protonmail]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[185.70.40.136:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.136:from]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[stevengharms.com]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[stevengharms.com:+] X-Rspamd-Queue-Id: 4Z6ftM2tcpz3tlv X-Spamd-Bar: ---- --b1=_5W785Oj63tRwXHVzW8zX020d8Kp65UjdikL29MNxc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Rm9sa3MsCgpUaGUgZG9jcyBzYXk6CgpBbGwgY29tcG9zaXRvcnMgdXNpbmcgV2F5bGFuZCB3aWxs IG5lZWQgYSBydW50aW1lIGRpcmVjdG9yeSBkZWZpbmVkIGluIHRoZSBlbnZpcm9ubWVudC4gU2lu Y2UgRnJlZUJTRCAxNC4xLCB0aGlzIGlzIGNyZWF0ZWQgYW5kIGRlZmluZWQgYXV0b21hdGljYWxs eS4gRm9yIHByZXZpb3VzIHZlcnNpb25zLCB0aGlzIGlzIGFjaGlldmVkIHdpdGggdGhlIGZvbGxv d2luZyBjb21tYW5kIGluIHRoZSBib3VybmUgc2hlbGw6CgolIGV4cG9ydCBYREdfUlVOVElNRV9E SVI9L3Zhci9ydW4vdXNlci9gaWQgLXVgCgpPSywgc28gdGhlbiBJIGV4ZWN1dGUgc3dheSgxKSBh bmQgSSBnZXQgdGhlIGxvdmVseSBibHVlIGJhY2tncm91bmQuIFdoZW4gSSBkbyBhIGxzIC92YXIv cnVu4oCLIHRoZXJlJ3Mgbm8gdXNlcuKAiyBkaXJlY3RvcnkgdGhlcmUuIFRoZXJlIGlz4oCLIGFu IHhkZ+KAiyBkaXJlY3RvcnkgdGhhdCBjb250YWlucyB0aGUgaWQgLWPigIsgb2YgdGhlIHVzZXIg dGhhdCByYW4gc3dheS4KCk5vdywgSSBncmFudCB0aGF0IEknbSBydW5uaW5nIDE1LjAtQ1VSUkVO VCBhZ2FpbnN0IGRvY3VtZW50YXRpb24gdGhhdCBkZXNjcmliZXMgYSBzaXR1YXRpb24gcG9zdCAx NC4xIC0tIGJ1dCBJIHdvdWxkIGFzc3VtZSB0aGUgaW50ZW50aW9uIGlzIGZvciB0aGF0IGNoYW5n ZSB0byBwZXJzaXN0IHRocm91Z2ggMTU/CgpVbHRpbWF0ZWx5OiBJcyAxNS4wLUNVUlJFTlQgbm90 IG1hdGNoaW5nIHN0YW5kYXJkcyBlc3RhYmxpc2hlZCBpbiAxNC4xIChpbiB3aGljaCB0aGVyZSdz IGEgYnVnIGZvciAxNS4wLUNVUlJFTlQpLCBvciBpcyB0aGUgZG9jdW1lbnRhdGlvbiBpbmNvcnJl Y3QgYW5kIEkgc2hvdWxkIG9wZW4gYSBkb2NzIGJ1Zz8KCkJlc3QsCgpTdGV2ZW4KCi0tLQoKUHVi bGljIEtleTogMjJCRTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZEOENFMkIwMzZERQoKTWVzc2Fn ZXMgZnJvbSB0aGlzIGFjY291bnQgYXJlIGNvbnNpZGVyZWQgdGhlIGJlc3Qtc2VjdXJlZCBhbmQg bW9zdCByZWxpYWJsZS4gU2VuZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgaGVhbHRoLCB3ZWFsdGgs IG9yIHJlcXVpcmluZyBoaWdoZXIgc3RhbmRhcmRzIG9mIHNlY3VyaXR5IHRvIHRoaXMgYWRkcmVz cy4KClNlbnQgd2l0aCBbUHJvdG9uIE1haWxdKGh0dHBzOi8vcHJvdG9uLm1lL21haWwvaG9tZSkg c2VjdXJlIGVtYWlsLg== --b1=_5W785Oj63tRwXHVzW8zX020d8Kp65UjdikL29MNxc Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5Gb2xrcyw8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPlRoZSBkb2NzIHNheTo8L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTZweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBmb250LWZhbWlseTogJnF1b3Q7aW50ZXIgdmFyJnF1b3Q7LCAtYXBwbGUt c3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICZxdW90O2F2ZW5pciBuZXh0JnF1b3Q7LCBhdmVu aXIsICZxdW90O3NlZ29lIHVpJnF1b3Q7LCAmcXVvdDtoZWx2ZXRpY2EgbmV1ZSZxdW90OywgaGVs dmV0aWNhLCBDYW50YXJlbGwsIFVidW50dSwgcm9ib3RvLCBub3RvLCBhcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYig2OCwgNjgsIDY4KTsiPjxwPjxzcGFuPjwvc3Bhbj48L3A+PC9kaXY+PHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPkFsbCBjb21wb3NpdG9y cyB1c2luZyBXYXlsYW5kIHdpbGwgbmVlZCBhIHJ1bnRpbWUgZGlyZWN0b3J5IGRlZmluZWQgaW4g dGhlIGVudmlyb25tZW50LiBTaW5jZSBGcmVlQlNEIDE0LjEsIHRoaXMgaXMgY3JlYXRlZCBhbmQg ZGVmaW5lZCBhdXRvbWF0aWNhbGx5LiBGb3IgcHJldmlvdXMgdmVyc2lvbnMsIHRoaXMgaXMgYWNo aWV2ZWQgd2l0aCB0aGUgZm9sbG93aW5nIGNvbW1hbmQgaW4gdGhlIGJvdXJuZSBzaGVsbDo8L3Nw YW4+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPjxicj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9u OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4+JSBleHBvcnQgWERHX1JVTlRJTUVfRElSPS92YXIvcnVu L3VzZXIvYGlkIC11YDwvc3Bhbj48YnI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ T0ssIHNvIHRoZW4gSSBleGVjdXRlIHN3YXkoMSkgYW5kIEkgZ2V0IHRoZSBsb3ZlbHkgYmx1ZSBi YWNrZ3JvdW5kLiBXaGVuIEkgZG8gYSA8Y29kZT5scyAvdmFyL3J1bjwvY29kZT7igIsgdGhlcmUn cyBubyA8Y29kZT51c2VyPC9jb2RlPuKAiyBkaXJlY3RvcnkgdGhlcmUuIFRoZXJlIDxpPmlzPC9p PuKAiyBhbiA8Y29kZT54ZGc8L2NvZGU+4oCLIGRpcmVjdG9yeSB0aGF0IGNvbnRhaW5zIHRoZSA8 Y29kZT5pZCAtYzwvY29kZT7igIsgb2YgdGhlIHVzZXIgdGhhdCByYW4gc3dheS48L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPk5vdywgSSBncmFudCB0aGF0IEknbSBydW5uaW5nIDE1LjAtQ1VSUkVO VCBhZ2FpbnN0IGRvY3VtZW50YXRpb24gdGhhdCBkZXNjcmliZXMgYSBzaXR1YXRpb24gcG9zdCAx NC4xIC0tIGJ1dCBJIHdvdWxkIGFzc3VtZSB0aGUgaW50ZW50aW9uIGlzIGZvciB0aGF0IGNoYW5n ZSB0byBwZXJzaXN0IHRocm91Z2ggMTU/PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5VbHRpbWF0 ZWx5OiBJcyAxNS4wLUNVUlJFTlQgbm90IG1hdGNoaW5nIHN0YW5kYXJkcyBlc3RhYmxpc2hlZCBp biAxNC4xIChpbiB3aGljaCB0aGVyZSdzIGEgYnVnIGZvciAxNS4wLUNVUlJFTlQpLCBvciBpcyB0 aGUgZG9jdW1lbnRhdGlvbiBpbmNvcnJlY3QgYW5kIEkgc2hvdWxkIG9wZW4gYSBkb2NzIGJ1Zz88 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkJlc3QsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5T dGV2ZW48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj4NCjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0 dXJlX2Jsb2NrIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7Ij4NCiAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11 c2VyIj4NCiAgICAgICAgPGRpdj4tLS08YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9y OiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlB1 YmxpYyBLZXk6IDxhIHRpdGxlPSIyMkJFMzlFMkZBNjhEOEJBOERDNEI0M0E1NUExNkQ4Q0UyQjAz NkRFIiBocmVmPSJodHRwczovLzIyQkUzOUUyRkE2OEQ4QkE4REM0QjQzQTU1QTE2RDhDRTJCMDM2 REUiPjxzcGFuPjIyQkUzOUUyRkE2OEQ4QkE4REM0QjQzQTU1QTE2RDhDRTJCMDM2REU8L3NwYW4+ PC9hPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsiPjxicj48L2Rpdj48ZGl2Pk1lc3NhZ2Vz IGZyb20gdGhpcyBhY2NvdW50IGFyZSBjb25zaWRlcmVkIHRoZSBiZXN0LXNlY3VyZWQgYW5kIG1v c3QgcmVsaWFibGUuIFNlbmQgaW5mb3JtYXRpb24gcmVnYXJkaW5nIGhlYWx0aCwgd2VhbHRoLCBv ciByZXF1aXJpbmcgaGlnaGVyIHN0YW5kYXJkcyBvZiBzZWN1cml0eSB0byB0aGlzIGFkZHJlc3Mu PGJyPjwvZGl2Pg0KICAgIDwvZGl2Pg0KICAgIDxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2Pg0KICAgIDxkaXYgY2xh c3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiI+DQogICAgICAgIFNlbnQgd2l0 aCA8YSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6Ly9wcm90b24ubWUvbWFpbC9ob21lIj5Q cm90b24gTWFpbDwvYT4gc2VjdXJlIGVtYWlsLg0KICAgIDwvZGl2Pg0KPC9kaXY+DQo= --b1=_5W785Oj63tRwXHVzW8zX020d8Kp65UjdikL29MNxc-- From nobody Thu Mar 6 23:44:04 2025 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 4Z85bw3Dnbz5qKGm for ; Thu, 06 Mar 2025 23:44:12 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 (2048 bits) client-digest SHA256) (Client CN "*.lerctr.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z85bv020Zz3tr9 for ; Thu, 06 Mar 2025 23:44:11 +0000 (UTC) (envelope-from ler@lerctr.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=Ed9sCXny; dmarc=pass (policy=quarantine) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To: From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description; bh=m+C3N9iKQ317GiByL/a913HI9eMhKMajwUz16hTr3EI=; b=Ed9sCXnytKP7g4+b3naZPyRNId /POyrteIz4p7g2xtWEQeO+k+LxUoWVeSs0OeyhXRNMIsjTIxC9fbYPXLK1VXCbkR8DNdtOJOXuIr7 +Azua6dqkT9tOA3wD1qSNYseQC/Lve8OINE/nueNYTBZkMmxPydtwHA+RDNZRje/wRy6z1u4BQ9yH NEmX5uXxk+3UlYainfbyvEvzm+64EBOktPJEwDdLclHrJVhQLAyfs8aGvQX7VKvfLUkSrLZghFGEx q1zreuAI9a74GY4WM1393pZkmv3Q7IHu4RlJNsPKhj4/XBCPyB9PFxS3pq81+5L1TMvzQiHZxQiG/ +NudvZzA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fccf:100:8002::53:1 as permitted sender) client-ip=2602:fccf:100:8002::53:1; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from [2602:fccf:100:8002::53:1] (port=36830 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98.1 (FreeBSD)) (envelope-from ) id 1tqKsm-00000000LIF-1pn7 for freebsd-current@freebsd.org; Thu, 06 Mar 2025 17:44:04 -0600 Received: from [47.220.6.253] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 06 Mar 2025 17:44:04 -0600 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 Date: Thu, 06 Mar 2025 17:44:04 -0600 From: Larry Rosenman To: Freebsd current Subject: -rxcsum not allowed? Message-ID: <40604ff2f9bde9719967b0ffab933afc@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.72 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_SENDERSCORE_REPUT_9(-1.00)[192.147.25.65:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.72)[-0.722]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[ler]; ASN(0.00)[asn:18474, ipnet:192.147.25.0/24, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+] X-Rspamd-Queue-Id: 4Z85bv020Zz3tr9 X-Spamd-Bar: --- somewhere between 22-feb and today something changed that -rxcsum and friends give me an error using the net/realtek-kmod re driver. Is this expected? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 2228 Bravo Pass, Leander, TX 78641-5209 From nobody Fri Mar 7 12:59:49 2025 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 4Z8RG15jbcz5pJc9 for ; Fri, 07 Mar 2025 12:59:53 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z8RFz6RShz3Cb1 for ; Fri, 07 Mar 2025 12:59:51 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unixarea.de header.s=blu3434000 header.b=ZYlilSCB; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=unixarea.de ; s=blu3434000; h=Content-Transfer-Encoding:Content-Type:MIME-Version: Reply-To:Message-ID:Subject:To:From:Date:Sender:Cc:Content-ID: Content-Description:In-Reply-To:References; bh=UJKi8JM/CkW5S14w+F7bYFeRvjZFWCk+nTxitiYMr8I=; b=ZYlilSCBZoUyN/QZOLqxAOCoD2 5humzxMytRMkOrBjjyxvkYbOYYDhiGMadBv7wdY/rXy3xe5kStJIG9v+whytEGL+LTAQlqWwqMFOE oojdZGViFdcsov+szl+3x5jY8zBv8g6yayJrn8KHlVjHbSQq6hhULaS+T7TjGxO9l1jzhxFUYvAPW 2pdDi81h1Miaqadb4YHui2yJ5D7r6azNrfsNl+SR2V+K+JVfkpjkWUydUGAswkQ5yGDfOQ3CZlm59 pwW+bw4c5yVT3SF839/zPBoEMfKz1+h4Y2CcOXeUHYW1KgqEmBIR92cpoDvzESLlxcB4qsnoOkMsu rg4G9AuQ==; Received: from [62.216.210.102] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tqXIr-009juo-0D for freebsd-current@freebsd.org; Fri, 07 Mar 2025 13:59:49 +0100 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 527Cxnsu002043 for ; Fri, 7 Mar 2025 13:59:49 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 527CxnU4002042 for freebsd-current@freebsd.org; Fri, 7 Mar 2025 13:59:49 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 7 Mar 2025 13:59:49 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: building port www/chromium fails due to paging problem Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails in HTML will not be read! Please, only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 62.216.210.102 X-Spamd-Result: default: False [-0.01 / 15.00]; RBL_SENDERSCORE_REPUT_5(1.50)[178.254.4.101:from]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_LONG(-0.94)[-0.939]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.02)[0.024]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; R_DKIM_ALLOW(0.00)[unixarea.de:s=blu3434000]; HAS_XAW(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[unixarea.de]; RCPT_COUNT_ONE(0.00)[1]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[unixarea.de:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:178.254.4.101]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; TO_DN_NONE(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4Z8RFz6RShz3Cb1 X-Spamd-Bar: / I'm building ports on a recent 15.0-CURRENT with ports tree from git on March 3: # uname -a FreeBSD jet 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n275738-7ee310c80ea7: Sun Mar 2 01:13:00 CET 2025 guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 # sysctl vfs.read_max=128 # sysctl vfs.aio.max_buf_aio=8192 # sysctl vfs.aio.max_aio_queue_per_proc=65536 # sysctl vfs.aio.max_aio_per_proc=8192 # sysctl vfs.aio.max_aio_queue=65536 # sysctl vm.pageout_oom_seq=120 # sysctl vm.pfault_oom_attempts=-1 # poudriere bulk -f /usr/local/etc/poudriere-list -J 3 -j 150-CURRENT -p ports20250303 The file /usr/local/etc/poudriere-list contains only www/chromium, because all other ~2400 pkg are already made. The job gets killed with: ... ===> chromium-133.0.6943.141_1 depends on package: py311-ply>0 - found ===> Returning to build of chromium-133.0.6943.141_1 ===> chromium-133.0.6943.141_1 depends on executable: bindgen - not found ===> Installing existing package /packages/All/rust-bindgen-cli-0.71.1_2.pkg [150-CURRENT-ports20250303-job-01] Installing rust-bindgen-cli-0.71.1_2... [150-CURRENT-ports20250303-job-01] `-- Installing llvm19-19.1.7_1... [150-CURRENT-ports20250303-job-01] | `-- Installing libedit-3.1.20240808,1... [150-CURRENT-ports20250303-job-01] | `-- Extracting libedit-3.1.20240808,1: .......... done [150-CURRENT-ports20250303-job-01] | `-- Installing lua53-5.3.6_1... [150-CURRENT-ports20250303-job-01] | `-- Extracting lua53-5.3.6_1: .......... done [150-CURRENT-ports20250303-job-01] | `-- Installing perl5-5.36.3_2... [150-CURRENT-ports20250303-job-01] | `-- Extracting perl5-5.36.3_2: .......... done [150-CURRENT-ports20250303-job-01] | `-- Installing zstd-1.5.7... [150-CURRENT-ports20250303-job-01] | | `-- Installing liblz4-1.10.0,1... [150-CURRENT-ports20250303-job-01] | | `-- Extracting liblz4-1.10.0,1: .......... done [150-CURRENT-ports20250303-job-01] | `-- Extracting zstd-1.5.7: .......... done [150-CURRENT-ports20250303-job-01] `-- Extracting llvm19-19.1.7_1: .....Killed Child process pid=66963 terminated abnormally: Killed # grep 66963 /var/log/messages Mar 7 10:24:34 jet kernel: pid 66963 (pkg-static), jid 3, uid 0, was killed: failed to reclaim memory # swapctl -l Device: 1024-blocks Used: /dev/da0p3 4194304 3144 /dev/md9 10485760 3060 /dev/md10 10485760 3448 /dev/md11 10485760 2924 I checked all swap devices with (example): # dd if=/dev/md10 of=/dev/null bs=8m all "devices" are fine. The box has 16 GByte RAM. What else could I check/do? -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Fri Mar 7 14:38:36 2025 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 4Z8TS91GF1z5pQtj for ; Fri, 07 Mar 2025 14:38:49 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z8TS83bZsz3sB2 for ; Fri, 07 Mar 2025 14:38:47 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-40-20.area1c.commufa.jp [124.18.40.20]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 527Ecbnm049622; Fri, 7 Mar 2025 23:38:38 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1741358318; bh=NvnyXeMno2R0SFutM2QnIJ6zqVdt5pMehYvsYKHY618=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=YMDloL6hD6rioJ4V2lzk6LeqDm/uB6q6HjaD8+lZnudow092li8fvkoZcd5rv+XDB sJ35DkSyJyt9dqN3fOKO3DWLeMxTFNe8OldvcgoBKsaQmXXaAeLq6qqNDjKw8Q8x7/ pfu2t8HrhlrWIgdvf4iNM6qNRuh0C9Jch0CDcMUw= Date: Fri, 7 Mar 2025 23:38:36 +0900 From: Tomoaki AOKI To: Matthias Apitz Cc: freebsd-current@freebsd.org Subject: Re: building port www/chromium fails due to paging problem Message-Id: <20250307233836.2dc302482c4eb8270746c51e@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4Z8TS83bZsz3sB2 X-Spamd-Bar: ---- On Fri, 7 Mar 2025 13:59:49 +0100 Matthias Apitz wrote: > > I'm building ports on a recent 15.0-CURRENT with ports tree from git on March 3: > > # uname -a > FreeBSD jet 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n275738-7ee310c80ea7: Sun Mar 2 01:13:00 CET 2025 guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > # sysctl vfs.read_max=128 > # sysctl vfs.aio.max_buf_aio=8192 > # sysctl vfs.aio.max_aio_queue_per_proc=65536 > # sysctl vfs.aio.max_aio_per_proc=8192 > # sysctl vfs.aio.max_aio_queue=65536 > # sysctl vm.pageout_oom_seq=120 > # sysctl vm.pfault_oom_attempts=-1 > > # poudriere bulk -f /usr/local/etc/poudriere-list -J 3 -j 150-CURRENT -p ports20250303 > > The file /usr/local/etc/poudriere-list contains only www/chromium, because > all other ~2400 pkg are already made. > > The job gets killed with: > ... > ===> chromium-133.0.6943.141_1 depends on package: py311-ply>0 - found > ===> Returning to build of chromium-133.0.6943.141_1 > ===> chromium-133.0.6943.141_1 depends on executable: bindgen - not found > ===> Installing existing package /packages/All/rust-bindgen-cli-0.71.1_2.pkg > [150-CURRENT-ports20250303-job-01] Installing rust-bindgen-cli-0.71.1_2... > [150-CURRENT-ports20250303-job-01] `-- Installing llvm19-19.1.7_1... > [150-CURRENT-ports20250303-job-01] | `-- Installing libedit-3.1.20240808,1... > [150-CURRENT-ports20250303-job-01] | `-- Extracting libedit-3.1.20240808,1: .......... done > [150-CURRENT-ports20250303-job-01] | `-- Installing lua53-5.3.6_1... > [150-CURRENT-ports20250303-job-01] | `-- Extracting lua53-5.3.6_1: .......... done > [150-CURRENT-ports20250303-job-01] | `-- Installing perl5-5.36.3_2... > [150-CURRENT-ports20250303-job-01] | `-- Extracting perl5-5.36.3_2: .......... done > [150-CURRENT-ports20250303-job-01] | `-- Installing zstd-1.5.7... > [150-CURRENT-ports20250303-job-01] | | `-- Installing liblz4-1.10.0,1... > [150-CURRENT-ports20250303-job-01] | | `-- Extracting liblz4-1.10.0,1: .......... done > [150-CURRENT-ports20250303-job-01] | `-- Extracting zstd-1.5.7: .......... done > [150-CURRENT-ports20250303-job-01] `-- Extracting llvm19-19.1.7_1: .....Killed > Child process pid=66963 terminated abnormally: Killed > > # grep 66963 /var/log/messages > Mar 7 10:24:34 jet kernel: pid 66963 (pkg-static), jid 3, uid 0, was killed: failed to reclaim memory > > # swapctl -l > Device: 1024-blocks Used: > /dev/da0p3 4194304 3144 > /dev/md9 10485760 3060 > /dev/md10 10485760 3448 > /dev/md11 10485760 2924 > > I checked all swap devices with (example): > > # dd if=/dev/md10 of=/dev/null bs=8m > > all "devices" are fine. > > The box has 16 GByte RAM. > > What else could I check/do? > > -- > Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > www/chromium is now at 134.0.6998.35. https://www.freshports.org/www/chromium/ https://cgit.freebsd.org/ports/log/www/chromium Not sure if it fails or not, as I'm currently on the way building it. (On stable/14, amd64 at commit e4bcef6daba71546570c623e6091fdef982a596b) -- Tomoaki AOKI From nobody Sat Mar 8 01:19:59 2025 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 4Z8lhL2Mydz5qBxH for ; Sat, 08 Mar 2025 01:20:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z8lhK1lz0z49F5 for ; Sat, 08 Mar 2025 01:20:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sNlk8dQl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1741396815; bh=kSoo/2CNzPkTaUoi4feC3hpMDTZMlJuFhQMEjCIzLsE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=sNlk8dQlVTku2MQ09+znkAuqnnXvgJUzrhxn5vwhU1J4tvjsXQlsimtsN1mkZJKpWG+8Tx+y5HCZlv4/5BCWhN82ZSLAQkoWx79lEgqxtzEMiQDpkw3PRGY/tZ2nm9pvbGuMWxGNFCMOS9rGC/UUNYHF3tRWZKLZdC8/iTgbBEBm2aFG8iOYi1jN5i2h4wnGDKPHFlYp0KjlzPp6+Abh22jAEz50chYn49ERPQcVIhjqIiq0/gyJHOL+XyzZyreOQ5Gfbb5pdj1H/bLty8R6ehBvCNdbcuQIYN9D0itZsHBqCz79P4Dfz5TUbPWnfqdPzHkmTZyQjjk32T9xWLbOPA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1741396815; bh=GaGjM4JCN7g4UoOO1ITkUZxZcxYTx4S6JZqqEWVLR5P=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=bj7CAv9MT8SlkQikpRJqvPxWvbfSXF5c2gERyMnbv88pHdeqkTa2tb1e9hCjgBVwCSD3J+zasBl5ymkmrjrxnhojt5N36hCCWiyM9xzuJTHgdjHPwztWmBrq0P/hKkoPd+2A5HzWCKVWETt5WXP8F+0XZUMmzyDUxVsST3FQOsxKHV4XDqJBTnwlLi2vPcgXd4DiI+vnbHSVKd6dOjAaTNf5SuSJ1gL0LWJg0kSIA3dwpK3E+Mj24jfomc0DUvCyQDJbae8Ri+RW5FtKUm/RGaVsU95e9N0CvQnCazXndsbrzK13zXnLMUdm4FB6XRSdwVo1vIeYH4A90OrSXWlz8w== X-YMail-OSG: qseP3AcVM1lFHU84mQn7t6gZPeKIdpb9XUmCtyaphAJEJ6UZB8q9QapQFGPr.j3 NH1Tv3QWSUm.k4rExiMaZkb8SnFVxQ_dBwacrf.lLah7CVYDj235Wsz4xSvf.xBwL_9R1fUidTMN 9dpxxncJ9FJbDcouTti0QkVF.9TnlmAY20SiCXP7RBpbdF7N_Al4UhignCZCVsAoY7T1JwnR7qcg f_b3_wplcQfR14Ub6v3s0ui2p6o.6zQZaf03SgFRO6xsy62VgP945tHWC8STbLU7IQ0zr9y53hyR meSZ6TgZJ3CdtugnHl0WGrbvsjp8rduWr.Tt4aps4UBIvCcyF3soQWRIp4WL41uQo_DPuNpOnJj8 aajEI4k0p4BvdqfDjVFMTaNfJJ.X984et3uFSljwBW8xHMNvpVkJ6lTVtAGuy.cDDg.FK87dBjrL aAAXGcQfDEGuoLoG.UbMatPdZnfr6e35XmKqTR.GxT0pH.2BlMMPGIm755cmRah5OebZ14_bGzWa 5AsRuwvjjK6vqF_pEGrVyY9gOLQMag4RwD0MQCOT.OahSjLtfnaW.2pJfAxAsXMSxaA.95ecxdto fLHob2aJaAfr4Ac95Lk6JwB857RVR9k5BkPyugG2LFVuP5SNtyljYZA775uwcoX1cxtQg2PodeFx 0ewuaH8Yq_FyxqtFiarBAdqsjPHJAWfqqbw.gFpWj0O0YVwZEDOzhcEcBM1dTqdR5Lldl27Ma5yK 0OQ066ye7mcJrryqjNyzElqL6n0xWISnd70dGSm3C7Gr9DZk8FdO5fnzIEGNRtZGkOQbNv63liq2 P8MVvMzBtm8EpQgxMelpjNpfQPvXxzlP4iacAwF.JL_DdYIORloEhNqM_oX0ApT0bqC_nntUD3PL _uFLYV59dKAwfl8DL885Bs_a5IOohVsP1uBaz6Wfc6zjNcvR7Xx12_ZLEqBbG2wOSMLx1MG9igxX zgqVO07meVmtAsn5dczE7xL9nnCxdLJT_BSy61_ef6rWbY6k46kE5U7DAAzROUfMtnqpH8j2PSHF J4vHyeSdn.yElg85KjYxhlEHkIIpt9mYoiMd5AO_H2qbRasSNQp2Ly1zG5objJRA3ac5qKmNzBhu qsJ3ld5OJxNBNjxOZxYynjKIiYkzhzDHHA3b7XC5zPA6Poy36js7rsMKCZio.dRIjX5c8e65wkyT .DY57ZeANG2Vd09vRuVVIH._azVeGN2j.qUH.0rg7yBPhcEG9BEIiv8JZYojjFCc5XdbDuKSyq9U teHCoG3g1Lxp.1raZ44OO7c.BakJwfFwR9439ks.k7Xfg._RALDnrb98e_d8r9Ccj4F04cnqWVrO LiEDJDI3aefGAb1TMh5EdJ7Yzzhdm27SH9a4dpgv8Ja3bq.E0l7tcvfnYNNvuS2P28jcnGLNn3d3 jbAuOAJPi4iMNcwOXfiW3NPNJ1hyE7YMt9gpTFRs4AfunKGl3SQyd94QRN_JMxmXfiQ.tERYzqXR KEVp1qHNWUua9ROAjnELYhJ9bMEd4Acdy0NdSdCfmDkGu5K4YaPEEpyIuhXVU8DBMfkYJwhUphHo 7nWzSB50sYP1bCieMcY7tuAK3mAGMZSuJpmybhjmrrR9apnbFZnMfOb3HPpr61URUCax7guWPn4_ jUVU7ev5SkvUT.NTuWR2cfSGJZFN1Yp6EjoD2zJkcb0cPxnLysra.O9fbJdx0mxGF8Z5nwgi73ne nngJPRJg93Vm_ZXKIKpwJYBSsUUvu2uLLqGsWOAthAtbzoKbBGNHA_tSYH6fyKu7hGLDcthESa4i UBf63JXAo7BezKf8oEzbkg3EzYfITUqlgUSwNTW5PxsrbP_eH5CZIJofSlH3nBZ0eDIg1V8DJPSD 27mc3ZFx2dHii6DDVlTrQneFVcLE1E9SY2CB0d9rFK1eYrL6J7mzeg30ydPe6wQOq8U79FDRudsY f36oAfSC6.zKcaet3nywrJcZUVcqbbmH5Lz9XQ1DrBObqUwFc5iH5c2WcTXQNqUi4idCU7gENURs KqX7g4.DvcJBysc7GpXqcOcWeRodkciMLxeH_ANwtWIjZfrgt3GqI8xAE2JQLFL7Yp9EUXmd_PUQ ogcd8V3GG4h.GSWgASiowOM1QfqNCVVijlmFAIqfSlXlAICaba76_poLyOJFPppaHUsjO.ehmuPv G.rW1fWKn2lTdFpDyll7eea6N1wAX6mdO6EQG3YFGefH8hW3Ssu.bPlWvux9E6IOc6KumDAMcmul J38t45UoA82eAhHiH2cBV4rmemiz5YtFkdYNLCfA2QK_pCxCrvXZRU3tEwfa1Cyw1PuvDO97Q6hW CgjmNHkhq X-Sonic-MF: X-Sonic-ID: 6924073b-1f81-483f-881a-01011ab0e63c Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 8 Mar 2025 01:20:15 +0000 Received: by hermes--production-gq1-7d5f4447dd-9qjv2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c89c55d0eea968c1db1b1721700c3abb; Sat, 08 Mar 2025 01:20:10 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: RE: building port www/chromium fails due to paging problem Message-Id: <5449D69F-85F3-4302-81B4-22C9D1130845@yahoo.com> Date: Fri, 7 Mar 2025 17:19:59 -0800 To: guru@unixarea.de, FreeBSD Current X-Mailer: Apple Mail (2.3826.400.131.1.6) References: <5449D69F-85F3-4302-81B4-22C9D1130845.ref@yahoo.com> X-Spamd-Result: default: False [-3.17 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.83:from]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; NEURAL_HAM_SHORT(-0.69)[-0.694]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.05)[-0.048]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4Z8lhK1lz0z49F5 X-Spamd-Bar: --- Matthias Apitz wrote on Date: Fri, 07 Mar 2025 12:59:49 UTC : > I'm building ports on a recent 15.0-CURRENT with ports tree from git = on March 3: >=20 > # uname -a > FreeBSD jet 15.0-CURRENT FreeBSD 15.0-CURRENT #0 = main-n275738-7ee310c80ea7: Sun Mar 2 01:13:00 CET 2025 = guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 >=20 > # sysctl vfs.read_max=3D128 > # sysctl vfs.aio.max_buf_aio=3D8192 > # sysctl vfs.aio.max_aio_queue_per_proc=3D65536 > # sysctl vfs.aio.max_aio_per_proc=3D8192 > # sysctl vfs.aio.max_aio_queue=3D65536 > # sysctl vm.pageout_oom_seq=3D120 > # sysctl vm.pfault_oom_attempts=3D-1=20 >=20 > # poudriere bulk -f /usr/local/etc/poudriere-list -J 3 -j 150-CURRENT = -p ports20250303 >=20 > The file /usr/local/etc/poudriere-list contains only www/chromium, = because > all other ~2400 pkg are already made. >=20 > The job gets killed with: > ... > =3D=3D=3D> chromium-133.0.6943.141_1 depends on package: py311-ply>0 - = found > =3D=3D=3D> Returning to build of chromium-133.0.6943.141_1 > =3D=3D=3D> chromium-133.0.6943.141_1 depends on executable: bindgen - = not found > =3D=3D=3D> Installing existing package = /packages/All/rust-bindgen-cli-0.71.1_2.pkg > [150-CURRENT-ports20250303-job-01] Installing = rust-bindgen-cli-0.71.1_2... > [150-CURRENT-ports20250303-job-01] `-- Installing llvm19-19.1.7_1... > [150-CURRENT-ports20250303-job-01] | `-- Installing = libedit-3.1.20240808,1... > [150-CURRENT-ports20250303-job-01] | `-- Extracting = libedit-3.1.20240808,1: .......... done > [150-CURRENT-ports20250303-job-01] | `-- Installing lua53-5.3.6_1... > [150-CURRENT-ports20250303-job-01] | `-- Extracting lua53-5.3.6_1: = .......... done > [150-CURRENT-ports20250303-job-01] | `-- Installing perl5-5.36.3_2... > [150-CURRENT-ports20250303-job-01] | `-- Extracting perl5-5.36.3_2: = .......... done > [150-CURRENT-ports20250303-job-01] | `-- Installing zstd-1.5.7... > [150-CURRENT-ports20250303-job-01] | | `-- Installing = liblz4-1.10.0,1... > [150-CURRENT-ports20250303-job-01] | | `-- Extracting liblz4-1.10.0,1: = .......... done > [150-CURRENT-ports20250303-job-01] | `-- Extracting zstd-1.5.7: = .......... done > [150-CURRENT-ports20250303-job-01] `-- Extracting llvm19-19.1.7_1: = .....Killed > Child process pid=3D66963 terminated abnormally: Killed Note that the above died while extracting from llvm19-19.1.7_1.pkg . What are you using in /usr/local/etc/poudriere.conf for USE_TMPFS=3D and for the likes of TMPFS_BLACKLIST=3D and TMPFS_BLACKLIST_TMPDIR=3D ? I'll note that the file system space use is vastly larger on later stages of building. Using RAM+SWAP via TMPFS use would have the file system competing for the RAM as well. How many FreeBSD cpus? in /usr/local/etc/poudriere.conf wat are you using for ALLOW_MAKE_JOBS=3D ? For ALLOW_MAKE_JOBS_PACKAGES=3D ? With -J3 in use, later in a bulk run there could be questions of what the RAM+SWAP usage is like for other jobs happening in parallel. > # grep 66963 /var/log/messages > Mar 7 10:24:34 jet kernel: pid 66963 (pkg-static), jid 3, uid 0, was = killed: failed to reclaim memory The above message means that FreeBSD had a sustained period of being unable to have its Free Memory threshold met. ven a single process (thread) that both stays runnable and causes a sufficiently large Active Memory figure can lead to this condition. There is a tunable for giving more time for something to complete before that happens. For example, in /boot/loader.conf : vm.pageout_oom_seq=3D120 is 10 times larger than the default of 12. # sysctl -Td vm.pageout_oom_seq vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM It is also writable on a live system: # sysctl -Wd vm.pageout_oom_seq vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM So: # sysctl vm.pageout_oom_seq=3D120 vm.pageout_oom_seq: 120 -> 120 (I use 120 over a wide variety of contexts.) > # swapctl -l > Device: 1024-blocks Used: > /dev/da0p3 4194304 3144 The above added 4 GiBytes of SWAP that (mostly) do not complete for RAM. So RAM+SWAP is effectively about 16 GiByte + 4 GiByte =3D=3D 20 GiByte. It is not clear for the below what type of /dev/md* is in use in each case: malloc? vnode? swap? ( better not be: null ) Presuming vnode: quoting = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048#c7 QUOTE On 2017-Feb-13, at 7:20 PM, Konstantin Belousov = wrote on the freebsd-arm list: . . . swapfile write requires the write request to come through the filesystem write path, which might require the filesystem to allocate more memory and read some data. E.g. it is known that any ZFS write request allocates memory, and that write request on large UFS file might require allocating and reading an indirect block buffer to find the block number of the written block, if the indirect block was not yet read. As result, swapfile swapping is more prone to the trivial and = unavoidable deadlocks where the pagedaemon thread, which produces free memory, needs more free memory to make a progress. Swap write on the raw partition = over simple partitioning scheme directly over HBA are usually safe, while = e.g. zfs over geli over umass is the worst construction. END QUOTE So I'd not recommend the use of vnode /dev/md* based swap spaces. Nor would I recommend one of the types: malloc, swap, or null for /dev/md* swap space creation. "man 8 mdconfig" reports: QUOTE -t type Select the type of the memory disk. malloc Storage for this type of memory disk is allocated with malloc(9). This limits the size to the malloc bucket limit in the kernel. If the -o reserve option is not set, creating and filling a large malloc-backed memory disk is a very easy way to panic the system. vnode A file specified with -f file becomes the backing store for this memory disk. swap Storage for this type of memory disk is allocated from buffer memory. Pages get pushed out to swap when the system is under memory pressure, otherwise they stay in the operating memory. Using swap backing is generally preferred instead of using malloc backing. null Bitsink; all writes do nothing, all reads return ze- roes. END QUOTE > /dev/md9 10485760 3060 > /dev/md10 10485760 3448 > /dev/md11 10485760 2924 > =20 > I checked all swap devices with (example): >=20 > # dd if=3D/dev/md10 of=3D/dev/null bs=3D8m >=20 > all "devices" are fine. >=20 > The box has 16 GByte RAM. >=20 > What else could I check/do? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Mar 8 09:20:17 2025 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 4Z8yLJ4k3Bz5qh7B; Sat, 08 Mar 2025 09:20:24 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z8yLH44hlz3MtS; Sat, 08 Mar 2025 09:20:23 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=DnGV5Mc7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::429 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-39129017bbbso1148652f8f.1; Sat, 08 Mar 2025 01:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741425619; x=1742030419; darn=freebsd.org; h=content-transfer-encoding:autocrypt:subject:to:content-language :from:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=9YB8xMKH//nMmgx78cMQeZVjZvHoAsSkwvTTB3iidFI=; b=DnGV5Mc77i4mwbByycmOdKH64hYqjCpR+NDkZt5CWiXhYrHAJ8zgMnp/4GaURckkqS g4e6cIwXkcxLqd+1/U7zmU6O7PuHauWaCWoCcJxq8wKu56b2s1631mGARirCjgOgi/jf bGN2b2WTI17v/rxdL6RiPg0x2ZEWm5//67TKCGb9efPQcIwvjR2kE/2hQ3P7z4xVuPI+ k28mO7y399E2qRNjaqd/DhWMItybMHwMmUBCol/Myomdgxrp+yQYNb50tcri42RmHGvB T8glffa9SU0/Gl05CYRcbZ9oFMC/aCvONePjRuksiiD4JASBvEbM0ZCOAm6f0Bt1w4cm o6ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741425619; x=1742030419; h=content-transfer-encoding:autocrypt:subject:to:content-language :from:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9YB8xMKH//nMmgx78cMQeZVjZvHoAsSkwvTTB3iidFI=; b=MYpjiRlrs32fYgJCYbW9dgHkkZuC17QVZh0agSs7fliFyGcrS6i+au+e6Q65PV0HPJ 3a9G5rI+pR9gD/eIzwHO2CGiy7UxWAnLQ0X6qjdgV8mQZeKn6w2AArosreQ45tv9ijzS 7TjB4UKEe3s/YH6Q1puiGIAt0Wdi4df40ze0jXaEUiz4oXJbhqdZAa6wFfybuhWw4aKT 0hEfalBPXfE4jzLd96E7OWp8N1ew0ndMVv9SBVIYp+ExKuEzecx7PoORwaETjbaUNTg5 loncqvYJBuaeDEypf0jUhIftjTeSK/mQ/eWsy9X2jddyXqeTQRZUPposN1A9AMsJz4ij QCSg== X-Forwarded-Encrypted: i=1; AJvYcCWJdme5pLf+zO7pke+i3WKKl/onNeSR/CLT5vGXYgJLHdSoEFb1SrciGKLa8TP1dgibw/qzQRv94bJbpsMyg/0=@freebsd.org X-Gm-Message-State: AOJu0YyHRn/0cXA501LL1Ajf+V0sERJe991wSM6dWrXutBLf9B6GxPk7 hSTzdF3LR+yNl3sVunqVjY/SxAGdX860XNK3GpWMZZm1btBgMQUkHzoXkg== X-Gm-Gg: ASbGncsYuX84li07icMhWLojnJZNqwlj5GxNyIy33517R8jZ1iOiqqxkGpqmxrH2zrX +OyaOLwLY34SKcQW9BMH5/1M+vl1QhuG5nl9qgfs7mksEyOclIlnke0MSYKkm3wijXQUw2G12B6 xNGC6hszbk+kiTmPMuYC+x2pqIWSu9JaRje+dfvyn/U8Ky4b7D1oRSc6vOCCvbFS2ixTRtzqxMj MmE0Kz/EaaoXTdamC7joKttqFycpxX1pirQxhesAVEGkRECZx/abTOXqKjKI3yIW0FBIkYr93od mZT6P3/rvKgVU/YLDxVQfnO8hQlX2Pp1jsOvQCNk2npuh7qvYLRqbIXuDNueRiesFUoYwme3BBc dOw== X-Google-Smtp-Source: AGHT+IGMB0opUKB9o2NItmb52g2JiwluLH3bM8OQZUX7/1GL0MyOZC/Rxps0eWDiilnqRJu2fMCbfw== X-Received: by 2002:a5d:6daa:0:b0:38f:34a7:ebfb with SMTP id ffacd0b85a97d-39132fd343amr3220867f8f.55.1741425619127; Sat, 08 Mar 2025 01:20:19 -0800 (PST) Received: from [192.168.1.10] (host-78-147-91-13.as13285.net. [78.147.91.13]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3912bfe0004sm8002976f8f.40.2025.03.08.01.20.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Mar 2025 01:20:18 -0800 (PST) Message-ID: <34597482-22c3-42c0-b4e5-343b5e6c9e9b@gmail.com> Date: Sat, 8 Mar 2025 09:20:17 +0000 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 Thunderbird From: Graham Perrin Content-Language: en-GB To: freebsd-wireless@freebsd.org, freebsd-current@freebsd.org Subject: iwlwifi kernel panics, Wireless 7260, main-n275833-136c5e17b61a (2025-03-07) Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJimMMBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQLbHAQAJi998y42bEbq5HmABYovmAEtQj33YSUWyc9QRmAHpN8Er3lTKsgmZcVChB5Fu/d go2oYynDjlVpA7+wiSmg4AG78mOYbg/e19XMhrH0keDKqZXFkU+G7agR0mF09qvpQZ9MTJYZ 2u7FtytZK665UfipOdV8eGn2hFC/WynjUwEzKyryBgbbLAEbfOPeZNry4h2ZPWbtTvx/PE/V X3Vh2oGqYx69DCGz+0xEhy62ZKbkX5SL8LUf/1WViyCVzsHasFxmFxYPWIfBy8ayQ7xapz7M cSXSQyu4oDT4qh9eZiGP9/aAcZKHcV6t9y77JGhUJ/5O1sANKMa3YhgimE+Z86LHYa1IH774 PHj1nAXBwS+Cj/1l/NQoQcyjvOj8zuCsMJVaLMb6B46YsReP4+3yBLpyeBC//t6zWPbgAkWW VjROC0dXUAMTFpnA6NZe3UghG+Nc4fnCLGOhc2nyWFYHIaYV6Hv1ITFSem9DdeNnR1CFm1VM TJ7i7TuqYM+WZTkoUsTf4c46hS/ZNJZSCxh0s9yYr+BYk3XBbd+ElaZ1dJE6cuSVdw15+P2h DnprurxC4byl4YFkn+UAVvQsOgeq6aSHLOHX0weYu1OLoiPYsTdyGhne72+kDhEEdFD5aHdQ PFrbQIrqWLV0a04++0ZwGpNvXtgnWhDdAQJDwGsSSwbLzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmKYt7ACGwwFCQWjmoAACgkQt2dIb0oY1Av7qg//YjCZg8VXyMzXssgIQpROKKqh5V0UBSQl rM3tq4tWhyg0HVMugQj0Om+iNPsEEOGHkm6tyhHMzlKGpAc/l0iAM+8twIyg44Yo5+DcfFXr OMTbTw9T9jDsWOkOBksxy29iYhgpqpWdDBnhXvrJp/FNAiX8CfzrIOZeFPydDoEiKBEXAxfe a9o5J/JeVnZiUeoiFe7i68nZGsb4JxhPczNfqW12t0Ll5/ibjszg5BgjXiLao0KqbWNh4bS5 CVwH90Or+5qqWgzWPeBiuz+rN2QXE/V/fL44GEj1YKASCqmaiYRgjoRFubz1aq1wCXMXY3Iq d4525rscUgS7HBxbblnyTodUPaamN/2nSzcmE/Pkx8MApDSgZCIhs0RTAg+/AoX4HULV1rSE TQwMrBEQt84Tw5W5rHsvXKr4ZEsJUpbPLWYTISsp23nHR+vZtL/Ug+OWCmHC7X7D21xk/xVJ 4sA1RLJBKdCHtnyA4Unv/kNS1KVGxHnITVyw1a71QJADu4qsdtM5u6CyYUhqhM1oseWtV6j+ Qi8KC/G4C3AgZf06fe2fVl42z2grTabL4bC6FQXMwTX2dsm5NakWjUCmUL8uwsQE7ZA4zKxo EYI1YV9q1birpzncYRupr1qnMoggMUHWq0IBYshFQrEO8PeVUZBw7/GfAeh3argdw2Qu748T Cyw= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.71 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.97)[-0.971]; NEURAL_HAM_LONG(-0.74)[-0.745]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-wireless@freebsd.org,freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::429:from] X-Rspamd-Queue-Id: 4Z8yLH44hlz3MtS X-Spamd-Bar: --- 136c5e17b61a from pkgbase base_latest. First panic today, Saturday 2025-03-08 02:18, in response to service netif restart wlan1 at home with ssid 'piano5'. Photographed five minutes after the command (whilst the computer was visibly frozen, non-responsive, before the automated restart of the OS): . For the first of the panics: I can not offer a backtrace, sorry. IIRC the second panic occurred after the savecore for the first; during automated generation of the crash summary. It seems that the third panic occurred during the next start of the OS, probably after the savecore and successful crash summary for the second panic. core.txt.14 (02:42, for a panic at 02:28) might contain enough for me to match it to something in Bugzilla. (Off-topic from freebsd-wireless: crashinfo(8) can not produce a useful core.txt.13 file.) For a few hours before the panics, on Friday, I had limited success with iwlwifi(4) with eduroam. Then at home, some panic-free experiments with a different ssid (piano). After the series of panics (with piano5), I reverted to iwm(4). root@mowa219-gjp4-zbook-freebsd:/var/crash # less core.txt.13 root@mowa219-gjp4-zbook-freebsd:/var/crash # crashinfo vmcore.13 Writing crash summary to ./core.txt.13. root@mowa219-gjp4-zbook-freebsd:/var/crash # less core.txt.13 root@mowa219-gjp4-zbook-freebsd:/var/crash # cat info.13 Dump header from device: /dev/ada1p2   Architecture: amd64   Architecture Version: 2   Dump Length: 2706395136   Blocksize: 512   Compression: none   Dumptime: 2025-03-08 02:18:33 +0000   Hostname: mowa219-gjp4-zbook-freebsd   Magic: FreeBSD Kernel Dump   Version String: FreeBSD 15.0-CURRENT main-n275833-136c5e17b61a GENERIC-NODEBUG   Panic String: page fault   Dump Parity: 3349005578   Bounds: 13   Dump Status: good root@mowa219-gjp4-zbook-freebsd:/var/crash # ls -hlnrt | grep 8\ 08 -rw-------  1 0 0  2.8G Mar  8 08:12 kgdb151.core -rw-r--r--  1 0 0  8.6K Mar  8 08:12 core.txt.13 root@mowa219-gjp4-zbook-freebsd:/var/crash # exit logout grahamperrin:~ % pciconf -lv | grep -A 3 iwm iwm0@pci0:61:0:0:       class=0x028000 rev=0x6b hdr=0x00 vendor=0x8086 device=0x08b1 subvendor=0x8086 subdevice=0xc060     vendor     = 'Intel Corporation'     device     = 'Wireless 7260'     class      = network grahamperrin:~ % bectl list -c creation | tail -n 6 1500034-002-ports         -      -          54.8M 2025-03-04 13:48 1500034-003-base-ports    -      -          1.30G 2025-03-05 01:18 1500034-004-ports         -      -          59.9M 2025-03-05 11:48 1500034-005-base          -      -          925M  2025-03-06 07:00 1500034-006-base          -      -          1006M 2025-03-07 09:40 1500034-007-base          NR     /          233G  2025-03-07 12:56 grahamperrin:~ % tail -n 6 /home/grahamperrin/Documents/boot\ environments.txt 1500034-002-ports               2025-03-04 13:48 main-n275770-6ba1c5abb957 GENERIC-NODEBUG 397957f38f35159b9774623b9522d57eddf5e648 1500034-003-base-ports          2025-03-05 01:18 main-n275791-ca48e43ba9ee GENERIC-NODEBUG c0ddb80a45d83268d27896df705cf1e009bd3f43 1500034-004-ports               2025-03-05 11:48 main-n275791-ca48e43ba9ee GENERIC-NODEBUG c0ddb80a45d83268d27896df705cf1e009bd3f43 1500034-005-base                2025-03-06 07:00 main-n275806-27bf5c405bf2 GENERIC-NODEBUG a9da0bcfd2f01fbdc86d37ce697b94a6cb6cbd16 1500034-006-base                2025-03-07 09:40 main-n275820-b8dfc3ecf703 GENERIC-NODEBUG 1a660da9f33417bb50c01a5b7f663a4992aedbd2 1500034-007-base                2025-03-07 12:56 main-n275833-136c5e17b61a GENERIC-NODEBUG e385de4e8451d91b453fc751b9d238625d961c25 grahamperrin:~ % root@mowa219-gjp4-zbook-freebsd:/var/crash # ls -hlnrt | tail -n 11 -rw-r--r--  1 0 0   11K Dec 31 04:24 core.txt.12 -rw-------  1 0 0  421B Mar  8 02:27 info.13 -rw-------  1 0 0   82M Mar  8 02:27 vmcore.13 -rw-r--r--  1 0 0    3B Mar  8 02:41 bounds -rw-------  1 0 0  421B Mar  8 02:41 info.14 -rw-------  1 0 0  1.4G Mar  8 02:42 vmcore.14 lrwxr-xr-x  1 0 0    7B Mar  8 02:42 info.last -> info.14 lrwxr-xr-x  1 0 0    9B Mar  8 02:42 vmcore.last -> vmcore.14 -rw-r--r--  1 0 0  230K Mar  8 02:42 core.txt.14 -rw-------  1 0 0  2.8G Mar  8 08:12 kgdb151.core -rw-r--r--  1 0 0  8.6K Mar  8 08:12 core.txt.13 root@mowa219-gjp4-zbook-freebsd:/var/crash # grep BOOT /var/log/messages Mar  8 02:27:43 mowa219-gjp4-zbook-freebsd kernel: ---<>--- Mar  8 02:34:24 mowa219-gjp4-zbook-freebsd kernel: ---<>--- Mar  8 02:41:45 mowa219-gjp4-zbook-freebsd kernel: ---<>--- Mar  8 03:48:23 mowa219-gjp4-zbook-freebsd kernel: ---<>--- Mar  8 06:27:05 mowa219-gjp4-zbook-freebsd kernel: ---<>--- root@mowa219-gjp4-zbook-freebsd:/var/crash # From nobody Sat Mar 8 13:09:18 2025 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 4Z93QV5Y80z5pBbq for ; Sat, 08 Mar 2025 13:09:22 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z93QT4wfJz3kr0 for ; Sat, 08 Mar 2025 13:09:21 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=unixarea.de ; s=blu3434000; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender: Content-ID:Content-Description; bh=r0STsJS1HNwJ89h00uyb5fTzNL33gouGIponvhs+93g=; b=MS0jDt8nyBKdY30WGqiUV2euyo cIt1ON+lg6gofdNiMw3WyYMJA/zEoVcmliNKJExteeeydd49qFBlnomJZelibghRTG/v7efEtw3N6 KCKf0LitQQjQBLCuT3ebeI33Um2FFOImEo2pWBTMCKYHQNi8OUD0jmaiDlIX5p40GylaVV5pzj7d0 nuE9JU2BoEOgBuWDz4bArhiuDco9sX4VC0svK4XXKkGS6NPbww5IdQx4RNFcYgqMgY4/kCMOyr64h kEzXjSrfC+JsJFT7j8mHIBZlwTenTKOrocPWCg30xm+OKTca18rWitR5D35s+xvCM3uafHtyx4swL pDnGIViQ==; Received: from [62.216.210.25] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tqtvb-00DkVL-1e; Sat, 08 Mar 2025 14:09:19 +0100 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 528D9IJj001815; Sat, 8 Mar 2025 14:09:18 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 528D9IAe001814; Sat, 8 Mar 2025 14:09:18 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 8 Mar 2025 14:09:18 +0100 From: Matthias Apitz To: Mark Millard Cc: FreeBSD Current Subject: Re: building port www/chromium fails due to paging problem Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Mark Millard , FreeBSD Current References: <5449D69F-85F3-4302-81B4-22C9D1130845.ref@yahoo.com> <5449D69F-85F3-4302-81B4-22C9D1130845@yahoo.com> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5449D69F-85F3-4302-81B4-22C9D1130845@yahoo.com> X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails in HTML will not be read! Please, only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 62.216.210.25 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] X-Rspamd-Queue-Id: 4Z93QT4wfJz3kr0 X-Spamd-Bar: ---- I set USE_TMPFS=no and it was built fine in ~22h on this box with 8 CPUs: ... ===> Cleaning for chromium-133.0.6943.141_1 build of www/chromium | chromium-133.0.6943.141_1 ended at 2025-03-08T13:09:13+01:00 build time: 21:59:28 [root@jet /usr/home/guru]# Thanks for all the hints matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sat Mar 8 23:02:14 2025 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 4Z9Jb04xCrz5q7qX; Sat, 08 Mar 2025 23:02:36 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z9JZz4Xsrz3ZXX; Sat, 08 Mar 2025 23:02:35 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Nk8mZeXC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5e5491eb379so4997159a12.3; Sat, 08 Mar 2025 15:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741474953; x=1742079753; darn=freebsd.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=DfKRR7ye/lAqnf2q6XmYy32yXFUvGUfzDWYnGHhrhwo=; b=Nk8mZeXClhYEh6c/XEjXBwYJfpWxT/7m+wKTpEhE3CKnoXELSES3sxe/NzWwVlaP5v R/FI2X7X5aupkbsXOgmA5LJqS0GnDX2MeRfv7wHjUFbR2lmo237cfTE5oTixbJXiwvWX 1QAxrmAO03W5+TCOyke1I/JBLGTbcxtv8TiEHcR3h4jSrmIa3CJ9yfeckOkAzdkyX7/d xXYypwwU9jlOeBMsWotxWAy4nHWyo+FQDbI6Z4gl9xlE+bBScwDr+Yy52tSakW5zpeph C3SLulfdSAptXqI6qG5SKRbI4lUkWMdrRv1L8BiPvpKhfem7G+iR6NpHHEOhQI41o0un TqCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741474953; x=1742079753; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DfKRR7ye/lAqnf2q6XmYy32yXFUvGUfzDWYnGHhrhwo=; b=hzD6udo/RnFJno7KRLLAk+HQfJMk4CimWYqLgZtyHpH3A5LxHtDdMUWYCHf5uVaXUW ITPi/H71qJLVnWvPrw7SYXMQUqo0z9eyrybe3z32h7ghv+yMwcLiWWnwPDI4WzzPazM8 v/LVyXkz30SoGBnnlhCr+abKQVR0ApRUS+1j1nAOmEpG81gKXbV+k1oFt3hujHVTMUuP R1ZormO814OiEpKasXlJsYE42YOuiuMBAGgbDTYKzN18qPbDvhUTayKu+WYLULLrJToP CHDhwGLhqyz6s69Yhs9AQDteZ7UJXbl7eUFYXAnCE5WBJBRy8YBoPFFr/SaLAbbQc1oV IB2g== X-Forwarded-Encrypted: i=1; AJvYcCXYe9Rlns9OU33isW3RRu3PJ/liXEeUkHfNKzFhZKcuTX01yxq4kA6YYGKaOKrBVB0E9A3M6VmK36glt9vQlbw=@freebsd.org X-Gm-Message-State: AOJu0Yx8iNT2quqgAbZY9wM5+eQ2n2TyzZQ8Ec1DibtO8+5028vwFRWm SyMYatF0bEj9X+7fcM8sOxp6IxOwJAAKz7r8Dy+NdowRrGiyy9yQHpjCMLhSPa5mXHXTDUVoL2w dv/+8appYlZRUgqNuD8uLsG14lXoQE9Q= X-Gm-Gg: ASbGncsgMzmwJdvA/1tqe7W8wMnUx5RcDGc5sPVIN4mgicYxL37OdfXnedk7jFzCkLx v07xKPRHE8hAVLis2jvSiJnZD1oiQc1X6v7T2ccZb2SbgNVrtMN2U9ilTs1WzYrZkPvZrx8Gubw 6XEC5yrgXpMAz+Q0yjkKe6AbSHWbEUN3zUPNx4ijVESkK41XhxV9Ix+jXLhw== X-Google-Smtp-Source: AGHT+IFjOFWGq4AITiWCzQ4eUVbxvt+Ta03udYVNeLPhUSz6pU/6hsNajzjO0NeAFc2c464YvcHtTWyzj9p8rCSjBc0= X-Received: by 2002:a05:6402:3495:b0:5e6:20de:f79b with SMTP id 4fb4d7f45d1cf-5e620df0103mr3430750a12.31.1741474952717; Sat, 08 Mar 2025 15:02:32 -0800 (PST) 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 From: Rick Macklem Date: Sat, 8 Mar 2025 15:02:14 -0800 X-Gm-Features: AQ5f1JoDHEmDsAxD6_WedRSkI6-vG_7fjsw2yAjPeHjRhI1APK01O8yrevYc7dw Message-ID: Subject: RFC: Solaris style extended attributes for FreeBSD To: freebsd-arch@freebsd.org, FreeBSD CURRENT Cc: Cedric Blancher , Lionel Cons Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [1.08 / 15.00]; NEURAL_SPAM_MEDIUM(0.84)[0.843]; NEURAL_SPAM_SHORT(0.67)[0.672]; NEURAL_SPAM_LONG(0.56)[0.562]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4Z9JZz4Xsrz3ZXX X-Spamd-Bar: + First off, I cross posted because I don't think many read freebsd-arch@. There seems to be a nice market for Solaris style extended attributes. Since ZFS is already wired for them, adding the basics is pretty straightforward. I am not suggesting that they should replace the current FreeBSD extended attributes. For those not familiar with them (I am not very familiar myself;-), a Solaris style extended attribute is in a directory that hangs off the file object and the entries in the directory (the attributes) can be manipulated with open/read/write/lseek just like a regular file. (They can be as large as a regular file, but there is no atomicity guarantees.) At this point I have a couple of rough patches: https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part I have a simple test program to test the above: https://people.freebsd.org/~rmacklem/xattrtest.c The VFS/ZFS patch defines: O_NAMEDATTR - similar to O_XATTR, but uses the NFSv4 named attribute terminology to avoid confusion with the other style of FreeBSD extended attributes. (The semantics probably are not exactly the same either. I do not have a Solaris system to test on, so I am going from the NFSv4 and Solaris doc. I have handy.) --> You can look at xattrtest.c to see how this is used. I have not done any userland patches and am not sure what might be needed? (I suspect a variant of pax/tar that knows about these is the minimum?) I defined a couple of new v_irflag bits to indicate that a vnode is a named attribute directory or a named attribute. That way, they are still of v_type VDIR or VREG and can be handled by most of the code without change. So, now for the questions... 1 - Do you think this should be put in FreeBSD? (If the consensus is no, I will try and maintain out of tree patches.) 2 - If the answer for #1 is yes, what do you think is needed beyond what I already have (which is a way to open the named attribute directory and named attributes within that directory). Thanks in advance for any comments, rick From nobody Sun Mar 9 09:33:57 2025 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 4Z9Zbq1CwRz5pYPQ; Sun, 09 Mar 2025 09:34:15 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z9Zbn6qCkz46sN; Sun, 09 Mar 2025 09:34:13 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5299Xvpj027065; Sun, 9 Mar 2025 11:34:00 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5299Xvpj027065 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5299Xvpt027064; Sun, 9 Mar 2025 11:33:57 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sun, 9 Mar 2025 11:33:57 +0200 From: Konstantin Belousov To: Rick Macklem Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Result: default: False [1.28 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_SPAM_MEDIUM(0.88)[0.885]; NEURAL_HAM_LONG(-0.11)[-0.111]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEFALL_USER(0.00)[kib]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; HAS_XAW(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4Z9Zbn6qCkz46sN X-Spamd-Bar: + On Sat, Mar 08, 2025 at 03:02:14PM -0800, Rick Macklem wrote: > First off, I cross posted because I don't think many read freebsd-arch@. > There seems to be a nice market for Solaris style extended attributes. > Since ZFS is already wired for them, adding the basics is pretty > straightforward. I am not suggesting that they should replace the > current FreeBSD extended attributes. > > For those not familiar with them (I am not very familiar myself;-), > a Solaris style extended attribute is in a directory that hangs off > the file object and the entries in the directory (the attributes) can > be manipulated with open/read/write/lseek just like a regular file. > (They can be as large as a regular file, but there is no atomicity > guarantees.) > > At this point I have a couple of rough patches: > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part > > I have a simple test program to test the above: > https://people.freebsd.org/~rmacklem/xattrtest.c > > The VFS/ZFS patch defines: > O_NAMEDATTR - similar to O_XATTR, but uses the NFSv4 named > attribute terminology to avoid confusion with the other style of > FreeBSD extended attributes. > (The semantics probably are not exactly the same either. I do not > have a Solaris system to test on, so I am going from the NFSv4 > and Solaris doc. I have handy.) > --> You can look at xattrtest.c to see how this is used. > > I have not done any userland patches and am not sure what might be > needed? (I suspect a variant of pax/tar that knows about these is the > minimum?) > > I defined a couple of new v_irflag bits to indicate that a vnode is > a named attribute directory or a named attribute. That way, they > are still of v_type VDIR or VREG and can be handled by most > of the code without change. > > So, now for the questions... > 1 - Do you think this should be put in FreeBSD? > (If the consensus is no, I will try and maintain out of tree patches.) > 2 - If the answer for #1 is yes, what do you think is needed beyond > what I already have (which is a way to open the named attribute > directory and named attributes within that directory). How to remove the attribute? Is there a way to rename? Could you please (try) to explain the semantic, for instance, to add the same support for UFS? Might be tmpfs would be much easier as the target, if some non-trivial on-disk structures needs to be added to UFS, esp. due to SU. From nobody Sun Mar 9 13:17:30 2025 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 4Z9gYh70X7z5qHsZ; Sun, 09 Mar 2025 13:17:44 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z9gYh3yg2z3TLL; Sun, 09 Mar 2025 13:17:44 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5e673822f76so627418a12.2; Sun, 09 Mar 2025 06:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741526263; x=1742131063; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=W1ioT5nWr4eFfA5ejBiuzPPMROAe8DZuLtxPzfAOqfA=; b=MeQpWBK+a+8wsZJuwyOCuw0gxUu/vaQq197F5oa/LT6wusVtDXKQri6i5f5ZJLiadj gp/ycVm52O6ZjLzANkc2ayl/52iWzoINr5Ol6i9SZ9gFDI8Nazk89T2xWTK9ctV+LkfY Tl0cKp+JQqYdVgnQWm+hGeoqOLsIqBHmTOd4iw4nDPDgHfKcmopUlGXjVJCKBKS6S6/4 CAh25RL4j9OaDJ0dR0TnTbjDhIiQV4VYosnvDD0lrJP1CcCvNnN6FQRP9Kv8t6TMrpnA NjPDcNRkHwp3ahrqSDPTzxqwo+fihREHBkIrshcTebhU/fpGcQDXACZoRibXkG0Zeqwz YObg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741526263; x=1742131063; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=W1ioT5nWr4eFfA5ejBiuzPPMROAe8DZuLtxPzfAOqfA=; b=CBovxuP64R294Qvhybe3zuQRb28Nu9iN6JvdngDo0zYNILNetPg1C6n18iqJKlxMqT uQqTWkUi6mWxkzWEhrrrB/6zt6eN+dQZSEtHZMA/hKFJvsiX3ve0aacQCrBxApEb150l KWYS9lFx/uy4+Rn0EV+Ejl1K4loxH2ApJjaUVXFCzJNdzj3Y8wl7YQTeF8GKl4Bajf68 FIVFTYlV6FpPnoTXtmQT3Qp/EzTgHQ9AAF7eOwE8A/Gvx4Z+s6VdSrgQPRjdAEqEAaWS h++S3ZQ8aik9DrManUI6mxg5unkYbY0kDN4YodFu5szOlKv5PH0Iorniqo4yY6JJYAsR 6ItA== X-Forwarded-Encrypted: i=1; AJvYcCUYK9sGetsB1dOaiL3cirEL9ar0VKVp/2mN94xXXi76Fzx1LaYcOWgPF3Apl0qQNXRDyHM4LhBNCMEtFZsYJPw=@freebsd.org X-Gm-Message-State: AOJu0Yxhjq943b9HA3LqDnRmXUS451Pw23dEHiD9SYKChyLd8As0NMW1 lUkdEan91IFTgbiaRtMwixnfyxKGycmw/eJ3SNNt42aLBLi5hDtP7SFVPa6S2MiRmED5SM4yXHh nycv1HLKZvzYsea0+KHfO+xb1JcAVDhY= X-Gm-Gg: ASbGncvuQ86A8ekineFCvkS3egQDkwGWApN5kexLrr+9VH8nih1JnHjaVZ7a9U+tem+ VWgM0q2B5V3idnbNOS1Z/LL/sQzLHX4mNAhgN4WfdjUyOk2DHTRpkcsL3VgSh0PwlWeHRaC3KuR h8GV/N/DEAB7Nfi2lmtb6Kd21D0dd8u4SCGJPnVFOHelmQ3P9RX4g1lGoMn/A= X-Google-Smtp-Source: AGHT+IG/KhpUWjzGVOZeSt26IswwpRWes5aqzO8EuFru0l+d1UuZgPP5D4PSUqttcx77jRB4aDBBtIyd36C6l7kmriA= X-Received: by 2002:a05:6402:5c8:b0:5e5:bde4:755f with SMTP id 4fb4d7f45d1cf-5e5e22df03amr11733947a12.14.1741526262176; Sun, 09 Mar 2025 06:17:42 -0700 (PDT) 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 References: In-Reply-To: From: Rick Macklem Date: Sun, 9 Mar 2025 06:17:30 -0700 X-Gm-Features: AQ5f1JqhCSiLwuwtArtWhvngCuwGcFLzIix2K9TdWbLL8vAtk6-79cBU451EuNk Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Konstantin Belousov Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Z9gYh3yg2z3TLL X-Spamd-Bar: ---- On Sun, Mar 9, 2025 at 1:34=E2=80=AFAM Konstantin Belousov wrote: > > CAUTION: This email originated from outside of the University of Guelph. = Do not click links or open attachments unless you recognize the sender and = know the content is safe. If in doubt, forward suspicious emails to IThelp@= uoguelph.ca. > > > On Sat, Mar 08, 2025 at 03:02:14PM -0800, Rick Macklem wrote: > > First off, I cross posted because I don't think many read freebsd-arch@= . > > There seems to be a nice market for Solaris style extended attributes. > > Since ZFS is already wired for them, adding the basics is pretty > > straightforward. I am not suggesting that they should replace the > > current FreeBSD extended attributes. > > > > For those not familiar with them (I am not very familiar myself;-), > > a Solaris style extended attribute is in a directory that hangs off > > the file object and the entries in the directory (the attributes) can > > be manipulated with open/read/write/lseek just like a regular file. > > (They can be as large as a regular file, but there is no atomicity > > guarantees.) > > > > At this point I have a couple of rough patches: > > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part > > > > I have a simple test program to test the above: > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > The VFS/ZFS patch defines: > > O_NAMEDATTR - similar to O_XATTR, but uses the NFSv4 named > > attribute terminology to avoid confusion with the other style of > > FreeBSD extended attributes. > > (The semantics probably are not exactly the same either. I do not > > have a Solaris system to test on, so I am going from the NFSv4 > > and Solaris doc. I have handy.) > > --> You can look at xattrtest.c to see how this is used. > > > > I have not done any userland patches and am not sure what might be > > needed? (I suspect a variant of pax/tar that knows about these is the > > minimum?) > > > > I defined a couple of new v_irflag bits to indicate that a vnode is > > a named attribute directory or a named attribute. That way, they > > are still of v_type VDIR or VREG and can be handled by most > > of the code without change. > > > > So, now for the questions... > > 1 - Do you think this should be put in FreeBSD? > > (If the consensus is no, I will try and maintain out of tree patch= es.) > > 2 - If the answer for #1 is yes, what do you think is needed beyond > > what I already have (which is a way to open the named attribute > > directory and named attributes within that directory). > How to remove the attribute? Is there a way to rename? unlinkat(2) and renameat(2). If you look at the version of https://people.freebsd.org/~rmacklem/xattrtest.c you'll see them tested. What I still working on is restrictions for other syscalls, which shouldn't work on them. (I currently don't think mkdir/rmdir/mknod/symlink should work.) I also need to look at how/what checking ZFS does w.r.t. their access permissions. (I currently think access is defined by the parent file object?) > > Could you please (try) to explain the semantic, for instance, to add the > same support for UFS? Might be tmpfs would be much easier as the target, > if some non-trivial on-disk structures needs to be added to UFS, esp. due > to SU. Not sure there is any point in doing other file systems. Anyone who wants these can use ZFS. (After all, only UFS and ZFS support NFSv4 style ACLs, so we already have features that only some file systems support.) As far as semantics, the attributes are basically a directory with regular files in it, but referred to by the parent file object instead of a name in= the file system's name space. (ZFS does generate "." and ".." in the directory, but I haven't yet looked to see what those refer to?) rick > > From nobody Sun Mar 9 13:24:23 2025 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 4Z9gjd2T9hz5qHxX; Sun, 09 Mar 2025 13:24:37 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z9gjd0KsFz3Wyc; Sun, 09 Mar 2025 13:24:37 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5e095d47a25so6179390a12.0; Sun, 09 Mar 2025 06:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741526675; x=1742131475; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=w8SG8wP3JYr+Xt2pkT+KZorLZZv4Ku1BadGBl13rll0=; b=cZ3TrHyw4vqPYXIkVR8pdHpyPEg3ck+WFaH4JAYBYUKd3CsTkWIVtriAwp5J0f5cSS diR4KUqNxFoLalF8Kct4Dcjj8TquZ01NhchBRvOKJX1z1lzDFBwrJ6QUd68CRYFb9Sdg VpJ3XLLw+wzIxWP0cUCOao3KRFaU0KRbg2fCEzKRaKdmgkZqsGZYkuinxV5a4c2nqBzi d4iDBzmttxvyyeppDPWSGBgMxzNAe3YE/+fhYRb1CUBaQoBzJPLpHYnCxi6jK10s3UZp Of9gyPUJrcmokqQegSj0h48D7rNoZ8uN8bJMlutFlYZCJxwlt584AOAaz6lyZCsuxkSF MSZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741526675; x=1742131475; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=w8SG8wP3JYr+Xt2pkT+KZorLZZv4Ku1BadGBl13rll0=; b=Z+TRjV3VgtIz8quVD4cHg0CoD7AGTh9i1Gkge3Vb+w45BjLvIbvG6ooOxGnS5T6p3W xWhWg91Tor/HN7b6E+zmRaHsCsrgChS5SzKnljXWTv7+caDFVRM90p75Sjom4Fn4MmGo QvLYzhH3HEfEcuKczaiLnrQNvUzTfT0w6iYcBRJxdHCZ5EndmgAVXqGxJfzDYukk13fs N3P/awSAFcEaA1RWHCFeefY8KWCY2+TbLoCv6d4PLzt6pgjG8uNk0ZTf/TXxg+BgS8LY U2Ax83s5lrzEJJWgOd98Q5woQSh3DT6LEo+LBi3/bN91MyO/nTs8Sh2yBl1uxSWM9E5Y 5KXg== X-Forwarded-Encrypted: i=1; AJvYcCX+jr5RosoonW6yVZP4krbUx5905VtTP64z8HNROYKWANPW/2AON+B0Bze8NljY9OHrT08QnZzb8M1xMWQ=@freebsd.org, AJvYcCXhcHVjL/NlJtnAab2XOVEjCBlyUOL1tLXRpJhlFfbLHvv4b4/GKUFsCVI/vMQ4ptqlJc+VODMMnpn8aLp4qgfm@freebsd.org X-Gm-Message-State: AOJu0YznOoJ9HmsS49YmCc5Ln/vjpsEMJag4fYIU4YBmWYlGUQQiPwhQ xykOPJEtP0IwM6CrSJ1gi3bPpSq5Gm4FezO8BFyyP8ZLhx3rLPHrornH39n4T01+CTrkU3q/gLr daZHwTOrddDp1VnVEWhf/Z22vsg== X-Gm-Gg: ASbGnctWShw9paImHvi1QGtk3tE3oUd2hKLI6Q3/GpIg9aqrVI4WGjBUdX+P7EDuZdH iVTW4gu5aNSmug5tXR+Jv1JSXIKjft1Ltc9AESXSYmtweWozjHVBdoTFQqmqy6h5wHUua6SBlZl PTFBA+254kLOHi9cmpj1zpJVgsPP6DrQeUS5EPDZCt4dDZclGyzh7hymzNKPA= X-Google-Smtp-Source: AGHT+IF+alaNj5xwDtofXEVude+I+ZKHWsDKTiaXr1a9FsgbLS80ngD5aEa1EE5MKYzDy+zvKeZBUe3BT9xwpi0FruE= X-Received: by 2002:a05:6402:1ed3:b0:5e5:bb58:d6bd with SMTP id 4fb4d7f45d1cf-5e5e22bf4c8mr11259528a12.10.1741526674963; Sun, 09 Mar 2025 06:24:34 -0700 (PDT) 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 References: In-Reply-To: From: Rick Macklem Date: Sun, 9 Mar 2025 06:24:23 -0700 X-Gm-Features: AQ5f1JpcG4Uit3Q5gPQcDTtF9NVlU5RYK-fl95n5_JYkmq1NrpRGRWH8ILU5Eqo Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Andrew Walker Cc: Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Z9gjd0KsFz3Wyc X-Spamd-Bar: ---- On Sun, Mar 9, 2025 at 5:46=E2=80=AFAM Andrew Walker wrote: > > Out of curiosity, how are you preventing users from creating / writing > xattrs with the `system?` name prefix. In ZFS on FreeBSD IIRC this > prefix is used to determine whether the corresponding attribute when > accessed via the extattr interface is in the user or system > namespaces. A couple of comments... 1 - My current thinking would be a ZFS fs would be configured for one or the other (mixing them is weird as noted by the next comment), There is currently the xattr property that can be set to "dir" or "sa"= . 2 - I haven't looked at system space FreeBSD attributes yet (I will), but when mixing them, you can get two attributes with the same name showing up in the named attribute directory (the open gets the named attribute one). I haven't yet figured out how to get rid of the duplic= ate. 3 - I assume the patch could include code that excludes "system.xxx" names from the directory. (I'll do some testing.) > I vaguely recall some people may have patched the FreeBSD > samba server for instance so that it writes security information > related into the system namespace when samba is configured as a domain > controller so some care needs to be taken with namespaces. > > You may also need to potentially restrict ones with `security.` and > `trusted.` prefixes in case the ZFS data is replicated to Linux > systems (because those are privileged namespaces and it may introduce > a CVE). Thank for the info. I didn't know what Linux does. rick From nobody Sun Mar 9 23:19:48 2025 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 4Z9wwf51qqz5pQGg; Sun, 09 Mar 2025 23:20:02 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z9wwd50mwz3rx6; Sun, 09 Mar 2025 23:20:01 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5e6c18e2c7dso1002504a12.3; Sun, 09 Mar 2025 16:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741562400; x=1742167200; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ma4kbwchYIwuaZattNDuHHdn+zQPt6poElqhFzg2Sa8=; b=JwtBZ0zn9/YLZRbzwruCtZL6TWzOCglSRZrwGyyAJdjrnqL5SC2tgRCs34FgGCtwwy K6xMHBcKsH9tDO1y5yL9VP1K199k793IqVidmZQ/KGmmj13IsFeNhtraFb99Y204DYCg fPk8yMf6BaGJps1d3sepoJnEoKrnF5cEPdSyRJGh4vNIufbNod1374xrFo/WMeHwFcTa TuOq2xNCNZk5vqpRFDcrUQsJma0OOo1/bAbG4NKzckoASLSx7wljsgY3sITjiBG4L7DJ OvqQzPHuUMpgrrwmqD6wKCrhn3Fa3FkKBU535CzH+mL6hApGTrnLgFfv3CPGNa6gHJeO Trwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741562400; x=1742167200; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ma4kbwchYIwuaZattNDuHHdn+zQPt6poElqhFzg2Sa8=; b=PiIQln0oAIeb9q4ZEGVldZ99Z9slMg6i7C/2P6MA4OXKZLm5N3aWdJmmXfKQX078At 8CvBuo2PcvASFLi5Qo9v5+40RwOlPSnFYttt//w2zRmuQOoLUCcckQYljXkI/33IqIZr N6jf+t1wMMugd0rbyHmqTJWhCHL3jByx5oKaNhx8S1as/3VmjGVIsKFRw6ETbUJ8yG6I pb6Em5mlfEkZc263bJxknAqhNkPa5H3JmI+IMcKwG3d5K+P30BXBBmw0jDF1aTB6S5sL DemqxYBoQZGA+yys+s85liT5+y5EvFhxFrVu0ADJl+n0BVpAc/zqw9qaA4n3G+8ivJRq j2AQ== X-Forwarded-Encrypted: i=1; AJvYcCV6ApYHwAzgoYSIdGL9+VRL4y1oJwg4dR6yslupwc/DWISU+impVzrqjJvpgOIEKCJ3WrfneLfQcOQ/ZDU=@freebsd.org, AJvYcCWSkdLHY6/an9aFGEPo/YY/SV4+DY4BsQCyGQCCGY/4/b0qFdq/nc+OF7VgPzfEQlBLdhJnI7G0rQCoxvZ8GR/9@freebsd.org X-Gm-Message-State: AOJu0YwOPKOOeg2Nu1iZaV2CSF6uoNaXyagcz9hvFY14/K+5V2YqhrPz 7RuxbWI+DFX2b5jJ5znUsBmXrIu/3TZ51mMZUfD4tRrU9VegpD/2UwE7tASgrvCoqecOWheOGmH Cvoqb0g479zOBTfj0pKSJSNvhDw== X-Gm-Gg: ASbGncsFr9rb8op3PCb9TQJLq5Ou3BOV20hTcx6Ds+fNa0Ts9SRjgkhVrimtIaM5v58 TWr7edABawddWVV9kTYqYCZV9iXRPUfr2gw7K9P0qUISjlEzTvqFbD91lFdTKOptAceWCgBgfXJ 9IFoT4HiJr+OJUXGAVutxn0Kv8Z2OZB9sz5KKGJzTaAI9MWSKonYhjlPKi X-Google-Smtp-Source: AGHT+IF+hSKJZ8ukfUKBrD4lsTAgKdQCW2fTzApRxcRX13CmCxezAXKBbv1spsjIRrv8toBvdxzOFe5uk+Tsm2heVmg= X-Received: by 2002:a17:907:1b05:b0:ac1:e881:89a7 with SMTP id a640c23a62f3a-ac252737ef2mr1198400566b.6.1741562399493; Sun, 09 Mar 2025 16:19:59 -0700 (PDT) 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 References: In-Reply-To: From: Rick Macklem Date: Sun, 9 Mar 2025 16:19:48 -0700 X-Gm-Features: AQ5f1Jog-vsJQhxeI6DnaP62EhYriflet6A3_uzosbAqX9RkyeM029YOmEcV88c Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Andrew Walker Cc: Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Z9wwd50mwz3rx6 X-Spamd-Bar: ---- On Sun, Mar 9, 2025 at 11:35=E2=80=AFAM Andrew Walker wrote: > > On Sun, Mar 9, 2025 at 8:24=E2=80=AFAM Rick Macklem wrote: > > > > On Sun, Mar 9, 2025 at 5:46=E2=80=AFAM Andrew Walker wrote: > > > > > > Out of curiosity, how are you preventing users from creating / writin= g > > > xattrs with the `system?` name prefix. In ZFS on FreeBSD IIRC this > > > prefix is used to determine whether the corresponding attribute when > > > accessed via the extattr interface is in the user or system > > > namespaces. > > A couple of comments... > > 1 - My current thinking would be a ZFS fs would be configured for one > > or the other (mixing them is weird as noted by the next comment), > > There is currently the xattr property that can be set to "dir" or = "sa". > > 2 - I haven't looked at system space FreeBSD attributes yet (I will), > > but when mixing them, you can get two attributes with the same nam= e > > showing up in the named attribute directory (the open gets the nam= ed > > attribute one). I haven't yet figured out how to get rid of the du= plicate. > > 3 - I assume the patch could include code that excludes "system.xxx" na= mes > > from the directory. (I'll do some testing.) > > > > > I vaguely recall some people may have patched the FreeBSD > > > samba server for instance so that it writes security information > > > related into the system namespace when samba is configured as a domai= n > > > controller so some care needs to be taken with namespaces. > > > > > > You may also need to potentially restrict ones with `security.` and > > > `trusted.` prefixes in case the ZFS data is replicated to Linux > > > systems (because those are privileged namespaces and it may introduce > > > a CVE). > > Thank for the info. I didn't know what Linux does. > > > > rick > > Rick, one other thing to maybe consider is the size of attributes that > you allow to be written via this special open flag. You can > potentially write an attribute that when accessed via extattr will > cause malloc failure because it will basically go OOM. For example if > you create a 30 GiB attribute in the ZFS attr dir, then accessing via > extattr will require allocating a 30 GiB buffer. So you'd probably > want to limit to something like 2 GiB max per attribute (which is what > we do in TrueNAS). I assume you are referring to accessing the attribute via getextattr? One of the main reasons people want the Solaris kind (you seem to call them streams?) is avoiding the size limitations related to FreeBSD (or Linux) extended attributes. I do know that FreeBSD allows pretty large ones for ZFS, but the NFSv4 crowd is against accessing extended attributes (not via named attributes) larger than Kbytes. I'm surprised you allow 2Gbytes for TrueNAS, since the limit for the NFSv4 extension is around 1Mbyte. (RFC8276 specifies the NFSv4.2 extension for Linux style extended attributes and the getextattr reply needs to be in a single RPC, which is normally limited to about 1Mbyte. There is talk of increasing this to 8Mbytes, but I don't know if Linux has gotten there yet.) rick From nobody Sun Mar 9 23:26:46 2025 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 4Z9x4h0HQCz5pRQG; Sun, 09 Mar 2025 23:27:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z9x4g2m4qz3wdL; Sun, 09 Mar 2025 23:26:59 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5e614da8615so2766043a12.1; Sun, 09 Mar 2025 16:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741562818; x=1742167618; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CybKTf33ljwC05WeLUg/0H32ZNN0S4l7K4WAVPY5N+w=; b=mcer65kfaGzBVuOgLpTJmo9+pvE8UP0IOYjCTezdisfFEAtm1j2tYIVTcc29B2uJ99 Lnlw9CwDLUa8vMpmyRxLAx56RVje1dhleAET3AMPTIzuw/y1G1Zr7HztGo0FB7+y+a3B iJZwgrUgszREHRsteAAPucJkA33CI/QNJpQCRDEWzIf1rGjogVhJRcxLdf9LOGjaqrVT nJ36x3bw3zWzpDLbOboGLNe21R2I7wJjvI0gkDLSABRjTbv35gpT3s4dLS+DEpe1Es8P hvH7TjX5bmlZS18ltmEOJTmhSO0Jd15m8NjBnPTnlk4Gs/S/KJ3tZY9FD767fXcVKvVx nTKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741562818; x=1742167618; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CybKTf33ljwC05WeLUg/0H32ZNN0S4l7K4WAVPY5N+w=; b=upT3Iq+r7ii9Trca93rv965x4UFoFH7Jzb/KWSjo17tnF6T0OTO95ctk8P/4VloC2t f5bHDYuuSOZEfXQT1yoLgjUgq8u43jmYwy7K0b8lKi1Be2i/r1PtwAoW2EiGVgs4BsN/ DF9CN1dWb+I1XoKb5MO6HUIJzCU8Fz52sKw4YJsrXGTVFTs9lVYIs7+nd605NPsihcmc zM1og5dPUnQ0qz2ovfhKyoHg52awtXKy4WOGprXWcBRzmTBHP4e6pFEDuUbCCEudPmyd nZ6NSuo/eyPJwcmEGKjN2Ck8LSQTT/Q+Odqgzb60VC/cf4sL8rJ+YgqEogXt2IjdGBsh pDAg== X-Forwarded-Encrypted: i=1; AJvYcCUFVNKfta0ldhkV5y29ZUMaKVUb6QrQy63ZvGPeMhWZxRVDoqVFYZaLhcw/OyyarN4+ksDckKnpJcqbcP0X4Soq@freebsd.org, AJvYcCW1D3Zu+Mq/HO3oXEA8k3S8zSRmxchfx2xXHmSpLe4+xcdQoViQbJ7F3CUGCmMJxiqemIudgHetaw/Ss1o=@freebsd.org X-Gm-Message-State: AOJu0Yz19u187GcdyR42DX8pFg0z7UTCJz4px+YCzSb13fhvDGE0h/1M 8WCm/ripBdQN3T9jHCQAQ6hhu0Nr0mLpcKdqKWYel0yIUkXEVJ0/aBZsUsqzXd95k4m9qut2NPX h7ezn3d6KH8rYGbsqTTMrSfLj3g== X-Gm-Gg: ASbGncs4ytHfnGULUqQVemT6DEcLLiYsNK5RQoMzs6pS57No9zdtCTbFS/R232UuiZm yjNzybyvwYAV4GA1s00Ocv03TqXnY1KD1hii1iEfwFlFviS+G6DoaKZjLO/MRGcGgzGcXOx2C4r my6IKEOVW8msHpkdrYJGj+iyjzA7EeBDI+cf9OqKpDpMjUK4Jo/xs16nE6 X-Google-Smtp-Source: AGHT+IG3EYxcjaN8e479takrLgpHO1bOcV5CvvjIyaFcMvRQNXmY8Z8OPAXYPQO2NNnbjTvqnPhFCeqJzlNpSHtQ0aY= X-Received: by 2002:a05:6402:51ca:b0:5e5:4807:545f with SMTP id 4fb4d7f45d1cf-5e6150296a1mr8783686a12.12.1741562817568; Sun, 09 Mar 2025 16:26:57 -0700 (PDT) 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 References: In-Reply-To: From: Rick Macklem Date: Sun, 9 Mar 2025 16:26:46 -0700 X-Gm-Features: AQ5f1JrDX7kC6CGXWk_n5nd239FIRB0mGx6wG_uk2_eoQGY6H0vqp-V3-tOLes8 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Andrew Walker Cc: Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Z9x4g2m4qz3wdL X-Spamd-Bar: ---- On Sun, Mar 9, 2025 at 10:15=E2=80=AFAM Andrew Walker wrote: > > On Sun, Mar 9, 2025 at 8:24=E2=80=AFAM Rick Macklem wrote: > > > > On Sun, Mar 9, 2025 at 5:46=E2=80=AFAM Andrew Walker wrote: > > > > > > Out of curiosity, how are you preventing users from creating / writin= g > > > xattrs with the `system?` name prefix. In ZFS on FreeBSD IIRC this > > > prefix is used to determine whether the corresponding attribute when > > > accessed via the extattr interface is in the user or system > > > namespaces. > > A couple of comments... > > 1 - My current thinking would be a ZFS fs would be configured for one > > or the other (mixing them is weird as noted by the next comment), > > There is currently the xattr property that can be set to "dir" or = "sa". > > 2 - I haven't looked at system space FreeBSD attributes yet (I will), > > but when mixing them, you can get two attributes with the same nam= e > > showing up in the named attribute directory (the open gets the nam= ed > > attribute one). I haven't yet figured out how to get rid of the du= plicate. > > 3 - I assume the patch could include code that excludes "system.xxx" na= mes > > from the directory. (I'll do some testing.) > > This seems to be the NFS equivalent to SMB alternate data streams (or > MacOS resource forks). > > In my opinion it's better to keep them cleanly separated from xattrs / > extattrs (minimally in a different namespace). Solaris IIRC did this > with its SMB server (there xattrs IIRC were written to an SA and > streams were written using the attributes directory). When ZFS got > ported to FreeBSD / Linux, the attr dir got repurposed for extattr / > xattr, and then when performance problems were found (and problems > with expectation of atomicity with ops) they were shifted to SA / > dnode bonus block. > > I think it would be better (inside ZFS) to have a dedicated hard-coded > prefix for stuff written in the attr dir. For example: "stream.". This > can be used to delineate ones that should never be written to SA from > regular user namespace extattrs and regular user namespace ones. This > can correspond to adding a new extattr namespace in the FreeBSD VFS > (for examples "stream") that can be used to present these like we > separate out the prefix for system. > > This gives a few advantages: > 1. It prevents writing to restricted namespace > 2. prevents weird combinations of SA and file > > Unfortunately, this also means having to adjust userspace backup tools > (such as tar) and cp / mv to account for the new extattr namespace. If > the data gets replicated to a system that lacks this support, IIRC the > ZFS streams will appear in the user namespace with the string > "stream." prefixing the extattr. > > It's somewhat awkward, but generally trying to treat two different > sorts of thing (streams and xattrs) as if they're the same thing is > awkward. I do think that this may need to be socialized with upstream > openzfs. Sounds good. You obviously know a lot more about how ZFS does this than I do. Are you volunteering to write some code? (I can probably figure out how to prefix the named attributes with "stream.= " and keep them separate from the ones handled via the get/setextattr mechani= sm.) I think we agree that they need to be kept separate. Alternately, having a new setting for the "xattr" property that does not al= low the get/setextattr interface might be a simpler way to do it. (Without that setting, the named attributes would not be allowed.) And, yes, obviously the OpenZFS folk would need to be involved if/when a patch was headed that way. (I think they are fairly flexible so long as the patch only applies to the module/os/freebsd subtree.) rick > > Andrew