From nobody Mon Dec 9 10:09:14 2024 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 4Y6Hf70yYGz5g4np for ; Mon, 09 Dec 2024 10:09:35 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y6Hf66LVwz4jKx; Mon, 9 Dec 2024 10:09:34 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733738974; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/pXqoIFtZPQ4rcgMLR78koMNIdwZAsPa/S8wTH43Wqs=; b=uqll7pl0A9mVV87tDTUmEAu3nP2PgxOid7Kpv8QvH/UrmI5Y3vVdC27d4tjMskaf05UHfz tGKF+JO4GIswrLJXhYh4+VdeQC/jpx/dJT1RBPTjCKB2k5dPPhdq1ogjKp9/6TCmf+KfFu qdUNMuFiQwxMiMmw4kB9DY/o4AlSMJgaLnKjCgp/B5iE4jMtHVW5LCmNhc/3wW1qcTwosx nwfYj77+Snf2InEAAnyAQH29z7hgG4XoPw2XlgRg6nlPYvUSRqE1jDp9hb2zTUIPYo5RcX eBv6m6k7G2sZJCM9QsE/rnoBKerXGpyS3DA7DCyCBYXpQ116QD/nVhwyM12xYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733738974; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/pXqoIFtZPQ4rcgMLR78koMNIdwZAsPa/S8wTH43Wqs=; b=f96CNlXeFd+qAgZ4riOlvC68jdTF8rwxriM57tCV03bXHhNUHyAjWcqziaJt/Ly81IVMWr QOdkDjQlwGCJDTatWbA06iTiiKIKH8cgFnfBxZ2h8RQJk2F9W5Lpjpkku358GmoIDRW9Xw KJbPr9pIoYyMrdCgcR0uKNZzYWrwmmhsepuoVoOBipxY8rx7dEaVMmv9FX0KsK4CtvUETd 7VM1GLLBPwUIjKFuyc2YoBglc5OA1Zg0OICWxgUYKIC/9Y261wv9r9wsgvT2rbRLQwjXz+ AWSrqGmbllp5sPTrQsD2LtdaLXFSw1HrtFPdCoQOs2bLVVGIAsX1MgQWThYSdQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733738974; a=rsa-sha256; cv=none; b=QfBRp3gFZBGxOQmw24B5tVdYdrrsCOnAlQKtzmiO4LY4suCA7DNuooVzk4kU+0+Gg2Wzqc iTkGuzOf95i76976vQp4lSbzaCFAZAaov6T1IHSMhophREf0sCNaE+gZXX6fUScDxklunn fhXkRtIaBNUN5VIRZncywy2x7SPLAKjK+qH49e1H10b9GpojENMwsfEoby7wYfXKpJxN/B C4T7QnQoQnTOr3nA4fWs6pwRnLKyGP0gi/YmlMJF7+RQlhJac64vMVI07Bze8tGwcA46Ar WLuts2vNgPK1EAD94+kfSUeUAnhuo/c0lveMMKTxOriEQrbX17Er6c08YguZJw== Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "E5" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Y6Hf652XmzR2l; Mon, 9 Dec 2024 10:09:34 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (unknown [217.73.28.193]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id C268761F8B; Mon, 09 Dec 2024 11:09:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 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 \(3776.700.51.11.1\)) Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out From: Juraj Lutter In-Reply-To: Date: Mon, 9 Dec 2024 11:09:14 +0100 Cc: FreeBSD User , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> To: Ronald Klop X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,TW_PF autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on ns2.wilbury.net > On 8 Dec 2024, at 20:30, Ronald Klop wrote: >=20 > Hi, >=20 > I can reproduce your error. >=20 > A cronjob which does a scp to another server didn't work anymore. When = I go back to the previous BE it works fine again. > Ipfw disable firewall also makes the scp work. >=20 > Scp also seems to work fine if I replace the statefull firewall rules = with stateless "pass all from any to any". Have you tried to allow ICMP in both directions explicitly, in case of = stateful rules? =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Mon Dec 9 12:43:14 2024 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 4Y6M3f3LLhz5gGHv for ; Mon, 09 Dec 2024 12:43:26 +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 4Y6M3d1Tvzz44gl; Mon, 9 Dec 2024 12:43:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4B9ChE9A042288; Mon, 9 Dec 2024 21:43:15 +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=1733748196; bh=DrtVfL/6sVwphHX9yii5L6eEnTTBJQlEBUXAUWzGI+w=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=E+QtPpZKPquRiDPqnYkf3my9/9As0GXMHeV+HDJ5vivZWtjGHTmAklnMzlPKTkdU2 iH3vrgFdi2ilgaE5iqLeACIGqOJ8vR2eCrj6L6PPX/Nla1welqEFI36CjniJqwNHfo jVtfu6vcisKlseUNshKCrNQwwPpCIWFPewpRmk+w= Date: Mon, 9 Dec 2024 21:43:14 +0900 From: Tomoaki AOKI To: Juraj Lutter Cc: Ronald Klop , FreeBSD User , freebsd-current@freebsd.org Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-Id: <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> In-Reply-To: <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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: 4Y6M3d1Tvzz44gl X-Spamd-Bar: ---- On Mon, 9 Dec 2024 11:09:14 +0100 Juraj Lutter wrote: > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > Hi, > > > > I can reproduce your error. > > > > A cronjob which does a scp to another server didn't work anymore. When I go back to the previous BE it works fine again. > > Ipfw disable firewall also makes the scp work. > > > > Scp also seems to work fine if I replace the statefull firewall rules with stateless "pass all from any to any". > > Have you tried to allow ICMP in both directions explicitly, in case of stateful rules? > > — > Juraj Lutter > otis@FreeBSD.org I think would usually work for clients with some limited services exposed to outside. IIUC, it basically allow all sessions from inside and allows limited serivices configured with variables via /etc/rc.conf[.local]. Some notes. *Last actual changes in /usr/src/libexec/rc/rc.firewall was at Jul.23, 2020. https://github.com/freebsd/freebsd-src/commits/main/libexec/rc/rc.firewall [cgit.freebsd.org seems to be unstable now.] *Variable firewall_logif currently does not exist. *Don't you need allowing 22/UDP, too, like below? firewall_myservices="22/tcp 22/udp" And if you're creating kernel config from scratch (such as copying from GENERIC at some point and editing it), it's no longer adviced. It's not robust for changes in GENERIC. Instead, include GENERIC and describe changes you want. An example (one of my test kernel config for a bit old stable). ===== Start example ===== include GENERIC ident TEST15 nooptions DDB nooptions GDB nooptions INVARIANTS nooptions INVARIANT_SUPPORT nooptions WITNESS nooptions WITNESS_SKIPSPIN nooptions DEADLKRES options CAM_IOSCHED_DYNAMIC device sg ===== End example ===== -- Tomoaki AOKI From nobody Mon Dec 9 16:45:14 2024 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 4Y6SRQ718rz5gWVZ for ; Mon, 09 Dec 2024 16:45:54 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4Y6SRQ4TCyz4Zq1; Mon, 9 Dec 2024 16:45:54 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 70852240ECA; Mon, 9 Dec 2024 17:45:45 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 9D0E3240031; Mon, 9 Dec 2024 17:45:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1733762743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SHAktIbUjlbwPH9MGnMv5/xih/AEEuwmLlfmlnNVmwk=; b=i/jl5fQPcB9oK/GoHvJ+mUQeUIWS92MBq2VdbsxWNFsaCT+57v4aMcH+02haoOFvFES1ly wqLdyH8z7sICmK69aHGpjxoGx3h+xoXM2gu1pesUNjgxyE9YAFCdej/+1C/YPvZvxk0vXO 1astymLT8kzcXmpsnMaDWl78B1JlXh6A8SOyp862ej6hGI8I5USijSS3QrE7GyM084pSmR oTCbkbum+REDQxcZQ68qpiTGi/5UpIKmzzdbz/f4p7x8iCOd4A2xXw+yEM29QW1oJYBva0 yJ+uYkM3w0yNj2DDPRQVONWBqWSQz6XRo3fn7vVg4Aszc54GsqZ46dSsBT1fJA== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-183-031-236.77.183.pool.telefonica.de [77.183.31.236]) (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) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 4FB8A24001B; Mon, 9 Dec 2024 17:45:42 +0100 (CET) Date: Mon, 9 Dec 2024 17:45:14 +0100 From: FreeBSD User To: Tomoaki AOKI Cc: Juraj Lutter , Ronald Klop , freebsd-current@freebsd.org Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-ID: <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> Organization: walstatt-de.de 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: quoted-printable X-Rspamd-UID: 4f33e4 X-Rspamd-UID: 1d2b26 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:25394, ipnet:2001:1640::/32, country:DE] X-Rspamd-Queue-Id: 4Y6SRQ4TCyz4Zq1 X-Spamd-Bar: ---- Am Mon, 9 Dec 2024 21:43:14 +0900 Tomoaki AOKI schrieb: > On Mon, 9 Dec 2024 11:09:14 +0100 > Juraj Lutter wrote: >=20 > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > >=20 > > > Hi, > > >=20 > > > I can reproduce your error. > > >=20 > > > A cronjob which does a scp to another server didn't work anymore. Whe= n I go back to the > > > previous BE it works fine again. Ipfw disable firewall also makes the= scp work. > > >=20 > > > Scp also seems to work fine if I replace the statefull firewall rules= with stateless > > > "pass all from any to any". =20 > >=20 > > Have you tried to allow ICMP in both directions explicitly, in case of = stateful rules? > >=20 > > =E2=80=94 > > Juraj Lutter > > otis@FreeBSD.org =20 >=20 > I think would usually work for clients with some limited services > exposed to outside. IIUC, it basically allow all sessions from inside > and allows limited serivices configured with variables > via /etc/rc.conf[.local]. >=20 > Some notes. > *Last actual changes in /usr/src/libexec/rc/rc.firewall was at > Jul.23, 2020. > https://github.com/freebsd/freebsd-src/commits/main/libexec/rc/rc.fi= rewall > [cgit.freebsd.org seems to be unstable now.] >=20 > *Variable firewall_logif currently does not exist. >=20 > *Don't you need allowing 22/UDP, too, like below? > firewall_myservices=3D"22/tcp 22/udp" >=20 > And if you're creating kernel config from scratch (such as copying from > GENERIC at some point and editing it), it's no longer adviced. > It's not robust for changes in GENERIC. >=20 > Instead, include GENERIC and describe changes you want. >=20 > An example (one of my test kernel config for a bit old stable). >=20 > =3D=3D=3D=3D=3D Start example =3D=3D=3D=3D=3D > =20 > include GENERIC >=20 > ident TEST15 >=20 > nooptions DDB > nooptions GDB=20 > nooptions INVARIANTS > nooptions INVARIANT_SUPPORT > nooptions WITNESS > nooptions WITNESS_SKIPSPIN > nooptions DEADLKRES >=20 > options CAM_IOSCHED_DYNAMIC >=20 > device sg >=20 > =3D=3D=3D=3D=3D End example =3D=3D=3D=3D=3D >=20 >=20 Thank you very much for the advice - but I do this kind of confugration now= since, I guess, 2020 or 2021. consider the host's kernel name to be "THOR", then /etc/src.c= onf has lines KERNCONF=3D THOR KERNCONFDIR=3D /etc/config/amd64/kernel_conf/ and the target's config file "/etc/config/amd64/kernel_conf/THOR" contains include GENERIC include NODEVICE-THOR include "std.nodebug" include ADDON-THOR This concept isn't bullet proof, since I had trouble with the relatively re= cent introduced "std.nodebug". As you mentioned, NODEVICE contains ALL "nooptions" and "nod= evice" and ADDON contains some extra options not contained in GENERIC. GENERIC is a symbolic= link to the original GENERIC in the appropriate sys folder. Thanks to FReeBSD's sophisticated kernel configuration, this hierarchical s= cheme prevents most accidents triggered by significant GENERIC changes. Do you suspect a misconfiguration due to uncaught changes in GENERIC?=20 --=20 O. Hartmann From nobody Mon Dec 9 17:27:10 2024 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 4Y6TMB529wz5gYTS for ; Mon, 09 Dec 2024 17:27:18 +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 4Y6TMB0Tnmz4lBw; Mon, 9 Dec 2024 17:27:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4B9HRAKp094276; Tue, 10 Dec 2024 02:27:11 +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=1733765232; bh=en2x43Fk32aVg15ZU2rEscl5LmMO1xFkDr9MQSHLqfs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=oirJ+u08GVJIFZgQ/w1DowLayd93c+mJLzm9XwICdWWMWnkPen5/SZzYjQuey+q1H Y815UbVpADSODsXRd5Yy7A9CdFUyIj41196dJ5GRrKNuzMwaWb9UCYb0INDth8RUoF INbZWLvT7udDXmVToxpMX2dz4EWMdzBT7HEINn5g= Date: Tue, 10 Dec 2024 02:27:10 +0900 From: Tomoaki AOKI To: FreeBSD User Cc: Juraj Lutter , Ronald Klop , freebsd-current@freebsd.org Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-Id: <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> In-Reply-To: <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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: 4Y6TMB0Tnmz4lBw X-Spamd-Bar: ---- On Mon, 9 Dec 2024 17:45:14 +0100 FreeBSD User wrote: > Am Mon, 9 Dec 2024 21:43:14 +0900 > Tomoaki AOKI schrieb: > > > On Mon, 9 Dec 2024 11:09:14 +0100 > > Juraj Lutter wrote: > > > > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > > > > > Hi, > > > > > > > > I can reproduce your error. > > > > > > > > A cronjob which does a scp to another server didn't work anymore. When I go back to the > > > > previous BE it works fine again. Ipfw disable firewall also makes the scp work. > > > > > > > > Scp also seems to work fine if I replace the statefull firewall rules with stateless > > > > "pass all from any to any". > > > > > > Have you tried to allow ICMP in both directions explicitly, in case of stateful rules? > > > > > > — > > > Juraj Lutter > > > otis@FreeBSD.org > > > > I think would usually work for clients with some limited services > > exposed to outside. IIUC, it basically allow all sessions from inside > > and allows limited serivices configured with variables > > via /etc/rc.conf[.local]. > > > > Some notes. > > *Last actual changes in /usr/src/libexec/rc/rc.firewall was at > > Jul.23, 2020. > > https://github.com/freebsd/freebsd-src/commits/main/libexec/rc/rc.firewall > > [cgit.freebsd.org seems to be unstable now.] > > > > *Variable firewall_logif currently does not exist. > > > > *Don't you need allowing 22/UDP, too, like below? > > firewall_myservices="22/tcp 22/udp" > > > > And if you're creating kernel config from scratch (such as copying from > > GENERIC at some point and editing it), it's no longer adviced. > > It's not robust for changes in GENERIC. > > > > Instead, include GENERIC and describe changes you want. > > > > An example (one of my test kernel config for a bit old stable). > > > > ===== Start example ===== > > > > include GENERIC > > > > ident TEST15 > > > > nooptions DDB > > nooptions GDB > > nooptions INVARIANTS > > nooptions INVARIANT_SUPPORT > > nooptions WITNESS > > nooptions WITNESS_SKIPSPIN > > nooptions DEADLKRES > > > > options CAM_IOSCHED_DYNAMIC > > > > device sg > > > > ===== End example ===== > > > > > > Thank you very much for the advice - but I do this kind of confugration now since, I guess, > 2020 or 2021. consider the host's kernel name to be "THOR", then /etc/src.conf has lines > > KERNCONF= THOR > KERNCONFDIR= /etc/config/amd64/kernel_conf/ > > and the target's config file "/etc/config/amd64/kernel_conf/THOR" contains > > include GENERIC > include NODEVICE-THOR > include "std.nodebug" > include ADDON-THOR > > This concept isn't bullet proof, since I had trouble with the relatively recent introduced > "std.nodebug". As you mentioned, NODEVICE contains ALL "nooptions" and "nodevice" and ADDON > contains some extra options not contained in GENERIC. GENERIC is a symbolic link to the > original GENERIC in the appropriate sys folder. > > Thanks to FReeBSD's sophisticated kernel configuration, this hierarchical scheme prevents most > accidents triggered by significant GENERIC changes. > > Do you suspect a misconfiguration due to uncaught changes in GENERIC? > > -- > O. Hartmann Just a possibility. Not sure when it was and which firewall (ipfw? pf? or else?) it was, but IIRC, I've seen some excessive configs to enable non-default options/devices built into kernel caused unwanted changes in default before when I was searching unrelated things of FreeBSD. And why I've mentioned about kernel configuration file is because I've bitten by the changes in GENERIC before. In contrast with rc.firewall, kernel side of ipfw received some changes this year. https://cgit.freebsd.org/src/log/sys/netpfil/ipfw So anything committed after your previous build could cause the issue. Sorry, I have not enough time to dig into deeper. Other points to worth checking would be: https://cgit.freebsd.org/src/log/sys/netgraph https://cgit.freebsd.org/src/tree/sys/net The latter should be limited with bpf related (otherwise too bload). net and netinet would be too bload, too. Bloader codes should be checked when narrow and close codes are analysed to be NOT affecting. Otherwise, there would be too much confusions. -- Tomoaki AOKI From nobody Mon Dec 9 18:19:20 2024 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 4Y6VWt1lFvz5gcqY for ; Mon, 09 Dec 2024 18:19:54 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4Y6VWs6hWlz4qsw; Mon, 9 Dec 2024 18:19:53 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 9959A240EC1; Mon, 9 Dec 2024 19:19:50 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 37E48240031; Mon, 9 Dec 2024 19:19:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1733768388; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=icX7PDuqYEe8KcGivgbwOte+2csDVMnhp5xcS7tMKfE=; b=EEtamF7mW0pflxBnfULlHw4P90oKGj6nJpLYejxiyblqZo3iJgW1Pf/QIT8zZbUi952NBW pNwZt3790Y0KZkZDsP8Qig32JwFi0KxuoEaxVCbvFrGZEtebkOwduUtVpFWY8VLoQF+Lvw ZWCWFSMWaf5zyJdbfGrEHgiaPx2PpVxWx+QFSxSBtp0R5udtXCcSG6hkcqP/l6OwnMy4AS YnyrGJqUztxaVZl5NHG0YArll9Szq4AM67ehKXkuNC/gMkGpilI2PM7wvjf4oLdCe9mhcU wYAbaGgNR2MLAlnBUN5hIDgj5QI0jNw4Ca6yjd8WdgSiXZP+qh34MZVaHR2ezg== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-183-031-236.77.183.pool.telefonica.de [77.183.31.236]) (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) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id E20ED24001B; Mon, 9 Dec 2024 19:19:47 +0100 (CET) Date: Mon, 9 Dec 2024 19:19:20 +0100 From: FreeBSD User To: Tomoaki AOKI Cc: Juraj Lutter , Ronald Klop , freebsd-current@freebsd.org Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-ID: <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> Organization: walstatt-de.de 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: quoted-printable X-Rspamd-UID: 5c6c10 X-Rspamd-UID: 146114 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:25394, ipnet:2001:1640::/32, country:DE] X-Rspamd-Queue-Id: 4Y6VWs6hWlz4qsw X-Spamd-Bar: ---- Am Tue, 10 Dec 2024 02:27:10 +0900 Tomoaki AOKI schrieb: My apology for topposting. The host I first realised the problems is updated on an almost daily basis = and the issue reported started last weekend. A possible candidate could be https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=3D0fc7bdc978366abb4= 351b0b76b50a5848cc5d982 since the other, younger, seem innocent. I try to revert the patch mentione= d and see ... > On Mon, 9 Dec 2024 17:45:14 +0100 > FreeBSD User wrote: >=20 > > Am Mon, 9 Dec 2024 21:43:14 +0900 > > Tomoaki AOKI schrieb: > > =20 > > > On Mon, 9 Dec 2024 11:09:14 +0100 > > > Juraj Lutter wrote: > > > =20 > > > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > I can reproduce your error. > > > > >=20 > > > > > A cronjob which does a scp to another server didn't work anymore.= When I go back to > > > > > the previous BE it works fine again. Ipfw disable firewall also m= akes the scp work. > > > > >=20 > > > > > Scp also seems to work fine if I replace the statefull firewall r= ules with stateless > > > > > "pass all from any to any". =20 > > > >=20 > > > > Have you tried to allow ICMP in both directions explicitly, in case= of stateful rules? > > > >=20 > > > > =E2=80=94 > > > > Juraj Lutter > > > > otis@FreeBSD.org =20 > > >=20 > > > I think would usually work for clients with some limited services > > > exposed to outside. IIUC, it basically allow all sessions from inside > > > and allows limited serivices configured with variables > > > via /etc/rc.conf[.local]. > > >=20 > > > Some notes. > > > *Last actual changes in /usr/src/libexec/rc/rc.firewall was at > > > Jul.23, 2020. > > > https://github.com/freebsd/freebsd-src/commits/main/libexec/rc/r= c.firewall > > > [cgit.freebsd.org seems to be unstable now.] > > >=20 > > > *Variable firewall_logif currently does not exist. > > >=20 > > > *Don't you need allowing 22/UDP, too, like below? > > > firewall_myservices=3D"22/tcp 22/udp" > > >=20 > > > And if you're creating kernel config from scratch (such as copying fr= om > > > GENERIC at some point and editing it), it's no longer adviced. > > > It's not robust for changes in GENERIC. > > >=20 > > > Instead, include GENERIC and describe changes you want. > > >=20 > > > An example (one of my test kernel config for a bit old stable). > > >=20 > > > =3D=3D=3D=3D=3D Start example =3D=3D=3D=3D=3D > > > =20 > > > include GENERIC > > >=20 > > > ident TEST15 > > >=20 > > > nooptions DDB > > > nooptions GDB=20 > > > nooptions INVARIANTS > > > nooptions INVARIANT_SUPPORT > > > nooptions WITNESS > > > nooptions WITNESS_SKIPSPIN > > > nooptions DEADLKRES > > >=20 > > > options CAM_IOSCHED_DYNAMIC > > >=20 > > > device sg > > >=20 > > > =3D=3D=3D=3D=3D End example =3D=3D=3D=3D=3D > > >=20 > > > =20 > >=20 > > Thank you very much for the advice - but I do this kind of confugration= now since, I guess, > > 2020 or 2021. consider the host's kernel name to be "THOR", then /etc/s= rc.conf has lines > >=20 > > KERNCONF=3D THOR > > KERNCONFDIR=3D /etc/config/amd64/kernel_conf/ > >=20 > > and the target's config file "/etc/config/amd64/kernel_conf/THOR" conta= ins > >=20 > > include GENERIC > > include NODEVICE-THOR > > include "std.nodebug" > > include ADDON-THOR > >=20 > > This concept isn't bullet proof, since I had trouble with the relativel= y recent introduced > > "std.nodebug". As you mentioned, NODEVICE contains ALL "nooptions" and = "nodevice" and ADDON > > contains some extra options not contained in GENERIC. GENERIC is a symb= olic link to the > > original GENERIC in the appropriate sys folder. > >=20 > > Thanks to FReeBSD's sophisticated kernel configuration, this hierarchic= al scheme prevents > > most accidents triggered by significant GENERIC changes. > >=20 > > Do you suspect a misconfiguration due to uncaught changes in GENERIC?=20 > >=20 > > --=20 > > O. Hartmann =20 >=20 > Just a possibility. Not sure when it was and which firewall (ipfw? pf? > or else?) it was, but IIRC, I've seen some excessive configs to enable > non-default options/devices built into kernel caused unwanted changes > in default before when I was searching unrelated things of FreeBSD. >=20 > And why I've mentioned about kernel configuration file is because I've > bitten by the changes in GENERIC before. >=20 > In contrast with rc.firewall, kernel side of ipfw received some changes > this year. >=20 > https://cgit.freebsd.org/src/log/sys/netpfil/ipfw >=20 > So anything committed after your previous build could cause the issue. > Sorry, I have not enough time to dig into deeper. Other points to worth > checking would be: >=20 > https://cgit.freebsd.org/src/log/sys/netgraph >=20 > https://cgit.freebsd.org/src/tree/sys/net >=20 > The latter should be limited with bpf related (otherwise too bload). > net and netinet would be too bload, too. Bloader codes should be > checked when narrow and close codes are analysed to be NOT affecting. > Otherwise, there would be too much confusions. >=20 --=20 O. Hartmann From nobody Mon Dec 9 18:24:27 2024 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 4Y6VdP2T2Zz5gd7n for ; Mon, 09 Dec 2024 18:24:41 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y6VdP1b1Vz4sXx; Mon, 9 Dec 2024 18:24:41 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733768681; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ujnubAu/kTHH9oaNLcSAW8LmyI9KY++Hzm43lCkgnkw=; b=fDe6h/CwfIj7rUOTlGZpe8OoLhJNnirDDtQL6cnxdD0z2y/eu5kRL7h4nIg64NZiItGSy+ wctM0Qwq1ktF3xHgMoG2qcIzoW9QUt939oVoi/BOW7a1r5iqzsY32M/2IKu5G0xlq24O5s QnXAkSEIIsOmJMbWFnJUdp/YmuwLQ+JxAklaRf5T0IyBwS2I0iwH8phte2FLL4yv8kgoum 7Ro9qA5/YNCQzw0Lmiw1rO/cxYEGTqFJ1O1r/wYXGVQdXSbFq8sElOSaecOLSjWLED1ZgT 1fx9f9FchMuZ4Vq92YcMExiN4s/uQLYmMt3sq2YpL3c1isSx/1tR+gOEWk+x8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733768681; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ujnubAu/kTHH9oaNLcSAW8LmyI9KY++Hzm43lCkgnkw=; b=VSXCKVOqs54YLlGCGYMO0eDXwzsB0TXDZhBrGRe2HbJUPYV7u6TO6FhJQ0yL4UPtPJ+VBR lofBnE+04m67YdJVzAkGSLrkNhjgcLznXO9tWOZ4vOjzGowPxaxLu54m0NREgE2qpindnQ bB3e7939KoC8l7AU//PzFgNPLUh2Y2YQ9m5x8j7FCHO087sIhbI6k4fsWvC5YTP3j7BG73 FV8Mx9SWb8ITaV/ghLbZNN4K/gg4ifxTgG0IUVB6I2Y4IZe2G8LK7miKL4AWOgrS0HHm/A RK9gGSKr6gOy+QuYvhyv8aXSLzz9gIZ/PIsrq2Sff0+2cwtJ7tvZNUTRcqX+ig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733768681; a=rsa-sha256; cv=none; b=PesZwfqOUYh1mNINX8UwxaWd6HtUIqMEmb6GTANZD0te3T91l31lEDx2uM/+kAJrONmy+J SQvnJ/11yYDznbkNgpHK81fUMVKHHmkk7MBa3/z9gfESMbgzJLaHEKvpeJUV6mSlZx1eL+ p9oXYOObHRoqmijQeMweZGjRAj8py9plqePFWDlEilw4aKLQ3AU0QnY/geyLkNxqX47BMi p/evlNKpPH79sKmmJJOQQeiz4hAP4UV1PR3vowGk44v+ILMk8bRACvYN3nXN9jaLUsdrzf XkNOMA6d+9CLQLDYurewIFCAkXrdbwg7pKtYY0P/Qf7SeANUC9sxJE9zQNFY1A== Received: from ns2.wilbury.net (ns2.wilbury.net [92.60.51.55]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "E5" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Y6VdP0JsrzbFf; Mon, 9 Dec 2024 18:24:41 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (gw-t.owhome.net [87.197.133.183]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 1BEB061F8D; Mon, 09 Dec 2024 19:24:38 +0100 (CET) Content-Type: text/plain; charset=utf-8 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 \(3776.700.51.11.1\)) Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out From: Juraj Lutter In-Reply-To: <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> Date: Mon, 9 Dec 2024 19:24:27 +0100 Cc: Tomoaki AOKI , Ronald Klop , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B720B82-09EF-4208-B814-B6BD75FC2F0E@FreeBSD.org> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> To: FreeBSD User X-Mailer: Apple Mail (2.3776.700.51.11.1) 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 ns2.wilbury.net > On 9 Dec 2024, at 19:19, FreeBSD User wrote: >=20 > Am Tue, 10 Dec 2024 02:27:10 +0900 > Tomoaki AOKI schrieb: >=20 > My apology for topposting. >=20 > The host I first realised the problems is updated on an almost daily = basis and the issue > reported started last weekend. >=20 > A possible candidate could be >=20 > = https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=3D0fc7bdc978366abb= 4351b0b76b50a5848cc5d982 >=20 > since the other, younger, seem innocent. I try to revert the patch = mentioned and see ... Try to only revert the ip_fw_nat.c part at first. =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Wed Dec 11 13:25:02 2024 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 4Y7btq0y54z5gwBw for ; Wed, 11 Dec 2024 13:25:07 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y7btq09TKz559t; Wed, 11 Dec 2024 13:25:07 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733923507; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qSxyd8Is7x0p5/m5bSL6GR4iXQ73E7f8xDqph5sjTOI=; b=DefbWdMLGuijp4u8fzmaLOeswVmMEMXr0zs31ePZsJaXPz3OETSFJsstIsJ+gdzSpWcooN IHsPP1i2e4OG6oQehtAIu6mJgKIVNlXY/BUFcuIQWKUoJI5yn/qNRKBUB+51lJr9sc4G99 Lk0tnw6Nd64As39yX89QAhxpByvvboYymGcKFoNyonJh9/UM4gEY67Qvy28Zc09AUJgDwo IPB4FiAck4lUY/u7uMjD+dMWTxWoO6MNRvqt/FmqvQ88EUVkCcZjdN4Sw/bcRazSyAXSft mp31dpuEeyMk0QLcNkcfarzmjqIaBpZrbQf7GHarjB71Oivnh/HsWdNMowfqRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733923507; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qSxyd8Is7x0p5/m5bSL6GR4iXQ73E7f8xDqph5sjTOI=; b=QMvnVoAzxpLNpUIZ0SJZIZcCxaaZXb6CmL8tBKT9XFnEK8mKxAG3wCbHfebkpU68qTdz1R XJRCOi9zOuZFHVoi9bve/BMSrQbYOqv+d6yxrHu0Uw+1tGHqhithdj7wyooPFdyp7dLd8E wbUxTzII3FVdgqv9mSR7dLxkpynjLDqqnOHYYmNwsG4AC0PiS9hZYtOzQpN/YWx2dRU+Nu 6g/OfNNYcU48djD0+8DmXfCOmzORF4D1kAjHxB1C9+MzIrT1yln16ja9VxyKWjYI+ue6x/ KvC33yFNB2D0g6BONLS9WZAFo4HBAWaE42TeB8wfcdNdjsSbyj3oxCXysjLjyA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733923507; a=rsa-sha256; cv=none; b=yNVlpXtKxJcF+N4xkoZjCEVq+daMsIbmU/VZAOj2IWDifwGuF372UDRnRzULOHq9Mj8Chs qUuwSzVZ5ATVuOqk1hBuBTLi0F4i6CUwahEdkKp3Vtbc83RzRbv6qevFX9+L1dLUDfI8Br VriYOM1YNtJnoVPbeBZameQg73o08YYJM1kvx5RL+Yi4cNecqpLsRu1Ts4sMDLc3+JgDAi ukLwVjA/1TzzbJv8eo8bOu24T233c+jKddoqcV0JdYY98+oaESxdIUSPPdU5P0B8jcR1RR yiI4Ir0D6L7ZLuCpSyPUGd1AtwHGLRmKvooTRlpEZoSHRrf9xPLyn4Zg1Ww0Ig== Received: from [IPV6:2001:1c00:2709:2010:c129:38:42e1:4c97] (2001-1c00-2709-2010-c129-0038-42e1-4c97.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:2709:2010:c129:38:42e1:4c97]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Y7btp1qJ8zXRb; Wed, 11 Dec 2024 13:25:06 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: Date: Wed, 11 Dec 2024 14:25:02 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out To: Juraj Lutter , FreeBSD User Cc: Tomoaki AOKI , freebsd-current@freebsd.org, Richard Scheffenegger References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> <6B720B82-09EF-4208-B814-B6BD75FC2F0E@FreeBSD.org> Content-Language: en-US From: Ronald Klop In-Reply-To: <6B720B82-09EF-4208-B814-B6BD75FC2F0E@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Op 09-12-2024 om 19:24 schreef Juraj Lutter: > > >> On 9 Dec 2024, at 19:19, FreeBSD User wrote: >> >> Am Tue, 10 Dec 2024 02:27:10 +0900 >> Tomoaki AOKI schrieb: >> >> My apology for topposting. >> >> The host I first realised the problems is updated on an almost daily basis and the issue >> reported started last weekend. >> >> A possible candidate could be >> >> https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=0fc7bdc978366abb4351b0b76b50a5848cc5d982 >> >> since the other, younger, seem innocent. I try to revert the patch mentioned and see ... > > Try to only revert the ip_fw_nat.c part at first. > > — > Juraj Lutter > otis@FreeBSD.org > Hi, I did a bisect of commits and my finding is that commit 347dd053 on 2024-11-29 is the cause. "tcp: add TH_AE capabilities to ppp and pf" https://github.com/freebsd/freebsd-src/commit/347dd0539f3a75fdf2128dd4620ca99e96f311e9 The commit before (0fc7bdc978) works fine. I cc'ed the author of the commit. (for context: start of the thread is here: https://lists.freebsd.org/archives/freebsd-current/2024-December/006778.html, it looks like the commit breaks a statefull ipfw firewall) Regards, Ronald. From nobody Wed Dec 11 16:20:40 2024 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 4Y7gp14HWhz5g7j9 for ; Wed, 11 Dec 2024 16:21:13 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4Y7gp12CJ4z47g0; Wed, 11 Dec 2024 16:21:13 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id EAC46240EB6; Wed, 11 Dec 2024 17:21:10 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 147222405BC; Wed, 11 Dec 2024 17:21:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1733934069; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7yDFADOgRl8yz+pn6MZ5kk4yJ0qWDFjgeMO2KbGLALQ=; b=jbcCcMkRUn+yae6g0gwmZ39utd07E3+yNm8X5N23pbGnRg5iIqvQxklEnDqokzOS+j0lCo FtcojhnYnrASn62i+RTadTi4qF7N9ud5j1zQTy0627aEc/kHLbBb+fuCabbU5nejU9ZLFn nzCFg5O2ZEEcy5cq1iWjxShBlppHmm7NwlSu2GeXET29jSZaZ6BzSdVcx7VoCjCQNibmPj CTOd9YKn+Wbmc9dECaVPAPShm6mWuA2zb/RnHyDMOdWaF7kWO0+vILjJjB+2yfQPfgoDlj sf27hbrpioJr+g7J/zuR4XFkYAub1DHqPqXobftdU3O+Vwg/H3YTk15hHHUycw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-191-042-127.77.191.pool.telefonica.de [77.191.42.127]) (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) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 246162402D8; Wed, 11 Dec 2024 17:21:08 +0100 (CET) Date: Wed, 11 Dec 2024 17:20:40 +0100 From: FreeBSD User To: Ronald Klop Cc: Juraj Lutter , Tomoaki AOKI , freebsd-current@freebsd.org, Richard Scheffenegger Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-ID: <20241211172107.6d7894cc@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> <6B720B82-09EF-4208-B814-B6BD75FC2F0E@FreeBSD.org> Organization: walstatt-de.de 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: quoted-printable X-Rspamd-UID: 8eadea X-Rspamd-UID: a9f540 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:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Queue-Id: 4Y7gp12CJ4z47g0 X-Spamd-Bar: ---- Am Wed, 11 Dec 2024 14:25:02 +0100 Ronald Klop schrieb: > Op 09-12-2024 om 19:24 schreef Juraj Lutter: > >=20 > > =20 > >> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > >> > >> Am Tue, 10 Dec 2024 02:27:10 +0900 > >> Tomoaki AOKI schrieb: > >> > >> My apology for topposting. > >> > >> The host I first realised the problems is updated on an almost daily b= asis and the issue > >> reported started last weekend. > >> > >> A possible candidate could be > >> > >> https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=3D0fc7bdc97836= 6abb4351b0b76b50a5848cc5d982 > >> > >> since the other, younger, seem innocent. I try to revert the patch men= tioned and see ... =20 > >=20 > > Try to only revert the ip_fw_nat.c part at first. > >=20 > > =E2=80=94 > > Juraj Lutter > > otis@FreeBSD.org > > =20 >=20 >=20 > Hi, >=20 > I did a bisect of commits and my finding is that commit 347dd053 on 2024-= 11-29 is the cause. >=20 > "tcp: add TH_AE capabilities to ppp and pf" > https://github.com/freebsd/freebsd-src/commit/347dd0539f3a75fdf2128dd4620= ca99e96f311e9 >=20 > The commit before (0fc7bdc978) works fine. >=20 > I cc'ed the author of the commit. > (for context: start of the thread is > here: https://lists.freebsd.org/archives/freebsd-current/2024-December/00= 6778.html, it looks like the commit breaks a statefull ipfw firewall) >=20 > Regards, > Ronald. >=20 >=20 Thank you very much! --=20 O. Hartmann From nobody Wed Dec 11 18:38:28 2024 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 4Y7krC3Kblz5gJcv for ; Wed, 11 Dec 2024 18:38:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y7krB3yTrz4SlL for ; Wed, 11 Dec 2024 18:38:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 4BBIcSh0042971 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 11 Dec 2024 10:38:28 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 4BBIcSGU042970 for freebsd-current@freebsd.org; Wed, 11 Dec 2024 10:38:28 -0800 (PST) (envelope-from fbsd) Date: Wed, 11 Dec 2024 10:38:28 -0800 From: bob prohaska To: freebsd-current@freebsd.org Subject: Cleaning before using WITH_META_MODE Message-ID: 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 X-Spamd-Result: default: False [-0.26 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; NEURAL_HAM_SHORT(-0.16)[-0.164]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; DMARC_NA(0.00)[zefox.net]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4Y7krB3yTrz4SlL X-Spamd-Bar: / What cleaning options minimize interference with the use of WITH_META_MODE ? Occasionally buildworld stops because of a missing dependency, usually just re-running git pull fixes the problem. In cases where it does not fix the problem how should one rank the various cleaning commands, from least to most thorough? Using rm -rf /usr/obj obviously works but AIUI deletes the data needed by WITH_META_MODE. The cleaning commands I've used include make clean make cleandir run once make cleandir run twice rm -rf /usr/obj but it isn't obvious how they interact with META_MODE. This is in the context of -current on Raspberry Pi2,-3 and -4 if it matters. Thanks for reading, bob prohaska From nobody Wed Dec 11 19:44:05 2024 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 4Y7mJL3v3Wz5gNt1 for ; Wed, 11 Dec 2024 19:44:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 4Y7mJL1qSDz4dFM for ; Wed, 11 Dec 2024 19:44:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-725c86bbae7so4819282b3a.3 for ; Wed, 11 Dec 2024 11:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1733946257; x=1734551057; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4aWXG3CSPwJ84WptW6GcbRZUxxgcfAICsDTJ86YBZIA=; b=qqO1v2JHGfo29nM4dtq59YBsoNNB4NXV5cPDqJaEa8w2j+AMSOK5zDFXcMgJl4aVBb GDoGl1Q09EvRsvMDIT2VhkVMGUZ7TWQqYTH2UQ8i/V0AKRHFhd86R5JuZ9D5NdO1sNvG bM0LshgI1w05X11X62xBZAU8OeF8fZKabvNY5+H0PboUU7uNHe/Xsga3/EggUwpO5LPO olV7rLeTKND2MxSOtJsIAwXpW9qMGz/7ThIaZkf4KELkr7Jg58DSUm4tvcWZZz9O1hxd cM7Mra/p/0DRDJtRr9n675l3h0rlYW5KYgSpj07rGo4xNpfibnT17GaRYqyOzCUuQpdw zeLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733946257; x=1734551057; h=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=4aWXG3CSPwJ84WptW6GcbRZUxxgcfAICsDTJ86YBZIA=; b=lqe7f9I7WtRqsySJ3nEU2ajMxcniSZhHvdCz9Jq6Zklg8vXRfQiJGqXiFNMk0MwTT+ DOH0b+V3SehWJHuGuBQBR3EY6pW1kpyVrpYLpd2wwkzXAp+H/ek7JFqm3t8+O5lZUXIl JWAHKoAWN2ZenCbig+OPzBwbCQsAuVLRbpwz75t2KLmINIctnzttYVA+wWd1IO7Q9QLs HjV1Qh+3i2fCIy8I4qh7X6ukVo4lQLKh4qiQqpCbbleRgqptNrXpsHgi69wPlO80Jsz9 WfO5C2o2fWage4AG60nbeP/XtrKGVm4RPxpBqeRcip/AlzcNdEPRr9fC1CoJrHM/heCV ArEA== X-Gm-Message-State: AOJu0Yzi7oYGJNL4Z74NOzqKWQfx3tnedThe9HN26exoXcMSEzL153fE WEU5JtMqHGdE3qKfvRktfAUw+6ZMJK4zcvKaiXTUf22FzXSdeDd6AmBCIyjXn9RwyqRolLfL4jn 0e8EPy4v0VvcPpWJFhv3CeV2VR0Vu1lu1NbGQUsUGIJyDaKBl X-Gm-Gg: ASbGncs/mTSKl9CnvrxBNmqYWUoumxYa3o/zbwAgWjcW0zcTlo7nmW0sEW5SywTWUpc 3kZjK1ww1TD//jFN6qcgYyi9hGC65abGclDwVNcZCt/+svPtonmXSH4dEJ4IK2L2E69mEIh4= X-Google-Smtp-Source: AGHT+IHS/wSyBvIjl0eYc8VbmIy+Vv19Hkx93P4XqJRIqVhfWcNdp42bdh7AAxJ9OhDLkUAcjgacr3Xa4Q08f3Mmpkk= X-Received: by 2002:a05:6a00:9a7:b0:725:ae5f:7f06 with SMTP id d2e1a72fcca58-728faadacd9mr781421b3a.23.1733946256586; Wed, 11 Dec 2024 11:44:16 -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 References: In-Reply-To: From: Warner Losh Date: Wed, 11 Dec 2024 12:44:05 -0700 Message-ID: Subject: Re: Cleaning before using WITH_META_MODE To: bob prohaska Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000af1575062903d2bc" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Y7mJL1qSDz4dFM X-Spamd-Bar: ---- --000000000000af1575062903d2bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 11, 2024, 11:38=E2=80=AFAM bob prohaska wr= ote: > What cleaning options minimize interference with the use of WITH_META_MOD= E > ? > > Occasionally buildworld stops because of a missing dependency, usually > just re-running git pull fixes the problem. In cases where it does not > fix the problem how should one rank the various cleaning commands, from > least to most thorough? Using rm -rf /usr/obj obviously works but AIUI > deletes the data needed by WITH_META_MODE. The cleaning commands I've > used include > make clean > make cleandir run once > make cleandir run twice > rm -rf /usr/obj > > but it isn't obvious how they interact with META_MODE. > > This is in the context of -current on Raspberry Pi2,-3 and -4 > if it matters. > In the past, I've just turned on meta mode. Meta mode just needs filmon and the it creates extra files, not different ones. I've not noticed issues with this, nor enough extra files to look closely. Warner Thanks for reading, > > bob prohaska > > > > --000000000000af1575062903d2bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 11, 2024, 11:38=E2= =80=AFAM bob prohaska <fbsd@www.ze= fox.net> wrote:
What cleanin= g options minimize interference with the use of WITH_META_MODE ?

Occasionally buildworld stops because of a missing dependency, usually
just re-running git pull fixes the problem. In cases where it does not
fix the problem how should one rank the various cleaning commands, from
least to most thorough? Using rm -rf /usr/obj obviously works but AIUI
deletes the data needed by WITH_META_MODE. The cleaning commands I've used include
make clean
make cleandir run once
make cleandir run twice
rm -rf /usr/obj

but it isn't obvious how they interact with META_MODE.

This is in the context of -current on Raspberry Pi2,-3 and -4
if it matters.

In the past, I've just turned on meta mode. Meta mode jus= t needs filmon and the it creates extra files, not different ones. I've= not noticed issues with this, nor enough extra files to look closely.=C2= =A0

Warner


Thanks for reading,

bob prohaska



--000000000000af1575062903d2bc-- From nobody Wed Dec 11 20:28:20 2024 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 4Y7nGt66dSz5gRDq for ; Wed, 11 Dec 2024 20:28:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y7nGt3MTGz4hrt for ; Wed, 11 Dec 2024 20:28:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 4BBKSLeB043408 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 11 Dec 2024 12:28:21 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 4BBKSK4w043407; Wed, 11 Dec 2024 12:28:20 -0800 (PST) (envelope-from fbsd) Date: Wed, 11 Dec 2024 12:28:20 -0800 From: bob prohaska To: Warner Losh Cc: FreeBSD Current Subject: Re: Cleaning before using WITH_META_MODE 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Queue-Id: 4Y7nGt3MTGz4hrt X-Spamd-Bar: ---- On Wed, Dec 11, 2024 at 12:44:05PM -0700, Warner Losh wrote: > On Wed, Dec 11, 2024, 11:38 AM bob prohaska wrote: > > > What cleaning options minimize interference with the use of WITH_META_MODE > > ? > > > > In the past, I've just turned on meta mode. Meta mode just needs filmon and > the it creates extra files, not different ones. I've not noticed issues > with this, nor enough extra files to look closely. > So, the extra files aren't removed by make clean or make cleandir? Thanks for writing! bob prohaska From nobody Wed Dec 11 20:39:38 2024 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 4Y7nXR2zlgz5gRd1 for ; Wed, 11 Dec 2024 20:39:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 4Y7nXR1BWrz4lFW for ; Wed, 11 Dec 2024 20:39:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-725dbdf380aso3833276b3a.3 for ; Wed, 11 Dec 2024 12:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1733949590; x=1734554390; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Fg18+SdZvu+1LXRJoqyhYObsBIY7YIIYRbiXWx/Wc+A=; b=OE0aa3Z54RDvWvqqiyu/fp4pUMdFZI//7Z1xTK4DXfROvjlh1jshuLhJvTh6KF5Mig av2TIayx9ftsT/A0iSIfjCFs+Tw9PQZ0f/p1oOyURmdAccjsBhpWs8+OyVwM4iMBkcy6 jwxVD1/ssiRSmpJmwaEC9Y7xMC2F2GlzYxSGHzj75QB1pMPSbUL5hnzD/TlV2+qeUgvV 7vwYn2u1RvFuf3NiaABksa/IRPEI0xyn37QGN5KCwze7S7W6/TRdnRekT1LxPFZ2HhJl Om6vZvCDNq9CNQIEGDiv1WVNaL3xXVVHq+p5WshjXJ0pS8Uz8vTSVNDMcxLui5eZKjyx y5Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733949590; x=1734554390; h=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=Fg18+SdZvu+1LXRJoqyhYObsBIY7YIIYRbiXWx/Wc+A=; b=ezfu0VmdQDXf9TmK68LqcUwC6RICLnV4Q33mrt09LFPYXVqBaNgCCYArDpyQgKvFIB 4SEMU+9kmHv3AhSYXOA5uiVUYnDl5f7I6SOe3KMHDIg4su+gPKQrOuaBjvTK0jKg/TPq PHXPZkJgfG8a278dp8X1EpWcOc0vgwWlqZVBrfZ5iVCMawhHfy+ZsF3e6BqouvzObf/i TB/beksetkGYB9VekqlnVwO4d8LSobcnBeE3uWV9N53z83TAfg2vFJ5iw+BNQQ2ztuE2 FP550B6975vEsRwSNmyS03Nc5I8vRtX/oSQCRNT5vhW8Qlp7XU4xN2rmIsr+GdNkKJbA GEag== X-Gm-Message-State: AOJu0YylHI7uSusYUiAmVbGLdqENJEEDaoSZ8B5t4qmZp/xpGILrCvuW 5wOSiR5vVVr/OfVDIQgnsHEB+o/D5OkGYeQzXFsShFdKNWRPeIaLlI9wutGoXBtWTgpAiuigomj 5Abu0L2OwZHuM5OtckzhHKv8YoTav0VtFFfkRzDlzVZ6PBU0WG8Y= X-Gm-Gg: ASbGncuYxz9naOilRTqlTZl12XuTVWm/TSXG9ZIHsaHn8M1h0RbI1qH8ihCPdo80rrU /iOkAAq1ERJxUjMtURd2di7xAUhvHDND53mg= X-Google-Smtp-Source: AGHT+IHQz3sXcetb78oFLwPlXT7Fx5GqjlH8aQyHnkOUncQ7V/t+dNeJB5TTDksLx56Yx19r5qp1gAJzQTDeYaKERqE= X-Received: by 2002:a05:6a00:3d4e:b0:725:ea30:aafc with SMTP id d2e1a72fcca58-728fa9b7848mr1063304b3a.5.1733949589783; Wed, 11 Dec 2024 12:39:49 -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 References: In-Reply-To: From: Warner Losh Date: Wed, 11 Dec 2024 13:39:38 -0700 Message-ID: Subject: Re: Cleaning before using WITH_META_MODE To: bob prohaska Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000005b9f0106290499f1" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Y7nXR1BWrz4lFW X-Spamd-Bar: ---- --0000000000005b9f0106290499f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 11, 2024 at 1:28=E2=80=AFPM bob prohaska w= rote: > On Wed, Dec 11, 2024 at 12:44:05PM -0700, Warner Losh wrote: > > On Wed, Dec 11, 2024, 11:38=E2=80=AFAM bob prohaska wrote: > > > > > What cleaning options minimize interference with the use of > WITH_META_MODE > > > ? > > > > > > > In the past, I've just turned on meta mode. Meta mode just needs filmon > and > > the it creates extra files, not different ones. I've not noticed issues > > with this, nor enough extra files to look closely. > > > > So, the extra files aren't removed by make clean or make cleandir? > I didn't say that... I just said the delta between a tree without metamode and one with metamode is just the .meta files. I think make clean will clean them, but I've not done that. Warner --0000000000005b9f0106290499f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 11,= 2024 at 1:28=E2=80=AFPM bob prohaska <fbsd@www.zefox.net> wrote:
On Wed, Dec 11, 2024 at 12:44:05PM -0700, Warner Los= h wrote:
> On Wed, Dec 11, 2024, 11:38=E2=80=AFAM bob prohaska <fbsd@www.zefox.net> wrote:=
>
> > What cleaning options minimize interference with the use of WITH_= META_MODE
> > ?
> >
>
> In the past, I've just turned on meta mode. Meta mode just needs f= ilmon and
> the it creates extra files, not different ones. I've not noticed i= ssues
> with this, nor enough extra files to look closely.
>

So, the extra files aren't removed by make clean or make cleandir?
<= /blockquote>

I didn't say that... I just said the de= lta between a tree without metamode and one with metamode
is just= the .meta files. I think make clean will clean them, but I've not done= that.

Warner=C2=A0
--0000000000005b9f0106290499f1-- From nobody Wed Dec 11 22:27:22 2024 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 4Y7qwq3p4Xz5gYgl for ; Wed, 11 Dec 2024 22:27:39 +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 4Y7qwn6dlgz40Jq for ; Wed, 11 Dec 2024 22:27:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KO7TYVzO; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733956056; bh=23YIS/1Wavdw4Ipx1FQysT6g2UpgrF/QrK/hSpYgJek=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=KO7TYVzOv9iC5TqWwD54eRL4UNcjdnNYrZo7iEcGI2T2TWF3ayQZBvzpZkKELCM22WyTqy3Yzd2oqa1LYpC6D97LJzr6WcDU1vZnIQ7eu6/Lv2YbDIyyerOvvEXp67S9jdQenPW8Q/mtEgsVvyyd0ehisx0EMRl1cQJrDTjSgCI6YJDFSsfZzkqNBlarZnMn03hIbK0pjwUoYyy9JygBILTNNbkbJ951bTXqMVw+uaPVZV/6onE+2t2sh9+z+lpPzQxTMOA8OmB5cj/QB6xpb694BTZz+7N+9faSjvSQgRSr0p1AMgmV9kDz2TVZ/uixxx8+94fPniRBqCYWhAUETA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733956056; bh=SJKU7u2OfAy6O3aIHeSDY27r8oMD44QV2RYgoI0t5R4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=LvuiQWr9JRxCOYvpp9/OugUG+Ek/45T92gZovwb5ugVMpfUzoOmtoZFximNsW6oGdSmJbaq5LFzdhmROVd/BgQXxpXTx9ZZodKxxkj4I2m2Q5bIT8/wbOfM2Uo5jk3Y84ycuioNahdhVKoCVSiYi4iQmo/5OerEcjNiegyxQ2dNkTah5otZb7cD1WNy7GeVk8GjuEmz/piw7o7pxlIU0zWe9Cfwr4VktbcVn7i/nFA4CRjufOceAwnCqILT2T9kHGaLXfq9kXsCLVNcZABS3fo1JqsIx/KKL/V8vFBugU7TdYK1i7rTGRcWRTyvPg4EGA60hKzHTpBBr2StaU/+tnQ== X-YMail-OSG: D.52Dt0VM1nCl2nlp1F9DEeaKESZw13Haul1IcaZycxBf5IlbY7c_AlydDjhf9e AUPBLAOtS2s8qMpJvYYfywz4O44ae6ZJSMSU2uOWd_GIvW1qPYML3ckheIt2owM9IgzH1Q4V.KZY nnur5eYcGqvCStQJsD1gyY2scTXINamsEYKiej64dN8CGgsWWEmrgYzBezyvnVf6EStOwDHCdSEf i_CTtUEm8xHETfF7Q2Q.hvKc94OPGHIG6Mat2qtah6dKrW3QrQ2hV.o7ZNm0lx36CgqydGpwssSS CCsgXJl9fDY8ZmWVbmzWGuUGxElmRT5MnZoa3Ka33F3xrtUbRDtHrJbe5yn4Kl7BfW4tSOpiEuP6 np_bfTysile76QD2Rt6xd3Du_R1on3bIJdgmlcyIdf3sr0p0iq4PB2OlL2azQ2jiFX8qewhRW9GY 71qPuUBM3CA797HJdYEyogrhBm5URUSWKjXVCytG4w.lqNIMQLSyjgyzJENMSR4LBgJer8k87N7Q NAWz3BvGVqxld8rWcNhWR35TeyRJ4mjG9hwpdstMxrGTxHgxyPu._bqZh.OCFsclSDdrutID.xns TFuWXPVFana1nAB161jY3x3tM63ohWcy1r4nphy5D644CdIdQM1lXqSYhREID0UixmuhdtlBQLT2 YhCjWU8WB3QWdHMcifL4djABe5dQqdOTvfsVg8z6wyMfdJDFczTwovPzHwFYCajmhMPm.0a8VUfx Mjzl7WczwQR_cJJTo1kFhxSep5l3dgpQnkk9EA2SDGnvSq3uLz9BweHDWCvHizxFrdEELNA7sG2u aLv_EHqQNw9VxzzuMSWJC_xEDz6xbJog3VnaUrMh.nmwO2a0A9vOznV95sWXbGfZA8ieRJNvfAGX qJJQttOT6E6JVghHb85sxN9yT_upRr3qRS_gbidQqdOFtgw8417q9xHamoZBa0i1FlJr_XArQ3YW K51P50I1NPPEZiK3OAU45itZ4hoTib..9pnECZcUSpbhsl5OBtDYNIM400cJFH1pfUGTZeTg9cwW k7HRmRNcZVVgeRBz1txqcJv44ieL8884Q3hJKpyjRSaoqpFq7HYN5ZaL6z61o7739xzDIp1MKhzV IDIyJNX0NfHOkBAqhNEr14L5esHyzdIhH2KqJo4XDw.WnYAds446mhF7.CUIP9rNNm1hWJpOmssH xtX9nol2sEd6_EV5FhSaN1fiwF324.TkjO6XR5ojk0s.4jN5ecFbqY04LPmfdh5VJzY1WCi7IzRW 8AmGRB67_5FkHSqpO0_a137KXITsnDBFpI4mPGSdjDDImEqe1Do12weQ4UiKb4eJhN05OdPSFSjJ xqqqMDzcbD3ZPl.Vr4Q_cq8Eo8G4bvwvTjnabNGbRk7MZAn7QT_lz_XDTxDldDiVtTnoIzn163fR NtQlXNXTCZXIIXNvnRrqEAtnkkhIBh6Yidf74tZhFrBxeFOTFej3ea2z3LYFFex0VEk6360SnodR vdcdbjXMUc5jWPHeucd46nb.OuE79q6PERnRxO1Y7r7UJlelqgGpnrAAQgsquLxicWDCJpJVPbru u3jbWYQq9fnpbNVWIQ1XQ8AKpTVd5nXyve44ezCcIJSHWKuZ.ZBmz3Tmd7g2D_7ucLee.GscAajx R7OQxry3iciSN3PlejEd7Hwhas6dIT_W6PI2qaWkWDKOAMY6dTDSv7ZhNu4Lvltx0IbLykFP1jRM Sq4H9oLYjP.GBidhKjEPXozmZHLgRz8FI._Nj.rHDA5mcvL.1nw.CW_eZMfjgvk5N6boWY5txAdE dkdEso7SmTyzDFZOUpp_4DSP53vwQEA7OQQrrbD31SIVAK6.PCiaUyc0YyG.XxrEq8sQQW9gKKm_ 8F0ThQsXC4p8b.Z0VTwbd8RTgjssI7otAiTtISM1tnVpFcQaAS4b1wMP1Zd4_ssoNunAny78ZG63 JU5bV1hhdmArtLe0nJTSTimB3IPPnnWeRu48xb.nNUSew3SrUdGQg5tpnxgB4_y0F5Wut26Gfg3A ubsjYL.iClT5WlRaqH51IeFsi1Eqs.ZC8eXyAyXofRHSn3fsc4T6JUh1xNSPTOLJ8A25J.ym6Gdr rsRLJTKgrMjP6PPmS3NRt3pWjAJQY534t8T3g0cuzp5.Z.bbfDFJdBd0Q.j9WpjWmzseN5msR28H yVu2qfAAou3mF9Sp1iu0UUQ3f98MCD_UijAP.y8K2w3hGLl9.pisM9eLSph_Ld0My1eC0suUkpZB t0zcHZQHwVLaHbDNB8o7DqBVewBvmAQ-- X-Sonic-MF: X-Sonic-ID: 6dd2f68e-1bb7-4938-9131-004485db3ead Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 Dec 2024 22:27:36 +0000 Received: by hermes--production-gq1-5dd4b47f46-wrqn7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1b43d5eedf7824fe7ae679315cf9280b; Wed, 11 Dec 2024 22:27:32 +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.200.121\)) Subject: RE: Cleaning before using WITH_META_MODE Message-Id: <1C9B6B0E-1D02-4ADE-BABE-9E0238F96FBE@yahoo.com> Date: Wed, 11 Dec 2024 14:27:22 -0800 To: bob prohaska , FreeBSD Current X-Mailer: Apple Mail (2.3826.200.121) References: <1C9B6B0E-1D02-4ADE-BABE-9E0238F96FBE.ref@yahoo.com> X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; SUBJECT_ENDS_SPACES(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]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(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]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4Y7qwn6dlgz40Jq X-Spamd-Bar: --- bob prohaska wrote on Date: Wed, 11 Dec 2024 18:38:28 UTC : > What cleaning options minimize interference with the use of = WITH_META_MODE ? >=20 > Occasionally buildworld stops because of a missing dependency, usually > just re-running git pull fixes the problem. In cases where it does not > fix the problem how should one rank the various cleaning commands, = from > least to most thorough? Using rm -rf /usr/obj obviously works but AIUI > deletes the data needed by WITH_META_MODE. The cleaning commands I've > used include > make clean > make cleandir run once > make cleandir run twice > rm -rf /usr/obj >=20 > but it isn't obvious how they interact with META_MODE. META_MODE produces files that include lists of file dependencies. If a form of clean removes one of those dependency files, that indicates needing to rebuild after the dependency has its file re-established, just like the file being newer leads to needing to rebuild with the newer file. (cleaning tends to be removal of things.) META_MODE also records what programs were executed, which leads to updated programs causing rebuilds too --even when the updated program is unlikely to be a functional change for the actual activity. Think, for example, of echo being updated by an install. The use of echo in the build likely gets the same result for both the old and the new version. For the initiating command(s), META_MODE records the command line arguments as well. If the command line changes, it leads to rebuilding with the new command. So a question is: Are there any forms of clean that would leave a substantial portion of material not being rebuilt via META_MODE, especially if the clean operation is global to the build materials instead of just localized to some sub-area of the overall build materials? The question would stand even if all .meta files were left in place. I'm not so sure there is a viable optimization of the type asked about, other than cleaning only part of the overall structure if/where such might be viable. > This is in the context of -current on Raspberry Pi2,-3 and -4 > if it matters. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 11 23:40:27 2024 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 4Y7sY33sgbz5gf5x for ; Wed, 11 Dec 2024 23:40:39 +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 4Y7sY26MNvz47g8; Wed, 11 Dec 2024 23:40:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4BBNeRCF052877; Thu, 12 Dec 2024 08:40:28 +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=1733960429; bh=qFtkpEEK0ihXBRsHbzkXu98ujioFmoQnLYNU4d55iVs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=J8435l4m9HrCfN+t8am/6UkuFijIGEEwu1KwDN+mh93IZWlbpSi/jNjUqYOEP1ZXI bZYTXhfVSbCaLho9XV32sEjt/k7zHl8mwgK6zc7dPZSvnC32q+TzMuImYUmWlVF1sC MXytAsJ7KsorYpBYIFVTR7kAuayrXXaAs39gAAq8= Date: Thu, 12 Dec 2024 08:40:27 +0900 From: Tomoaki AOKI To: Ronald Klop Cc: Juraj Lutter , FreeBSD User , freebsd-current@freebsd.org, Richard Scheffenegger Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-Id: <20241212084027.8f3aa854426aaa98e3fd68d1@dec.sakura.ne.jp> In-Reply-To: References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> <6B720B82-09EF-4208-B814-B6BD75FC2F0E@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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: 4Y7sY26MNvz47g8 X-Spamd-Bar: ---- On Wed, 11 Dec 2024 14:25:02 +0100 Ronald Klop wrote: > Op 09-12-2024 om 19:24 schreef Juraj Lutter: > > > > > >> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > >> > >> Am Tue, 10 Dec 2024 02:27:10 +0900 > >> Tomoaki AOKI schrieb: > >> > >> My apology for topposting. > >> > >> The host I first realised the problems is updated on an almost daily basis and the issue > >> reported started last weekend. > >> > >> A possible candidate could be > >> > >> https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=0fc7bdc978366abb4351b0b76b50a5848cc5d982 > >> > >> since the other, younger, seem innocent. I try to revert the patch mentioned and see ... > > > > Try to only revert the ip_fw_nat.c part at first. > > > > — > > Juraj Lutter > > otis@FreeBSD.org > > > > > Hi, > > I did a bisect of commits and my finding is that commit 347dd053 on 2024-11-29 is the cause. > > "tcp: add TH_AE capabilities to ppp and pf" > https://github.com/freebsd/freebsd-src/commit/347dd0539f3a75fdf2128dd4620ca99e96f311e9 > > The commit before (0fc7bdc978) works fine. > > I cc'ed the author of the commit. > (for context: start of the thread is here: https://lists.freebsd.org/archives/freebsd-current/2024-December/006778.html, it looks like the commit breaks a statefull ipfw firewall) > > Regards, > Ronald. Ah, completely missed to check sys/netpfil/ipfilter/netinet directory. And intentionally dropped to check on sys/netpfil, as checking log there would pull in too many noises only related with pf. And even if I've not missed sys/netpfil/ipfilter/netinet, I'm almost sure I've overlooked the commit, as the top of its commit log (shown in https://cgit.freebsd.org/src/log/sys/netpfil/ipfilter/netinet) only states about ppp and pf. -- Tomoaki AOKI From nobody Thu Dec 12 02:44:53 2024 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 4Y7xdw1KWnz5gsPZ for ; Thu, 12 Dec 2024 02:45:08 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4Y7xdt4ZvYz4X9n for ; Thu, 12 Dec 2024 02:45:06 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XHoxvgzn; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5cedf5fe237so150170a12.3 for ; Wed, 11 Dec 2024 18:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733971503; x=1734576303; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=xqJcu51mEoGOtCOx3ztiY/clkdaQe7AJVi7MCq9a90M=; b=XHoxvgznJeKlKta84JjVP/wypNqgQ2R5Vhy437IC8rSh1gECyuum1fG5sidfsZ3wRu Da2MBNxpHY/UKRbQzgI6Sy3453KsIQcXxy3n5JonrddtFwxAKQ2fDXstQwEDC+WWesZq /p8W9hj2dNkLDvLmn2Qtu2PQJk/NcX9kxISC/uFG2cpGZB+cxW/iOz75kLKi9WbAQ52t qVTIyFiPVvCeiJ8lISnEjkZcOyaSR4McTREDkA5detkB38hUgd/l3DGhN05vDOGP6USQ nX4SNTvyKjazR2O/LEiN4Z9ZBmtj6ftwJenqbdx+ji7YqKUCmGIkUovwde19t1pwXS70 dRJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733971503; x=1734576303; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=xqJcu51mEoGOtCOx3ztiY/clkdaQe7AJVi7MCq9a90M=; b=aQV33O4C13Oia/JL8iGi9tBKVLX1SynQi+APc5N6khz/RRElLlamweWLV9Z6tRty++ 5mW9oYdWubanRbrz9pw6RGh3PhRT1T5LUO9qFaO3BiCcBq0VtVBfIPAYthoCu0mnwFcs OvS7wlKMyfRPg15B602huK0p1SsM6I/6HhbFK80XEnadHV7FB1guFkKTy6eiKVEIWoFv hBQ/Wy440qY1rZCZWAmWSDtUefrJXyTznRJLiedwTvbMB1O+c72T8q3HkawpoCW2J1zt sbvVTwPHnEKMdOxRfpa6qMQCO7vstM9ualUsdor8hkeWYIVDgRWhS2DCL46y5sITwAwp CTNw== X-Gm-Message-State: AOJu0Ywx+XP+qjibMwJv6c/SETn/FLMJ/U988n+LnQIBSms2UmguZyRz Z60f+r3Gm9k3rubcWmg2RJfZEWbH90tJOkB/U110b0OduFoKS82pZVFb9rpFEIqpTI+0oh1QPex F8cAFBhMUGnOdX9hZw3zG7cwQriGb X-Gm-Gg: ASbGncsxMyd8slwELvWhC2XHXHYNVSFVnbwhg1Pirj0Y1cRWbG6sU/pwst6BUZ0ODvE FDUlnsOfSsFoYsJo1ZxzWXWQtED4dzb5Yna1hShKAusiRfIdHJOD78uVNIk8fdALvEIhiUA== X-Google-Smtp-Source: AGHT+IEzZMcCO2uOjO2PrMBdx6vwFwVSvnna7Ua9I86ut03Wua25ioN7bv9IkQKJJHAZ1qmRsKcflox9QDAihcS0PsY= X-Received: by 2002:a05:6402:540e:b0:5d0:d5af:d417 with SMTP id 4fb4d7f45d1cf-5d433048d7dmr4671410a12.1.1733971503171; Wed, 11 Dec 2024 18:45:03 -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: Wed, 11 Dec 2024 18:44:53 -0800 Message-ID: Subject: Module variable initialization To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.909]; 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)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from] X-Rspamd-Queue-Id: 4Y7xdt4ZvYz4X9n X-Spamd-Bar: --- Hi, Bugzilla pr#282156 reports a crash that appears to be caused by a NFS client variable (nfscbd_pool) not being initialized when a NFS mount is done. Now, the NFS client module (nfscl.ko) is weird in that it has two definitions for the module. There is a VFS_SET() one for the file system and a separate DECLARE_MODULE() for nfscl. (The latter exists so that the module can refuse to unload and define dependencies on other modules.) The variable (nfscbd_pool) is initialized in the modevent() function for nfscl in the MOD_LOAD section. Does anyone know if this can somehow result in the variable not being initialized when an NFS mount occurs? And, if the above is possible, would doing the initialization in the vfs_init function for VFS_SET() be guaranteed to happen before a mount is done? Thanks for any help with this, rick From nobody Thu Dec 12 03:47:46 2024 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 4Y7z4L4wKZz5gwVW for ; Thu, 12 Dec 2024 03:49:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y7z4L2Hrcz4cgL for ; Thu, 12 Dec 2024 03:49:38 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BBLsYk0026242; Wed, 11 Dec 2024 19:49:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=9WCicXnxGCzr4 G7ZlCPOTzHBln0MJraF0kqpqdRe2UY=; b=U6x+k2FWyqHShj5ze/MkvaxiDlTew kaxYzQOEwBapXPXxAT6FOIZ5ZUKmTHiC6jP31hrBjLkUFyFPxcNrAlE6/GtEdk+Y vTLyEzjJaMCSj6eTuugXFfFWf1zA+4q940AcDzxMzISZ/cY/I9hjyZsesvGkvP4y tXWwJO3P/GYOWDBwpmLQdMXUsZ/GUTgWCG7iwO0caiX4eTYea3pddzNXMcnRa99f ylvqdVIC4FoJWOGrbzUHYK4OwQk2oyFsMb+hDFZI9lI7h8kzCSJ0uUOZ4zn3Lm/I 3tw6oBkw6faXIim4U2icUzXNOezTZcpadHmphuDIMxxXzjtCmAEDK20Yg== Received: from cy7pr03cu001.outbound.protection.outlook.com (mail-westcentralusazlp17012036.outbound.protection.outlook.com [40.93.6.36]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 43exwuk7r5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2024 19:49:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ipyilacj8RDbq2yLFw0N+aEfq8f49LN1xrDSEvQPtbAX40RZdMpqIQmHVPAF6dyJv0njEXUSUWrVf7KOGtK6ZSvaCTwDOoKAU45CIg4RScZNka/0xY9Z0aly7RUsqqMsJCt4FPsgIQ04hHBweAzQ7G0XdY4yIKU8PB5YvVfrBuMbbruensKaqvLE0LJCuZKHKmxY2RjX+x22Jn5NlX94/wgvgyStxdNzuKGWQPNO3DsNhongrJJKHgKW75mBzJqxWxTuX+SHKMhivGZ6w2d8Vmg9g2+Q1BHUt/K6PyHBqwSrWzd9okjHmtYcUvGBVxDz6E243Y1B7sKQBgb2V2rHpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9WCicXnxGCzr4G7ZlCPOTzHBln0MJraF0kqpqdRe2UY=; b=YYPBnZWHd17m5rZOvaXWkt9oqYNmQZqg5p67dE+tSXGoxwJyIrkH/irHJR0CUzXlN5WnF4giTHW0pG/QIHFAnbdjeSEpHyKwuGMv78MNa1/yoHhQBA9IHW7OY0dzY+CkXTQHkx6LcqAlNOaegTgf2YOepkapsGnnILXfHIm2rI4x3nMFuA0D/F82g0npVkWxenUdfDudYfd1Fv955Sjrc0GxVY78fjhb8NZiAeVtdRQFnH8KCFtFOzicfcFWXHgAMeeKoEiPGNH8FPlvcBGaOtRmML54np7VdDXBvsvc8p+6gaalXPK+BcCRCorDhG0o9at5G6XXH0Hq0g2Xfqw7Aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=www.zefox.net smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9WCicXnxGCzr4G7ZlCPOTzHBln0MJraF0kqpqdRe2UY=; b=KZPORpYFp2EmkxEIjkyQR4OWhBPn3bTY3SQvB+Jd5eIOf6MgjrQwXf/flmM6MpTQwle+HEiIuyl9S/nECuQlNzJrci3LGnUo59RYH1XWIKMVtTfsbKhxQt1aEdMuuVqm0SEG912xsMxdn7B5JkE8xjPRlD4HtgZ0n5d/DbQGk/g= Received: from BL1PR13CA0086.namprd13.prod.outlook.com (2603:10b6:208:2b8::31) by DS0PR05MB10953.namprd05.prod.outlook.com (2603:10b6:8:200::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Thu, 12 Dec 2024 03:49:33 +0000 Received: from BN3PEPF0000B36D.namprd21.prod.outlook.com (2603:10b6:208:2b8:cafe::bb) by BL1PR13CA0086.outlook.office365.com (2603:10b6:208:2b8::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.13 via Frontend Transport; Thu, 12 Dec 2024 03:49:32 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by BN3PEPF0000B36D.mail.protection.outlook.com (10.167.243.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.0 via Frontend Transport; Thu, 12 Dec 2024 03:49:32 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4; Wed, 11 Dec 2024 21:49:31 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4 via Frontend Transport; Wed, 11 Dec 2024 21:49:31 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 4BC3nU5i020939; Wed, 11 Dec 2024 19:49:30 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 75653ACE7F; Wed, 11 Dec 2024 19:47:46 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 7294EACF49; Wed, 11 Dec 2024 19:47:46 -0800 (PST) To: bob prohaska CC: , Subject: Re: Cleaning before using WITH_META_MODE In-Reply-To: References: Comments: In-reply-to: bob prohaska message dated "Wed, 11 Dec 2024 10:38:28 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 29.3 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-ID: <93832.1733975266.1@kaos.jnpr.net> Date: Wed, 11 Dec 2024 19:47:46 -0800 Message-ID: <96807.1733975266@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B36D:EE_|DS0PR05MB10953:EE_ X-MS-Office365-Filtering-Correlation-Id: 3467db40-42d0-4551-6d63-08dd1a5ffcdf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?MIW/PTu5cRXkEruHOinl23L+peBuuPvMJ7mt6AtaXY7NdSHl/AVVXxhbWmm6?= =?us-ascii?Q?yDGUtqOr4b/OH4q4paYag22Wh0TkdYb+CyQsi7iUe6LGDewnkCsYNowiQIRJ?= =?us-ascii?Q?2ctAmxz41jLqWgwj+QMlfBUw0bARN2iw7hLOGmE/SAlFp4OVRJ4ZSIMWR125?= =?us-ascii?Q?TcHEFMXLqWaYsRpGyuePfJ4ndI/kxEHSRc94PXFnepljoqnW6P6+158H007E?= =?us-ascii?Q?HKqGP2OwWTCjGrAQCHNfsjJwfIFrYpli2DU6f/RT+GLuxwcyFBQjmngN+/2i?= =?us-ascii?Q?yRM2aKcR13mVRNCfPMIOK4Ai9YhBgEUylTcq3gcPm/EUCPw5TssJ5au+Klcc?= =?us-ascii?Q?EjgBDeQgYF2j4nPVTb+tca0K6YY9+t0Cmkr1UKyLs8zQUZU02bDSJ+iuox9v?= =?us-ascii?Q?8ha8Wt3FPYttxKCHLIkhujIBAW7pEATxCu5dz9guAE1VF8pEJrTRaXRaWLvf?= =?us-ascii?Q?XDhQd6KZSIrTSMKUu9CqydBlrpiC6mclxLogLmtep4YLqeFHI8blsRJ52hiP?= =?us-ascii?Q?ttObT+PKgow28pzE/GWSo/Dl8JI8uTIOfw3u2qc1Xr/Nsn71IWT3vqfiQ4l2?= =?us-ascii?Q?Ls0R8EMHMnZnzXrfEqHCgoo2hGcvGGOtO7ca3YV+xXQ067+l4LVLIUszEemj?= =?us-ascii?Q?vfH6UhUsm7fXGfDpUHHuH0h4BdNwfRYEC/90T7SbNFbJw1meXo3R+HswK1Ac?= =?us-ascii?Q?sLdyZ0QRZqGJgdMpzkt8wyFVi2yc6ad1cgWGkhmIZ3gsJYTg+j1IsdEotUkP?= =?us-ascii?Q?HggCcJL/iUlhqisvEi1PFYvpr7epevYntK/ijh1a4Tja+oHP9xk+W/kY9qAO?= =?us-ascii?Q?lbcbMZNG017PDjw2SLavGimspPaQZmFvx4OIz4N2ARa2Ga4tMJx31k+U2nKu?= =?us-ascii?Q?e0iSc4gIsI8jVTIE2OR1xGjMDxxeFzhzMayQaUauWIqKwSVrQZwMsPRiAMNf?= =?us-ascii?Q?DWnRSlk+Ni9QBssED8HnhdlY+Vobfo2eAjOgfQn89SP4iIh4hJafRguxKl17?= =?us-ascii?Q?VsstHpSXdJKLi0CW7y1grKLmTQxGF7McjGKjDzQIb9S/ecSFIxK7kh/p5tH6?= =?us-ascii?Q?uYUo7E+B60SnPxQ1jcbnIl4/8/ThgTCZDjcBQg5Ui+ZyCTXnr7ICizP8yTo4?= =?us-ascii?Q?hcnlucXTS9pVh8sCo2RFL5/6pqQ4pmJGoCNt0m/YkZXwa0+NpmIbBqIW00rg?= =?us-ascii?Q?tPyZC1NeW2UqGEOsnQhXm01j1BEvISuPlzSdiPMxZY8GrMGoOV4Y/ilXJ4Gx?= =?us-ascii?Q?phiPSzUcFUhPYx4RrHQDK8SoEn4CB/CknIvf9lPuHcW9kAhFnqAesljnb51l?= =?us-ascii?Q?xHVioI0mot1gz2qNikxe+GOGt2jJpIeyQzpBcYvgAR/Ir0km3h15AT1Hf2SB?= =?us-ascii?Q?eQmdJdIyXTngefOYUVitafVbwEazw4RY0Bw8J7DXws7HMDj+wL/RfrUhzXeX?= =?us-ascii?Q?c33JkIQC5Y0=3D?= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2024 03:49:32.1788 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3467db40-42d0-4551-6d63-08dd1a5ffcdf X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B36D.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR05MB10953 X-Proofpoint-GUID: FmZ5Up-TfqUURSEaRMs_2wy4ZgIEiCXW X-Proofpoint-ORIG-GUID: FmZ5Up-TfqUURSEaRMs_2wy4ZgIEiCXW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 bulkscore=0 impostorscore=0 spamscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=927 clxscore=1011 phishscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2412120025 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:26211, ipnet:208.84.65.0/24, country:US] X-Rspamd-Queue-Id: 4Y7z4L2Hrcz4cgL X-Spamd-Bar: ---- bob prohaska wrote: > What cleaning options minimize interference with the use of WITH_META_MODE ? FWIW I very rarely clean a tree where I use META_MODE, maybe once a year or so. > Occasionally buildworld stops because of a missing dependency, usually > just re-running git pull fixes the problem. In cases where it does not If I need to clean I tend to use one of the 'destroy' targets, which is equivalent to your rm -rf /usr/obj below - which is way faster than any alternative. Note: bsd.obj.mk only defines destroy et al if you have OBJROOT defined (eg you use MAKEOBJDIRPREFIX or MAKEOBJDIR) > fix the problem how should one rank the various cleaning commands, from > least to most thorough? Using rm -rf /usr/obj obviously works but AIUI > deletes the data needed by WITH_META_MODE. The cleaning commands I've That's true, but the info in a .meta file is not needed in a clean tree build - it is most useful when re-building. > used include > make clean > make cleandir run once > make cleandir run twice > rm -rf /usr/obj > > but it isn't obvious how they interact with META_MODE. The short answer is they don't and it doesn't really matter. HTH --sjg From nobody Thu Dec 12 08:53:25 2024 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 4Y85pz0Kn0z5hCkQ for ; Thu, 12 Dec 2024 08:53:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward501d.mail.yandex.net (forward501d.mail.yandex.net [178.154.239.209]) (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 4Y85px5wB7z41vw for ; Thu, 12 Dec 2024 08:53:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=hepWeKuy; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 178.154.239.209 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru; dmarc=pass (policy=none) header.from=yandex.ru Received: from mail-nwsmtp-smtp-production-main-23.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-23.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:36ab:0:640:28ab:0]) by forward501d.mail.yandex.net (Yandex) with ESMTPS id E6E8B616BC for ; Thu, 12 Dec 2024 11:53:26 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-23.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id PrjxquIOg8c0-zsd9d38r; Thu, 12 Dec 2024 11:53:26 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1733993606; bh=LTzQ+CBjrmBxxyDYMO10PRpms9GqlAW73UIDIJX6QHU=; h=In-Reply-To:To:From:Date:References:Subject:Message-ID; b=hepWeKuyRsaGCxKySi/LyFWQoq/Q9MjhkyVsdB3CbJ+WB8JmTI4KNM+JtoJ+X+o6J uEGBT5bPMVwDhKaHevOazcE09pOpkThtaGIRlDi3kpnAN2Hzsf4GtOQg3GmOuPRVAV B1WerXvxR/gKxZz1vZ4npEHl9/8maW6xTvT3jpcc= Message-ID: Date: Thu, 12 Dec 2024 11:53:25 +0300 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 Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Content-Language: ru, en-US To: freebsd-current@freebsd.org References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> <6B720B82-09EF-4208-B814-B6BD75FC2F0E@FreeBSD.org> From: "Andrey V. Elsukov" Autocrypt: addr=bu7cher@yandex.ru; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNJUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT7CwHgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAzOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.923]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; R_SPF_ALLOW(-0.20)[+ip4:178.154.239.208/28]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; SUBJECT_HAS_EXCLAIM(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yandex.ru:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:200350, ipnet:178.154.224.0/19, country:RU]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[178.154.239.209:from] X-Rspamd-Queue-Id: 4Y85px5wB7z41vw X-Spamd-Bar: --- On 11.12.2024 16:25, Ronald Klop wrote: > I did a bisect of commits and my finding is that commit 347dd053 on > 2024-11-29 is the cause. > > "tcp: add TH_AE capabilities to ppp and pf" > https://github.com/freebsd/freebsd-src/commit/347dd0539f3a75fdf2128dd4620ca99e96f311e9 > > The commit before (0fc7bdc978) works fine. > > I cc'ed the author of the commit. > (for context: start of the thread is here: > https://lists.freebsd.org/archives/freebsd-current/2024-December/006778.html, it looks like the commit breaks a statefull ipfw firewall) Hi, thanks for bisecting. I think this patch should fix problem with statefull ipfw: --- a/sys/netpfil/ipfw/ip_fw_dynamic.c +++ b/sys/netpfil/ipfw/ip_fw_dynamic.c @@ -927,7 +927,7 @@ print_dyn_rule_flags(const struct ipfw_flow_id *id, int dyn_type, #define _SEQ_GE(a,b) ((int)((a)-(b)) >= 0) #define BOTH_SYN (TH_SYN | (TH_SYN << 8)) #define BOTH_FIN (TH_FIN | (TH_FIN << 8)) -#define TCP_FLAGS (TH_FLAGS | (TH_FLAGS << 8)) +#define TCP_FLAGS ((TH_FLAGS & 0xff) | ((TH_FLAGS & 0xff) << 8)) #define ACK_FWD 0x00010000 /* fwd ack seen */ #define ACK_REV 0x00020000 /* rev ack seen */ #define ACK_BOTH (ACK_FWD | ACK_REV) -- WBR, Andrey V. Elsukov From nobody Thu Dec 12 09:46:40 2024 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 4Y870T4f27z5g2wl for ; Thu, 12 Dec 2024 09:46:49 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y870T3zbtz469J; Thu, 12 Dec 2024 09:46:49 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733996809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=66rbOPJ8nQ2TDUUr9gCIjuq4jnPshpq06qlrlDlS2Zs=; b=hwW/K107SdAmiSredV+iEecSQ6rygz6tMHpsQYT9uoPHCEnnohWL+LUlxn42nHA0/oTThq mB5ucSzWe4hnHR/pUo4lzphyBBVZxVjr5dhgduoz0JoG+/9ONfVQ+ubFIxMUENWHwFYC4P mFNdgIapd6AAmRk4tyblau/fv7S6rjsT2y+GY+h8v4DxgABTP1G77fcxtPBXkAaFvj74a1 GOraibZEuMpE2DFnCVPtjcZ4zpAeDGhsFfZAIWsIcUjTI7i35FCTz8md5C/Is/7JxVjpee it6PF81+f6PCX6AQT5Cv+QMzqmBKLfp+IyKRL12rQ1ic7+Y0FM8bXaumeqORxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733996809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=66rbOPJ8nQ2TDUUr9gCIjuq4jnPshpq06qlrlDlS2Zs=; b=XtAU51sm5LC7S073/xctpDZr/QmTZfPKVdkCcr2mH+Bdm6LulorksIJlVgDvvuLXzyu1l5 YNXvsyxc2W/dU3jAYqymCrmqsLqQ9hV94p0d7vL6m79E96mj/pxnhCDc3QIF7j+xhorB/M hgNox/bLDw70ysfNJU4goA/vFhe55MGQyRGAcpXMLIvIgW7BghIpDnPypFjGLt0r8MP5B5 RYqfMElI/4fndXnmb/tkaUXNpp9e12nnC9o4uXQfpaAu6YBQRlftiiMqykCX6sdKqKr6kG gT6UhSTnS359dmutNMVeHesUqEW5mFbOIAppfkyxz17OsV0JCwA6CqLzsr/Lww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733996809; a=rsa-sha256; cv=none; b=J3LUKQm4SAx0aXQ38HxWJXZBCBz9ZNyIo7m+vNX0N85s2OSgSGMsWGQB7DiN7BqGYxCZ+C 5sQT9GqQXFaqVtc/dK3Y0ddD52W9QcQ14IUj2YMInOEdQoJxopPvgDpM4A5d7UFykEYEJR DI5ieEuHLjzjecb5doVMUyW3mUkafdaD3BTwv4fc9yVMMLNJHkqgQNzs6W3SvMSJhK0u5I W2qFvjVob9SxfEWkdixL7F1TEgLu/+BJxkfZcBpV0/Qpudo2/HtK4uJXNtF6UlJdQcdOtj N5nwc/JyfxBymzvZGsBHuzKX/vpWb/lWZCIubAAuyF4v5S6KfCJnpA9EsgvPuA== Received: from smtpclient.apple (unknown [IPv6:2001:19f0:6001:9db:98f0:9fe0:3545:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Y870S51vrz1D5V; Thu, 12 Dec 2024 09:46:48 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <3FBDFCF4-4427-4653-9EE4-EBC44DCB72ED@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A" 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 \(3696.120.41.1.10\)) Subject: Re: Module variable initialization Date: Thu, 12 Dec 2024 17:46:40 +0800 In-Reply-To: Cc: FreeBSD CURRENT To: Rick Macklem References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 12, 2024, at 10:44 AM, Rick Macklem = wrote: >=20 > Hi, >=20 > Bugzilla pr#282156 reports a crash that appears to be caused by > a NFS client variable (nfscbd_pool) not being initialized when a > NFS mount is done. >=20 > Now, the NFS client module (nfscl.ko) is weird in that it has > two definitions for the module. There is a VFS_SET() one for > the file system and a separate DECLARE_MODULE() for nfscl. > (The latter exists so that the module can refuse to unload and > define dependencies on other modules.) >=20 > The variable (nfscbd_pool) is initialized in the modevent() function > for nfscl in the MOD_LOAD section. >=20 > Does anyone know if this can somehow result in the variable not > being initialized when an NFS mount occurs? I'm not familiar with NFS. =46rom a quick look of the source code I = think `nfscbd_pool` is correctly initialized. I do not know the exact version pr#282156, so I guess and tried 14.1-p1, ``` $ addr2line -fip -e = /.zfs/snapshot/14.1-p1/usr/lib/debug/boot/kernel/kernel.debug = 0xffffffff80e1c558 svc_run at /usr/src/sys/rpc/svc.c:1414 ``` = https://cgit.freebsd.org/src/tree/sys/rpc/svc.c?h=3Dreleng/14.1&id=3D0892d= ff104440867956a53e78c12d66090fec36b#n1414 If `nfscbd_pool` is NULL, then I expect the panic should happens = earlier. Say line 1405 or event earlier line 1389 . Maybe `svc_run_internal()` is to be blamed ? >=20 > And, if the above is possible, would doing the initialization in the > vfs_init function for VFS_SET() be guaranteed to happen before > a mount is done? The order of modules seems right to me. nfscl module has order = SI_ORDER_FIRST and VFS_SET(... nfs ... ) has SI_ORDER_MIDDLE. >=20 > Thanks for any help with this, rick >=20 Best regards, Zhenlei --Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Dec 12, 2024, at 10:44 AM, Rick Macklem <rick.macklem@gmail.com> wrote:

Hi,
Bugzilla pr#282156 reports a crash that = appears to be caused by
a NFS client variable = (nfscbd_pool) not being initialized when a
NFS mount is = done.

Now, the NFS client module (nfscl.ko) = is weird in that it has
two definitions for the module. = There is a VFS_SET() one for
the file system and a = separate DECLARE_MODULE() for nfscl.
(The latter exists so = that the module can refuse to unload and
define = dependencies on other modules.)

The = variable (nfscbd_pool) is initialized in the modevent() function
for nfscl in the MOD_LOAD = section.

Does anyone know if this can = somehow result in the variable not
being initialized when = an NFS mount occurs?

I'm not familiar with NFS. =46rom a quick look of the = source code I think
`nfscbd_pool` is correctly initialized.

I do not know the exact version pr#282156, so I guess and tried = 14.1-p1,
```
$ addr2line= -fip -e /.zfs/snapshot/14.1-p1/usr/lib/debug/boot/kernel/kernel.debug = 0xffffffff80e1c558
svc_run = at /usr/src/sys/rpc/svc.c:1414
```


If `nfscbd_pool` is NULL, then I expect the panic should happens = earlier. Say line 1405 or event earlier line 1389 .

Maybe `svc_run_internal()` is to be blamed ?


And, if the above is possible, would doing the = initialization in the
vfs_init function for VFS_SET() be = guaranteed to happen before
a mount is done?

The = order of modules seems right to me. nfscl module has order  SI_ORDER_FIRST
and VFS_SET(... nfs ... ) has SI_ORDER_MIDDLE.


Thanks for any help with this, rick


Best regards,
Zhenlei

= --Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A-- From nobody Thu Dec 12 12:11:42 2024 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 4Y8BCk3BtCz5gBxJ for ; Thu, 12 Dec 2024 12:11:46 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y8BCk2gnSz4LbF; Thu, 12 Dec 2024 12:11:46 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734005506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1bWfePJb7c/cTM84xlrdRXgL16Thc7p4n1X3E2ZKOtc=; b=IIbWpebDms1keBglihwy1Odysthc+ux3XZp9bMUAz9uK1m9yifjXFGBQTL6fTCpyvayEBc atG45+FtdGQ/+1aPmq8Tmd+wavQ1flqnQsMrWH1F9fnX5VWUNs7JCLHp8Ayy73Heql19LO PwlVoCwTHRgbv4ZGhvnrC7oGX66hqhCOxitLqY5Rt/dPa9kdl54Ez/BI5klUTfv6BtuMxH 2rqpm9qX00KeTfl5ilZMkMCP5NziaNf3JqJpMKPOvreMcEychGd57Vo/4QCJ5Y4KwO1P6h pjnYL7JL+hqlhgDWKs7zt0EIt5/4Ln0AmehOL8KyKeCwpvLhjdXHDvnoPpqpDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734005506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1bWfePJb7c/cTM84xlrdRXgL16Thc7p4n1X3E2ZKOtc=; b=CQKS8FCLqJtKBuvMwJk9B1VR0PRAxy/LupRaVCeeY7w/nsphd4SkJvm2k0WrKu9snvaZSo TV/CiVV6/NwwT1vjL1VTfLlnCgNnQrjOT2AfvNVSRHXZzi/fdz1BeWvdevNFEmgEulOjMj M2aX258aH/GMa0NrgFjhVr6AxgNS87GDRqmF88xZUucs1P25+FcGMAGakIYCLApJ7HvpxO 3mb8qO6KKVSrUPBTdLYVfpgLVvuh5BUa7lLi4dWWnUuuU5mLLZ41BpoV3a47aigKdzCuEa paaUYt3jnCtOwxPAqVtetTB5yea9LiNBBk85S6NQJ7PNXnungag9ezX4K1y8Yg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734005506; a=rsa-sha256; cv=none; b=a/IuM/zoAQlKb53qrpaBUbafrrvYMVqugrhjf08AFdU4/nkWda+3hvIB/9KEhHlxAE797u QkvwbJrmuC8Umht9ew8KVWK9p1ho8oHyY6lejJ8IubsA6duTVUK9Q/DgsxbAB3tA2i75FZ ec/Rl1DXrW9FUIG3TpzNtaSw9rAGa/vXVG++0lCfNpEL9w75frydyki5XvCNXNeDrBLmg7 an8HKL/No7FY+Cpb1t0KTNnhsjcO0fBH+bpj6aMCZK8X65bqNVHOXopvbf0+IO4pFHexdu UatDEVXIl/gmXrfPr/zc4C0lD7ELFMLTKHbP90dhG1HXlwKPskKnA8CgB0CS1g== Received: from [IPV6:2001:1c00:2709:2010:c129:38:42e1:4c97] (2001-1c00-2709-2010-c129-0038-42e1-4c97.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:2709:2010:c129:38:42e1:4c97]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Y8BCk0LpYz1HV2; Thu, 12 Dec 2024 12:11:45 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Content-Type: multipart/alternative; boundary="------------Rq1g26V7jo6qrFVI1I9FqJGt" Message-ID: <33cbcbbd-bf36-4059-a012-842c7ff80568@FreeBSD.org> Date: Thu, 12 Dec 2024 13:11:42 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Ronald Klop Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out To: "Andrey V. Elsukov" Cc: freebsd-current@freebsd.org References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> <20241209191947.39ac4843@thor.intern.walstatt.dynvpn.de> <6B720B82-09EF-4208-B814-B6BD75FC2F0E@FreeBSD.org> Content-Language: en-US In-Reply-To: This is a multi-part message in MIME format. --------------Rq1g26V7jo6qrFVI1I9FqJGt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgQW5kcmV5LA0KDQpXaXRoIHlvdXIgcGF0Y2ggYXBwbGllZCBJIGRvbid0IGhhdmUgdGhl IHN5bXB0b21zIG9mICdoYW5naW5nJyB0Y3AgY29ubmVjdGlvbnMgYW55bW9yZS4NClRoYW5r cyBmb3IgbG9va2luZyBpbnRvIGl0Lg0KDQpSZWdhcmRzLA0KUm9uYWxkLg0KDQoqVmFuOiog IkFuZHJleSBWLiBFbHN1a292IiA8YnU3Y2hlckB5YW5kZXgucnU+DQoqRGF0dW06KiBkb25k ZXJkYWcsIDEyIGRlY2VtYmVyIDIwMjQgMDk6NTMNCipBYW46KiBmcmVlYnNkLWN1cnJlbnRA ZnJlZWJzZC5vcmcNCipPbmRlcndlcnA6KiBSZTogKGlwZncpIFJlOiBIRUxQISBmZXRjaDog c3R1Y2sgZm9yZXZlciBPUiBlcnJvcjogUlBDIGZhaWxlZDogY3VybCA1NiByZWN2IGZhaWx1 cmU6IE9wZXJhdGlvbiB0aW1lZCBvdXQNCg0KICAgIE9uIDExLjEyLjIwMjQgMTY6MjUsIFJv bmFsZCBLbG9wIHdyb3RlOg0KICAgICA+IEkgZGlkIGEgYmlzZWN0IG9mIGNvbW1pdHMgYW5k IG15IGZpbmRpbmcgaXMgdGhhdCBjb21taXQgMzQ3ZGQwNTMgb24gPiAyMDI0LTExLTI5IGlz IHRoZSBjYXVzZS4NCiAgICAgPg0KICAgICA+ICJ0Y3A6IGFkZCBUSF9BRSBjYXBhYmlsaXRp ZXMgdG8gcHBwIGFuZCBwZiINCiAgICAgPiBodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9m cmVlYnNkLXNyYy9jb21taXQvMzQ3ZGQwNTM5ZjNhNzVmZGYyMTI4ZGQ0NjIwY2E5OWU5NmYz MTFlOQ0KICAgICA+DQogICAgID4gVGhlIGNvbW1pdCBiZWZvcmUgKDBmYzdiZGM5NzgpIHdv cmtzIGZpbmUuDQogICAgID4NCiAgICAgPiBJIGNjJ2VkIHRoZSBhdXRob3Igb2YgdGhlIGNv bW1pdC4NCiAgICAgPiAoZm9yIGNvbnRleHQ6IHN0YXJ0IG9mIHRoZSB0aHJlYWQgaXMgaGVy ZTogPiBodHRwczovL2xpc3RzLmZyZWVic2Qub3JnL2FyY2hpdmVzL2ZyZWVic2QtY3VycmVu dC8yMDI0LURlY2VtYmVyLzAwNjc3OC5odG1sLCBpdCBsb29rcyBsaWtlIHRoZSBjb21taXQg YnJlYWtzIGEgc3RhdGVmdWxsIGlwZncgZmlyZXdhbGwpDQoNCiAgICBIaSwNCg0KICAgIHRo YW5rcyBmb3IgYmlzZWN0aW5nLiBJIHRoaW5rIHRoaXMgcGF0Y2ggc2hvdWxkIGZpeCBwcm9i bGVtIHdpdGggc3RhdGVmdWxsIGlwZnc6DQoNCiAgICAtLS0gYS9zeXMvbmV0cGZpbC9pcGZ3 L2lwX2Z3X2R5bmFtaWMuYw0KICAgICsrKyBiL3N5cy9uZXRwZmlsL2lwZncvaXBfZndfZHlu YW1pYy5jDQogICAgQEAgLTkyNyw3ICs5MjcsNyBAQCBwcmludF9keW5fcnVsZV9mbGFncyhj b25zdCBzdHJ1Y3QgaXBmd19mbG93X2lkICppZCwgaW50IGR5bl90eXBlLA0KICAgICDCoMKg I2RlZmluZSDCoMKgwqDCoMKgwqDCoF9TRVFfR0UoYSxiKSDCoMKgwqAoKGludCkoKGEpLShi KSkgPj0gMCkNCiAgICAgwqDCoCNkZWZpbmUgwqDCoMKgwqDCoMKgwqBCT1RIX1NZTiDCoMKg wqDCoMKgwqDCoChUSF9TWU4gfCAoVEhfU1lOIDw8IDgpKQ0KICAgICDCoMKgI2RlZmluZSDC oMKgwqDCoMKgwqDCoEJPVEhfRklOIMKgwqDCoMKgwqDCoMKgKFRIX0ZJTiB8IChUSF9GSU4g PDwgOCkpDQogICAgLSNkZWZpbmUgwqDCoMKgwqDCoMKgwqBUQ1BfRkxBR1MgwqDCoMKgwqDC oMKgKFRIX0ZMQUdTIHwgKFRIX0ZMQUdTIDw8IDgpKQ0KICAgICsjZGVmaW5lIMKgwqDCoMKg wqDCoMKgVENQX0ZMQUdTIMKgwqDCoMKgwqDCoCgoVEhfRkxBR1MgJiAweGZmKSB8ICgoVEhf RkxBR1MgJiAweGZmKSA8PCA4KSkNCiAgICAgwqDCoCNkZWZpbmUgwqDCoMKgwqDCoMKgwqBB Q0tfRldEIMKgwqDCoMKgwqDCoMKgwqAweDAwMDEwMDAwIMKgwqDCoMKgwqAvKiBmd2QgYWNr IHNlZW4gKi8NCiAgICAgwqDCoCNkZWZpbmUgwqDCoMKgwqDCoMKgwqBBQ0tfUkVWIMKgwqDC oMKgwqDCoMKgwqAweDAwMDIwMDAwIMKgwqDCoMKgwqAvKiByZXYgYWNrIHNlZW4gKi8NCiAg ICAgwqDCoCNkZWZpbmUgwqDCoMKgwqDCoMKgwqBBQ0tfQk9USCDCoMKgwqDCoMKgwqDCoChB Q0tfRldEIHwgQUNLX1JFVikNCg0KICAgIC0tIA0KICAgIFdCUiwgQW5kcmV5IFYuIEVsc3Vr b3YNCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== --------------Rq1g26V7jo6qrFVI1I9FqJGt Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Andrey,

With your patch applied I don't have the symptoms of 'hanging' tcp connections anymore.
Thanks for looking into it.

Regards,
Ronald.

 

Van: "Andrey V. Elsukov" <bu7cher@yandex.ru>
Datum: donderdag, 12 december 2024 09:53
Aan: freebsd-current@freebsd.org
Onderwerp: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On 11.12.2024 16:25, Ronald Klop wrote:
> I did a bisect of commits and my finding is that commit 347dd053 on > 2024-11-29 is the cause.
>
> "tcp: add TH_AE capabilities to ppp and pf"
> https://github.com/freebsd/freebsd-src/commit/347dd0539f3a75fdf2128dd4620ca99e96f311e9
>
> The commit before (0fc7bdc978) works fine.
>
> I cc'ed the author of the commit.
> (for context: start of the thread is here: > https://lists.freebsd.org/archives/freebsd-current/2024-December/006778.html, it looks like the commit breaks a statefull ipfw firewall)

Hi,

thanks for bisecting. I think this patch should fix problem with statefull ipfw:

--- a/sys/netpfil/ipfw/ip_fw_dynamic.c
+++ b/sys/netpfil/ipfw/ip_fw_dynamic.c
@@ -927,7 +927,7 @@ print_dyn_rule_flags(const struct ipfw_flow_id *id, int dyn_type,
  #define        _SEQ_GE(a,b)    ((int)((a)-(b)) >= 0)
  #define        BOTH_SYN        (TH_SYN | (TH_SYN << 8))
  #define        BOTH_FIN        (TH_FIN | (TH_FIN << 8))
-#define        TCP_FLAGS       (TH_FLAGS | (TH_FLAGS << 8))
+#define        TCP_FLAGS       ((TH_FLAGS & 0xff) | ((TH_FLAGS & 0xff) << 8))
  #define        ACK_FWD         0x00010000      /* fwd ack seen */
  #define        ACK_REV         0x00020000      /* rev ack seen */
  #define        ACK_BOTH        (ACK_FWD | ACK_REV)

-- 
WBR, Andrey V. Elsukov

 

  --------------Rq1g26V7jo6qrFVI1I9FqJGt-- From nobody Thu Dec 12 16:27:20 2024 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 4Y8Hts6FP7z5gSqZ for ; Thu, 12 Dec 2024 16:27:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4Y8Hts3XTxz4kVx; Thu, 12 Dec 2024 16:27:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5d2726c0d45so1425477a12.2; Thu, 12 Dec 2024 08:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734020852; x=1734625652; 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=Z4Xh4F5uOx13HyraeRCyNTUBRBLxJMeEUCHUhjMUmdk=; b=bTRtxv31yL+IYkC9PuU9NqKTwcNPLexIbZ+MsNUJghmmgeD8TgNDGQuhp7SGW709EJ En5VEJJtNm/MosHGt9NJvJUEqQuCP+PMGhXs7WcWF2sWf1r+qvP+pu21Dpgb/4uWCsAO YQQigbqDzRi1cDqgmWln9onWPRA8ErCZN+Jd7VbWlBicIYpgjGA37Nrb+vDHe6J81AzV uV+PIFzGqwlGdP5P0q/XgK4x2d33/NuRVClULeXN1GLj0DbeHqo6VePeG43gKSkO/eJ4 BocfJvtbFOE8e2KtJTGKTTMHIeSv82AWlEMVy+KjtA3ibuayo6dtU8AZo5JbmV/FK3UZ UKXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734020852; x=1734625652; 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=Z4Xh4F5uOx13HyraeRCyNTUBRBLxJMeEUCHUhjMUmdk=; b=uWgQdmb3CzlPqBXfWY0KW+KUWn4yTrJALe8CfkNULmNklXS6ev4f9EU6Ayj1lvvIMn C4wHhbtJWXwHSr1IcRL5gqh7ATKnxDWYEi3Z+83qShQR1lR0OEczMcdeCa/xUklzwVoB jQk6ZXZXzux4QXSEnfMPJDaNFzvxiANPpwsQgzeKe3PvPl2BYRPsAeKX3YYTza/D+ejE awEGNaLaghbj8L+OcbmKS1ceGMTqe737jhGsS35g6cKCbmBzv8weteyWT5qqTzDUMMDL gEmjLTL/oHJLQznUunR0BrPqvegHZGt2A9IF5sEojuSPoy66P7toxjcr93iOvQe3mhvM obEg== X-Gm-Message-State: AOJu0Yxk0Uqz0puR91F9fSW+CrZXWlGgrJtgG2EKnPTmdIrzn4qUCK1I GVTtjYfYR0kObOhaQUPuRDrB2U1frS7vFR3zzBBdkX6kp1T8eI7ql78lxiAsXg75zMoPihtWkso elt2K4i1lJWWLxclLx918EtbM931T X-Gm-Gg: ASbGnctU+b7g3GPvFrqIPpFke/HyegObVpYGYAeCjaf5kW7Zt5zSbfa3FUJGX6YWZfW qmyGfQdrFRkJmI2bcSGhlNZuF/8nAV/PdNSbAxNoTBhS6iiZiu0i747LPzWe1SRv3mOeStw== X-Google-Smtp-Source: AGHT+IGwE5LeuYgvwFeKRy20hp17KeSzg6ih609R1bz///c9UzrNOzgKlSC63o/9GTWsvZ9aX/oRkBkcNiPxZ6jEjdI= X-Received: by 2002:a05:6402:358e:b0:5d2:723c:a559 with SMTP id 4fb4d7f45d1cf-5d63237a498mr946183a12.10.1734020851217; Thu, 12 Dec 2024 08:27:31 -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 References: <3FBDFCF4-4427-4653-9EE4-EBC44DCB72ED@FreeBSD.org> In-Reply-To: <3FBDFCF4-4427-4653-9EE4-EBC44DCB72ED@FreeBSD.org> From: Rick Macklem Date: Thu, 12 Dec 2024 08:27:20 -0800 Message-ID: Subject: Re: Module variable initialization To: Zhenlei Huang Cc: FreeBSD CURRENT 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)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Y8Hts3XTxz4kVx X-Spamd-Bar: ---- On Thu, Dec 12, 2024 at 1:46=E2=80=AFAM Zhenlei Huang wr= ote: > > > > On Dec 12, 2024, at 10:44 AM, Rick Macklem wrote= : > > Hi, > > Bugzilla pr#282156 reports a crash that appears to be caused by > a NFS client variable (nfscbd_pool) not being initialized when a > NFS mount is done. > > Now, the NFS client module (nfscl.ko) is weird in that it has > two definitions for the module. There is a VFS_SET() one for > the file system and a separate DECLARE_MODULE() for nfscl. > (The latter exists so that the module can refuse to unload and > define dependencies on other modules.) > > The variable (nfscbd_pool) is initialized in the modevent() function > for nfscl in the MOD_LOAD section. > > > Does anyone know if this can somehow result in the variable not > being initialized when an NFS mount occurs? > > > I'm not familiar with NFS. From a quick look of the source code I think > `nfscbd_pool` is correctly initialized. > > I do not know the exact version pr#282156, so I guess and tried 14.1-p1, > ``` > $ addr2line -fip -e /.zfs/snapshot/14.1-p1/usr/lib/debug/boot/kernel/kern= el.debug 0xffffffff80e1c558 > svc_run at /usr/src/sys/rpc/svc.c:1414 > ``` > > https://cgit.freebsd.org/src/tree/sys/rpc/svc.c?h=3Dreleng/14.1&id=3D0892= dff104440867956a53e78c12d66090fec36b#n1414 > > If `nfscbd_pool` is NULL, then I expect the panic should happens earlier.= Say line 1405 or event earlier line 1389 . This is not a panic most see. I haven't been able to reproduce it and I think it has been reported by one other person. However, if you look at 282156, you'll see that the address is d0 (208). This is almost guaranteed to be a NULL pointer to a structure. I looked at the structures accessed via the callback stuff and the only one with a field at offset 208 is SVCPOOL. The code does use nfscbd_pool in the NFS common code, where it sets xprt->xp_pool =3D nfscbd_pool in svc_vc_create_backchannel(), which is called when a TCP connection for a mount is created. --> So, one theory is that the code somehow does this before nfscbd_pool is set non-null. --> Another would be that some runaway pointer set it back to NULL. Anyhow, I will probably get the reporter to add some sanity checks to their code to try and see what the results of that are. > > Maybe `svc_run_internal()` is to be blamed ? In a sense, yes, in that the crash occurs in there. However, this code is worked heavily for the NFS server and doesn't demonstrate issues that I am aware of. Thanks for your comments, rick > > > And, if the above is possible, would doing the initialization in the > vfs_init function for VFS_SET() be guaranteed to happen before > a mount is done? > > > The order of modules seems right to me. nfscl module has order SI_ORDER_= FIRST > and VFS_SET(... nfs ... ) has SI_ORDER_MIDDLE. One additional issue is that nfscbd_pool is actually declared in the nfscommon module and the use of it that might "save" the NULL value in xp_pool before it gets set non-NULL is also in nfscommon. Maybe there is some memory cache issue where the stale (set to NULL) value = for nfscbd_pool persists in the nfscommon module for long enough to cause this? (It is a stretch, but I am pretty well running out of thoughts on this.) --> I could move the initialization into the nfscommon module easily enough= . I might create such a patch for the reporter to try. Thanks for your comments, rick > > > Thanks for any help with this, rick > > > Best regards, > Zhenlei > From nobody Thu Dec 12 17:13:09 2024 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 4Y8Jw50PxSz5gW9m; Thu, 12 Dec 2024 17:13:41 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4Y8Jw45PsSz4qLD; Thu, 12 Dec 2024 17:13:40 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id E1FC124098D; Thu, 12 Dec 2024 18:13:38 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 16ADD2402D8; Thu, 12 Dec 2024 18:13:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1734023617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Mwr9BR4LbDSA5z91tOxKB61kr++W2bPEdvC7wcNho6w=; b=AyaD1TZo/rcPQ6jA47j2PESs3TN4h6uD4s9qkCraYlumWqgx5EFite9eeaPscTqnknczM4 xojObUNBQhnN7dJUI8rFWT9ox22QbKHgWWPSftfIZgOs2plJ3QqDYcgx8r8e0wF76Ub/M+ 1iTKzmUu/FWvLrVJuo1bWBH59AWufLnIAeQGpqSk9sx6YMKqCtGopmH24vStKuE5p/T2eI kJwIV14XZJbF0loB4quhra4ArTS8de8W5Tn3bAdqn/3cC0bOO4mVXWVnrlc/mzdd6czMqI dom2oIZLtwMWTd/F78fuGd2SUkD5r3EehdbhhhMHYqE4aLUQWS5geEb1+jF/+w== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-055-054-119.78.55.pool.telefonica.de [78.55.54.119]) (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) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id BB0932402D7; Thu, 12 Dec 2024 18:13:36 +0100 (CET) Date: Thu, 12 Dec 2024 18:13:09 +0100 From: FreeBSD User To: "Andrey V. Elsukov" Cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: git: 9ea8d692f4cb - main - ipfw: use only needed TCP flags for state tracking Message-ID: <20241212181336.01db53f2@thor.intern.walstatt.dynvpn.de> In-Reply-To: <202412121306.4BCD6sqR017458@gitrepo.freebsd.org> References: <202412121306.4BCD6sqR017458@gitrepo.freebsd.org> Organization: walstatt-de.de 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-Transfer-Encoding: 7bit X-Rspamd-UID: db1dde X-Rspamd-UID: 3f15e0 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:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Queue-Id: 4Y8Jw45PsSz4qLD X-Spamd-Bar: ---- Am Thu, 12 Dec 2024 13:06:54 GMT "Andrey V. Elsukov" schrieb: > The branch main has been updated by ae: > > URL: https://cgit.FreeBSD.org/src/commit/?id=9ea8d692f4cb552902b9e8394260d7f3cf4aefb0 > > commit 9ea8d692f4cb552902b9e8394260d7f3cf4aefb0 > Author: Andrey V. Elsukov > AuthorDate: 2024-12-12 12:57:45 +0000 > Commit: Andrey V. Elsukov > CommitDate: 2024-12-12 12:57:45 +0000 > > ipfw: use only needed TCP flags for state tracking > > This fixes stateful firewall failures after adding TH_AE flag > into TH_FLAGS. > > Reported by: ronald > Fixes: 347dd05 > MFC after: 2 weeks > --- > sys/netpfil/ipfw/ip_fw_dynamic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sys/netpfil/ipfw/ip_fw_dynamic.c b/sys/netpfil/ipfw/ip_fw_dynamic.c > index 34aae71c174b..ff55e3360c13 100644 > --- a/sys/netpfil/ipfw/ip_fw_dynamic.c > +++ b/sys/netpfil/ipfw/ip_fw_dynamic.c > @@ -920,7 +920,8 @@ print_dyn_rule_flags(const struct ipfw_flow_id *id, int dyn_type, > #define _SEQ_GE(a,b) ((int)((a)-(b)) >= 0) > #define BOTH_SYN (TH_SYN | (TH_SYN << 8)) > #define BOTH_FIN (TH_FIN | (TH_FIN << 8)) > -#define TCP_FLAGS (TH_FLAGS | (TH_FLAGS << 8)) > +#define BOTH_RST (TH_RST | (TH_RST << 8)) > +#define TCP_FLAGS (BOTH_SYN | BOTH_FIN | BOTH_RST) > #define ACK_FWD 0x00010000 /* fwd ack seen */ > #define ACK_REV 0x00020000 /* rev ack seen */ > #define ACK_BOTH (ACK_FWD | ACK_REV) > The problem reported is now also present in 14-STABLE! -- O. Hartmann From nobody Thu Dec 12 19:19:46 2024 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 4Y8MjP0rHrz5gdkN for ; Thu, 12 Dec 2024 19:19:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y8MjN44zyz46FJ for ; Thu, 12 Dec 2024 19:19:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 4BCJJlZW049549 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 12 Dec 2024 11:19:47 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 4BCJJkUq049548; Thu, 12 Dec 2024 11:19:46 -0800 (PST) (envelope-from fbsd) Date: Thu, 12 Dec 2024 11:19:46 -0800 From: bob prohaska To: Mark Millard Cc: FreeBSD Current Subject: Re: Cleaning before using WITH_META_MODE Message-ID: References: <1C9B6B0E-1D02-4ADE-BABE-9E0238F96FBE.ref@yahoo.com> <1C9B6B0E-1D02-4ADE-BABE-9E0238F96FBE@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=us-ascii Content-Disposition: inline In-Reply-To: <1C9B6B0E-1D02-4ADE-BABE-9E0238F96FBE@yahoo.com> 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:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Queue-Id: 4Y8MjN44zyz46FJ X-Spamd-Bar: ---- On Wed, Dec 11, 2024 at 02:27:22PM -0800, Mark Millard wrote: > bob prohaska wrote on > Date: Wed, 11 Dec 2024 18:38:28 UTC : > > > What cleaning options minimize interference with the use of WITH_META_MODE ? > > I'm not so sure there is a viable optimization of the type asked > about, other than cleaning only part of the overall structure > if/where such might be viable. > That hits the nail on the thumb 8-) I was hoping to minimize world re-build time when what looks like a trivial error occurs. Guess it's not possible, except to run make clean in the directory where the failure occurred. Thanks to all who responded! bob prohaska From nobody Fri Dec 13 21:15:45 2024 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 4Y92FC4rbSz5g7ll for ; Fri, 13 Dec 2024 21:15:59 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 4Y92FB4RWLz4YD1 for ; Fri, 13 Dec 2024 21:15:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-844d67eb693so152303139f.3 for ; Fri, 13 Dec 2024 13:15:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734124557; x=1734729357; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lxAyzWImpAsfQKnTmjz1DM8LFLAfFYCZDKv0TeKQa+s=; b=hLnkL35Ew8HDDRlZiGSfViP1Ln2QyJ59aW4cwu1XK6fm6f2xPuKAWlSxPETmF+X+hC Hw2K9WGepERBpVkbmUDt8tqeDZcfVTZvg+r1khK+oqtyNpIHPsgd5PYWxsYkCwwFTbgz Yqw503w1Oh/aPNCMwpG3mmITIIgGJEbsnEJl6JXQrek6mHhIyb8+PZPiPi1CZWda9Q78 9wav+VfnIERGzF8vR8VPH0KvXWFTTVQFhmqUv/0PeKZjdTbmoaB8dXwL5OIB0EAtWrqs ch4IjP6c7iBZV+sb/kDTGkXlfGYCqwTzOPeD25VVuXntzA2c/B6UheqfML3+69Toluzx npPA== X-Gm-Message-State: AOJu0YxagyoHE0DwDh+ntFu0urwA2I6/6vYID5Et8HpIMQCrLCQ2zFLI gfe/5t4a0zyl3b5PudWp931+4efq+SSz2zePnIvjGvNNlc1XY7UEyzemMGX711gwvkvVSPpp/PD spUspmIO+P30/aFx6omkGl5KE2n1l1Oua X-Gm-Gg: ASbGncuGNAf38J/dlhE1fiEg6DybR9QCSQ2ttTUduNyBrsW94499caslutac2zxJ2R/ sjMqkzXWGIty8ZUhFsdYPZovMAoIbcACNfnWepS12o+w/6RQYk5zbDq5FXpL2zL8LM/IsIb4= X-Google-Smtp-Source: AGHT+IEfiJPFu1LE9hHIITiq9PYUwwHpn54/6KyDV4tpbd8UJtt4rBm4hnDIRaPKzQWMlK042bnA/vNQqSowK0pZh9Y= X-Received: by 2002:a05:6e02:1a07:b0:3a7:1f72:ad3c with SMTP id e9e14a558f8ab-3aff0961e22mr53735385ab.19.1734124556950; Fri, 13 Dec 2024 13:15:56 -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: Ed Maste Date: Fri, 13 Dec 2024 16:15:45 -0500 Message-ID: Subject: Switching release media dist sets to .tzst (tar + zstd)? To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-1.88 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.46:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.46:from] X-Rspamd-Queue-Id: 4Y92FB4RWLz4YD1 X-Spamd-Bar: - I have been reviewing parts of the release artifact build process, including ISO and memstick images, and came across the distribution sets (e.g., base.txz, src.txz) used by the installer to populate new file systems. I=E2=80=99d like to discuss switching these to .tzst (tar + zstd) compression. While I haven=E2=80=99t yet conducted detailed benchmarks comparing zstd an= d xz specifically for this use case, here are some initial considerations: Pros of zstd: - Faster compression and decompression speeds. - Aligns with the compression method used for FreeBSD packages. Cons of zstd: - Somewhat larger compressed file sizes. - Requires updates to tools that interact with distribution sets. - May have limited availability on some other operating systems (?). I have a review open to demonstrate the extent of the change in the build system & installer: https://reviews.freebsd.org/D48042 It might be that this is not worth pursuing, as dist sets will most likely go away with the migration to pkgbase, but I would like to discuss and make an explicit decision. We can separately consider compression on the release media images themselves. Feedback Requested: Is there support for this idea? Are there objections to pursuing this? Are there other factors I should consider, especially compatibility concern= s? From nobody Fri Dec 13 21:19:24 2024 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 4Y92KR11r2z5g8Df for ; Fri, 13 Dec 2024 21:19:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 4Y92KQ5MV9z4ZLs; Fri, 13 Dec 2024 21:19:38 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5d647d5df91so1256098a12.0; Fri, 13 Dec 2024 13:19:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734124776; x=1734729576; 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=aGJDmcnL3ejVmlCWWNabI428NoGqgg5eO/YEpnq3vmU=; b=sWiCNz1RAihGqU7e/XxhCGeFPmNjEiY+PcM7huF301JguGulEX45D4+rOlYJYH17jd 86LUdRJMTGPW/yldqQQro/uzTgeFC4D4Y9YN+gxWJGRrEU4MVsB7koNgfvENUZ9x3BJD FrDpheHw1QiN05o3Uif86r/e1bP5Uwv+G+hD8yAPMQ+81vLkMTm3oGKqDwemj/sCkUiS Wn3LbNUwZYrYpVDyLIsLtFsYhrGlbMIcGCd39KzUz1GKkMXuVBGW4dDGBcLHBjUzNfwV Nf41ki68FtP9vFJ7U5h19XqNmjPI+LS1qSFIoZNe6OP7zWqxFKfoAGvczRWhaMNCBkb2 8pIA== X-Gm-Message-State: AOJu0YzHjIH5oqTqJD/vukcS9CVdxHlo99JhVU8DvfAV4gBmKY5BSdal LMWQkz7LvLDoUdWckNW6K8Wv1s1MQcoFs89Lei2J5Tge2hBhiF4Pm2aWi1hIYpjyCWYq0wdcpFm O14S3DmZFRHPNFmsd0SGDu8kUfm7KlQ== X-Gm-Gg: ASbGncuCQEH2IMeAAY5fY5f3iDFsEL9tiDwIRIkgFuzeGuyEXhyPd1mI/4X/p+px/9O cQBd8d0GRSGZ7kXv6Hgpik9/Qt92Fnjbz1nWpmA== X-Google-Smtp-Source: AGHT+IEJ84E82+mv7m1H8w9hy0tgjkt2qEdd0hjVfzV8cEsBOgPsl9d/UWOAOPS7DfHc8T6xluvRGBJEk0/boNSpZqo= X-Received: by 2002:a05:6402:5242:b0:5d0:ee52:353e with SMTP id 4fb4d7f45d1cf-5d63c3c068cmr3199693a12.29.1734124775886; Fri, 13 Dec 2024 13:19:35 -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 References: In-Reply-To: From: Alan Somers Date: Fri, 13 Dec 2024 14:19:24 -0700 Message-ID: Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? To: Ed Maste Cc: FreeBSD Current 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)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Y92KQ5MV9z4ZLs X-Spamd-Bar: ---- On Fri, Dec 13, 2024 at 2:16=E2=80=AFPM Ed Maste wrote= : > > I have been reviewing parts of the release artifact build process, > including ISO and memstick images, and came across the distribution > sets (e.g., base.txz, src.txz) used by the installer to populate new > file systems. I=E2=80=99d like to discuss switching these to .tzst (tar + > zstd) compression. > > While I haven=E2=80=99t yet conducted detailed benchmarks comparing zstd = and > xz specifically for this use case, here are some initial > considerations: > > Pros of zstd: > - Faster compression and decompression speeds. > - Aligns with the compression method used for FreeBSD packages. > > Cons of zstd: > - Somewhat larger compressed file sizes. > - Requires updates to tools that interact with distribution sets. > - May have limited availability on some other operating systems (?). > > I have a review open to demonstrate the extent of the change in the > build system & installer: https://reviews.freebsd.org/D48042 > > It might be that this is not worth pursuing, as dist sets will most > likely go away with the migration to pkgbase, but I would like to > discuss and make an explicit decision. We can separately consider > compression on the release media images themselves. > > Feedback Requested: > > Is there support for this idea? Are there objections to pursuing this? > Are there other factors I should consider, especially compatibility conce= rns? Even with a good internet connection, I usually find that downloading the tarballs is slower than decompressing them. So I vote to stick with xz. From nobody Fri Dec 13 21:35:12 2024 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 4Y92gf1BRFz5g9fy for ; Fri, 13 Dec 2024 21:35:26 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (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 4Y92gd53RGz4cWK for ; Fri, 13 Dec 2024 21:35:25 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-6efa1e49ef0so19794227b3.2 for ; Fri, 13 Dec 2024 13:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1734125725; x=1734730525; 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=NodF4jHBRl1xkNj6JOGuLSji/Q9wOn4SDIQw1fkQdS0=; b=Y+VEav3NJ4+0bRxNOkq78IsZdNq1oM2uGXbtfZOwpvwgERdC1q2hCzxNYMKfmDrQtM aYx3DktFXgWY9cysgBr3gLcXy8NqQ5ioTIILirz05bspZwik/TczEkPIOdRJEcZ45eWU EA0nLgv/fUW3O87U7Bt589Rv3RBhv6Y8iggCBmPjC5+L/dU631eufqqdjS5Ke2w//L/j pT+HOxyUhZECHKH4i/x9859TRvKZZ8ZnTHOcYQoegTpYtpIwod1ywVrhiGi7f47ANVq0 NXcsqX9vmGYoKS4wLbNMk39MP7LyZUn4aJ45FzM8WDhYWbzBZL3TGM9704L56A0twnLW wYBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734125725; x=1734730525; 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=NodF4jHBRl1xkNj6JOGuLSji/Q9wOn4SDIQw1fkQdS0=; b=F8QZShE3bcOOFHEXPKlTMg4o7MucWNbIB0NBcYS2BKKKoxFTnA4jK9hxsLKc9OkOJW Ixj4vG0iktkdkx3oWMU1MKZf57wTR4ksFq5eCpI/Jnkiwe4qWfcg9akaerM7Xty6AmNw cFtdQqKHx/k5YeK3tB2bsncsN3A7gyYubuxMCBiSIdlYctupyiCNEmpw/buTUPv++IVA EBKZxdkYPtmS28z5vnIBnp09+2hWb3QLtTPkYE39xZJ8/mnRTE8kHUD3PdItBmy6rbcj +nTubQmWs8mHKo3VuSCYXEBHE/tzSX5CoBqDRVkH0dzMZKWTV9S+VlpELsj7N7GmD66G rRuA== X-Gm-Message-State: AOJu0Yxh9wxtFS95KoWOm+R65hcH34zTCcJAsmoRVqE+f0xeAVOOVQ2/ 7DN4IL+PBe49ROk5UzUAMOW+FwKhck/D/oKwFYR263wG6xg/QfdINAE6oQVmu9zgmvljbiA3MBQ = X-Gm-Gg: ASbGncvM7XH/hTt3MtmS5fbMYQMqLyy9372DgiOwwZXKTeIAWZI/E+CZD6s9Eu0qpFc YqcZQBKZmCEG86AmrnqMKGmEd9G6u9ROOoeyKA5kMZSFYO/Mbl+y9HN/LmN6FMBRHjqnxuAxvaM mp3tJksEoRpYj/zeac/WO6qmq9b7bJMREiGeJaiCUgqk4BKO8Y82WeHKINfRB8hOBYpH7nZhej6 dd/UvLCIrBz1uwkor1vB2Xw4QMT8+QE5pzjgNa0N5loGikA7HDNCTl3LQGUDqgZsR3bYCNZnWQZ BZNl1A3MvSDSw+P9DQ== X-Google-Smtp-Source: AGHT+IGc7zNia7xNkugVyBTKHtWWMVhLhUtkcKVN5xZ/cAjvQWVHciah5PaEVMnMZnOeeiAh0FaXHQ== X-Received: by 2002:a05:690c:64c6:b0:6ef:593e:285c with SMTP id 00721157ae682-6f279adcd82mr48490007b3.3.1734125724861; Fri, 13 Dec 2024 13:35:24 -0800 (PST) Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com. [209.85.128.182]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6f2890c8094sm1006587b3.91.2024.12.13.13.35.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Dec 2024 13:35:24 -0800 (PST) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-6f27c47b4e6so8242827b3.0; Fri, 13 Dec 2024 13:35:24 -0800 (PST) X-Received: by 2002:a05:690c:25c8:b0:6f0:237e:fc4c with SMTP id 00721157ae682-6f279b0b711mr40740077b3.12.1734125723660; Fri, 13 Dec 2024 13:35:23 -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 References: In-Reply-To: From: Tomek CEDRO Date: Fri, 13 Dec 2024 22:35:12 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? To: Ed Maste Cc: FreeBSD Current 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)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Y92gd53RGz4cWK X-Spamd-Bar: ---- On Fri, Dec 13, 2024 at 10:16=E2=80=AFPM Ed Maste wrot= e: > I have been reviewing parts of the release artifact build process, > including ISO and memstick images, and came across the distribution > sets (e.g., base.txz, src.txz) used by the installer to populate new > file systems. I=E2=80=99d like to discuss switching these to .tzst (tar + > zstd) compression. Why? > While I haven=E2=80=99t yet conducted detailed benchmarks comparing zstd = and > xz specifically for this use case, here are some initial > considerations: Benchmarks would be nice know what is the time-space benefit :-) > Pros of zstd: > - Faster compression and decompression speeds. > - Aligns with the compression method used for FreeBSD packages. > > Cons of zstd: > - Somewhat larger compressed file sizes. > - Requires updates to tools that interact with distribution sets. > - May have limited availability on some other operating systems (?). Seems like more cons than pros at first glance and even more in depth? > Feedback Requested: > Is there support for this idea? Are there objections to pursuing this? > Are there other factors I should consider, especially compatibility conce= rns? Not much clear benefit for a large (compatibility) breaking change on many levels, sounds like a NO GO :D --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Fri Dec 13 21:47:53 2024 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 4Y92y51pQHz5gBQK for ; Fri, 13 Dec 2024 21:47:57 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 4Y92y46BCQz4g1T for ; Fri, 13 Dec 2024 21:47:56 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x129.google.com with SMTP id e9e14a558f8ab-3a81a0277d3so6850725ab.3 for ; Fri, 13 Dec 2024 13:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1734126475; x=1734731275; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=wHWQuT6exLBsYrwBQHRBbp+ZWWOo58z0SRWPW3Wrq2U=; b=EDp1A0dPrv/7z1RY3P62IUBWctRS+/v5Y9kc3lCa65Jgrvd/yfoGwupJ0ETd9afhEg j0jkyqqMrJHMu4jPmG+Wokt1Gu0JNEaa3ioIQe1ZmKJLqmriKI4vMu+1O+SDAelZY4Xq MI5S6seGE0ITAPeQhV4WDjbNNRJnq8xSZ7sDlyO8W7CuPyPbbWEf30FsjqHEnQrJnZb8 7z0rt65xz2nQ684rM5rTSc4c0AZbFury/Rl3HK58dK2GqIAYeIiC+wJ4LxwvxfWx0SGm mjtFpipq5wvQB4E/TXXKyrId8kqvPBY32HcJ5WTLYDwrtUAT0qYOV5qJAcjnoJmtLiRK iRig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734126475; x=1734731275; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wHWQuT6exLBsYrwBQHRBbp+ZWWOo58z0SRWPW3Wrq2U=; b=Qf6GrnuVWyMzdAl/3QGDvx2Nc9tAH6XyLxLU0keuN4EWv4DQ7VzZ9+m7s6yN2srzsj yTPO1MShHY4fMuxblUe5TQzlA2Ut+KHbG0ttxLnfo61+iTKEkJn0nrGyp3ImxjFE5SBy Qc1zR2aDMPyirf3PhhClXIgNr8SAFJnfAAFbi8Jid0+UjK63GNaOXjaLB68sZg6jp++G pQ8K99O7tv+m3TtuorZc8EM+SooJO4Uon7HTstPQVutbQpytTOt7JrqPajdWGz/kEvKU Rx6jg+oGpRLz/qiOyLaUJF8v8Iq/oNc7R3GDFmZ31XoGgx7CtPB4yqNhuBIkzyjnwWjb yaOQ== X-Gm-Message-State: AOJu0YzMdcydPTHtmjGVngImHs6bP/9i8beGqBXE2PMR1+DgcNSNfSLn KqhO/YPnzx9cgy8wMjHPaWkj/gUiJr7Yz6VdsJR9pBpwUDsfmuKYtTAy7YEl2rXlgieGvZseD3J Exeg= X-Gm-Gg: ASbGncvh+XqZ42lfVD4MQQV0dq0SxilshSijYv9Zvse71e74316MTdGrVAZmrbOURvB yzAHG9n9TiRQcUlwmRUPzCC8kXt4Hve3S2GXRKdGYw8LoAfIhR/jYbnwZWzd2PFE7d+N1BATCdi 30w7zdMTwj4yPU2GDoYSG3+9REth/YqvNdekZcIQUY8xH1H+J/mWKQZ96WFEHVD7TvcGmaWW+jk NwTJzy3R+NqDS28E367AKQ9zOZIztjIC19p+Fg= X-Google-Smtp-Source: AGHT+IFIJoI6zW3mNj5g1/3vw6S+qPXKgsQbX7kanrnl8TTtp3QzBhAB/dTSuxuftBG+610CYiUsiQ== X-Received: by 2002:a92:c266:0:b0:3a8:1195:f1f9 with SMTP id e9e14a558f8ab-3aff50b324fmr54547905ab.6.1734126475381; Fri, 13 Dec 2024 13:47:55 -0800 (PST) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e5e0a3de83sm73992173.57.2024.12.13.13.47.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Dec 2024 13:47:54 -0800 (PST) Date: Fri, 13 Dec 2024 21:47:53 +0000 From: Shawn Webb To: Ed Maste Cc: FreeBSD Current Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jruhgstu4ull3b45" Content-Disposition: inline In-Reply-To: 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Y92y46BCQz4g1T X-Spamd-Bar: ---- --jruhgstu4ull3b45 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? MIME-Version: 1.0 Hey Ed, Thanks for providing the opportunity to discuss this before landing it. On Fri, Dec 13, 2024 at 04:15:45PM -0500, Ed Maste wrote: > I have been reviewing parts of the release artifact build process, > including ISO and memstick images, and came across the distribution > sets (e.g., base.txz, src.txz) used by the installer to populate new > file systems. I=E2=80=99d like to discuss switching these to .tzst (tar + > zstd) compression. >=20 > While I haven=E2=80=99t yet conducted detailed benchmarks comparing zstd = and > xz specifically for this use case, here are some initial > considerations: >=20 > Pros of zstd: > - Faster compression and decompression speeds. > - Aligns with the compression method used for FreeBSD packages. >=20 > Cons of zstd: > - Somewhat larger compressed file sizes. > - Requires updates to tools that interact with distribution sets. > - May have limited availability on some other operating systems (?). The tool for updating HardenedBSD installs (and the tool used to build the update artifacts) would be impacted. It wouldn't be too difficult to update the tools (hbsd-update and hbsd-update-build). However, if the switch zstd is not done at the same time for all supported branches (main and stable/14), we would need to have hbsd-update reference different archives between different branches--zstd for main and xz for stable/14. I would prefer not to have to include branch-specific code in a generic system updater utility. >=20 > I have a review open to demonstrate the extent of the change in the > build system & installer: https://reviews.freebsd.org/D48042 One thought might be to make the choice of compression method dynamic. Folks could then choose what makes sense for them. FreeBSD could make the switch to zstd while downstreams could still use xz (should they so choose.) HardenedBSD would likely stay on xz until it makes sense to follow its upstream. >=20 > It might be that this is not worth pursuing, as dist sets will most > likely go away with the migration to pkgbase, but I would like to > discuss and make an explicit decision. We can separately consider > compression on the release media images themselves. >=20 > Feedback Requested: >=20 > Is there support for this idea? Are there objections to pursuing this? > Are there other factors I should consider, especially compatibility conce= rns? For reference, hbsd-update can be found at [1] and hbsd-update-build can be found at [2]. [1]: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/blob/hardened/current= /master/usr.sbin/hbsd-update/hbsd-update?ref_type=3Dheads [2]: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/blob/hardened/current= /master/usr.sbin/hbsd-update/hbsd-update-build?ref_type=3Dheads Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --jruhgstu4ull3b45 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmdcq4EACgkQ/y5nonf4 4fps4hAAgkCULKlwU/+oOoN0qQOzTYrYzyQEizkYR3ZWCiKMfjgqgEeCG9ihhv1+ tHqkRCaO5rJDiFJviHG6UfhCaZvD2UhpAnDHwJu2ZPXRi746EU5VCHQndk+y19pL eeoZelqqb0KCDIfHZw+PNVozhec57ngP2VjCvRXtTjdXHNYufTkyIXe+R8VLmyEX 2Qh54Yy9cWKXrfcQNiCgJYWg2ZPZKghrZDEavTD/ss0Dwh3eETfwysb6x1YoxJfT XClYfNZvqng9TLi1PRabSSRinfw6sJJKTupN9kw1KHAR5CBxlf0cwDMp1d7mSQMt 3b4hAeVjLRtlUqqT/tnu1AohpP3XuIUWVyvLiLhWYinHcusm+QZJ5Z7oAMfIZnga NIsqeITbaHt4vMUxZ7aQht8Co4ZNDuI/KvZzmOAFIEyfvSI7+GoumwpdJAr8gkzI pYMEfbHaFCMGjrDhtkj6pyYFfvCiU9eOv0e6lItqmBKEgSUTHE2C6WayzsTlkp5A Y5/GiJfVycz522GFwoLXyzeKIn4Cojrd3vVQMihwTzsTaSltg8pl0KD+EAw7Ge2i Q2aUCa0jVABvD+5TQde+QOlLZpSYTv4f/0g8EkxuGO1EZNnulXp5udbWT3HVoLeX jggbK8y/9OGfL4gr0ujxp1gL+HSTvd19tHbf/dbpLKExPdkT2VU= =iIAH -----END PGP SIGNATURE----- --jruhgstu4ull3b45-- From nobody Sat Dec 14 00:42:13 2024 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 4Y96qV6SfGz5gNW8 for ; Sat, 14 Dec 2024 00:42:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4Y96qT6vk3z43fS for ; Sat, 14 Dec 2024 00:42:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=L62ywvGe; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734136947; bh=aQfB+R4hK6sg21ca9Qq/oraUFAVHkd8QNaGky3toy/s=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=L62ywvGeSYELZSpR6QY8Wotis23QeQpk19Xt+DlXP4coEOPPm8Dxv+yf8prpQTmC19q3U0WBdy6lJvSP0Rx/36tO5DOW32lAe1lSfZvtlPAzm4xIx49Er1zkD/xx7lwm3Mtds3VaBlNNmBBZKmEeiCO7uKeFT7Q38SUV/uYMzxTomIGPsd0yCyZd9OhrSICVO5L3uOMg2Rb4LRVoI1hlqLYruNMZJDxtGICZY6EXxB1Uvp5Oz7gAJlCQUHQnedNoI+ynMDrsNzxIsUD94d2aWP1lwCY7GxEKKxviyPs4ORgP6nahiAdYLlZeUnQyAmnoB9yAWoISjMaDqdmBPXrGOg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734136947; bh=dh3IVh3kIZa7D2FOUvAua4Y8MMSDRrXZnXiIuR252sg=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=p6HY1J/d9m673YPb/MaubxGnoTXppbNFCs4ADG2rD75A7fhfAmxn/JJ9w8cDOPFgSOtBEzI5w1CwmGF9XNYXptYtAIMybjST/6kDuwZYY/y+GmWtLg/8fsw+hZnJeBnG9ZTf8uqsXE3I9MJg9Vm5Pfd28Da4pluAN2cCVwZbA4PtPUdBDcoRAiw36WkxBJGQXs5lkWzrnzNuP+h37VYMK0m+PN1VPqIUMfiswrWLXnqvvY90ty0F7u58WVaZ3ZJ6dGmymTpQMKLngqf2bPVNz/xY4GLwmp71xKw1KwuxqDaz2gUDSS/8Q8l270UJLcVw6wIrWprjFT61WFUACXiNzA== X-YMail-OSG: j3utuvcVM1lZaTvi42n1JQ4I2XquhCYw92iVr1LI8zJmYq5tjFrjjlDqkmLN0YR ebtcYu8YWF73tkciVeVi719WKOOm60agSQa2jEN_nED4fkPYXTlosELyHNi7ypPBgy2iFQ73llr2 FgD08lciSf0ENNL5z1bMuA_zMlTrOBwl1f8LNOoCDzysv3N3rWKoZkF0Wrp_DDf4pGxWrr1N26y1 OznP5Ksg.8b2yIaG0IYWPcedkShSUvGdhJ2VT5IRkuc1co9wjiLNZKx4vSOsHQXaO5w7MObGXhYy UiM4MU7J.js1uFGwDAoPoQFSWUQf4O2jrneOKzd3U6WL.PP.xD4Aizk4b.Mv33kwcxPbdgcXtmK3 ptDPVzUoZN2pID02cndl.L_NpmEJT7mceIatEN.kCBAJci5q_O36qnTDmUBmUTJraQKhapTHWxYt 0IbpKs2X5wamtDMLtZ_fIBnBv6b2n9s3v4_nYdNxWB_PYSNq7uUrpUgRH5dPUyKNwwf11_vlDU.o Ya3fLBAXvvzm5x3vs5oooUG56YfMUs5DLPyGVJzJCbdCAhwIPFZWZRdBEu8Q.5E1vDzsLchDgwO7 wLEDKbVwgBM58I25xMuGp11lGU7TjLBsB1sfJpm0Ivla8ff9JY4OjI3qfHvtqpw8Ap4w7AB9nYRx JT0TSLUJYvym8CEDJqagrzrqgTQCT1B6cmpsgJNyhBKOzKuu.mgR2EXS1vZJezdakntoA7jBf3tN XkUuylrorw7hUpGHMy0E64xJDiC0NctXMcfLQH.lmi2cru93TFWT3TO90KwlVLzS.M6.P7tRtTty r4WuzAJFNyyXtSfzGbWD3xeoxYUrCRT5KLyTl.xDu9JF_w5D9fZhjHPRubm5SCPywzfe_AFq0_nr _4q4iDxiqj9sU.yX3YaL.K6tTAdG241gcFQs_zY8Rh4eh8latcQIqRcLlPe342HZcCu6sg3bJo8x EKMvT8yxHrHh04Y67FQy2HhwFEiXwiU9a_iod6c8M5x8fq._S9P..PxGzoXxbvgC.SxUI5xDERM6 qJaZFaA029D6bMb2al4dBgBTcGsQEz2pHhANcCFD2Fxrv.XsZKI3IcZVJLcgeah_lKpLAQ1qH5m7 XNDokBNNzlWcl_F3DnkIM.tzHQXErly2PC7a9SBbjzA03.kgP7wdHgIR0nThVE24_HyoEn4aQfdY SawmynvuUBV3t0aPRytBUgxl3MEEq48NMJrRT4w3BozZMqnHCGXh7iWmBGoWLOUN0J6t8Mv55CQ_ fcHjlHaJJsJ9DpwSbNDQ0bEoLnBKZXmuyOy4IsGnhhhjVBF8dVZcDGd9SGxC9HonIlANDelsPCOT X198AP5NX.nnw.aeUvT26hwODYvKEm8VmmBrmNPG74dt7zUvkrGIOLn4NII6rl_D2EtF59o.Pf6j 0vY2NTGBE.SgT5KMVwcON5jefaQSThdrS.lZ3vdwk9qr2VY0VurWc6VvNBsxQOwmume4oaU7Km57 9RKG8OcXK_PmQmFbRtXwcDJxL8w_Xu4seudMGBMHn6IxrNGVCM6KxDZOw7p5vtPcr6oZik1fNJ85 4tu3wEC_6MAc4XkTymkEYVg.1jjnJc3Ef7IJY1Fa.V300zb90FjR71kRxqqtDHdr9HHKNNXAiR98 oQA4Bu.7WBGB4luW0f6in3gwV8v8UNRizdJMJwXZm7KYrGt0o.dcSQvncPapT_.iCsd9zJwrWQ.2 mdk6XSVJeCqc54GhoOzOmU5eZY0WEi0rFoY6dgRQp8Q_1Qt0YqIH_orjVCw20lRSelIiTcHVGQZR EnJqgnnrYCAg8qUCHA1UCS0h4Fv3DFFOEbBR1KIJAacOq0ii0aFmJDHlwIRtqF9pVp6JFkmkBSRK ezAsTFIKflr0rSRbE7dojTtM_Jvf0iYzd3NH7ZXrYsHC_YbrZCDj8er7T6_UwW4e4n.HrdK251IJ AiKrF2Z80Q_SbpZW3BrtUEm0235mjoIb6A1R9chZAKkvaFlYbLEun.Wr.wfvPEi.vBInNpqWjkK5 dsXH6cMlnTHSYFJgwBgbEf6eAlkGb05a9rDEeWQwJiLmXhDc3886d59QO.C37GU7sZgqEqENK1UF A73vLBSmLaEW0y56rvvK3_cEX1tHEGXvXUtsxNph6hQcaP4tlC6drfCFeJvvBTshj3hHu1gKDSgx O99tnGMF2Y0zdmC4osbbiuA3trlVRNj0U8NJEQ2qKfg5iyL0_ZtnH77AY362Kj.rLoTNoVqYuHj2 R_vyD.X2_RfpL9Kepnam0FcZ51UjrC03K2srH3p62Y5ySvX5G0GjxVTOVagcdhxd7.0R6J1iDaG5 sEKY- X-Sonic-MF: X-Sonic-ID: 2fd65a6f-3011-43fe-abe5-486d794d8f2a Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 14 Dec 2024 00:42:27 +0000 Received: by hermes--production-gq1-5dd4b47f46-k4d2j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1237c3cdea7bd40e34820087282e386d; Sat, 14 Dec 2024 00:42:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 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.300.87.4.3\)) Subject: RE: Switching release media dist sets to .tzst (tar + zstd)? Message-Id: Date: Fri, 13 Dec 2024 16:42:13 -0800 To: Ed Maste , FreeBSD Current X-Mailer: Apple Mail (2.3826.300.87.4.3) References: X-Spamd-Result: default: False [-2.24 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.74)[-0.740]; 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]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from] X-Rspamd-Queue-Id: 4Y96qT6vk3z43fS X-Spamd-Bar: -- Ed Maste wrote on Date: Fri, 13 Dec 2024 21:15:45 UTC " > I have been reviewing parts of the release artifact build process, > including ISO and memstick images, and came across the distribution > sets (e.g., base.txz, src.txz) used by the installer to populate new > file systems. I=E2=80=99d like to discuss switching these to .tzst = (tar + > zstd) compression. My notes are mostly not about the specific compression format --but are about the dist-sets potentially going away. I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz for crude bisecting without needing to do builds. For example, grabbing something like: = https://artifact.ci.freebsd.org/snapshot/main/926905796749750da6464b97ec4f= 8eec0882cc0e/arm64/aarch64/kernel.txz = https://artifact.ci.freebsd.org/snapshot/main/926905796749750da6464b97ec4f= 8eec0882cc0e/arm64/aarch64/kernel-dbg.txz to see compare/contrast behavior with other builds. This also avoids questions about if my builds create any problems vs. official builds. > While I haven=E2=80=99t yet conducted detailed benchmarks comparing = zstd and > xz specifically for this use case, here are some initial > considerations: >=20 > Pros of zstd: > - Faster compression and decompression speeds. > - Aligns with the compression method used for FreeBSD packages. >=20 > Cons of zstd: > - Somewhat larger compressed file sizes. > - Requires updates to tools that interact with distribution sets. > - May have limited availability on some other operating systems (?). >=20 > I have a review open to demonstrate the extent of the change in the > build system & installer: https://reviews.freebsd.org/D48042 >=20 > It might be that this is not worth pursuing, as dist sets will most > likely go away with the migration to pkgbase, I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz for crude bisecting without needing to do builds. Are you saying that such will no longer be a possibility? (This is not a which-compression-style question.) I've also used the likes of the below with kgdb to look at reported backtraces from problems that have been reported --for versions of FreeBSD that I do not have a boot environment for. (Not wanting to do a normal install on other media and to boot/configure it --just to look around.) = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel.txz= = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel-dbg= .txz http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/src.txz (But there is no equivalent for patch revisions of *.*-RELEASE 's .) = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel.txz= = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel-dbg= .txz http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/src.txz Similar question for those: no longer to be possible? > but I would like to > discuss and make an explicit decision. We can separately consider > compression on the release media images themselves. >=20 > Feedback Requested: >=20 > Is there support for this idea? Are there objections to pursuing this? > Are there other factors I should consider, especially compatibility = concerns? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 14 01:58:16 2024 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 4Y98W556Y7z5gTR0 for ; Sat, 14 Dec 2024 01:58:25 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y98W53hC9z4QWW; Sat, 14 Dec 2024 01:58:25 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734141505; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0KtQgwlc75aRGfTr4XmtVI69I2vMpR+CgiTLzNN94jo=; b=e5EzD/L5czx/MEr2N0CWgLReWnO7RX0S3NVeIHGOE/TI538x3g7jiB94wERxEEZIU8CGnK 3zKy7Ho+d9LakPhgI9cq9NmrPsLJowdwVKRy9hL2T/UvH9BUGwtr3wSrwHEZJaYS2BTG0z HrTzQYXHN0RZEY62zp+y8XjGQD98kJAxq1moEBFGoIyxX4OHdN+gH+Ti5DOkakpqMnAx/m qfwKwwtHlct5phFMw8cpD2CfZsHqLqRSjxtJc9qIHY4T8rQXWPMHe5BvN+BP9CdSj0VwiF EeCDSim47XLzurwPK7lpjjsYwsimdyPq76wdXqzoS43d5XQoxT/hNYsIbbR4aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734141505; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0KtQgwlc75aRGfTr4XmtVI69I2vMpR+CgiTLzNN94jo=; b=lerfHOPyC7BHBti4f5euuZ7Xw1+vQy4usTWkYI3j64Y+aH264KXY3d6FbJ8A5KWG82dB1J 2RQ9/jDPBxhyZ736Q6bUsAG1ioOhHMhXLF1eyZsgStJsF86ZDCWM90Q6bY0SnpV7GkA5u8 4yNdDBxNT8aFW4sdhxQUbRzoXTCeNR1sVFadsJYyXAaPrwapS/2aTuqmSusIoNrQmJFUWG MtJrxaFW3rCfH/goBfPqd97MUf8/reRif9e4Hei34A1s14Up/+2/zLOVntDH/vkZGH/CbM huCqT2yGg1m56fTbSNxX1KK4s7oJ12RH3XQqoZkS9DbM6AC0isiJh3mlNoL75g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734141505; a=rsa-sha256; cv=none; b=Ku+fzIwoHEn7FTjutj6DSuPzgJRFJ/irJkQQDd1RlReXdmeyxK3scF6GbjTAO2p53bYYme Jerx5vuIVYJ8hEfgrIftA1nVdOcuRkLJlVX7T1lTKsVQIjU1U/+aNoYXGwx0vBHh630Ur0 k8CJjhCNtVa/fFQF2QPjYDXdsII4WxvT04pUYjwovAzEfI6O4csmEXNWv1Dgo/eS+GvMMo 8qtdH3qH11a1TtsLfeqZGF1OUbYaQivFEV1ZfXgrDOVS3GtSmA2s0t+BJ+ZWsesIusP90L 7lsKe1Egg9Ukdkzv4l5N//kHqHus9uz+S+MgOL2OM5IpnFsdPqce+8fDAIdHAA== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Y98W44pTjz16TZ; Sat, 14 Dec 2024 01:58:24 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Content-Type: text/plain; charset=utf-8 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 \(3696.120.41.1.10\)) Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? From: Zhenlei Huang In-Reply-To: Date: Sat, 14 Dec 2024 09:58:16 +0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Maste X-Mailer: Apple Mail (2.3696.120.41.1.10) > On Dec 14, 2024, at 5:15 AM, Ed Maste wrote: >=20 > I have been reviewing parts of the release artifact build process, > including ISO and memstick images, and came across the distribution > sets (e.g., base.txz, src.txz) used by the installer to populate new > file systems. I=E2=80=99d like to discuss switching these to .tzst = (tar + > zstd) compression. >=20 > While I haven=E2=80=99t yet conducted detailed benchmarks comparing = zstd and > xz specifically for this use case, here are some initial > considerations: >=20 > Pros of zstd: > - Faster compression and decompression speeds. > - Aligns with the compression method used for FreeBSD packages. >=20 > Cons of zstd: > - Somewhat larger compressed file sizes. > - Requires updates to tools that interact with distribution sets. > - May have limited availability on some other operating systems (?). >=20 > I have a review open to demonstrate the extent of the change in the > build system & installer: https://reviews.freebsd.org/D48042 >=20 > It might be that this is not worth pursuing, as dist sets will most > likely go away with the migration to pkgbase, but I would like to > discuss and make an explicit decision. We can separately consider > compression on the release media images themselves. >=20 > Feedback Requested: >=20 > Is there support for this idea? Are there objections to pursuing this? > Are there other factors I should consider, especially compatibility = concerns? >=20 I have slow internet, I'd always prefer xz than zstd, as the decompress = speed does not matter much. For the compression, I'm not member of RE, but I guess that ( the slow = speed of=20 compression ) is affordable, as the releasing is not frequent. One good example usage of zstd is compressed kernel ( it seems we do not=20= support that yet ). OCI images may also have benefit with that as those = images typically not large, xz saves a little more spaces then zstd but the = decompress speed is much slower. It is good to have fast startup speed of = containers. Best regards, Zhenlei From nobody Sat Dec 14 14:21:41 2024 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 4Y9T0x61q0z5gHxt for ; Sat, 14 Dec 2024 14:21:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (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 4Y9T0x1jx4z4v3V for ; Sat, 14 Dec 2024 14:21:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-f177.google.com with SMTP id e9e14a558f8ab-3a9cb667783so22266735ab.1 for ; Sat, 14 Dec 2024 06:21:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734186112; x=1734790912; h=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=t9hEpezzzQc8t1bXIQo62AW1Dle6wfov9feN6Rm7YUE=; b=CaapVzg/FroGk8guMxDJK39A76WM3yOQFjcWo7DkAEb6jpsyY1sYpmnJqqx5qsBUzw VavrPQWZHh2irnQ77luXGLAfP9lgGG4BCLoPvAwDA7FxB4jviE7lLHrDMTpgJg4RlpfW I4gEEfzx+aoljwuJ5VPl+efgpM6P26nk956f7Kgd6IeAdIL9/GX+a4oIbejB75+pknA+ 8jo488FGjWCTGSw0YjImc4E5HQ/uguljrwB9nihif0z+RqL1vGf3bX7y9VarrL5o1lyE XQe+3/UszIKgdHe430TBpE5YOaaYfxbd3q6xCB2Nf1HOLX5n41To2msSy0PypMTr+G2s 8o/w== X-Gm-Message-State: AOJu0Yy9IBWYv7JLo5KsEDzgTbrMWVtsA6TqPrRJZw0ESSxFtvFOPqKw CVpcI0aMePX8iz3omlxNYuQMiEDbycMMYJzd4CBiYFa/VqEktXcb4U21lhXHz6LWEj2KcBFarKh RZH05eC2nLkmP/3NzsKt4xuJlQsx8tA== X-Gm-Gg: ASbGncuVWCpZIOianaaPbSCdrlogMBAr7Uf25VAGdTGvBNJcP9O8vLCEdBOi8VdUt7S L2WDVFFWAclsFVHKOUnEwK2uylXeZm6//TLJzKQ86fBSv6SxEgO/Z2n+4R2mDoPm6wFMX6Dte X-Google-Smtp-Source: AGHT+IFiN6CAbNVyXSamG5TQ01CoRewiDPnGDuFKzr4RN0e1TL08AG60LH3Yu7VKXFVQ/tBHZJaAsd615iH9Z5/aCsg= X-Received: by 2002:a05:6e02:168a:b0:3a7:7ad4:fe78 with SMTP id e9e14a558f8ab-3aff88b85bfmr62720885ab.19.1734186112340; Sat, 14 Dec 2024 06:21:52 -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 References: In-Reply-To: From: Ed Maste Date: Sat, 14 Dec 2024 09:21:41 -0500 Message-ID: Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" 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:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Y9T0x1jx4z4v3V X-Spamd-Bar: ---- On Fri, 13 Dec 2024 at 19:42, Mark Millard wrote: > > I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz > for crude bisecting without needing to do builds. > > Are you saying that such will no longer be a possibility? (This is > not a which-compression-style question.) With pkgbase these distribution sets are not used by the installer, so they will no longer be required for their original purpose. It may be that there are a sufficient number of other use cases (like yours) that we still build them anyway, for some time. I would imagine most use cases can also switch to pkgbase packages, though. If it's different kernels you're looking to test it will be straightforward to use the kernel packages instead. > I've also used the likes of the below with kgdb to look at reported > backtraces from problems that have been reported --for versions of > FreeBSD that I do not have a boot environment for. (Not wanting to > do a normal install on other media and to boot/configure it --just > to look around.) > > http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel.txz > http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel-dbg.txz > http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/src.txz > > (But there is no equivalent for patch revisions of *.*-RELEASE 's .) > > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel.txz > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel-dbg.txz > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/src.txz > > Similar question for those: no longer to be possible? The same applies to these ones - they won't be needed after moving to pkgbase, but I imagine we could still build them if they're being used for other purposes. From nobody Sat Dec 14 15:00:41 2024 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 4Y9Tt45j9Tz5gLLF for ; Sat, 14 Dec 2024 15:01:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (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 4Y9Tt36PkWz50wc for ; Sat, 14 Dec 2024 15:00:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734188458; bh=VaKsg6N0gNNgOxGhL/i9gNUcUDIlJ5sLFHCRDM/LgiU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JQCCm53GIslXTos3nbz9QQ1Y/OZkQAGKRUw/Rc8JlOVyrAQomw9jFC5md0xSadmI+O6/df5VA0uCF6vXXxxuDpiIPR2PI5pQ30SiwtOAESZIIbGcbdztvuWHOySLuA38RuqNJGBxKpdjc9Nn0U/HWunAtZ/eOGxcrznDm4JV4i7zEOkZK8kVc8QbxP5lFOeQy8/33HHfOdFg2Zby6Run+tqCdgaEanqsHN7Nq8TkoPQpH6iV5b2ylS4P7JOGrySHIkWqOOkaAG/gOKmxswh89yzNalA5r7cNjcr+OXfZvbzA/609fHHI6hMQ8UjXPtMuJ3ZhH6wm+dO3o3kFotC/IA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734188458; bh=6IrZVmBa18x3kybFqDWhJGoFl4qwZbm22K67LBHjhtV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=aqLVLZqnVv3PXVE7CDU9RzDYXSiPLBi4FjGijLvkPQ1jqbkEOA0CxZ8kzGBgEeAPYbXzTbcDhbYE57rlPqRCvQ/x6CaEvuFyfQwNCZXy9GzkUmHdaxuRa9ISJFjwqX75tT7LUUdadwRnYXd/xl2z/5AiC8zta2MDPgxtkEUdj9q1BhYeAS1UdHT2tO4vXoyWaxu5HTi2MVQ1qGoWc/3bekPKveixbI691YhUyqyqCGkY0h7Hz0ZrX9F3xeylYeloZabs51xGwa+doXhS303D2ZZm1E3QWxxF5vS2JFJJXvbRZWhkgnqytqH8BFU59XSYyckbQARUaJtzUMKvv8kMpg== X-YMail-OSG: eNCyRQAVM1nWt.jriG8l1y4JcfGeAESOo2d4tN8rnynwK96mX60yQuQy_lndMtJ Wod3V59Oooz5H8jU9ZQqx3YY68dCerkAr8xabsstcvKMQw6JhsrS.V2fVGILiL88UGktg700.1dv Kw5X7l5sgDV2GDJESmFZR8Gsh4cE_pHIqNm1616f5Kef2hhkG5MRqBOG70akHWUKgJgM1KeK5yB_ dWOWBwtvNotcCO9cLYB7bN_bSynRhRPh866ZvTLtyQQUKKgnh792lo13qeQsThznRlMS2_xnRrJP 5JqSNRnl4k..z.7KWJyQzgEAvXr8XOqv8hg_7vqSo4quvyj7_08ZPShxeMmF1X4CwQukkUq_XhJs lPjDi69N0ofWzghFrk.E8LCeTfQ.lz92ZcIppyRZcVuaXCEpmEaA.JItaY9jJ30b8O1q6EkZBc_4 2KHTmpRvbXTCY4MXXy_mUvqGW.Lnr6CsrcWUrNZU5na4hCRkgc3NaTcv_ujt69_mq_jcDXjLpZ5i fIwmd4Pf7aVOj_QUfbJs5eNKRUw6Vjz6t_eGbM_SsdvR9EI3nJfMDAg8YpNZzmZUN17bADiHOyFg EGfDwEybKu8MnzpLmM6INK6uLF9swYAX3rwS.0kstsXNXVLzWKuxv7yhXhKqWZKLh2hITrIhPPju DuakFQ5VHWZTo2RWclD1ErNSXh1DWq5D1heL1rVFWjMuq5s0s.YevQqkszJVw_WVsNuZsNYcJUjf JwMxKJknrForQE_F0qNYOn1GXdYqTbvlHvrflSIYYnzWbJ4FQ0QCjpXveWMedk4yfpbdvNC6C2ep G0nyujJF5y3O_avpZsRifwJsYs8r3EDob1teB3XXrfwqB2k2sdpi_ohGmQw7GjR_f5MfyIE587Jh YyWxKxvo04asQhWjWJYpKp1ZaALIqt4V5OnfXc_GhfCKrNUiuQEyLlMIC6NNCLsRYe4J8k6LVMiu JoNV82s7XH8UiLFToLaap7rbFRccc9OZmZsS6Y_bD76259E6tERpmP4YV.QUX.ZOg5JmQVYAl1dl Zam0_O1DwJx7M.hiHcoriffa029QLXNdE9wRON9MNlshtyled9h7miloQgz3W5RQFieR_t5_lm63 zRhRnfNGTvxrKlI5DSRg.Z_vetvusJiEXi.5dcURuOkxMMcioYxNT.rLZLK86smZY4bRrdBOgrwV IwkxKptm325feJ4IuBP7FDx0Fjz9mA1tS_Y.VQRUXGOhWW5KUpyUYFxBYrv.z6IDCB_QoAHfN99r QlNwM8oSeq5Sk1Z3UnnG0NKZ07hhYb8Y9f31jlGvyCfAlh1UHTJRVSgqULhz0e7mNPhtPQxeuoMf _EpE8KWtvrdT5BJPddb0H6FooyTpxlwcwp1Obt_v8.l3_L2o7RxEqXV..E.dg3QOrc9RKJIq5kJ3 0Ez4ene1SwbaxHEw25UsXTmwQoLJPBw6IygSvhqFB2grXzq3Z6QUrBDRjqEskRi8jvele0I0kcwM isDVKk3LO7h6FHYbuk4Rd9ckjnhhwvUlgaM5tazip2oX5UFRj6Gh7T_B6w3ehQHvjYW1Cc9TUoTw B51tFJjol20bNhas3GsmzbjlZ9FVbbyNo9k0pXmGjjmh_PyxSuRC8.bkEp2jfJqz2yi.ArR2NYmf TStzRvtHRDBXhAHO90pALg0uG719jtXu8UBhewsn.xtl16cWgKszP.mfehigEAlNl9bxH7_wnQhy qQxAQZ4pUdxq0nSDSpUt3Fw45FlCUtk68dvARkG6r2oVyz4vJOnYdIhyUaKFnhuFTqZn7Ac0GrUy 6aWv6r6bS41w2Kblm8NYMDVT7RBpJ1P.4v97sVVdBgLu1D1S_M54YEVQz6gS22ij0LnN95jsXJ9F 4Ozs_cvcSkmqs9aiB7_hWhDj49g72bhsR_2stNy.N2lbjO4MUZ3UGweKTeUcZ0YpkIiNZ4F_tiow l9qTKqnKz1g36uj32Uj6BohiqFeFUJCKPpT1wn.G0GS0oSe866C9vTaXRGgjGxkJ9ZftO6dZk0gt fpSWEjmk69IjkXGTWMwyZOYdwkILjP7ddWArzG7YjFqdNJSgW0nJvOTDUULC5edIJV.ohS5NSApX a7uvRGPUaUAhN1KOMdesaVPiII4KK_ucEs9kTRuzLprMZSUGE3r1uqF_wPFATklEJK1x3TNiMQVe mhnBzQNkiwVAT0akQfkMIq5UbVfqVsA5lA4348KccDC4WReWVJzsqbetM7M_XfHHthRvFQHJKzXo M9aLOmWiYxYFYO1bdeb7_CEh0vvn.pUFU87rTEao59FUtnhvXDjLR3jgcS67pGG856L8ZUKjYcaC r9U4- X-Sonic-MF: X-Sonic-ID: d7ccb15c-4a6d-4104-a5a2-2837dd47ed5c Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 14 Dec 2024 15:00:58 +0000 Received: by hermes--production-gq1-5dd4b47f46-sx6k2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4c02dd316907138245bde97e6be3ac82; Sat, 14 Dec 2024 15:00:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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.300.87.4.3\)) Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? From: Mark Millard In-Reply-To: Date: Sat, 14 Dec 2024 07:00:41 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Maste X-Mailer: Apple Mail (2.3826.300.87.4.3) 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:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Y9Tt36PkWz50wc X-Spamd-Bar: ---- On Dec 14, 2024, at 06:21, Ed Maste wrote: > On Fri, 13 Dec 2024 at 19:42, Mark Millard wrote: >>=20 >> I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz >> for crude bisecting without needing to do builds. >>=20 >> Are you saying that such will no longer be a possibility? (This is >> not a which-compression-style question.) >=20 > With pkgbase these distribution sets are not used by the installer, so > they will no longer be required for their original purpose. >=20 > It may be that there are a sufficient number of other use cases (like > yours) that we still build them anyway, for some time. I would imagine > most use cases can also switch to pkgbase packages, though. If it's > different kernels you're looking to test it will be straightforward to > use the kernel packages instead. At least currently, there is no history of PkgBase builds available, for download, just the most recent of of latest and weekly. Would artifact.ci.freebsd.org be replaced = with a source of PkgBase build history that would allow the approximate bisecting of pre-built materials? Without the history, activity like bisecting would require doing the builds, making things take much much longer for various platform instances that take notable time to do builds. >> I've also used the likes of the below with kgdb to look at reported >> backtraces from problems that have been reported --for versions of >> FreeBSD that I do not have a boot environment for. (Not wanting to >> do a normal install on other media and to boot/configure it --just >> to look around.) >>=20 >> = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel.txz= >> = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel-dbg= .txz >> = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/src.txz >>=20 >> (But there is no equivalent for patch revisions of *.*-RELEASE 's .) >>=20 >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel.txz= >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel-dbg= .txz >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/src.txz >>=20 >> Similar question for those: no longer to be possible? >=20 > The same applies to these ones - they won't be needed after moving to > pkgbase, but I imagine we could still build them if they're being used > for other purposes. base_release_* will exist, also spanning patches. I've not yet tested if these are binary matches to the official non-PkgBase builds from http://ftp3.freebsd.org/pub/FreeBSD/releases/ such that, say, kernel backtrace addresses are usable across the types of builds. (Sort of a reproducibility criteria.) base_weekly is like http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ , other than having no history prior to the most recent base_weekly as things are. Lack of history also has issues when it turns out that base_latest is or base_weekly is broken/unusable. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 14 19:00:21 2024 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 4Y9bDS1lyFz5gcZB for ; Sat, 14 Dec 2024 19:02:16 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y9bDR5Dc0z47D8; Sat, 14 Dec 2024 19:02:15 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BECPelI004228; Sat, 14 Dec 2024 11:02:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=WIfNuaaes13oS nR7zLlsIwFIChIiv99UQqyCPVNvHCY=; b=WhxtT0hZREY+p5kALHiwlgTa7mCx0 ShS9v3jBW8E/Msxdf7kEm7mgilxVRIz31KzWLtqri5Ext12wq81zMC3FWO8z3nqs 8paWxy4dCXmod/23GsW1WjmK9DtnXFKc5qSV/nsOt8+ZLEWhDrDvWCvkliORPr+9 CiM0E4bmEJw0OK8X8kp3+zc+MUZn9U+qDV/S2rqz0hfVzGQDUgNE8gD3pE+ItTla /ERiYx/7N6adxtJAp840xHe+VvyvCj/MaFw4DlK+Rz5rHdDuLxuslD0801a6ZjZ1 vz+IT88nws1ElAhwoHlt64i+HvmhQ+POO437XiFOMNRWTDVaGSou7AVSw== Received: from sa9pr02cu001.outbound.protection.outlook.com (mail-southcentralusazlp17011027.outbound.protection.outlook.com [40.93.14.27]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 43ha0vre7c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Dec 2024 11:02:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dmabS1jOgUlI6pAC8Z1AdTpNfpdW5WiWcM6hVBD9NH71qODIiD3pfYk7aHd+4gUdLaFpvPAjV70AqH6WBzY87+K5+8vCjCBNuxNet1Boszkp899KXTWQHk2mNZuXz9+GQcrdoP+MCv3ySVTDNFIEtel7R0Z+6rew9RyYHC6gaZhdXpit7rAdPChs72vkgIo1wTG1ZzqshB3xWeSB4G0GMqxfKYpf8FdbcMCCn3YBwQOLKsItZVO0pqXoki+VptfsSFw+O/CLqxWMf1xg1E/ybkIaRTBq0Drz1ABJsP/rC/5ugJt6oi/rP7xyMwczmR1GW0X8ZBIHRH6/8wXuLkmDeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WIfNuaaes13oSnR7zLlsIwFIChIiv99UQqyCPVNvHCY=; b=UjoEv1YP7dii1XHN3eQ8hGqKnIwhTNOnvTd94QFp9+VrdDKGnq9SnT/yUj1Xlg0FBbTcZPfYBh1AGwyOQiUH1nP5VnVCB/cgYP4fugf7CypxbrcebwT5UCRtFt2KP5ByUALwIAID6cvMGoD2QxKaCqLW6aQeFt+uHFR2dDqnjLjos1jBnfFx4wzwBCU2oVKaEyiHRgMX1Jq0iNvhUnbK/oiFa3i+yVl9kgam/dAUFomsjerVwwC7/JMVd2t98q6zFNGCZH2sLXYyJEHDKIeFpC7u9zZyZzU8NM2px5rNpLAaCebD6KKprLLzVdMnohWkYsQX6D1gQ7H/N8WWqLydsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WIfNuaaes13oSnR7zLlsIwFIChIiv99UQqyCPVNvHCY=; b=NhP39aDqTVl47cEJBKhxBd80/jFzbwtHvrkkd6JzVJ/o1u8WIofE7M5WT0XQsGS/zUkqcbl2n3/0wUqbvfXp8y5UzA2IavpmLe20N7ntce0S0XvO8UoSP5RpWJyZFDqqGzmSnSqf25bori9rtuubsHg6z1iNUPDaEM820MSI9dk= Received: from SA1PR04CA0020.namprd04.prod.outlook.com (2603:10b6:806:2ce::29) by SJ0PR05MB7456.namprd05.prod.outlook.com (2603:10b6:a03:288::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.18; Sat, 14 Dec 2024 19:02:11 +0000 Received: from SA2PEPF00003F66.namprd04.prod.outlook.com (2603:10b6:806:2ce:cafe::7c) by SA1PR04CA0020.outlook.office365.com (2603:10b6:806:2ce::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.16 via Frontend Transport; Sat, 14 Dec 2024 19:02:11 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by SA2PEPF00003F66.mail.protection.outlook.com (10.167.248.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15 via Frontend Transport; Sat, 14 Dec 2024 19:02:10 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4; Sat, 14 Dec 2024 13:02:09 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4 via Frontend Transport; Sat, 14 Dec 2024 13:02:09 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 4BEJ29Jn032632; Sat, 14 Dec 2024 11:02:09 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id D8DB6ADDA3; Sat, 14 Dec 2024 11:00:21 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D83B8ADAEE; Sat, 14 Dec 2024 11:00:21 -0800 (PST) To: Ed Maste CC: FreeBSD Current , Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? In-Reply-To: References: Comments: In-reply-to: Ed Maste message dated "Fri, 13 Dec 2024 16:15:45 -0500." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 29.3 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-ID: <39569.1734202821.1@kaos.jnpr.net> Date: Sat, 14 Dec 2024 11:00:21 -0800 Message-ID: <42173.1734202821@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F66:EE_|SJ0PR05MB7456:EE_ X-MS-Office365-Filtering-Correlation-Id: e31578a6-0552-4963-ace2-08dd1c71d01c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?GsIGhyp3JvINt+3xR3NB4UtyHY8jtwyVzUFRLLWz+JULic+gGny7hZ1aCcMC?= =?us-ascii?Q?10OlbypMolS8tQCuCxSKmSBbN+XFAUuXNk67OzYRKy6maCpGwSoYqXx9iarR?= =?us-ascii?Q?gCTlEvEZFMH7FV7jplm/tCg7ElD8z6aDARTKCW8ET8G6EbN7QerRr808k7zI?= =?us-ascii?Q?g9aYG7aAU+pZY9vkNGJLftUZhexuAvXxeZmusypiQ7kOO3UTbD4P6YU6ZH8g?= =?us-ascii?Q?Fym3OvdGSz6wSdxdCAnujSMHupqqpRx3WH4IEZP3ZN4cJfPNdtzrthR2rD8W?= =?us-ascii?Q?eMjmL3sojR7adILOdztZZjqGaL86YALdolSlV8TyFwOMkVkbkRQqTeoq3LfI?= =?us-ascii?Q?6ZcyceTucTtJ5UvVpmsSsEE91PK4kybpqod1JkAaohQAIjrJFQCgJ7O2awi1?= =?us-ascii?Q?NdyCPR2w2W2baABgYN5Zi34SdirkyLuEhvICVt5Lr6mZyqEsGLbqJRk3Knk9?= =?us-ascii?Q?R7nPycH7K6AOtxT9Sk2gMa33NpWlzX9X/JQ7Hox1H3b7FBPXRokLmPy6b+ar?= =?us-ascii?Q?xbHamwXRFw5hlFRxAGTsNqneAXLYcw2cgSf540WvQCrhs1yg/1FLclUyBuBG?= =?us-ascii?Q?Ujkmw3cyJ29Qxspot2ygjtk5NEMEtE5HoEPBRqycRw3y3WcvTdmscM9L8ZY+?= =?us-ascii?Q?zklhZCxHod8qp7hfuwkPbRDB2nGAeb4u+2Im/ZYeEKoGJbbLS8iHUFpSYrBP?= =?us-ascii?Q?P+UOvSHVfAh4z2ZPJAfZ/SAMdCE6X4zXSx1lpkyT6wieAWAZ1/3+AzhqjV7N?= =?us-ascii?Q?yFYrbgKhneJyEEhMRxLEyB7G31ZU8Z2GwjTYswr9KrbR8N0XPN/ptQS1fO/q?= =?us-ascii?Q?e8Tf/0oM2F+eGAb3dagD65f4PnMaL5twu+8wnKs6MW53sEysM2qyIYHr+nWF?= =?us-ascii?Q?e6yUXZwF7w93aYJ7JTN8UkABf8xLmep4p+SndM6ckHcryjj3oxsO4kGzwQ74?= =?us-ascii?Q?KF2hE48sdE5JbTi8bNAPH0jn39/o8vz4/8tC+sau6AIXgR6zne+CwyG2/HJ6?= =?us-ascii?Q?4LAh3p3rykQ8JmbT6K5kvDjmsLDwpKMOu9KghsDZ/GGRAZwkyFg5Y6WurT45?= =?us-ascii?Q?uNabgMfZdmrlxATaG+NFe+mhbBHNf/GPprtBefuWzjYXygaDPhc9zIbbT1c3?= =?us-ascii?Q?KZUDVSt9iEvv/hvlvHeUuGb6GRz51BjkeX6uyMSPr0BxJ5YNJCvRR4045cDL?= =?us-ascii?Q?ZEytylJ6gwQybAbNTfx78a1hu73hpPRioWu+GKw0gqcuQpWgvdkjW5u3/0YW?= =?us-ascii?Q?Ne179wgNs5Nn0xf854/izyJzOycyoVw6m6zJv63qjIwsMmjoAQxvOBfhXha8?= =?us-ascii?Q?2Fsk4UIn/x33XKmlsQe0Do9CEbMAkJa7NbXwcxItOZd54XdXjEIjiLyMkzSB?= =?us-ascii?Q?M8R3ZGBRb62SYxky6z6z/fgG/blUtJD0ad7gEE/IqdZhIQiYKqnMrwuYSRIa?= =?us-ascii?Q?b3p7F2Ux+nsTS/No11k2mlhi1e4tPPnVqE7B5oNexHNL0oqHV/OJCg=3D=3D?= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2024 19:02:10.4119 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e31578a6-0552-4963-ace2-08dd1c71d01c X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF00003F66.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB7456 X-Proofpoint-GUID: C5pZO_fq8SklDZxpkdXcpLr_x9xZXU0K X-Proofpoint-ORIG-GUID: C5pZO_fq8SklDZxpkdXcpLr_x9xZXU0K X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 impostorscore=0 phishscore=0 adultscore=0 malwarescore=0 bulkscore=0 spamscore=0 mlxlogscore=520 clxscore=1015 priorityscore=1501 lowpriorityscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2412140157 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:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Queue-Id: 4Y9bDR5Dc0z47D8 X-Spamd-Bar: ---- Ed Maste wrote: > Pros of zstd: > - Faster compression and decompression speeds. > - Aligns with the compression method used for FreeBSD packages. FWIW this should also allow the sets to be mountable using tarfs? Browse the content without having to unpack. From nobody Sun Dec 15 00:00:37 2024 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 4Y9jrj5MPJz5gxRn; Sun, 15 Dec 2024 00:00:37 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y9jrj4bJxz4YhH; Sun, 15 Dec 2024 00:00:37 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734220837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=fX7O2+XsLTbdxTTjqISDnAmRPcm8ltigtm5MwSRW3KE=; b=cEKtI1yTO3N/io5SHXLFg0aoyg6pE8POhW9+SNuQcPUODLMUBmb6rOT/IdNwuphH74OVvE DaMN+C3JgS69R8bZfMXQ94TimssUHjwRyMsAaIC0AyPR7jUSVNA4uc8vcO6AB4qoH1R6xW SMFSxC71yQBrW3sOkGOwO/KWZWlb/INUibsF7wi0RzqEwANhsHmqL5/b5AvQc4GoHCPdxb r+ayVJTUn2ZgRF9cXskbTSupr1Er53j438sAO15YbrpfsP3SYorelVLc+hN/c8VS3hUnZl b2S7Tu3uPRq3OJfONwYz1QKuKoD9dODE4ZnAedJKmdNbLKLbfX98iyKpDeYUFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734220837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=fX7O2+XsLTbdxTTjqISDnAmRPcm8ltigtm5MwSRW3KE=; b=fDMx6laXlQZrsM2P+3nUqMiI5C6Znn3HmmiTmSa57t6V7F27D945DmGxxwWOcqWFr28mR7 kXN80Yuxim/tkKmyqT4P+owl8LbbhPQiv3O5cJW1ywCkSmgI4EPIEKCkf9PkIuJLVT2uCG 8knC5wlAsAXh8tlxmh37veWWZEo4Bkz5+IRwh2LI30A84hP7S29dvzp+EV80iXPysInRfY C7Y7TIdREE701q/RQW0xlVVWPK5TXZhJnMS30gw7LAhh2yFxLD6+Zs2g7k5J/qY60VQeaa codhTn1GT97+0I7MINRM+n3g9ej4YcKMM1fhdqZazpDRekVDVCI55QQfqAZrug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734220837; a=rsa-sha256; cv=none; b=llt2ujVEMipLkdTP40W5uFahiQCyDFXP3mCE/NrkRNuA3KME7/N0ckBMH2eSPvpvjJ3hKo bxG+drOvBsvldn9YhJRdr55rNZBEsvbIWcV7neMogPp67alN3IiNjrz69xfR9YVBHhBCyW zWJ8hP6jN5QL3/8LQ8O/RD0zYr4dXBytjGE2aQQUNe1nG2IkAqsuz2FI6GdtPaHn1w2+gU cnPU+96wmr3mCqHUme6ugbNt+jOYbON3g4KyarfUDtYDV60+TY3WYSsUm0lq97Pmr73etU 9zJwWKpNI5By/AcKlxAH+cRFN6phhWVg850Iku+pJxoZWKZgsPv+nWfgi8aRZg== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 74B1B17F7E; Sun, 15 Dec 2024 00:00:37 +0000 (UTC) To: freebsd-status-calls@FreeBSD.org Subject: [2 WEEKS LEFT REMINDER] Call for 2024Q4 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org Message-Id: <20241215000037.74B1B17F7E@freefall.freebsd.org> Date: Sun, 15 Dec 2024 00:00:37 +0000 (UTC) From: Lorenzo Salvadore 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 Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is December, 31st 2024 for work done since the last round of quarterly reports: October 2024 - December 2024. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2024-10-2024-12/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2024-10-2024-12/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2024Q4 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Sun Dec 15 15:58:05 2024 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 4YB75Y2r5tz5h0K3 for ; Sun, 15 Dec 2024 15:58:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YB75Y0p1Hz44Kb; Sun, 15 Dec 2024 15:58:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734278289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=W6Qk52I9OeS7IULA7jgJcQOMGJOlUvFr+LD5yhyynQs=; b=Knu/hVtAYjxHUsI3JRab3Wsd2jM2IsBqrEVUKnA3GobCWfc2nUfBfxGWNZaMmL91+8Wv/+ S04jdmacKRc64AyiniJsjG7GPm1U9eXwKNhVz6NETSnPLfRSGgbq2IfBROKponPxgknx3L QL/JQ55YRQNfAV6b0iUXYQ3jh7rhLVS+ZVkqVHWfX/bw5x4qejaGVkj9wxjrfBKJ0QFbnx 3w1R1QmUra185tFtQgmxjeZ/wMeCgYjbiDmUmNATcbw7Jyq+x1DZO2aDByupVFQYnqJuTJ WzvUhr95tA2Oazh1cv06leWBm0EgVal7u7c516ULcM5g4kQIuDLNCgN568P0XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734278289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=W6Qk52I9OeS7IULA7jgJcQOMGJOlUvFr+LD5yhyynQs=; b=QcldZIi124qVjCeBUNJV67zXAkKETqKe5U8a/IwAzDDNuiWMNvHRfrpQmxB0EGGCVatWdN gH4j5peYhx8GxDHXomTffeHy6L/X3vnX3HYcRmTBa4Yz8Cky7KVdGLe4Ijn1uXHKySyd4A XoFiOPqgxMLqjLfyMc7nFdKA/Ney+xhX0b2/+K5nvjY9JEcegxmncp5OYHXzInB2ZQpfKE aPnuDSYA9WfE415pBdqf/MYgawPgPr7RJlApsloMP/n+TAxtuHhbZfhkLsT6j0JdJsLydL nWQkxb5EkJeGR1e9k78yBB9TPY+NFz1qV7iW9Oc3JfHTTI3x66f1MtUwYVBMAw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734278289; a=rsa-sha256; cv=none; b=EbO2Iol5kbz6vDHZcFGqMAhUB3ECmYv4/xA8YAgciJIjTke0j2Dr++9m3kZsEpx3XIQ5ua RWbPsLazMJAsKnQxC7fZCIl6RmbSekwNLPeI+9XuvQh3KjMqCK3uX/RHesRvTLhAns2T7E lJAB2iobyUaPEACTBLXmG0Uijj0pRbjjQiQzF2qfEV/4GH0sR1CeYgjNpDaypc2T7s6voz bMFsN0rJIqcyMO41TAbjQ7Yps8nT7O2Jyd1EPoydUch3Jp/5DExZVDjU90CAsbZfUbAS/J iRkbBdW4qbTAhVfyhoyL7/MCd3tffqLFDH7zK2tqvFlkZJ5+qIX8L7la/guzDg== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YB75X49hGzRys; Sun, 15 Dec 2024 15:58:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Sun, 15 Dec 2024 17:58:05 +0200 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 Subject: Re: zpools no longer exist after boot To: Dennis Clarke , Alan Somers Cc: Current FreeBSD References: <5798b0db-bc73-476a-908a-dd1f071bfe43@blastwave.org> <22187e59-b6e9-4f2e-ba9b-f43944d1a37b@blastwave.org> Content-Language: en-US From: Andriy Gapon In-Reply-To: <22187e59-b6e9-4f2e-ba9b-f43944d1a37b@blastwave.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 28/11/2024 16:45, Dennis Clarke wrote: > This is progress ... however the cachefile property is wiped out again : > > titan# zpool get cachefile t0 > NAME  PROPERTY   VALUE      SOURCE > t0    cachefile  -          default > titan# zpool get cachefile leaf > NAME  PROPERTY   VALUE      SOURCE > leaf  cachefile  -          default > titan# zpool get cachefile proteus > NAME     PROPERTY   VALUE      SOURCE > proteus  cachefile  -          default It's not wiped out. "-" means the default value. Which SOURCE column also confirms. -- Andriy Gapon From nobody Sun Dec 15 16:07:07 2024 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 4YB7Hx0cn0z5h13J for ; Sun, 15 Dec 2024 16:07:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YB7Hw70ptz45jj; Sun, 15 Dec 2024 16:07:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734278829; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AdxOWfGd4qGTN83r+g9i2LwCgpcqhbxVk638yjqRUfY=; b=ANl8NgxQw2dXnrRBlUHTKKNP1hanhIj+zdhpwdsfrzK5KvKa9ed+DrTrbdFNW1jqCX8AZ8 CVrIkiXZRTFfAzioooNt9ivDiDLyJNQLL69hCiOblw7uu28t6TooBOgAeLcPvwxBJW0+sO 7GMiJGLSs3ott6HIYtV+Jez25jwZTGuyC3E02Ze9LWNt7tMrZfqvRm/+437bxjQDJsUadL wMdVbeGY30E90OS3WTjXs+7DE1IyQxLHlsYCxzbshrKQRkdYOWylPFay/JaJXRG8RyKboM ni8y1NWfV3Zz0xraW5aqUVeyUOf5jt9TiBqf6j8jseMnGxAMGFvyWpND/cxeQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734278829; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AdxOWfGd4qGTN83r+g9i2LwCgpcqhbxVk638yjqRUfY=; b=xT8easedE18vYMowgIC3+rX97P/jeRtAT8GsJ7PcJ6lhi/jDDDosEbHA5b8igrcWxRhyIQ r5I62u8sLWBIQisxOnk0SZ6xVGylZ7UKjZVZoAsHG04qV9yZKhuP1DL2tME8njSOYKqQqa lZv1DPxOkZlbuSuwyyBuh+rD0RF7EfRe0KeCBL3P2LGpbrNCVzEv8m5BfOdqCN/aeMg521 3Ic+n1vlRaEO9v87kbV2P66IypfwsD14xrIVEAMzgOa7+1qEGFANx9LIRJaRdLErjljVEH kEzNbsJNgPaRyxLUvQKVXfyHv5lhg3ECVfT564vQzCrXL4YiBnK/EMTL5hg4cQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734278829; a=rsa-sha256; cv=none; b=aLF2/Psn7nDR7IYkprg3GIqUGYupQZR+dkmp96FaRNSxISOyosP2KH6DJAW1lbf0EFtKtF ct9Znh5vtppf2o6vhkHZl09dumfXTAWJfB5ypxCw0yIDuEfeeyZgIL7IAigRfdSUpy8OjV +/pKcON3VO1VotM42y/+g1cSA9eoH7BokwBzls6Kdp/+LXeineijj4+bvIoIf9orKBpV42 Wwe194gJWSXfISkbrQkcOMxIceQJdc2slQz1OIJh1ZkHTKUarZ0qG6kKGKTxMPDKnNBnRA FrsyHP56Sh9I1XWLes563+H+Rvrn19IEm/sZLjMfWFsJrGKqQRZUEmmO2d0Crg== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YB7Hw3F8JzRW1; Sun, 15 Dec 2024 16:07:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Sun, 15 Dec 2024 18:07:07 +0200 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 Subject: Re: zpools no longer exist after boot To: Dennis Clarke , Ronald Klop Cc: Current FreeBSD References: <1764191396.6959.1732802309600@localhost> <043aee93-3dbd-4e6f-b0ee-fc6ebae9b8ef@blastwave.org> Content-Language: en-US From: Andriy Gapon In-Reply-To: <043aee93-3dbd-4e6f-b0ee-fc6ebae9b8ef@blastwave.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 28/11/2024 16:16, Dennis Clarke wrote: > So the cachefile property needs to be a specific filename or that script > will have no clue. Initially you looked at those things al little bit backwards. To know properties of a pool you have to import the pool. But how would you know that the pool is to be imported? So, it works in a different way. /etc/zfs/zpool.cache lists the pools that you want auto-imported. /boot/zfs/zpool.cache is a legacy location of that file, so it's consulted as well. If you want a pool to be auto-imported, you must have it in /etc/zfs/zpool.cache. So, the pool's cachefile property must be set to that path. Which is also the default. The cachefile property is changed only in special cases like importing a pool under alternative root. Or wanting to produce a cache file with a pool but not wanting the pool in the system cache file (/etc/zfs/zpool.cache). So, basically if you do not have a purpose for changing the property, then don't change it. -- Andriy Gapon From nobody Sun Dec 15 22:19:00 2024 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 4YBHY44q7Lz5hNfW for ; Sun, 15 Dec 2024 22:19:04 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazon11023092.outbound.protection.outlook.com [40.93.201.92]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YBHY35Kkdz4pP5 for ; Sun, 15 Dec 2024 22:19:03 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=selector2 header.b=iFcKWZuv; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 40.93.201.92 as permitted sender) smtp.mailfrom=jfc@mit.edu; dmarc=pass (policy=none) header.from=mit.edu; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=An5IyFsv5X0+9xqSXI0cTFML1ucXTvMDZF7ZPd4D3zA1yus+rEGbc8Z/rDZUHJ0mA1LpxArOl4izqks0LKMutdq4p074KMbfo6cP7UMWVdnXumTyoFTDND52XIruDWL/k52MmMsos8HzDLx4xJ/0TnXPclWlO+gHfGd5qjf1a3AKcAlQ0tTnLRixYGtfJ6beA1WVRXjAm372cMBKsbEzYuP9UqSsoeNC1at5HICQg/vackyZalYO8J9CNAPELWin76/uqH52mGdj/X0v1erzjQKSkpOzEK6hfLH+j3IWRBlivBz5YgGKvyIHudvqFtnwff+gEWTbGUdFxoKC4Hua5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OazHt1nPv6Ggb5jldhDyFftSkEIRCoZgqQu7LUBlQhI=; b=LTDPPpXKV7+U3xc9wr9mPiOhx8tFfjp7/8vS3JTripdUDXNFTt+vOynatN+s0yaKwzTb1WVRx9v7mDEvTb4O9GzCCKpYoAjBkeAILGDyk96zNF3+VzMWeCQ7qj+J4N9hxdxv38K3eugDytPA6simX+sU/aOvLz9lS7OcpYo1WIp3OKKSxxCVpQapq0dXZo89H/7WixZwtcv75U+2v//Y8zjXbFmOCon3ifTnBuKVislqBHy0IVkLXjpTTjGSPSC7n4iiKUd2sp+xv0tunMWAb0Gfzwm9NSRZHAvrHlubNhUgWrtdwbDKOfxxW6hgwKh+OaqDUJ7jxwARRXiXzj9/Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OazHt1nPv6Ggb5jldhDyFftSkEIRCoZgqQu7LUBlQhI=; b=iFcKWZuvNvGrGBQNV2VqImoRwpVAjeKykkbroDnTilH4CntMmqKVi6yQDgTnwJB/+XSqjhjpnXslZeT9FndEfAwDbVwQZcOdTXJkE9C8AoByyE1rUKSZX8ZhKQNahCXZ1uqr480f8ZYs6bd4PuLkqKkg2FIITMcKXEqRUxq5tJ8= Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by CO1PR01MB8844.prod.exchangelabs.com (2603:10b6:303:272::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.8; Sun, 15 Dec 2024 22:19:00 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d%5]) with mapi id 15.20.8272.005; Sun, 15 Dec 2024 22:19:00 +0000 From: John F Carr To: FreeBSD Current Subject: panic: Memory modified after free Thread-Topic: panic: Memory modified after free Thread-Index: AQHbTz9X14tJKvesHES0Pi+nC7gUeA== Date: Sun, 15 Dec 2024 22:19:00 +0000 Message-ID: <5AAF5C07-F278-42D6-AE9C-419448CE07A1@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|CO1PR01MB8844:EE_ x-ms-office365-filtering-correlation-id: 6baead10-b926-486d-b08a-08dd1d5679e1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|10070799003|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?uTTjnScsZtR5wvf+2ZIoT4djaP0pcJoEwP+8vNR8GA0KqBQQ58PjjkCaZVhS?= =?us-ascii?Q?OUs6R0EINt9RdMIfYkcg4uakmrYd6F0AXmkj7KA9qDTBIDpjiGgQOSMKby7j?= =?us-ascii?Q?+bCPKmrgt8ePFAFEOoCZlXcU0/PWIKR4T8tExIDKY0SkmVsnIF2hpimhv/Hb?= =?us-ascii?Q?osyMRte7VjtA+IAwotjW7n1aNOu4HGni5xSdeD0fHF14okiBaxz3yS1i0CbK?= =?us-ascii?Q?6rPzn1YXhfgrXp/2qY5GUiPG+rW20g1BRcJEMKnNugAoRMDxl48F48OaFY21?= =?us-ascii?Q?naj0DruSS/6nFYKNn33Eo254rLPuI8WR+Poi3lxNY/BdI+So276/Kyhumx9g?= =?us-ascii?Q?zjdzdEt1utNhM229OpY7yO6GA456NrZOVhRCGmk+x9aIVVNEIXi/f324h4Hd?= =?us-ascii?Q?3skxuN0npT3CsGlUNcCPule6cDJxwYsbT7ufQaxXQCQ4Gst7Q5Ee5FykSW8h?= =?us-ascii?Q?8xMCsWWeydt2xCw0gHctpNijuHAkp2GRIi5Za1N9mFEN0H22aRB39rWOktam?= =?us-ascii?Q?N+3FM6fBBewtS8D4iAL3Hcq5up4uaqvYgI4hIgJNg4XEOaM68mjVs6+OAZNU?= =?us-ascii?Q?a41u/1jYCJ5FfFATTD8+Gbn5T4/GO1TgEqaM5De8sUSmXC+qfGTNc1df8SAi?= =?us-ascii?Q?qG24CHaVHV7cu4oGckdx1bFB6GVuRJfyyMhwv4rGmEylaCWhHTAJV86abBmf?= =?us-ascii?Q?zLGbTNv0iM0ZFBrSSSJ17Uhz8qqCDtRxjJiSTRJ/XtbHyum2kJ3sAyBmvKxw?= =?us-ascii?Q?M1SUX6W0KfVxZCSeOQiIj5gRNLZYKM5aCIGGPPt4P0PytCSXM0TeQ+fVXB52?= =?us-ascii?Q?hZVheYCxH7ZkHeWXwgXMwro/W4sbC9QtqCr7BPUtSeIJAQobTPDN5dJAiw6j?= =?us-ascii?Q?EAZQ8vlF0pxjqh+OMiR7/BVV96K6SnEkqSCk2CRIeoty81UPlvR8dRJH9e2W?= =?us-ascii?Q?FU1byd7qYCdvQlBVcBGRWsVXQUGExK84sY7f0VqEXIzfF6GvPzMgd2aF7ZVc?= =?us-ascii?Q?Y+eWmAbRH//3+82QZ5PgRK2/1PDbISl6wy9JC0cOotrnLBTL9xEITul4r3Lv?= =?us-ascii?Q?UqTG5nT+e0gWYkquhai8vgE19UoOoqaqWxvZah+8+mJO7Psu0cn4naNmpPqa?= =?us-ascii?Q?yXMqEk2mB5lQC2qJe/ds3ngrwC8vgqastPXr6xrDsvIos2+RSIVnGXlOMvKw?= =?us-ascii?Q?IbJvjdy11DmqEfAwLDdd//yhzGE1Yc7+L8CELv5RfRdvLyjuF0tbkzuPOqnG?= =?us-ascii?Q?w3cs7SrvmTLvK/PHxTE31i7M2tpORgjWhws3ulfu+LRU173+Roeu+ZFJINrr?= =?us-ascii?Q?eeSxXY6JmdJth3/1dd9QjaC2VKnGqR161ISFPBWDMPf+pSmAExtnbDQ8mCT9?= =?us-ascii?Q?/XEqc9plg43Jhx/dqUCZiLhfvlcynByjYreXuxHe8EYIv3/qlloCm0ftneSI?= =?us-ascii?Q?B/YgVziAaSeEHDfcCm0zq9/HKciKA0Wh?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Q643m9D9W9MTZupUuagsjLRwyLxQVp+mjP05/PS3ABgw7Vh3znEQfbSOlps0?= =?us-ascii?Q?fq9EBkxBGTlrF2mjJuN6e9c50Amvq4c6ZhK7Hht5XnFRY8ENEEgQsR7XE/7o?= =?us-ascii?Q?a1qwph8ddbTYPlaWTn5Lrrr2wbcsQbaec3AJQ+RPRCHVkj1fOD7zrzqkadGt?= =?us-ascii?Q?GOUFTAZ6fbinBT/id9yIluAOkEljWV9JwRCNZRWMfoo07dDIzH2FftVwVpS+?= =?us-ascii?Q?wZo97q46e3PMbaUoyG7o6g1Hwd9l70x9ILIgPK1wzlGNsV8j6dztOsyfwUTL?= =?us-ascii?Q?Z1dS5u95lcQ9BeKM5LMT4FAJ34xyuL0TDi66QmPajlotOkrYJ8qDogGKyBkt?= =?us-ascii?Q?OdlsR2dAJrPcBJwF2vNhq5CkABvPj51WvInkwK6bM8Lr+V7Xnb+rA4/csMJd?= =?us-ascii?Q?oiE35a9TQLwAQqzu3090QFdc6LoZkY0i5gfXiCO74+tIBMNXR+txmo0R7azC?= =?us-ascii?Q?jKxg/CNb4VOuYuHAZ/r2jxzODoUDAC1sUmXOIVREU6x0KZlA8Q+img8jima8?= =?us-ascii?Q?MbnVOonOmhLuTlwF5EHILsknkr9HScGJnlaSKJcP1xX/SskyAnNG0TNKSmQ1?= =?us-ascii?Q?V2+9qIyh9QEP/JiP4QJ1a10CUaasLjUKfFEHk0+VOAhnTuCkmp3MpP1UIUtc?= =?us-ascii?Q?8ZmLcWautKBKhVCHlwzDHRQoS49eMnNSW/Rv+AebQE0Qrzft4R3jvX/zXwCO?= =?us-ascii?Q?zjS4AiSaGxp2PFCGdA/aymHCCWz1dacHFTc65P4dP8m37fZrp11zJoeJNoog?= =?us-ascii?Q?U6VmBwvR/ouzRJnudI+MDf8S9O1cAVlhK8UfC+FXDC3VKGBP7JLExrOoQnVV?= =?us-ascii?Q?CUuozvad4D2Cg6wYPIx13SGkX0n3Eu8t7xNFoiawxSSbUVso2tJvPrln6qek?= =?us-ascii?Q?JR3bPuIL12/2xts50ZLR3/s2wMVGkKHhw5ejlRuk/FrsXP1rcNDRAOLQ588f?= =?us-ascii?Q?2NPk2KtScM/u6AAMy5mkv1YF0DXWIuOL6QZKR8gU2Xr/ZjRXXW8FUAF2eG+h?= =?us-ascii?Q?QVvFRufA7cDxlb0wtLqE5lYddbL6QF76lpytLD4DBPPycbOlqxvi5cEDdTp8?= =?us-ascii?Q?2BL9Bqm11ihXWeqEJkRvTXz4C8hCjwHQ/11u5FwM5wcI6K7zoQTfbaApTL6M?= =?us-ascii?Q?/EB1VRQLfb+KUNvPmTjjhmviaX5Nz+UUwsOMxHtAnYvMKr8y/ClxEpCG6oX0?= =?us-ascii?Q?FFuU+mLOHjHQaMtNgsNt1CorC/dCQ49g63T5xOH5X8orjVsS7bdiNnJ2I7PE?= =?us-ascii?Q?xvAoTvBEW8XPl3QZf6PsRVxtQcIN2MXjX1UzEegDNssNl1S67+D+9ES5VUSf?= =?us-ascii?Q?KKquBlIJ7HIeo4qe3jvk/4pylwmJS2VP+zUSCchLouUayE/AHMmwat/1ZGAt?= =?us-ascii?Q?7e0G3R9G+s0DKRX1PunP987JtSkacrYBwoBwA8SAV40F6YMUflFZoQjJJg/U?= =?us-ascii?Q?3EiadgYFUYKq0Xtmtl+Bbr4nB7I7dPVqSNbVQhLuaVuKd4pbEHn8A9l/3UVs?= =?us-ascii?Q?8O9RVV/QlDMdqCVk8n0Kua68+iuJKP51NPQ9ZP/fdEEC5rL6DQEsGlCqbgim?= =?us-ascii?Q?ILSJfc/WqnXShQgsOjn+I2pGCz0mJvoNPWzCc7NUxDwwn3TtvGFX+tbngftc?= =?us-ascii?Q?DmzrzQrKC+XtyYUAtILVO/OsYDKd2dAUkdpBpv+zeaZv?= Content-Type: text/plain; charset="us-ascii" Content-ID: <6F6BA5057CCE1D4092E8926036436D03@prod.exchangelabs.com> 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 X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6baead10-b926-486d-b08a-08dd1d5679e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2024 22:19:00.5633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r+x60lbE0D64T6xPS+5nD4e76E5DsGBfBGWNDgZwKjaBbmh+c/AWKRIoceLgftN0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR01MB8844 X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector10001:i=1]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; R_DKIM_ALLOW(-0.20)[mit.edu:s=selector2]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.93.201.92:from]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[mit.edu:+] X-Rspamd-Queue-Id: 4YBHY35Kkdz4pP5 X-Spamd-Bar: ----- My ARM server crashed while running "make installworld installkernel". The message is panic: Memory modified after free 0xffffa00006305e60 (16, malloc-16, devbuf= ) + 0 =3D deadc0dedeadc006 The stack trace goes through tmpfs, which could be an innocent victim. The other filesystems are ZFS. There are a lot of USB devices connected. The last commit from main in the kernel is fe291141486acf27ed1c8eed791ba989= 7f84c3f0. The local changes should not affect the kernel on this machine. Is there anything likely to be useful in the crash dump? The rest of the message is the start of core.txt.6. striatus dumped core - see /var/crash/vmcore.6 Fri Dec 13 19:29:06 EST 2024 FreeBSD striatus 15.0-CURRENT FreeBSD 15.0-CURRENT #3 striatus-n273968-f25f= d2c8374a: Sun Dec 1 03:17:23 EST 2024 jfc@striatus:/usr/obj/usr/src/ar= m64.aarch64/sys/STRIATUS arm64 panic: Memory modified after free 0xffffa00006305e60 (16, malloc-16, devbuf= ) + 0 =3D deadc0dedeadc006 Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Reading symbols from /boot/kernel/cryptodev.ko... Reading symbols from /usr/lib/debug//boot/kernel/cryptodev.ko.debug... Reading symbols from /boot/kernel/ig4.ko... Reading symbols from /usr/lib/debug//boot/kernel/ig4.ko.debug... Reading symbols from /boot/kernel/uftdi.ko... Reading symbols from /usr/lib/debug//boot/kernel/uftdi.ko.debug... Reading symbols from /boot/kernel/ucom.ko... Reading symbols from /usr/lib/debug//boot/kernel/ucom.ko.debug... Reading symbols from /boot/kernel/uchcom.ko... Reading symbols from /usr/lib/debug//boot/kernel/uchcom.ko.debug... Reading symbols from /boot/kernel/if_axge.ko... Reading symbols from /usr/lib/debug//boot/kernel/if_axge.ko.debug... Reading symbols from /boot/kernel/mac_ntpd.ko... Reading symbols from /usr/lib/debug//boot/kernel/mac_ntpd.ko.debug... Reading symbols from /boot/kernel/filemon.ko... Reading symbols from /usr/lib/debug//boot/kernel/filemon.ko.debug... Reading symbols from /boot/kernel/nullfs.ko... Reading symbols from /usr/lib/debug//boot/kernel/nullfs.ko.debug... Reading symbols from /boot/kernel/fdescfs.ko... Reading symbols from /usr/lib/debug//boot/kernel/fdescfs.ko.debug... 0xffff0000006ddb88 in doadump (textdump=3D0, textdump@entry=3D3220761328) at /usr/src/sys/kern/kern_shutdown.c:404 404 dump_savectx(); (kgdb) #0 0xffff0000006ddb88 in doadump (textdump=3D0, textdump@entry=3D32= 20761328) at /usr/src/sys/kern/kern_shutdown.c:404 error =3D 0 coredump =3D #1 0xffff0000002f84bc in db_dump (dummy=3D,=20 dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:596 error =3D #2 0xffff0000002f8270 in db_command (last_cmdp=3D,=20 cmd_table=3D, dopager=3Dtrue) at /usr/src/sys/ddb/db_command.c:508 modif =3D "\000\353\370\277\000\000\377\377\000\353\370\277\000\000= \377\377\000@\000\001\000\000\377\377\310\377\377\377\000\000\000\000\200\3= 53\370\277\000\000\377\377p\255/\000\000\000\377\377\000\000\000\000\000\00= 0\000\000\000\320!\001\000\000\377\377\200\353\370\277\000\000\377\377|\255= /\000\000\000\377\377\000\000\000\000\000\000\000\0000\340!\001\000\000\377= \377\340\353\370\277\000\000\377\377t\260/\000\000\000\377\377\000`\b\001\0= 00\000\377\377" addr =3D -281474969178324 count =3D -1 have_addr =3D cmd =3D 0xffff000000faff60 t =3D result =3D #3 0xffff0000002f7f34 in db_command_loop () at /usr/src/sys/ddb/db_command.c:555 No locals. #4 0xffff0000002fbfb4 in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:267 jb =3D {{_jb =3D {18446462601953602608,=20 -5192240428643675738518913775244240,=20 -5192296467524930435797529359615502,=20 -5192296477290489174466776304776360,=20 -5192296468505116628898160085655552,=20 -5192237445959521374093222199402496,=20 -5192296590745196351457412900733128,=20 -5192237445966900071722702816613136,=20 79228161499693132067762662960,=20 -5192237445966900071722702816613136,=20 79228161499693132067762662960,=20 -5192296800790449699300821084607248,=20 -5192296718864917493094550124040768,=20 -5192296626485486292827088539877369,=20 -5192296728739902317609042133324512,=20 -5192296719202197761738255565787696,=20 -5192296719202197761738258752417864, -184467440771455254527,= =20 26615710863082138512284773984,=20 -5192296765144699321027431923913328,=20 -5192296765145086702371508068548598,=20 -5192296507247853976218498451492864,=20 -5192296734691486038574397028504128,=20 -5192296734691486038574397028504128,=20 -5192296734691504485036998982107126,=20 -5192296668329914529214643795595728,=20 -5192237445951128105258209394032640,=20 -5192296555040877560468520940077056,=20 -5192237445949910620149344563625983,=20 -5192296718790835368894532564750720,=20 -5192296718790835368894532564750720,=20 -5192296734717680415159064591798720}}} bkpt =3D false watchpt =3D false prev_jb =3D 0x0 why =3D #5 0xffff00000072fc8c in kdb_trap (type=3D60, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:790 other_cpus =3D {__bits =3D {18446462598743929896, 18446462601953603= 544,=20 12, 5, 10, 0, 256, 18446462598750552064, 18446462601791911488,= =20 18446462601953603440, 0, 35088872438672, 35088965921264,=20 18446462601953603952, 13597801529282666180, 1844646260195360376= 0}} be =3D 0xffff000000fb0b58 intr =3D 704 did_stop_cpus =3D handled =3D #6 No locals. #7 kdb_enter (why=3D, msg=3D) at /usr/src/sys/kern/subr_kdb.c:556 No locals. #8 0xffff0000006dde98 in vpanic ( fmt=3D0xffff000000c4a3ca "Memory modified after free %p (%d, %s, %s) + = %d =3D %lx\n", ap=3D...) at /usr/src/sys/kern/kern_shutdown.c:967 buf =3D "Memory modified after free 0xffffa00006305e60 (16, malloc-= 16, devbuf) + 0 =3D deadc0dedeadc006\n", '\000' other_cpus =3D {__bits =3D {11, 0 }} td =3D 0xffff0000b655b640 newpanic =3D bootopt =3D 4 #9 0xffff0000006ddc7c in panic ( fmt=3D0x12 ) at /usr/src/sys/kern/kern_shutdown.c:892 ap =3D {__stack =3D 0xffff0000bff8f380, __gr_top =3D 0xffff0000bff8= f330,=20 __vr_top =3D 0x1, __gr_offs =3D -56, __vr_offs =3D 0} #10 0xffff000000a4873c in mtrash_ctor (mem=3D0xffffa00006305e60,=20 size=3D, arg=3D, flags=3D) at /usr/src/sys/vm/uma_dbg.c:179 zone =3D p =3D osize =3D 16 e =3D 0xffffa00006305e68 ksp =3D 0xffffa00006305e68 off =3D #11 0xffff000000a4068c in item_ctor (zone=3D0xffff000040405400,=20 uz_flags=3D, size=3D16, udata=3D, flags= =3D2,=20 item=3D0xffffa00006305e60) at /usr/src/sys/vm/uma_core.c:3515 skipdbg =3D #12 0xffff0000006acf70 in malloc (size=3Dsize@entry=3D10,=20 mtp=3D0xffff000000ff4788 , flags=3Dflags@entry=3D2) at /usr/src/sys/kern/kern_malloc.c:663 va =3D 0x0 indx =3D 0 zone =3D 0xffff000040405400 #13 0xffff000000603180 in tmpfs_alloc_dirent (tmp=3D0xffffa00001bb8300,=20 node=3D0xffffa000ec5472d0, name=3D0xffffa00051cb7030 "LC_COLLATE", len= =3D10,=20 de=3D) at /usr/src/sys/fs/tmpfs/tmpfs_subr.c:914 _size =3D 10 nde =3D 0xffffa0010f011680 _size =3D _malloc_item =3D _size =3D _malloc_item =3D #14 tmpfs_alloc_file (dvp=3Ddvp@entry=3D0xffffa0004a40c6e0,=20 vpp=3Dvpp@entry=3D0xffff0000bff8f708, vap=3D,=20 cnp=3Dcnp@entry=3D0xffff0000bff8f730, target=3D,=20 target@entry=3D0xffff0000bff8f4c0 "\360", ) at /usr/src/sys/fs/tmpfs/tmpfs_subr.c:1245 node =3D 0xffffa000ec5472d0 tmp =3D 0xffffa00001bb8300 dnode =3D parent =3D error =3D de =3D #15 0xffff0000005fc344 in tmpfs_create (v=3D) at /usr/src/sys/fs/tmpfs/tmpfs_vnops.c:269 dvp =3D 0xffffa0004a40c6e0 vpp =3D 0xffff0000bff8f708 cnp =3D 0xffff0000bff8f730 vap =3D 0xffff000000d09fc8 error =3D #16 0xffff000000bdf7d0 in VOP_CREATE_APV ( vop=3D0xffff000000ff3f20 ,=20 a=3Da@entry=3D0xffff0000bff8f600) at vnode_if.c:242 rc =3D #17 0xffff0000007f19d0 in VOP_CREATE (dvp=3D0xffff00000141015c ,=20 vpp=3D0xffff0000bff8f708, cnp=3D0xffff0000bff8f730, vap=3D0xffff0000bff= 8f540) at ./vnode_if.h:131 a =3D {a_gen =3D {a_desc =3D 0xffff0000010da340 },= =20 a_dvp =3D 0xffffa0004a40c6e0, a_vpp =3D 0xffff0000bff8f708,=20 a_cnp =3D 0xffff0000bff8f730, a_vap =3D 0xffff0000bff8f540} #18 vn_open_cred (ndp=3Dndp@entry=3D0xffff0000bff8f6b0, flagp=3D,=20 flagp@entry=3D0xffff0000bff8f784, cmode=3D292,=20 vn_open_flags=3Dvn_open_flags@entry=3D16, cred=3D0xffffa0001f692400,=20 fp=3D) at /usr/src/sys/kern/vfs_vnops.c:285 vp =3D 0xffffa0000701a5f0 mp =3D 0xffff0000b6458b80 vat =3D {va_type =3D VREG, va_mode =3D 292, va_padding0 =3D 0,=20 va_uid =3D 4294967295, va_gid =3D 4294967295,=20 va_nlink =3D 18446744073709551615, va_fsid =3D 184467440737095516= 15,=20 va_fileid =3D 18446744073709551615, va_size =3D 18446744073709551= 615,=20 va_blocksize =3D -1, va_atime =3D {tv_sec =3D -1, tv_nsec =3D -1}= ,=20 va_mtime =3D {tv_sec =3D -1, tv_nsec =3D -1}, va_ctime =3D {tv_se= c =3D -1,=20 tv_nsec =3D -1}, va_birthtime =3D {tv_sec =3D -1, tv_nsec =3D -= 1},=20 va_gen =3D 18446744073709551615, va_flags =3D 1844674407370955161= 5,=20 va_rdev =3D 18446744073709551615, va_bytes =3D 184467440737095516= 15,=20 va_filerev =3D 0, va_vaflags =3D 0, va_spare =3D 0} first_open =3D false error =3D fmode =3D vap =3D #19 0xffff0000007e85b0 in openatfp (td=3D0xffff0000b655b640,=20 dirfd=3D,=20 path=3D0x1fe942f24678 , pathseg=3DUIO_USERSPACE, pathseg@entry=3D(unknown: 0xbff8f800), fla= gs=3D1538,=20 mode=3D33060, fpp=3D0x0, fpp@entry=3D0xffff0000bff8f800) at /usr/src/sys/kern/vfs_syscalls.c:1211 fp =3D 0xffffa0000701a5f0 nd =3D { ni_dirp =3D 0x1fe942f24678 , ni_segflg =3D UIO_USERSPACE, ni_rightsneeded =3D 0xffff0= 000bff8f6a0,=20 ni_startdir =3D 0x0, ni_rootdir =3D 0xffffa00006ecd898, ni_topdir= =3D 0x0,=20 ni_dirfd =3D -100, ni_lcf =3D 0, ni_filecaps =3D {fc_rights =3D { cr_rights =3D {0, 0}}, fc_ioctls =3D 0x0, fc_nioctls =3D -1,= =20 fc_fcntls =3D 0}, ni_vp =3D 0x0, ni_dvp =3D 0xffffa0004a40c6e0,= =20 ni_resflags =3D 1, ni_debugflags =3D 3, ni_loopcnt =3D 0, ni_path= len =3D 59,=20 ni_next =3D 0xffffa00051cb703a "", ni_cnd =3D {cn_flags =3D 28131= 3359,=20 cn_cred =3D 0xffffa0001f692400, cn_nameiop =3D CREATE,=20 cn_lkflags =3D 524288,=20 cn_pnbuf =3D 0xffffa00051cb7000 "/tmp/install.KlmLI038ne/locale= /nl_NL.ISO8859-15/LC_COLLATE", cn_nameptr =3D 0xffffa00051cb7030 "LC_COLLAT= E",=20 cn_namelen =3D 10}, ni_cap_tracker =3D { tqh_first =3D 0xffffffffffffffff, tqh_last =3D 0xffffffffffffff= ff},=20 ni_dvp_seqc =3D 1689292205, ni_vp_seqc =3D 0} indx =3D -1 p =3D rights =3D {cr_rights =3D {, 288230376151711744}} fdp =3D 0xffff0000e701fc90 pdp =3D 0xffffa00006477b00 error =3D vp =3D fcaps =3D cmode =3D #20 0xffff0000007e8330 in kern_openat (td=3D0x12, dirfd=3D21037404,=20 path=3D0xffff000000d09fc8 "/usr/src/sys/kern/kern_cons.c",=20 pathseg=3DUIO_USERSPACE, flags=3D115, mode=3D7572444) at /usr/src/sys/kern/vfs_syscalls.c:1316 No locals. #21 0xffff0000e68f8cac in filemon_wrapper_openat (td=3D0xffff0000b655b640,= =20 uap=3D0xffff0000b655ba40) at /usr/src/sys/dev/filemon/filemon_wrapper.c= :229 ret =3D #22 0xffff000000ac11c8 in syscallenter (td=3D0xffff0000b655b640) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:189 se =3D 0xffff000001002040 sa =3D 0xffff0000b655ba30 p =3D error =3D sy_thr_static =3D true traced =3D _audit_entered =3D #23 svc_handler (td=3D0xffff0000b655b640, frame=3D) at /usr/src/sys/arm64/arm64/trap.c:198 No locals. #24 do_el0_sync (td=3D0xffff0000b655b640, frame=3D) at /usr/src/sys/arm64/arm64/trap.c:658 far =3D esr =3D exception =3D bp_harden =3D dfsc =3D #25 No locals. #26 0x00001fe9c95969f0 in ?? () No symbol table info available. #27 0x00001fe9c6f48c0c in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) (kgdb) (kgdb) Tracing command "pagedaemon\000\000\000\000\000\000\000\000\0= 00" pid 8 tid 100107 (CPU 0) #0 0xffff000000aa7614 in ipi_stop (dummy=3D) at /usr/src/sys/arm64/arm64/mp_machdep.c:337 #1 0xffff000000a8a748 in arm_gic_intr (arg=3D0xffffa00001baf100,=20 arg@entry=3D) at /usr/src/sys/arm/arm/gic.c:582 #2 0xffff000000a84410 in intr_irq_handler (tf=3D0xffff0000bfe27240,=20 rootnum=3D) at /usr/src/sys/kern/subr_intr.c:360 #3 #4 trash_ctor (mem=3D0xffffa00107fb5000, size=3D4096, arg=3D0x0, flags=3D0= ) at /usr/src/sys/vm/uma_dbg.c:79 #5 trash_fini (mem=3D0xffffa00107fb5000, size=3D4096) at /usr/src/sys/vm/uma_dbg.c:133 #6 0xffff000000a465b4 in keg_free_slab (keg=3Dkeg@entry=3D0xffff0000c15868= 00,=20 slab=3D0xffffa000a4032558, start=3D) at /usr/src/sys/vm/uma_core.c:1621 #7 0xffff000000a464d0 in keg_drain_domain (keg=3Dkeg@entry=3D0xffff0000c15= 86800,=20 domain=3Ddomain@entry=3D0) at /usr/src/sys/vm/uma_core.c:1686 #8 0xffff000000a43220 in keg_drain (keg=3D0xffff0000c1586800,=20 domain=3D) at /usr/src/sys/vm/uma_core.c:1706 #9 zone_reclaim (zone=3Dzone@entry=3D0xffff0000c1588800, domain=3Ddomain@e= ntry=3D-1,=20 waitok=3D, waitok@entry=3D1, drain=3D) at /usr/src/sys/vm/uma_core.c:1731 #10 0xffff000000a42748 in uma_zone_reclaim_domain (zone=3D0xffff0000c158880= 0,=20 req=3D3, domain=3D-1) at /usr/src/sys/vm/uma_core.c:3090 #11 uma_reclaim_domain_cb (zone=3D0xffff0000c1588800, arg=3D= ) at /usr/src/sys/vm/uma_core.c:5310 #12 zone_foreach_unlocked (zfunc=3D, arg=3D) at /usr/src/sys/vm/uma_core.c:3091 #13 zone_foreach (zfunc=3D, arg=3D) at /usr/src/sys/vm/uma_core.c:3112 #14 uma_reclaim_domain (req=3Dreq@entry=3D3, domain=3D-1) at /usr/src/sys/vm/uma_core.c:5334 #15 0xffff000000a4266c in uma_reclaim (req=3D133910528, req@entry=3D3) at /usr/src/sys/vm/uma_core.c:5317 #16 0xffff000000a71168 in vm_pageout_lowmem () at /usr/src/sys/vm/vm_pageout.c:2041 #17 vm_pageout_worker (arg=3D) at /usr/src/sys/vm/vm_pageout.c:2133 #18 0xffff000000a70d48 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:236= 6 #19 0xffff00000068e25c in fork_exit (callout=3D0xffff000000a70b60 ,=20 arg=3D0x0, frame=3D0xffff0000bfe27a00) at /usr/src/sys/kern/kern_fork.c= :1151 #20 Tracing command "idle\000l", '\000' pid 11 tid 100004 (C= PU 1) #0 0xffff000000aa7614 in ipi_stop (dummy=3D) at /usr/src/sys/arm64/arm64/mp_machdep.c:337 #1 0xffff000000a8a748 in arm_gic_intr (arg=3D0xffffa00001baf100,=20 arg@entry=3D) at /usr/src/sys/arm/arm/gic.c:582 #2 0xffff000000a84410 in intr_irq_handler (tf=3D0xffff0000bfc1a6e0,=20 rootnum=3D) at /usr/src/sys/kern/subr_intr.c:360 #3 #4 cpu_idle (busy=3D) at /usr/src/sys/arm64/arm64/machdep.c= :282 #5 0xffff000000712680 in sched_idletd (dummy=3Ddummy@entry=3D0x0) at /usr/src/sys/kern/sched_ule.c:3058 #6 0xffff00000068e25c in fork_exit ( callout=3D0xffff0000007121e0 , arg=3D0x0,=20 frame=3D0xffff0000bfc1aa00) at /usr/src/sys/kern/kern_fork.c:1151 #7 Tracing command "cp", '\000' pid 73242 tid 100204 (CPU 2= ) #0 0xffff0000006ddb88 in doadump (textdump=3D0, textdump@entry=3D322076132= 8) at /usr/src/sys/kern/kern_shutdown.c:404 #1 0xffff0000002f84bc in db_dump (dummy=3D,=20 dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:596 #2 0xffff0000002f8270 in db_command (last_cmdp=3D,=20 cmd_table=3D, dopager=3Dtrue) at /usr/src/sys/ddb/db_command.c:508 #3 0xffff0000002f7f34 in db_command_loop () at /usr/src/sys/ddb/db_command.c:555 #4 0xffff0000002fbfb4 in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:267 #5 0xffff00000072fc8c in kdb_trap (type=3D60, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:790 #6 #7 kdb_enter (why=3D, msg=3D) at /usr/src/sys/kern/subr_kdb.c:556 #8 0xffff0000006dde98 in vpanic ( fmt=3D0xffff000000c4a3ca "Memory modified after free %p (%d, %s, %s) + = %d =3D %lx\n", ap=3D...) at /usr/src/sys/kern/kern_shutdown.c:967 #9 0xffff0000006ddc7c in panic ( fmt=3D0x12 ) at /usr/src/sys/kern/kern_shutdown.c:892 #10 0xffff000000a4873c in mtrash_ctor (mem=3D0xffffa00006305e60,=20 size=3D, arg=3D, flags=3D) at /usr/src/sys/vm/uma_dbg.c:179 #11 0xffff000000a4068c in item_ctor (zone=3D0xffff000040405400,=20 uz_flags=3D, size=3D16, udata=3D, flags= =3D2,=20 item=3D0xffffa00006305e60) at /usr/src/sys/vm/uma_core.c:3515 #12 0xffff0000006acf70 in malloc (size=3Dsize@entry=3D10,=20 mtp=3D0xffff000000ff4788 , flags=3Dflags@entry=3D2) at /usr/src/sys/kern/kern_malloc.c:663 #13 0xffff000000603180 in tmpfs_alloc_dirent (tmp=3D0xffffa00001bb8300,=20 node=3D0xffffa000ec5472d0, name=3D0xffffa00051cb7030 "LC_COLLATE", len= =3D10,=20 de=3D) at /usr/src/sys/fs/tmpfs/tmpfs_subr.c:914 #14 tmpfs_alloc_file (dvp=3Ddvp@entry=3D0xffffa0004a40c6e0,=20 vpp=3Dvpp@entry=3D0xffff0000bff8f708, vap=3D,=20 cnp=3Dcnp@entry=3D0xffff0000bff8f730, target=3D,=20 target@entry=3D0xffff0000bff8f4c0 "\360", ) at /usr/src/sys/fs/tmpfs/tmpfs_subr.c:1245 #15 0xffff0000005fc344 in tmpfs_create (v=3D) at /usr/src/sys/fs/tmpfs/tmpfs_vnops.c:269 #16 0xffff000000bdf7d0 in VOP_CREATE_APV ( vop=3D0xffff000000ff3f20 ,=20 a=3Da@entry=3D0xffff0000bff8f600) at vnode_if.c:242 #17 0xffff0000007f19d0 in VOP_CREATE (dvp=3D0xffff00000141015c ,=20 vpp=3D0xffff0000bff8f708, cnp=3D0xffff0000bff8f730, vap=3D0xffff0000bff= 8f540) at ./vnode_if.h:131 #18 vn_open_cred (ndp=3Dndp@entry=3D0xffff0000bff8f6b0, flagp=3D,=20 flagp@entry=3D0xffff0000bff8f784, cmode=3D292,=20 vn_open_flags=3Dvn_open_flags@entry=3D16, cred=3D0xffffa0001f692400,=20 fp=3D) at /usr/src/sys/kern/vfs_vnops.c:285 #19 0xffff0000007e85b0 in openatfp (td=3D0xffff0000b655b640,=20 dirfd=3D,=20 path=3D0x1fe942f24678 , pathseg=3DUIO_USERSPACE, pathseg@entry=3D(unknown: 0xbff8f800), fla= gs=3D1538,=20 mode=3D33060, fpp=3D0x0, fpp@entry=3D0xffff0000bff8f800) at /usr/src/sys/kern/vfs_syscalls.c:1211 #20 0xffff0000007e8330 in kern_openat (td=3D0x12, dirfd=3D21037404,=20 path=3D0xffff000000d09fc8 "/usr/src/sys/kern/kern_cons.c",=20 pathseg=3DUIO_USERSPACE, flags=3D115, mode=3D7572444) at /usr/src/sys/kern/vfs_syscalls.c:1316 #21 0xffff0000e68f8cac in filemon_wrapper_openat (td=3D0xffff0000b655b640,= =20 uap=3D0xffff0000b655ba40) at /usr/src/sys/dev/filemon/filemon_wrapper.c= :229 #22 0xffff000000ac11c8 in syscallenter (td=3D0xffff0000b655b640) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:189 #23 svc_handler (td=3D0xffff0000b655b640, frame=3D) at /usr/src/sys/arm64/arm64/trap.c:198 #24 do_el0_sync (td=3D0xffff0000b655b640, frame=3D) at /usr/src/sys/arm64/arm64/trap.c:658 #25 #26 0x00001fe9c95969f0 in ?? () #27 0x00001fe9c6f48c0c in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Tracing command "idle\000l", '\000' pid 11 tid 100006 (C= PU 3) #0 0xffff000000aa7614 in ipi_stop (dummy=3D) at /usr/src/sys/arm64/arm64/mp_machdep.c:337 #1 0xffff000000a8a748 in arm_gic_intr (arg=3D0xffffa00001baf100,=20 arg@entry=3D) at /usr/src/sys/arm/arm/gic.c:582 #2 0xffff000000a84410 in intr_irq_handler (tf=3D0xffff0000bfc106e0,=20 rootnum=3D) at /usr/src/sys/kern/subr_intr.c:360 #3 #4 cpu_idle (busy=3D) at /usr/src/sys/arm64/arm64/machdep.c= :282 #5 0xffff000000712680 in sched_idletd (dummy=3Ddummy@entry=3D0x0) at /usr/src/sys/kern/sched_ule.c:3058 #6 0xffff00000068e25c in fork_exit ( callout=3D0xffff0000007121e0 , arg=3D0x0,=20 frame=3D0xffff0000bfc10a00) at /usr/src/sys/kern/kern_fork.c:1151 #7