From nobody Mon May 19 07:22:24 2025 X-Original-To: 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 4b18KP0t5nz5wfQj for ; Mon, 19 May 2025 07:22:49 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from fhigh-a7-smtp.messagingengine.com (fhigh-a7-smtp.messagingengine.com [103.168.172.158]) (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 4b18KL6d2Dz3LN0; Mon, 19 May 2025 07:22:46 +0000 (UTC) (envelope-from dch@skunkwerks.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=r4YIs3il; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="eOS/aMqA"; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 103.168.172.158 as permitted sender) smtp.mailfrom=dch@skunkwerks.at; dmarc=pass (policy=reject) header.from=skunkwerks.at Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 711E711400EB; Mon, 19 May 2025 03:22:45 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Mon, 19 May 2025 03:22:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1747639365; x=1747725765; bh=2Lw3jhXh2qKxlZyK84WiM1oDUjvqm2t2qANTHoz4H8k=; b= r4YIs3ilc9mXdPMADUdcjsFhY15YFuuYRRk+MaKmhRlV/LYNUS1Ga2rF0Fd5Bt4L CC75PskqKNPkiY0KcAh6en5+MGMhJEek9dlwDUg3cRmajllzeqxhzwF3CoexGvIO J4AtI8arsxMcYh/mvBkGO4HDX9DWsx0cKMXL8DRDs/h0+MpkzoKusKUeVLJeJCBA BIQkTWAhvpIcgzZgy6llg9SZyR/icR48ESSIme2VjtmesWsLtQSSQ2QkXj72M8nu OCb1LTUUpiMeTkBye5az7Lownn500Jcvrpc4D9be5BQuWhc59nlbsS6ek2+kfDjq RXH7ysP/GvKzgCwkhnPpUA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1747639365; x=1747725765; bh=2 Lw3jhXh2qKxlZyK84WiM1oDUjvqm2t2qANTHoz4H8k=; b=eOS/aMqALtz/WHOuh x1CxCy/lzGVI8NWufwHPqKOtnB441N+tq6lvL2s8gdFG3OrQ8fS9jAUWFO7P1oik nFYHYT2ZCAbsfE9KqeCOAJFBPtz6pmcm8ljPgme5Y70buF1DGw9LErfgAzN56/2s pO2HtmPlyKRnUQhEV2mIdthYg3U/InsBX6CmwzL2b5vIL5vuIpo+vzHGEQwXxYoW pU2Yn/n0GTQYUm82kGAE0GnkevJKyuEb1xvTjuUskDMESMtHgs1QuVW+uPfQJova gpl1WfmW0g9KahbbWdc0yoeE2AnhJzTvXetVmzjZBl5IJqj3YwEBGLWzW1Cd/Yk7 UJAYQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefvddtjeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvffkjghfufgtgfesthejredtredt tdenucfhrhhomhepfdffrghvvgcuvehothhtlhgvhhhusggvrhdfuceouggthhesshhkuh hnkhifvghrkhhsrdgrtheqnecuggftrfgrthhtvghrnhepieevheejfedugfejleejleek tdeileeukedtveefieetuedtleejheefgeehfefhnecuffhomhgrihhnpehfrhgvvggssh gurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepuggthhesshhkuhhnkhifvghrkhhsrdgrthdpnhgspghrtghpthhtohepvddpmhhoug gvpehsmhhtphhouhhtpdhrtghpthhtohepsggrphhtsehfrhgvvggsshgurdhorhhgpdhr tghpthhtoheptghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id D34422CC007F; Mon, 19 May 2025 03:22:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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-ThreadId: T9fd310189b0edc49 Date: Mon, 19 May 2025 07:22:24 +0000 From: "Dave Cottlehuber" To: "Baptiste Daroussin" , current@freebsd.org Message-Id: <275a1cd1-8fdf-4df9-98d3-fe3e78ada23c@app.fastmail.com> In-Reply-To: <682742f0.c1kjogtHsKHAqFq9%bapt@FreeBSD.org> References: <682742f0.c1kjogtHsKHAqFq9%bapt@FreeBSD.org> Subject: Re: New packages repositories for kernel modules (without typo) Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4b18KL6d2Dz3LN0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.892]; DMARC_POLICY_ALLOW(-0.50)[skunkwerks.at,reject]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.158:from]; XM_UA_NO_VERSION(0.01)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[dch]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+] On Fri, 16 May 2025, at 13:51, bapt@freebsd.org wrote: > New package repositories available for kernel modules. > > Since 14.2-RELEASE we have been publishing a repository of packages built for > all supported arches. > > With the upcoming 14.3-RELEASE we have extended the infrastructure so it now > covers the following branches: > - releng/14.2 (14.2-RELEASE) (from latest and quarterly ports) > - releng/14.3 (14.3-RELEASE) (from latest and quarterly ports) > - stable/14 (14.3-STABLE) (from latest and quarterly ports) > - main (15.0-CURRENT) (only latest ports) > > To use them, here is the necessary configuration: > (it can be added to /usr/local/etc/pkg/repos/kmods.conf) > > ---- > FreeBSD-kmods: { > url: "pkg+https://pkg.FreeBSD.org/${ABI}/KMODSFLAVOR", > mirror_type: "srv", > signature_type: "fingerprints", > fingerprints: "/usr/share/keys/pkg", > enabled: yes > } > ---- > > KMODSFLAVOR repect the following pattern: > > kmods_PORTBRANCH_MINORRELEASE > > List of what is being published: > > +----------------------+----------------+-------------------+ > | FreeBSD Release | ports main | ports quarterly | > +----------------------+----------------+-------------------+ > | FreeBSD 14.2-RELEASE | kmods_latest_2 | kmods_quarterly_2 | > | FreeBSD 14.3-RELEASE | kmods_latest_3 | kmods_quarterly_3 | > | FreeBSD 14.3-STABLE | kmods_latest | kmods_quarterly | > | FreeBSD 15.0-CURRENT | kmods_latest | | > +----------------------+----------------+-------------------+ > > Note for current and stable the repositories are built against > the version available in the weekly pkgbase snapshots. > > Best regards, > Bapt Thanks Baptiste this is fantastic. On a practical note, how will this information get into the hands of users, both for upgrades, and for new installs? A+ Dave From nobody Mon May 19 08:43:22 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1B6Q1hRKz5wlkZ for ; Mon, 19 May 2025 08:43:26 +0000 (UTC) (envelope-from kp@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1B6Q0wZSz3wc1; Mon, 19 May 2025 08:43:26 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747644206; 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=3QDaKYjDl+AMi2dkqMfQLkip6lta4ZHSlXXlIMWXBnU=; b=AbKIg+WuJfQmOgVWs4Azx8PiNHzHCDng6bxJFRPIoL9TE+O7ncvaG9Exb+OuWJPt3QIP7P 6OUbrcbPhVMwzuzrbd7EQG7lI0uDoEsVoOrkTLa/YA8QoXfyy73l9a8s1ib5Cv/atVoqpe DQjXwlRnI7YehIh4xN29KmU57sgLfUggWwDVy1ayXtt4xBqlGLfnylmrMOQjOwfVXT/x5+ CgN0aeNLEzeKb3e6g6R0KFtOTBcjgxu4oUP80UuPEVXWfuCYPf4TuRmz/aja1XcaEZKGed 4x3CfO8R7L9vjxFyS54Lh0OWuK6NncK/if/7Tra9/3nlnjm5W3pacsyOugtUNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747644206; 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=3QDaKYjDl+AMi2dkqMfQLkip6lta4ZHSlXXlIMWXBnU=; b=PbkJ+pCHK0GPI3bsA0GRY5DWcy9Ey4tfZdmpFQWZuMPgxDjqJfRJ26DF1iz6T40D/OIesj kOkS/ZMsWZ9JDHFJ86ve285OaecXZSexqb+xRJgeK/P6Wb1CalbH7tSy77hkcynHwqVSaT b47QyniGSkQB7ON1kAvz4rRJRHru3pk8DNlBStYJ/La6q1b9cRSfgkV4frkW/AlX/tOBcv 6i5C8Cqs6Lc4cQmXSFwaz4m9HAOUyLYo8g+YwHW18mSCN2smrQUBbTHLoK8k0owRO0bL8O 3uu2JPL2TjmPsfkV1MwZyAO9lDu6Vt5nEzyzTPQr3GQDQ+Y+jX1PmV5j6c0Gow== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747644206; a=rsa-sha256; cv=none; b=dBkKcqpJpfQiGXUK4mybtszr70ykOPhFVqLQbdt8JOYoaUqjuLJvC1rKfLTj2FqE8g2Wgi Fj0x5bmoSV+DDqxTOqc671U8nmjsPiYPdvOiqRGNre/Hw7OoH0YKGRmE2Z6Fwbj27Winxe 29VDPUIeCYD3VxdIOihoawv2hyyZnk5O6XZjO5hszIC3lr/ptnhBBYoKO0P5QRfBYu63o+ CLiq4R1pP6nsaZAH7DTJxJ+oAsceSGchegHGC9wrsfAi+tGvtTAX1ozeeuVMVdHxCMX2Hz bruFfp1KyDGS/u5O+dG8JKIBIpn6BtJejHkvmKZqvKCg9AZO84YwH4ew6l7JYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b1B6P6XSgz9gp; Mon, 19 May 2025 08:43:25 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id E13891EB7A; Mon, 19 May 2025 10:43:23 +0200 (CEST) From: Kristof Provost To: Marek Zarychta Cc: Alexander Leidinger , A FreeBSD User , rgrimes@freebsd.org, FreeBSD CURRENT Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument Date: Mon, 19 May 2025 10:43:22 +0200 X-Mailer: MailMate (2.0r6255) Message-ID: <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> In-Reply-To: <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> 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; markup=markdown Content-Transfer-Encoding: quoted-printable On 18 May 2025, at 21:24, Marek Zarychta wrote: > W dniu 18.05.2025 o=C2=A019:48, Alexander Leidinger pisze: >> You want to make it work without this. Short: use the IP on the bridge= itself, not in the member IF. > I'm not sure we should be dictating to Oliver what he must do. Oliver is of course free to solve his problem however he wishes, but sett= ing the sysctl is the worst option available. This will break again later= , and will continue to break multicast. The usual warranty applies: you get to break your own systems however you= like, and you even get to keep all of the pieces afterwards too. > There are multiple possible solutions. One could, for example, use ng_b= ridge(4), or take yet another direction entirely. Users should be free to= experiment and work flexibly with the operating system. Forcing everyone= to move all their addresses to the logical bridge(4) interface seems lik= e it narrows the range of valid deployment scenarios for bridge(4) > What specific scenario does not work with the address assigned to the bri= dge rather than a member interface? > That said, is the fact that a few users are experiencing issues with mu= lticast between interfaces connected to a bridge - or that they struggle = to migrate addresses onto the bridge interface - really a sufficient reas= on to prohibit everyone from assigning addresses to bridge members? > Multicast does work. It just doesn=E2=80=99t work between bridge member= s. Maybe someone will fix that someday. It=E2=80=99s been broken for years, and no one has fixed it so far. All o= f the people who have done actual work on the if_bridge code (e.g. myself= and Ivy) are telling you this configuration is broken and will not be su= pported. > Back to Cy Schubert=E2=80=99s thread about epair(4), which touches on t= his issue: what's striking is that this change doesn=E2=80=99t just shoot= users in the foot, it shoots and surprises committers as well. Committer= s who, well, will grit their teeth and defend the change regardless. > And this is exactly why Ivy=E2=80=99s change is good. Users have been sho= oting themselves in the foot for years. We=E2=80=99re making that impossi= ble. > I do miss people like the late Mike Karels,=C2=A0who would have made a = clear and confident decision about how this should be handled. > That decision has been made. > Where is the Janitor? Mr Grimes -=C2=A0 where are you? > > As a user with 30 years of experience with this OS, allow me to ask: wh= o=E2=80=99s actually in charge of all this now? As always: the people actually doing the work. =E2=80=94 Kristof From nobody Mon May 19 08:53:13 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1BKm0PfFz5wmQP for ; Mon, 19 May 2025 08:53:16 +0000 (UTC) (envelope-from ivy@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1BKl6xRpz42R9; Mon, 19 May 2025 08:53:15 +0000 (UTC) (envelope-from ivy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747644796; 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=B6XPQjryHpZ1x+GuNuLdq2hkz4rX4nUSjAOjMNRNbl4=; b=LimJnVfIAAg+kjuB1P8Q7pcultIn9Xy/0k1fwDTM+FUvQxcnnP24A+Ty3kVe4P8ALQcGAA 5OXxyouK/cq9y99K5+m5zU6rD9CpJa+Ns5gqdjzasVzgNyXGXJrHPFkslmozzpJqzl6g8f D/AF0zOlkvY/5u7T19ONRNBnmsPuB/73rAGE5Llsc3EK2J1elqYi9cvjy+Lb1sX08KN0IG sJVzUF6ICNyNztna0pR088BGv/gJv/dcPDWoIY1v5ZZ8xQRX4fI1zFe+focy6HjZk3gCW3 y5YjvOBpRycY2yLtOeEssQrE4vDPp3FfFsQ1Glwx6hrdDwXFDZUwLy6Nu8u+4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747644796; 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=B6XPQjryHpZ1x+GuNuLdq2hkz4rX4nUSjAOjMNRNbl4=; b=oVkBzgH8V7Z3g9+y1jkGqsSyvTEV45ER2ReL2jdqwuJXQK2+4nrx+qnyUcRwVv9wWgMKO+ Cm92EzMyLXoCLr1gYGoXbV+BIP62IH7VE8Z3ukqLhbeexuGa9c284IOW2OCjiZnvpL9irP wNZxupqd9VBKwwQIctVY2TV9qiTKNkYxhM7B63heU5Thy5GYTOOuHTIpQ+7xUHfyL439W9 sp00qvE4HHQoG6ddsujNMoe47FAe1DlliVmCMQ7FcmLxBPvd6LtYbQHl431HdSRc4MKYAG RySV0JTAutc3TSxtDTlkFMIaTNmrlvHk17yyHXaeJzh5jhvjHzczTwyagb+bEg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747644796; a=rsa-sha256; cv=none; b=Lj9V8QXjMeUL6exPA/G4mS6NCtdd6W4VSXjEWHLG+UvCInLLB66mEsXNWVro+D6qyiuQbb N+sgH1O0XGeF60kiu2Vqc7Mhzz/evuHji5899dnYWmScroEd5wVjPTqDBL9QeBH3Kvf+Nv Z7rrs4iY0lOvdYLQYZ+/zAT1ahj0RmhbNApc05xPjlndXoiTjYSJizgqJCqZp/OVZ6wc7S mvjjEdQRVoUIKIv0cMFfn7Wd4tQaNZBCufWtdXIuEqhFv6PKxn0x0NFQjxku/dxE75AB4h zlfhvSguS37X2cgdNSX3B+a/+xLo+VkwHt1qMGqAx5BhZtTKVKUkqM32pilZGg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ragweed.eden.le-fay.org (ragweed.eden.le-fay.org [IPv6:2001:8b0:aab5:c401:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b1BKl1jYvz9gw; Mon, 19 May 2025 08:53:15 +0000 (UTC) (envelope-from ivy@FreeBSD.org) Date: Mon, 19 May 2025 09:53:13 +0100 From: Lexi Winter To: Kristof Provost Cc: Marek Zarychta , Alexander Leidinger , A FreeBSD User , rgrimes@freebsd.org, FreeBSD CURRENT Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument Message-ID: Mail-Followup-To: Kristof Provost , Marek Zarychta , Alexander Leidinger , A FreeBSD User , rgrimes@freebsd.org, FreeBSD CURRENT References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tLnpZKfC5e35S2ma" Content-Disposition: inline In-Reply-To: <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> --tLnpZKfC5e35S2ma Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kristof Provost: > On 18 May 2025, at 21:24, Marek Zarychta wrote: > > W dniu 18.05.2025 o=A019:48, Alexander Leidinger pisze: > >> You want to make it work without this. Short: use the IP on the > >> bridge itself, not in the member IF. > > I'm not sure we should be dictating to Oliver what he must do. =20 > Oliver is of course free to solve his problem however he wishes, but > setting the sysctl is the worst option available. This will break > again later, and will continue to break multicast. i think it's worth mentioning that this doesn't just break multicast. i recently ran into a user with some weird arp problem where dmesg kept logging messages that an IP address was moving from one MAC address to another. after they moved their IP address from the bridge member to the bridge itself, the problem was solved. the basic problem here is that putting IP addresses on a bridge member is a layering violation and it's just not reasonable (or even possible) to support this in a sensible way in bridge. this is why most dedicated network devices (switches, routers, etc.) don't let you do this. i appreciate there are some specific use-cases that are currently still easier if this is allowed, this is why the sysctl exists. hopefully, we can fix all of these before 16.0-RELEASE. and to be clear, i didn't make this change out of a random desire to break everything's network because i think that's fun. i am planning a lot of changes to bridge(4) to make it faster and more functional, and fixing basic issues like IP addresses on member addresses makes those changes a lot easier. --tLnpZKfC5e35S2ma Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaCrxeAAKCRD1nT63mIK/ YBMRAP4vtTWGxLC9azCaaslYWgIl2Hl/uQh9Bn7zamua/x23FAEA3gzJM7ldQut9 6W1x65WT8GOz92mJrT/fvSCXRMYjBwA= =Exyy -----END PGP SIGNATURE----- --tLnpZKfC5e35S2ma-- From nobody Mon May 19 09:22:31 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1Bzt3jhRz5wpXS for ; Mon, 19 May 2025 09:22:50 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1Bzt0BKDz3DKP; Mon, 19 May 2025 09:22:49 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 394416; Mon, 19 May 2025 11:22:41 +0200 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.500.181.1.5\)) Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument From: "Patrick M. Hausen" In-Reply-To: Date: Mon, 19 May 2025 11:22:31 +0200 Cc: Kristof Provost , Marek Zarychta , Alexander Leidinger , A FreeBSD User , rgrimes@freebsd.org, FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> To: Lexi Winter X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4b1Bzt0BKDz3DKP 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:16188, ipnet:217.29.32.0/20, country:DE] X-Spamd-Bar: ---- Hi all, > Am 19.05.2025 um 10:53 schrieb Lexi Winter : >=20 > the basic problem here is that putting IP addresses on a bridge member > is a layering violation and it's just not reasonable (or even = possible) > to support this in a sensible way in bridge. this is why most = dedicated > network devices (switches, routers, etc.) don't let you do this. Adding to this, the fact that IP addresses on member interfaces are not supported has been documented from day one of the introduction of = if_bridge(4). A couple of months ago I did check the commit times of the code and the relevant handbook section because exactly this discussion came up again in a different context. = https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-br= idging > If the bridge host needs an IP address, set it on the bridge = interface, not on the member interfaces Kind regards, Patrick= From nobody Mon May 19 09:54:28 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1Chj6xxYz5wrPy for ; Mon, 19 May 2025 09:54:45 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1Chj5929z3TWZ; Mon, 19 May 2025 09:54:45 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2001:678:618:402f:b479:6983:b494:3b10] ([IPv6:2001:678:618:402f:b479:6983:b494:3b10]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 54J9saGP040517 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 19 May 2025 11:54:37 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1747648477; bh=y530LjsCcnpTeCi9PiABHTIVuItqN6p464kssISAVXY=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=NiUolhfspoiDSiYOR/mX0VrX41XgzEO6FIf4qo8FDIO0MK2Y0orLzlcdFIWSPZCVI GutHta8uWEp9ihixRJpR2FBFr88UMEP/hm7fK3dz9SW/5BYpMP8pqd72NJ87MJeSGS Rke9svgYCfPJXAu1Ir+wpyPJc8jd5Xitr4ISPCiCUNlUEtNfCZmC4jDzmbf7e5jm8J mH7g7O3gxLoVPqn+JM2NpLaWA7g6Dqc3vUlk7SisRBJtGPOJjxorS+GtnEha216qGQ GxDBilD/oMb0+F4MuiEPiARlrYcWdXevDTo7wZMHUEzPPbWvxmCrpR6cfBzhMIytYE ebTy6Xghktueg== Content-Type: multipart/alternative; boundary="------------g0oroke8V4PaanluqcQ1YgF8" Message-ID: <9ba436fb-4fdd-4f05-b92d-0704a2d203a3@plan-b.pwste.edu.pl> Date: Mon, 19 May 2025 11:54:28 +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: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument To: Kristof Provost Cc: Alexander Leidinger , A FreeBSD User , rgrimes@freebsd.org, FreeBSD CURRENT References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> Content-Language: en-US From: Marek Zarychta In-Reply-To: <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> X-Rspamd-Queue-Id: 4b1Chj5929z3TWZ 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:206006, ipnet:2001:678:618::/48, country:PL] X-Spamd-Bar: ---- This is a multi-part message in MIME format. --------------g0oroke8V4PaanluqcQ1YgF8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 19.05.2025 o 10:43, Kristof Provost pisze: > On 18 May 2025, at 21:24, Marek Zarychta wrote: >> W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze: >>> You want to make it work without this. Short: use the IP on the bridge itself, not in the member IF. >> I'm not sure we should be dictating to Oliver what he must do. > Oliver is of course free to solve his problem however he wishes, but setting the sysctl is the worst option available. This will break again later, and will continue to break multicast. > > The usual warranty applies: you get to break your own systems however you like, and you even get to keep all of the pieces afterwards too. > >> There are multiple possible solutions. One could, for example, use ng_bridge(4), or take yet another direction entirely. Users should be free to experiment and work flexibly with the operating system. Forcing everyone to move all their addresses to the logical bridge(4) interface seems like it narrows the range of valid deployment scenarios for bridge(4) >> > What specific scenario does not work with the address assigned to the bridge rather than a member interface? It's a temporary bridge, but that’s not really the issue. Perhaps the way this change was introduced caught some people by surprise. > >> That said, is the fact that a few users are experiencing issues with multicast between interfaces connected to a bridge - or that they struggle to migrate addresses onto the bridge interface - really a sufficient reason to prohibit everyone from assigning addresses to bridge members? >> Multicast does work. It just doesn’t work between bridge members. Maybe someone will fix that someday. > It’s been broken for years, and no one has fixed it so far. All of the people who have done actual work on the if_bridge code (e.g. myself and Ivy) are telling you this configuration is broken and will not be supported. > >> Back to Cy Schubert’s thread about epair(4), which touches on this issue: what's striking is that this change doesn’t just shoot users in the foot, it shoots and surprises committers as well. Committers who, well, will grit their teeth and defend the change regardless. >> > And this is exactly why Ivy’s change is good. Users have been shooting themselves in the foot for years. We’re making that impossible. > >> I do miss people like the late Mike Karels, who would have made a clear and confident decision about how this should be handled. >> > That decision has been made. > >> Where is the Janitor? Mr Grimes -  where are you? >> >> As a user with 30 years of experience with this OS, allow me to ask: who’s actually in charge of all this now? > As always: the people actually doing the work. > > — > Kristof Thanks for stepping in Kristof. It's good to hear that everything is under control. The change seems well justified - and perhaps even a bit overdue. Let’s hope it brings a noticeable improvement to the user experience. Kind regards, Marek --------------g0oroke8V4PaanluqcQ1YgF8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

W dniu 19.05.2025 o 10:43, Kristof Provost pisze:

On 18 May 2025, at 21:24, Marek Zarychta wrote:

W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze:

You want to make it work without this. Short: use the IP on the bridge itself, not in the member IF.

I'm not sure we should be dictating to Oliver what he must do.

Oliver is of course free to solve his problem however he wishes, but setting the sysctl is the worst option available. This will break again later, and will continue to break multicast.

The usual warranty applies: you get to break your own systems however you like, and you even get to keep all of the pieces afterwards too.


There are multiple possible solutions. One could, for example, use ng_bridge(4), or take yet another direction entirely. Users should be free to experiment and work flexibly with the operating system. Forcing everyone to move all their addresses to the logical bridge(4) interface seems like it narrows the range of valid deployment scenarios for bridge(4)


What specific scenario does not work with the address assigned to the bridge rather than a member interface?
It's a temporary bridge, but that’s not really the issue.
Perhaps the way this change was introduced caught some people by surprise. 


That said, is the fact that a few users are experiencing issues with multicast between interfaces connected to a bridge - or that they struggle to migrate addresses onto the bridge interface - really a sufficient reason to prohibit everyone from assigning addresses to bridge members?
Multicast does work. It just doesn’t work between bridge members. Maybe someone will fix that someday.

It’s been broken for years, and no one has fixed it so far. All of the people who have done actual work on the if_bridge code (e.g. myself and Ivy) are telling you this configuration is broken and will not be supported.


Back to Cy Schubert’s thread about epair(4), which touches on this issue: what's striking is that this change doesn’t just shoot users in the foot, it shoots and surprises committers as well. Committers who, well, will grit their teeth and defend the change regardless.


And this is exactly why Ivy’s change is good. Users have been shooting themselves in the foot for years. We’re making that impossible.


I do miss people like the late Mike Karels, who would have made a clear and confident decision about how this should be handled.


That decision has been made.


Where is the Janitor? Mr Grimes -  where are you?

As a user with 30 years of experience with this OS, allow me to ask: who’s actually in charge of all this now?

As always: the people actually doing the work.

—
Kristof

Thanks for stepping in Kristof. It's good to hear that everything is under control.

The change seems well justified - and perhaps even a bit overdue. Let’s hope it brings a noticeable improvement to the user experience.

Kind regards,
Marek

--------------g0oroke8V4PaanluqcQ1YgF8-- From nobody Mon May 19 10:33:50 2025 X-Original-To: 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 4b1DYx2GCnz5wttX; Mon, 19 May 2025 10:33:57 +0000 (UTC) (envelope-from ivy@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1DYx05CVz3knf; Mon, 19 May 2025 10:33:57 +0000 (UTC) (envelope-from ivy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747650837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ALZXURuzCfkXuKe/Mi1c1Y32GE+GX9PjjjoiakLpoKw=; b=XVAcWNvR6XuR4K/lais4fNfEAm9krB/sjqaPqG4qFxTeHdO8KYezvZSh5Uq/vf8GVQoK9M fANyGdofcCF9TzGX3eqyXlf+cjmvcJQTx0ItbeyFNxmofhszTZ1RiAgqdBZu7OinCDmR5g fcvPZS3bVc2tdZqtuz0VuVe0BCi+Bf55AStl+GCdyy2+Al+BL7MOwJpH9sgSz48dCtd6nw npw0rRuUcV4KUyDriuniGhRMyMiMSOe3CwPm1r87ebt7zRhFSgL694MnqhW6xdZRPNupDw lAGCqjGkbogffJF11DLUy0gmWbk5OoYpMcC27raJj4ZeR98d2X5sd4GnB2gO0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747650837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ALZXURuzCfkXuKe/Mi1c1Y32GE+GX9PjjjoiakLpoKw=; b=Y9+UCri35+pBRIs7N6yWJjOPOD0Ak6iALN+q8BokooI5OzzDGc/it+QDanRhzYJqOmPQxi s3Bx4o+35co9I4aVDPxrAWmyb/4kCSF9Jp0n+imAlCDMyUY8Q+TtDaxc5wruAQj6LRP5fq KIQHLLAb7pcnTSYgvT3X9O+XjXGilDneYPg5/KzM64Oq+xhCIEdNI3XNq5uDf3freaKcEc Avjm2ZfshjOLFPDzYib2rF/jwYW/I+JQZbujypuFgsdi5M3djH8NqUMm6e9Jare0pIpnst dj5qFZMvsecfHwobdYI51Ba4e9ERzvB472MwFwLpyGJMNX9GLR394N4jivJjKA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747650837; a=rsa-sha256; cv=none; b=XF2s5bNaPdHNvdjQWdBlpS6MomEDVubOFjCwXliPkdv6l5fS6zlAuTsAmIuv2KIi9wEUCi 6CZrIp+bpLRBfl7AXvVPUW4aEUVmBM8TUP6HGfEA/lWRxbc94ZjGvtt+y3uutX8kNQ/gVP Qrtho+bdzNLhFURgjXLO2ACe7SdRtBWowW31dKGsFH5Scw0cdxa+wfjZiHaNqHbEfQ6452 IydM1+ngY0R30e7+YE8b5aWi2ZR2Rfn4QQQMgbuqrH4aiUDtwmyvFEUV/ox/ZQJFLQ9ytP UPEmBRsWJblRAzWV4gq4rOhamDaEK/8TpApKN8p+kJesyQ9ENosnmhSEHJgFLQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ragweed.eden.le-fay.org (ragweed.eden.le-fay.org [IPv6:2001:8b0:aab5:c401:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b1DYw4d9Tz9jh; Mon, 19 May 2025 10:33:56 +0000 (UTC) (envelope-from ivy@FreeBSD.org) Date: Mon, 19 May 2025 11:33:50 +0100 From: Lexi Winter To: current@freebsd.org, net@freebsd.org Subject: HEADS UP: 15.0-CURRENT, change =?utf-8?Q?t?= =?utf-8?Q?o_bridge=284=29_might_break_some_network_configurations_with_?= =?utf-8?B?4oCcSW52YWxpZCBhcmd1bWVudOKAnQ==?= Message-ID: Mail-Followup-To: current@freebsd.org, net@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="snmROKrOoOnHE87x" Content-Disposition: inline --snmROKrOoOnHE87x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hello, although it's possible everyone who is affected by this is already aware of the change, i thought i should send a heads up anyway, if only to have a single place to discuss this (since there was quite a lot of discussion). in short, following this commit... b61850c4e6f "bridge(4): default net.link.bridge.member_ifaddrs to false" https://cgit.freebsd.org/src/commit/?id=b61850c4e6f6b0f21b36da7238db969d9090309e ...it is now impossible to use a network interface which has an IP address assigned to it as a bridge member, or to configure an IP address on an interface which is a member of a bridge. the immediate, "oh shit, my network is broken" fix for this issue is to set the sysctl net.link.bridge.member_ifaddrs=1. this will restore the previous behaviour of bridge(4). however, the preferred fix is that if you are doing something like this in /etc/rc.conf: cloned_interfaces="bridge0" ifconfig_ix0="1.1.1.1/24" ifconfig_bridge0="addm ix0" you should do this instead: cloned_interfaces="bridge0" ifconfig_ix0="up" ifconfig_bridge0"1.1.1.1/24 addm ix0" in other words, instead of assigning the IP address to the member interface, assign it to the bridge instead. i am aware that there are some configurations which currently cannot be done this way. in that case, please set member_ifaddrs=1 and i hope to have resolved all of these cases prior to 16.0-RELEASE, at which point i intend to remove the member_ifaddrs sysctl. i do *not* intend to revert this commit, but i *do* want to work with people who are negatively affected by this change to address their use-case prior to the removal of the aforementioned sysctl. specific known issues: - ifconfig_bridge0="SYNCDHCP" may be broken, in which case try "DHCP" instead. - automatic dhclient invocation on a bridge member via devd when the link comes up is broken. in both cases, setting member_ifaddrs=1 will restore the previous behaviour. again, i intend to fix or provide alternatives for all known breakages caused by this commit. --snmROKrOoOnHE87x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaCsJDQAKCRD1nT63mIK/ YOpTAQDdeW8qdnlo7ZXK1+XtWhB7VVUjwO3WiMxv9r2CPj1KGwD+PUh1n9jspK2p x1wU2HNT5zqMRAtdA7GXg5tEuPy1Ng0= =AcAA -----END PGP SIGNATURE----- --snmROKrOoOnHE87x-- From nobody Mon May 19 14:33:04 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1Ksw2y0Xz5vwT6 for ; Mon, 19 May 2025 14:33:08 +0000 (UTC) (envelope-from garga@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1Ksw2KRkz3qCy for ; Mon, 19 May 2025 14:33:08 +0000 (UTC) (envelope-from garga@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747665188; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type:autocrypt:autocrypt; bh=5Rw+E+oMBDw2dz8KYeW4MFI4kxIe8+GJQn9QuflA+Fk=; b=ilxWO/sMufA242aN/LFrA9501vEKuRegBeybGlUvwPkRLmZB11K6RYQNvxxAWQOOAum51Q J+S7KNBSsoDGMA4QxvaXAQHzc7jQMBOdtQv05tzKSbVvQROivibhu2/nGzOjIF/czVNWWR tCLmHOmwjTnYfwd+DzuTZZLA11Ks89r1YvNKWAoJw6o+uHXtdJ9RMEgfniEdHOO3C/buQN sfrH6ffX7g3W/vhfNn6c4z8LClWlA0aAQc+XV8IKVwN5U974Cm+cZqntlbVX0Zr6ll/enk yEA8y5xx8qaIHT2u6cBI7U+/RrkUJcBrWcBBJx1Lf8T1W59hZV4hsIehKFJFyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747665188; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type:autocrypt:autocrypt; bh=5Rw+E+oMBDw2dz8KYeW4MFI4kxIe8+GJQn9QuflA+Fk=; b=aqP3p11F4w9gPfOuBl4ESw0aRFSsnAdzEBB1ZTsBgKdB95vjCorSCBig030Ed9mPLrRLyb iN6cCvEUjycyATGIfLyLx9zUQoZPJzjxrhLW7sgF+DjDbwuqn7cLhSD73mOutRA9LLIRL7 dxXcGoipCrv4nDn70ISwf/gRP/g2adglbeGlCYUGk0Qn3lfMj5unAq/XTmKMz19d4QMoxV u2US8TxwcwoWtYV0GBcPy8Lz9XNcdtz+oDffTBeI/XywMKIQIlU4IJDlo7rS91VrcNgFxA +STfI72U1T1hd9sL0fwSmzhDYEeGgJk9fQ22OE8tq3+N/A6PxVozQxWnN+h94Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747665188; a=rsa-sha256; cv=none; b=RRP8228w1mbHY3eGQcV6a6PyAOiRhpU+USCr3jnrEBL8RNgzfS1ERCp3WJr8TkqObW6EPh rWyPzf1rz+LfVrzbLJo9s52M9UGVeQJanRCnqN9h5ob8LbCFLrfdGJFSyOVnZqcQnpj7ut uRqOB8jxDuWBWPgJdrFiNcDBSV60U1eUDSns7SA0kXVN8Y55bfR8Roj0USHPj8dEwnZXjz VQK7/jwbXMn24hffeTKYbrYNvmjMlsOZwvEV3s0FmJu1fv3oyviSnu5TS3XiEF5EM6c/nX qnCrxS8w99T+O+lR9nw+88QdXyX0NjJ+2uwEP570G+ewuqxcW6D1kFby1+ojiQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2804:f1c:3c:b01:57d:894f:afe:fa42] (unknown [IPv6:2804:f1c:3c:b01:57d:894f:afe:fa42]) (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: garga) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b1Ksv65tWzHmW for ; Mon, 19 May 2025 14:33:07 +0000 (UTC) (envelope-from garga@FreeBSD.org) Content-Type: multipart/mixed; boundary="------------j0nMJfmbvzzB9K4R9hO2pm1a" Message-ID: <7c6bea8b-b16f-41a0-88d1-65d9980bc378@FreeBSD.org> Date: Mon, 19 May 2025 11:33:04 -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 Content-Language: en-US To: Current FreeBSD From: Renato Botelho Subject: lid state stop changing after suspend/resume Autocrypt: addr=garga@FreeBSD.org; keydata= xsBNBGStavwBCACjNlp/9+Y+VFe9ieR2h/WWbdvjz4Mb2z/f22bGoaskzCfvVNbo/v3i34I9 H6OdgZkGqheQEAD2jNfRbmPr4z40xDMUpYGLds+1Mvg7G3Hms3j5Ef8KaLSWUNWIfwKdfSVR Qs35ccSJxAdRW5YdI6J3xZgika+3Bc4eJ05YE/nWW+PNTYevt5rqD50N3zybVYIcLoqVPpBi AZE/sf5SLiLACIJb1t/s4x+pi8vgWevxVVT9u8V1f8zYErmHSLSqjxii0B3eRZphX9NCJOv9 +tfFZhnENInhn9gT7H4e2YumUltEy3jacONHJF3CC1pvvWEa6lEyypclMOkHQwNON7DLABEB AAHNLFJlbmF0byBCb3RlbGhvIChGcmVlQlNEKSA8Z2FyZ2FARnJlZUJTRC5vcmc+wsCXBBMB CgBBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAFiEERL7Dxegbnh7xTiQ5Ob6P xxJcZXoFAmSta78CGQEACgkQOb6PxxJcZXrYlggAgaZmr6c1yIWzN8VksHrHpwt/uxONEP+h ljy3yfrMsgfS5wx5Uzgfih1xYZUFC6jiI63CetqBqJpp3g1klRS1UWYKx2NeXphDMYZEdPm/ a6sXh4bKZbk6IE8Yn0/YiRT57d9DtbvswC7Gn7Igj/MSbhl49TvTGyvuB6juaffVoYZViomx 5zMoee8Ml2o2qj3MrCJ+/K8GU54RlpOGqGRsqdwVdr9XEWub6fF2YFwR46cjmbiU3P5urFHH nkJlBGPIwKxHimTW0lZsdx9aCKRDd/D80/WOEzXmk3k8B9lv/GsvOluHmveLhJG1R1tIJ31I f2q8dfTvqsQXnu8CcWRcgc7ATQRkrWr8AQgA1DufoxScA+CWQbUR6zExIu8wXQKrhuRt4DG2 BgynT7EMUvEBadcbQRZXsBpemNfncc9Axyut/+rWiyKJf9BLQuo/9QYmSRvW1U6+0LJUYmdg kMyBeYaPk+vnssv/u9jLuvV7FVgyE0yk1iaWIKOVDD+XrQCOvGw9uSceBrQyCyo3A/eRM/+p vnDCaywR63PKE+3axk6lfNdGK3TnaWmS30/ZDCZlNsXuqprqR4JdT5wXids5o36dsuJ5EZ20 s5hNMD34s4Yr1Y1R9elH6qBsFCpozs0+jwrArxq+UJJCR6hH5W8ZEwJtRC8tzR8mRE1WywzX BXYj0YhfGztQIxZckQARAQABwsB8BBgBCgAmFiEERL7Dxegbnh7xTiQ5Ob6PxxJcZXoFAmSt avwCGwwFCQWjmoAACgkQOb6PxxJcZXr1vgf/SKXhoZcUU5I7TqcbHg0lJz9tICTupCGHWr/s SQgjh9oEM5j1wqW7FlCGP90Tl9K0g3ow9YdbhU7VK470o6pymX9V9eLHzGgkZO/KMEtGBeK1 u+5ePjCJ/MK5B21KODLSU7WrIL1VN5ceXfQPLYt02LMLtPri+oduHD6RNBeA7US1DUzleq5F 9NHGbvV2U7BdDUezpiO8NaFjFZVB11I5d99FxUM5XGVstI3VhsRKZxjY0KnqJzaQgTFsPGmv AUfZVIN1pXgXiedhPXpr8+Y64jP+pHVwpVmh1zYWL6+q3kqFOUVP6c5iiMeoEXZvgJz7x/AC ek3X5gvu8Hpcv+MZIg== This is a multi-part message in MIME format. --------------j0nMJfmbvzzB9K4R9hO2pm1a Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello! I have a ThinkPad E14 2nd gen and recenly installed FreeBSD 15-CURRENT on it. I noticed a problem with lid state not changing and started to collect more information about it. Here is what I got. I changed hw.acpi.lid_switch_state to none so the laptop doesn't sleep when I open/close the lid and after booting it I can see the sysctl dev.acpi_lid.0.state changing to 0 and back to 1 when I close/open the lid. It works just like it's expected. Then I put the system to sleep using `acpiconf -s 3` and resumed it. After that, dev.acpi_lid.0.state doesn't change anymore to 0 when I close the lid, it keeps its value as 1 until the next boot. I've updated BIOS to most recent version provided by Lenovo (1.64) and configured sleep to the value `Linux S3` on BIOS setup utility. Attached you can see a full dmesg output. If you need any other data just let me know. Thanks! -- Renato Botelho --------------j0nMJfmbvzzB9K4R9hO2pm1a Content-Type: text/plain; charset=UTF-8; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: base64 LS0tPDxCT09UPj4tLS0KQ29weXJpZ2h0IChjKSAxOTkyLTIwMjUgVGhlIEZyZWVCU0QgUHJv amVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5 LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0 eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVn aXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAx NS4wLUNVUlJFTlQgIzcgYXJjcGF0Y2gtRDQ5NzczLW4yNzcyNjctN2ZjM2JhOWI0ZDNhOiBU aHUgTWF5IDE1IDEwOjI4OjUyIC0wMyAyMDI1CiAgICByb290QGUxNDovdXNyL29iai91c3Iv c3JjL2FtZDY0LmFtZDY0L3N5cy9HRU5FUklDLU5PREVCVUcgYW1kNjQKRnJlZUJTRCBjbGFu ZyB2ZXJzaW9uIDE5LjEuNyAoaHR0cHM6Ly9naXRodWIuY29tL2xsdm0vbGx2bS1wcm9qZWN0 LmdpdCBsbHZtb3JnLTE5LjEuNy0wLWdjZDcwODAyOWUwYjIpClZUKGVmaWZiKTogcmVzb2x1 dGlvbiAxOTIweDEwODAKQ1BVOiAxMXRoIEdlbiBJbnRlbChSKSBDb3JlKFRNKSBpNS0xMTM1 RzcgQCAyLjQwR0h6ICgyNDE5LjIwLU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luPSJHZW51 aW5lSW50ZWwiICBJZD0weDgwNmMxICBGYW1pbHk9MHg2ICBNb2RlbD0weDhjICBTdGVwcGlu Zz0xCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxN Q0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERU UyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4 N2ZmYWZiYmY8U1NFMyxQQ0xNVUxRRFEsRFRFUzY0LE1PTixEU19DUEwsVk1YLEVTVCxUTTIs U1NTRTMsU0RCRyxGTUEsQ1gxNix4VFBSLFBEQ00sUENJRCxTU0U0LjEsU1NFNC4yLHgyQVBJ QyxNT1ZCRSxQT1BDTlQsVFNDRExULEFFU05JLFhTQVZFLE9TWFNBVkUsQVZYLEYxNkMsUkRS QU5EPgogIEFNRCBGZWF0dXJlcz0weDJjMTAwODAwPFNZU0NBTEwsTlgsUGFnZTFHQixSRFRT Q1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDEyMTxMQUhGLEFCTSxQcmVmZXRjaD4KICBTdHJ1 Y3R1cmVkIEV4dGVuZGVkIEZlYXR1cmVzPTB4ZjNiZmE3ZWI8RlNHU0JBU0UsVFNDQURKLEJN STEsQVZYMixGRFBFWEMsU01FUCxCTUkyLEVSTVMsSU5WUENJRCxORlBVU0csUFFFLEFWWDUx MkYsQVZYNTEyRFEsUkRTRUVELEFEWCxTTUFQLEFWWDUxMklGTUEsQ0xGTFVTSE9QVCxDTFdC LFBST0NUUkFDRSxBVlg1MTJDRCxTSEEsQVZYNTEyQlcsQVZYNTEyVkw+CiAgU3RydWN0dXJl ZCBFeHRlbmRlZCBGZWF0dXJlczI9MHgxOGMwNWZkZTxBVlg1MTJWQk1JLFVNSVAsUEtVLE9T UEtFLEFWWDUxMlZCTUkyLEdGTkksVkFFUyxWUENMTVVMUURRLEFWWDUxMlZOTkksQVZYNTEy QklUQUxHLEFWWDUxMlZQT1BDTlREUSxSRFBJRCxNT1ZESVJJLE1PVkRJUjY0Qj4KICBTdHJ1 Y3R1cmVkIEV4dGVuZGVkIEZlYXR1cmVzMz0weGZjMTAwNTEwPEZTUk0sQVZYNTEyVlAySU5U RVJTRUNULE1EX0NMRUFSLElCVCxJQlBCLFNUSUJQLEwxREZMLEFSQ0hfQ0FQLENPUkVfQ0FQ LFNTQkQ+CiAgWFNBVkUgRmVhdHVyZXM9MHhmPFhTQVZFT1BULFhTQVZFQyxYSU5VU0UsWFNB VkVTPgogIElBMzJfQVJDSF9DQVBTPTB4NmI8UkRDTF9OTyxJQlJTX0FMTCxTS0lQX0wxREZM X1ZNRSxNRFNfTk8+CiAgVlQteDogUEFULEhMVCxNVEYsUEFVU0UsRVBULFVHLFZQSUQsVklE LFBvc3RJbnRyCiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ugc3RhdGlz dGljcwpyZWFsIG1lbW9yeSAgPSAxNzE3OTg2OTE4NCAoMTYzODQgTUIpCmF2YWlsIG1lbW9y eSA9IDE2MjcyNTE1MDcyICgxNTUxOCBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBxdWFsaXR5 IDYwMApBQ1BJIEFQSUMgVGFibGU6IDxMRU5PVk8gVFAtUjFFICA+CkZyZWVCU0QvU01QOiBN dWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDggQ1BVcwpGcmVlQlNEL1NNUDogMSBw YWNrYWdlKHMpIHggNCBjb3JlKHMpIHggMiBoYXJkd2FyZSB0aHJlYWRzCnJhbmRvbTogcmVn aXN0ZXJpbmcgZmFzdCBzb3VyY2UgSW50ZWwgU2VjdXJlIEtleSBSTkcKcmFuZG9tOiBmYXN0 IHByb3ZpZGVyOiAiSW50ZWwgU2VjdXJlIEtleSBSTkciCnJhbmRvbTogdW5ibG9ja2luZyBk ZXZpY2UuCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMTE5CkxhdW5jaGluZyBBUHM6 IDEgNCA2IDMgMiA1IDcKcmFuZG9tOiBlbnRyb3B5IGRldmljZSBleHRlcm5hbCBpbnRlcmZh Y2UKa2JkMSBhdCBrYmRtdXgwCmVmaXJ0YzA6IDxFRkkgUmVhbHRpbWUgQ2xvY2s+CmVmaXJ0 YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jaywgcmVzb2x1dGlvbiAxLjAw MDAwMHMKc21iaW9zMDogPFN5c3RlbSBNYW5hZ2VtZW50IEJJT1M+IGF0IGlvbWVtIDB4NzAz NjcwMDAtMHg3MDM2NzAxNwpzbWJpb3MwOiBFbnRyeSBwb2ludDogdjMgKDY0LWJpdCksIFZl cnNpb246IDMuMgphZXNuaTA6IDxBRVMtQ0JDLEFFUy1DQ00sQUVTLUdDTSxBRVMtSUNNLEFF Uy1YVFMsU0hBMSxTSEEyNTY+CmFjcGkwOiA8TEVOT1ZPIFRQLVIxRT4KYWNwaV9lYzA6IDxF bWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHg2ZSwgRUNEVD4gcG9ydCAweDYyLDB4NjYgb24g YWNwaTAKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmNwdTA6IDxBQ1BJIENQVT4gb24g YWNwaTAKaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQw MDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kg MTkyMDAwMDAgSHogcXVhbGl0eSA5NTAKRXZlbnQgdGltZXIgIkhQRVQiIGZyZXF1ZW5jeSAx OTIwMDAwMCBIeiBxdWFsaXR5IDU1MAphdHJ0YzE6IDxBVCByZWFsdGltZSBjbG9jaz4gb24g YWNwaTAKYXRydGMxOiBXYXJuaW5nOiBDb3VsZG4ndCBtYXAgSS9PLgphdHJ0YzE6IHJlZ2lz dGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jaywgcmVzb2x1dGlvbiAxLjAwMDAwMHMKRXZl bnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMAphdHRpbWVyMDog PEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNwaTAKVGlt ZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQg dGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApUaW1lY291 bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAphY3Bp X3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDE4MDgtMHgx ODBiIG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgt MHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKdmdhcGNpMDog PFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHg0MDAwLTB4NDAzZiBtZW0gMHg2MDFj MDAwMDAwLTB4NjAxY2ZmZmZmZiwweDQwMDAwMDAwMDAtMHg0MDFmZmZmZmZmIGF0IGRldmlj ZSAyLjAgb24gcGNpMAp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQpwY2liMTogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMAp4aGNpMDogPEludGVsIFRp Z2VyIExha2UtTFAgVGh1bmRlcmJvbHQgNCBVU0IgY29udHJvbGxlcj4gbWVtIDB4NjAxZDE3 MDAwMC0weDYwMWQxN2ZmZmYgYXQgZGV2aWNlIDEzLjAgb24gcGNpMAp4aGNpMDogMzIgYnl0 ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCnVzYnVzMCBvbiB4aGNpMAp1c2J1czA6IDUu MEdicHMgU3VwZXIgU3BlZWQgVVNCIHYzLjAKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQg ZGV2aWNlIDEzLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKeGhjaTE6IDxJbnRlbCBUaWdlciBM YWtlLUxQIFVTQiAzLjIgY29udHJvbGxlcj4gbWVtIDB4NjAxZDE2MDAwMC0weDYwMWQxNmZm ZmYgYXQgZGV2aWNlIDIwLjAgb24gcGNpMAp4aGNpMTogMzIgYnl0ZXMgY29udGV4dCBzaXpl LCA2NC1iaXQgRE1BCnVzYnVzMSBvbiB4aGNpMQp1c2J1czE6IDUuMEdicHMgU3VwZXIgU3Bl ZWQgVVNCIHYzLjAKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMjAuMiAobm8gZHJp dmVyIGF0dGFjaGVkKQpwY2kwOiA8bmV0d29yaz4gYXQgZGV2aWNlIDIwLjMgKG5vIGRyaXZl ciBhdHRhY2hlZCkKcGNpMDogPHNlcmlhbCBidXM+IGF0IGRldmljZSAyMS4wIChubyBkcml2 ZXIgYXR0YWNoZWQpCnBjaTA6IDxzZXJpYWwgYnVzPiBhdCBkZXZpY2UgMjEuMiAobm8gZHJp dmVyIGF0dGFjaGVkKQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMjIuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAyOC4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjM6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMiBvbiBwY2kwCnBjaTI6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWIzCnJlMDogPFJlYWxUZWsgODE2OC84MTExIEIvQy9DUC9EL0RQ L0UvRi9HIFBDSWUgR2lnYWJpdCBFdGhlcm5ldD4gcG9ydCAweDMwMDAtMHgzMGZmIG1lbSAw eDhlMzA0MDAwLTB4OGUzMDRmZmYsMHg4ZTMwMDAwMC0weDhlMzAzZmZmIGF0IGRldmljZSAw LjAgb24gcGNpMgpyZTA6IFVzaW5nIDEgTVNJLVggbWVzc2FnZQpyZTA6IEFTUE0gZGlzYWJs ZWQKcmUwOiBDaGlwIHJldi4gMHg1NDAwMDAwMApyZTA6IE1BQyByZXYuIDB4MDAxMDAwMDAK bWlpYnVzMDogPE1JSSBidXM+IG9uIHJlMApyZ2VwaHkwOiA8UlRMODI1MS84MTUzIDEwMDBC QVNFLVQgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWlidXMwCnJnZXBoeTA6ICBub25l LCAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTBiYXNlVC1GRFgtZmxvdywgMTAwYmFzZVRYLCAx MDBiYXNlVFgtRkRYLCAxMDBiYXNlVFgtRkRYLWZsb3csIDEwMDBiYXNlVC1GRFgsIDEwMDBi YXNlVC1GRFgtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLWZsb3csIDEwMDBiYXNlVC1GRFgtZmxv dy1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpyZTA6IFVzaW5nIGRlZmF1bHRzIGZvciBUU086 IDY1NTE4LzM1LzIwNDgKcmUwOiBFdGhlcm5ldCBhZGRyZXNzOiA2NDoxYzo2NzpkYTo5Njpj ZQpyZTA6IG5ldG1hcCBxdWV1ZXMvc2xvdHM6IFRYIDEvMjU2LCBSWCAxLzI1NgpwY2liNDog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOS4wIG9uIHBjaTAKcGNpMzogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjQKbnZtZTA6IDxHZW5lcmljIE5WTWUgRGV2aWNlPiBtZW0g MHg4ZTIwMDAwMC0weDhlMjAzZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMwppc2FiMDogPFBD SS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBv biBpc2FiMApoZGFjMDogPEludGVsIFRpZ2VyIExha2UgSERBIENvbnRyb2xsZXI+IG1lbSAw eDYwMWQxODgwMDAtMHg2MDFkMThiZmZmLDB4NjAxZDAwMDAwMC0weDYwMWQwZmZmZmYgYXQg ZGV2aWNlIDMxLjMgb24gcGNpMApwY2kwOiA8c2VyaWFsIGJ1cz4gYXQgZGV2aWNlIDMxLjUg KG5vIGRyaXZlciBhdHRhY2hlZCkKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBh Y3BpMAphY3BpX2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCmFjcGlfbGlkMDog PENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2Fy ZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0 a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0 a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGti ZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCldBUk5JTkc6IERldmljZSAicHNtIiBpcyBHaWFu dCBsb2NrZWQgYW5kIG1heSBiZSBkZWxldGVkIGJlZm9yZSBGcmVlQlNEIDE1LjAuCnBzbTA6 IG1vZGVsIEVsYW50ZWNoIFRvdWNocGFkLCBkZXZpY2UgSUQgMAphY3BpX3N5c2NvbnRhaW5l cjA6IDxTeXN0ZW0gQ29udGFpbmVyPiBvbiBhY3BpMAphY3BpX2FjYWQwOiA8QUMgQWRhcHRl cj4gb24gYWNwaTAKYmF0dGVyeTA6IDxBQ1BJIENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9u IGFjcGkwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBhdCBwb3J0IDB4NzAgaXJxIDgg b24gaXNhMAphdHJ0YzA6IFdhcm5pbmc6IENvdWxkbid0IG1hcCBJL08uCmF0cnRjMDogcmVn aXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrLCByZXNvbHV0aW9uIDEuMDAwMDAwcwph dHJ0YzA6IENhbid0IG1hcCBpbnRlcnJ1cHQuCmh3cHN0YXRlX2ludGVsMDogPEludGVsIFNw ZWVkIFNoaWZ0PiBvbiBjcHUwCmNwdWZyZXEwOiA8Q1BVIGZyZXF1ZW5jeSBjb250cm9sPiBv biBjcHUwCmh3cHN0YXRlX2ludGVsMTogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHUxCmNw dWZyZXExOiA8Q1BVIGZyZXF1ZW5jeSBjb250cm9sPiBvbiBjcHUxCmh3cHN0YXRlX2ludGVs MjogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHUyCmNwdWZyZXEyOiA8Q1BVIGZyZXF1ZW5j eSBjb250cm9sPiBvbiBjcHUyCmh3cHN0YXRlX2ludGVsMzogPEludGVsIFNwZWVkIFNoaWZ0 PiBvbiBjcHUzCmNwdWZyZXEzOiA8Q1BVIGZyZXF1ZW5jeSBjb250cm9sPiBvbiBjcHUzCmh3 cHN0YXRlX2ludGVsNDogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHU0CmNwdWZyZXE0OiA8 Q1BVIGZyZXF1ZW5jeSBjb250cm9sPiBvbiBjcHU0Cmh3cHN0YXRlX2ludGVsNTogPEludGVs IFNwZWVkIFNoaWZ0PiBvbiBjcHU1CmNwdWZyZXE1OiA8Q1BVIGZyZXF1ZW5jeSBjb250cm9s PiBvbiBjcHU1Cmh3cHN0YXRlX2ludGVsNjogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHU2 CmNwdWZyZXE2OiA8Q1BVIGZyZXF1ZW5jeSBjb250cm9sPiBvbiBjcHU2Cmh3cHN0YXRlX2lu dGVsNzogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHU3CmNwdWZyZXE3OiA8Q1BVIGZyZXF1 ZW5jeSBjb250cm9sPiBvbiBjcHU3ClRpbWVjb3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kg MTIwOTYxMjI5NiBIeiBxdWFsaXR5IDEwMDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4w MDAgbXNlYwp1Z2VuMC4xOiA8SW50ZWwgWEhDSSByb290IEhVQj4gYXQgdXNidXMwCnVnZW4x LjE6IDxJbnRlbCBYSENJIHJvb3QgSFVCPiBhdCB1c2J1czEKdWh1YjAgb24gdXNidXMwCnVo dWIwOiA8SW50ZWwgWEhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMy4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMAp1aHViMSBvbiB1c2J1czEKdWh1YjE6IDxJbnRlbCBYSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxClpG UyBmaWxlc3lzdGVtIHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0 dXJlcyBzdXBwb3J0ICg1MDAwKQpudm1lMDogQWxsb2NhdGVkIDY0TUIgaG9zdCBtZW1vcnkg YnVmZmVyCmhkYWNjMDogPFJlYWx0ZWsgQUxDMjU3IEhEQSBDT0RFQz4gYXQgY2FkIDAgb24g aGRhYzAKaGRhYTA6IDxSZWFsdGVrIEFMQzI1NyBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQg bmlkIDEgb24gaGRhY2MwCnBjbTA6IDxSZWFsdGVrIEFMQzI1NyAoQW5hbG9nIDIuMCtIUC8y LjApPiBhdCBuaWQgMjAsMzMgYW5kIDI1IG9uIGhkYWEwCmhkYWNjMTogPEludGVsIFRpZ2Vy IExha2UgSERBIENPREVDPiBhdCBjYWQgMiBvbiBoZGFjMApoZGFhMTogPEludGVsIFRpZ2Vy IExha2UgQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMQpwY20xOiA8 SW50ZWwgVGlnZXIgTGFrZSAoSERNSS9EUCA4Y2gpPiBhdCBuaWQgNCBvbiBoZGFhMQpuZGEw IGF0IG52bWUwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMQpuZGEwOiA8U0FNU1VORyBN WkFMUTI1NkhBSkQtMDAwTDEgRUwxUUZYVjcgUzRZRE5GMFI0MjIxMDM+Cm5kYTA6IFNlcmlh bCBOdW1iZXIgUzRZRE5GMFI0MjIxMDMKbmRhMDogbnZtZSB2ZXJzaW9uIDEuMwpuZGEwOiAy NDQxOThNQiAoNTAwMTE4MTkyIDUxMiBieXRlIHNlY3RvcnMpClRyeWluZyB0byBtb3VudCBy b290IGZyb20gemZzOnpyb290L1JPT1QvZGVmYXVsdCBbXS4uLgp1aHViMDogNSBwb3J0cyB3 aXRoIDUgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6IDE2IHBvcnRzIHdpdGggMTYg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWdlbjEuMjogPExvZ2l0ZWNoIFVTQiBSZWNlaXZl cj4gYXQgdXNidXMxCnVrYmQwIG9uIHVodWIxCnVrYmQwOiA8TG9naXRlY2ggVVNCIFJlY2Vp dmVyLCBjbGFzcyAwLzAsIHJldiAyLjAwLzUuMDEsIGFkZHIgMT4gb24gdXNidXMxCmtiZDIg YXQgdWtiZDAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxCnVnZW4xLjM6IDw4U1ND MjBGMjcxNDVWMVNSMThQMEFYUyBJbnRlZ3JhdGVkIENhbWVyYT4gYXQgdXNidXMxCnVnZW4x LjQ6IDxHZW5lcmljIEdvb2RpeCBGaW5nZXJQcmludCBEZXZpY2U+IGF0IHVzYnVzMQpSb290 IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEKdWdlbjEuNTogPHZlbmRvciAweDgwODcgcHJv ZHVjdCAweDAwMjY+IGF0IHVzYnVzMQpHRU9NX0VMSTogRGV2aWNlIG5kYTBwMi5lbGkgY3Jl YXRlZC4KR0VPTV9FTEk6IEVuY3J5cHRpb246IEFFUy1YVFMgMTI4CkdFT01fRUxJOiAgICAg Q3J5cHRvOiBhY2NlbGVyYXRlZCBzb2Z0d2FyZQpbZHJtXSBHb3QgSW50ZWwgZ3JhcGhpY3Mg c3RvbGVuIG1lbW9yeSBiYXNlIDB4N2M4MDAwMDAsIHNpemUgMHg0MDAwMDAwCmRybW4wOiA8 ZHJtbj4gb24gdmdhcGNpMAp2Z2FwY2kwOiBjaGlsZCBkcm1uMCByZXF1ZXN0ZWQgcGNpX2Vu YWJsZV9pbwp2Z2FwY2kwOiBjaGlsZCBkcm1uMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9pbwpp OTE1L3RnbF9kbWNfdmVyMl8xMi5iaW46IGNvdWxkIG5vdCBsb2FkIGJpbmFyeSBmaXJtd2Fy ZSAvYm9vdC9maXJtd2FyZS9pOTE1L3RnbF9kbWNfdmVyMl8xMi5iaW4gZWl0aGVyCnRnbF9k bWNfdmVyMl8xMi5iaW46IGNvdWxkIG5vdCBsb2FkIGJpbmFyeSBmaXJtd2FyZSAvYm9vdC9m aXJtd2FyZS90Z2xfZG1jX3ZlcjJfMTIuYmluIGVpdGhlcgppOTE1X3RnbF9kbWNfdmVyMl8x Mi5iaW46IGNvdWxkIG5vdCBsb2FkIGJpbmFyeSBmaXJtd2FyZSAvYm9vdC9maXJtd2FyZS9p OTE1X3RnbF9kbWNfdmVyMl8xMi5iaW4gZWl0aGVyCmxrcGlfaWljMDogPExpbnV4S1BJIEky Qz4gb24gZHJtbjAKaWljYnVzMDogPFBoaWxpcHMgSTJDIGJ1cz4gb24gbGtwaV9paWMwCmlp YzA6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czAKbGtwaV9paWMxOiA8TGludXhLUEkg STJDPiBvbiBkcm1uMAppaWNidXMxOiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBsa3BpX2lpYzEK aWljMTogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzMQpsa3BpX2lpYzI6IDxMaW51eEtQ SSBJMkM+IG9uIGRybW4wCmlpY2J1czI6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGxrcGlfaWlj MgppaWMyOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMyCmxrcGlfaWljMzogPExpbnV4 S1BJIEkyQz4gb24gZHJtbjAKaWljYnVzMzogPFBoaWxpcHMgSTJDIGJ1cz4gb24gbGtwaV9p aWMzCmlpYzM6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czMKbGtwaV9paWM0OiA8TGlu dXhLUEkgSTJDPiBvbiBkcm1uMAppaWNidXM0OiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBsa3Bp X2lpYzQKaWljNDogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzNApsa3BpX2lpYzU6IDxM aW51eEtQSSBJMkM+IG9uIGRybW4wCmlpY2J1czU6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGxr cGlfaWljNQppaWM1OiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXM1CmxrcGlfaWljNjog PExpbnV4S1BJIEkyQz4gb24gZHJtbjAKaWljYnVzNjogPFBoaWxpcHMgSTJDIGJ1cz4gb24g bGtwaV9paWM2CmlpYzY6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czYKbGtwaV9paWM3 OiA8TGludXhLUEkgSTJDPiBvbiBkcm1uMAppaWNidXM3OiA8UGhpbGlwcyBJMkMgYnVzPiBv biBsa3BpX2lpYzcKaWljNzogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzNwpsa3BpX2lp Yzg6IDxMaW51eEtQSSBJMkM+IG9uIGRybW4wCmlpY2J1czg6IDxQaGlsaXBzIEkyQyBidXM+ IG9uIGxrcGlfaWljOAppaWM4OiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXM4CmRybW4w OiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlICdpOTE1L3RnbF9kbWNfdmVy Ml8xMi5iaW4nCmRybW4wOiBbZHJtXSBGaW5pc2hlZCBsb2FkaW5nIERNQyBmaXJtd2FyZSBp OTE1L3RnbF9kbWNfdmVyMl8xMi5iaW4gKHYyLjEyKQpzeXNjdGxfYWRkX29pZDogY2FuJ3Qg cmUtdXNlIGEgbGVhZiAoaHcuZHJpLmRlYnVnKSEKbGtwaV9paWM5OiA8TGludXhLUEkgSTJD PiBvbiBkcm0xCmlpY2J1czk6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGxrcGlfaWljOQppaWM5 OiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXM5CmxrcGlfaWljMTA6IDxMaW51eEtQSSBJ MkM+IG9uIGRybTMKaWljYnVzMTA6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGxrcGlfaWljMTAK aWljMTA6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czEwCmxrcGlfaWljMTE6IDxMaW51 eEtQSSBJMkM+IG9uIGRybTQKaWljYnVzMTE6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGxrcGlf aWljMTEKaWljMTE6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czExCmxrcGlfaWljMTI6 IDxMaW51eEtQSSBJMkM+IG9uIGRybTUKaWljYnVzMTI6IDxQaGlsaXBzIEkyQyBidXM+IG9u IGxrcGlfaWljMTIKaWljMTI6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czEyCmxrcGlf aWljMTM6IDxMaW51eEtQSSBJMkM+IG9uIGRybTYKaWljYnVzMTM6IDxQaGlsaXBzIEkyQyBi dXM+IG9uIGxrcGlfaWljMTMKaWljMTM6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czEz Cltkcm1dIEluaXRpYWxpemVkIGk5MTUgMS42LjAgMjAyMDExMDMgZm9yIGRybW4wIG9uIG1p bm9yIDAKVlQ6IFJlcGxhY2luZyBkcml2ZXIgImVmaWZiIiB3aXRoIG5ldyAiZHJtZmIiLgpz dGFydCBGQl9JTkZPOgpoZWlnaHQ9MTA4MCB3aWR0aD0xOTIwIGRlcHRoPTMyCnBiYXNlPTB4 NDAwMDAwMDAwMCB2YmFzZT0weGZmZmZmZTAxMTZhMDAwMDAKbmFtZT1kcm1uMCBpZD1pOTE1 ZHJtZmIgZmxhZ3M9MHgwIHN0cmlkZT03NjgwCmVuZCBGQl9JTkZPCkludGVsKFIpIFdpcmVs ZXNzIFdpRmkgYmFzZWQgZHJpdmVyIGZvciBGcmVlQlNECml3bHdpZmkwOiA8aXdsd2lmaT4g bWVtIDB4NjAxZDE4YzAwMC0weDYwMWQxOGZmZmYgYXQgZGV2aWNlIDIwLjMgb24gcGNpMApp d2x3aWZpMDogRGV0ZWN0ZWQgY3JmLWlkIDB4MzYxNywgY252LWlkIDB4MjAwMDAzMDIgd2Zw bSBpZCAweDgwMDAwMDAwCml3bHdpZmkwOiBQQ0kgZGV2IGEwZjAvMDA3NCwgcmV2PTB4MzUx LCByZmlkPTB4MTBhMTAwCml3bHdpZmkwOiBEZXRlY3RlZCBJbnRlbChSKSBXaS1GaSA2IEFY MjAxIDE2ME1Iegppd2x3aWZpMDogc3VjY2Vzc2Z1bGx5IGxvYWRlZCBmaXJtd2FyZSBpbWFn ZSAnaXdsd2lmaS1RdVotYTAtaHItYjAtNzcudWNvZGUnCml3bHdpZmkwOiBUTFZfRldfRlNF UV9WRVJTSU9OOiBGU0VRIFZlcnNpb246IDg5LjMuMzUuMzcKaXdsLWRlYnVnLXlveW8uYmlu OiBjb3VsZCBub3QgbG9hZCBiaW5hcnkgZmlybXdhcmUgL2Jvb3QvZmlybXdhcmUvaXdsLWRl YnVnLXlveW8uYmluIGVpdGhlcgppd2wtZGVidWcteW95by5iaW46IGNvdWxkIG5vdCBsb2Fk IGJpbmFyeSBmaXJtd2FyZSAvYm9vdC9maXJtd2FyZS9pd2wtZGVidWcteW95by5iaW4gZWl0 aGVyCml3bC1kZWJ1Zy15b3lvX2JpbjogY291bGQgbm90IGxvYWQgYmluYXJ5IGZpcm13YXJl IC9ib290L2Zpcm13YXJlL2l3bC1kZWJ1Zy15b3lvX2JpbiBlaXRoZXIKaXdsX2RlYnVnX3lv eW9fYmluOiBjb3VsZCBub3QgbG9hZCBiaW5hcnkgZmlybXdhcmUgL2Jvb3QvZmlybXdhcmUv aXdsX2RlYnVnX3lveW9fYmluIGVpdGhlcgppd2x3aWZpMDogbG9hZGVkIGZpcm13YXJlIHZl cnNpb24gNzcuMGI0YzA2YWQuMCBRdVotYTAtaHItYjAtNzcudWNvZGUgb3BfbW9kZSBpd2xt dm0KaXdsd2lmaTA6IERldGVjdGVkIFJGIEhSIEIzLCByZmlkPTB4MTBhMTAwCml3bHdpZmkw OiBiYXNlIEhXIGFkZHJlc3M6IDQ0OmU1OjE3OmZkOjg3OmY3CmlnNGlpYzA6IDxJbnRlbCBU aWdlciBMYWtlLUxQIEkyQyBDb250cm9sbGVyLTQ+IG1lbSAweDYwMWQxOTcwMDAtMHg2MDFk MTk3ZmZmIGF0IGRldmljZSAyMS4wIG9uIHBjaTAKaWc0aWljMDogVXNpbmcgTVNJCmlpY2J1 czE0OiA8UGhpbGlwcyBJMkMgYnVzIChBQ1BJLWhpbnRlZCk+IG9uIGlnNGlpYzAKaWljMTQ6 IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czE0CmlnNGlpYzE6IDxJbnRlbCBUaWdlciBM YWtlLUxQIEkyQyBDb250cm9sbGVyLTY+IG1lbSAweDYwMWQxOTYwMDAtMHg2MDFkMTk2ZmZm IGF0IGRldmljZSAyMS4yIG9uIHBjaTAKaWc0aWljMTogVXNpbmcgTVNJCmlpY2J1czE1OiA8 UGhpbGlwcyBJMkMgYnVzIChBQ1BJLWhpbnRlZCk+IG9uIGlnNGlpYzEKaWljMTU6IDxJMkMg Z2VuZXJpYyBJL08+IG9uIGlpY2J1czE1CmljaHNtYjA6IDxJbnRlbCBUaWdlciBMYWtlIFNN QnVzIGNvbnRyb2xsZXI+IHBvcnQgMHhlZmEwLTB4ZWZiZiBtZW0gMHg2MDFkMTk0MDAwLTB4 NjAxZDE5NDBmZiBhdCBkZXZpY2UgMzEuNCBvbiBwY2kwCnNtYnVzMDogPFN5c3RlbSBNYW5h Z2VtZW50IEJ1cz4gb24gaWNoc21iMAphY3BpX3dtaTA6IDxBQ1BJLVdNSSBtYXBwaW5nPiBv biBhY3BpMAphY3BpX3dtaTA6IEVtYmVkZGVkIE1PRiBmb3VuZAphY3BpX3dtaTE6IDxBQ1BJ LVdNSSBtYXBwaW5nPiBvbiBhY3BpMAphY3BpX3dtaTE6IEVtYmVkZGVkIE1PRiBmb3VuZAph Y3BpX3dtaTI6IDxBQ1BJLVdNSSBtYXBwaW5nPiBvbiBhY3BpMAphY3BpX3dtaTI6IEVtYmVk ZGVkIE1PRiBmb3VuZAphY3BpX3dtaTM6IDxBQ1BJLVdNSSBtYXBwaW5nPiBvbiBhY3BpMAph Y3BpX3dtaTM6IEVtYmVkZGVkIE1PRiBmb3VuZAphY3BpX3dtaTQ6IDxBQ1BJLVdNSSBtYXBw aW5nPiBvbiBhY3BpMAphY3BpX3dtaTQ6IEVtYmVkZGVkIE1PRiBmb3VuZAphY3BpX3dtaTU6 IDxBQ1BJLVdNSSBtYXBwaW5nPiBvbiBhY3BpMAphY3BpX3dtaTU6IEVtYmVkZGVkIE1PRiBm b3VuZAphY3BpX3dtaTY6IDxBQ1BJLVdNSSBtYXBwaW5nPiBvbiBhY3BpMAphY3BpX3dtaTY6 IEVtYmVkZGVkIE1PRiBmb3VuZAphY3BpX3dtaTc6IDxBQ1BJLVdNSSBtYXBwaW5nPiBvbiBh Y3BpMAphY3BpX3dtaTc6IEVtYmVkZGVkIE1PRiBmb3VuZAphY3BpX3dtaTg6IDxBQ1BJLVdN SSBtYXBwaW5nPiBvbiBhY3BpMAphY3BpX3dtaTg6IEVtYmVkZGVkIE1PRiBmb3VuZApoZGFj MDogQ29tbWFuZCAweDIwNDNiMDAwIHRpbWVvdXQgb24gYWRkcmVzcyAyCnJlMDogbGluayBz dGF0ZSBjaGFuZ2VkIHRvIFVQCmxvMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCnJlMDog bGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KQ3VzZSB2MC4xLjM3IEAgL2Rldi9jdXNlCnVt czAgb24gdWh1YjEKdW1zMDogPExvZ2l0ZWNoIFVTQiBSZWNlaXZlciwgY2xhc3MgMC8wLCBy ZXYgMi4wMC81LjAxLCBhZGRyIDE+IG9uIHVzYnVzMQp1bXMwOiAxNiBidXR0b25zIGFuZCBb WFlaVF0gY29vcmRpbmF0ZXMgSUQ9Mgp1aGlkMCBvbiB1aHViMQp1aGlkMDogPExvZ2l0ZWNo IFVTQiBSZWNlaXZlciwgY2xhc3MgMC8wLCByZXYgMi4wMC81LjAxLCBhZGRyIDE+IG9uIHVz YnVzMQpyZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAp1YnQwIG9uIHVodWIxCnVidDA6 IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgwMDI2LCBjbGFzcyAyMjQvMSwgcmV2IDIuMDEv MC4wMiwgYWRkciA0PiBvbiB1c2J1czEKU2VjdXJpdHkgcG9saWN5IGxvYWRlZDogTUFDL250 cGQgKG1hY19udHBkKQpoZGFjMDogQ29tbWFuZCAweDIwMTcwNTAzIHRpbWVvdXQgb24gYWRk cmVzcyAyCnJlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KcmUwOiBsaW5rIHN0YXRl IGNoYW5nZWQgdG8gVVAKcmUwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgp1aHViMTog YXQgdXNidXMxLCBwb3J0IDEsIGFkZHIgMSAoZGlzY29ubmVjdGVkKQp1Z2VuMS4yOiA8TG9n aXRlY2ggVVNCIFJlY2VpdmVyPiBhdCB1c2J1czEgKGRpc2Nvbm5lY3RlZCkKdWtiZDA6IGF0 IHVodWIxLCBwb3J0IDUsIGFkZHIgMSAoZGlzY29ubmVjdGVkKQp1a2JkMDogZGV0YWNoZWQK dW1zMDogYXQgdWh1YjEsIHBvcnQgNSwgYWRkciAxIChkaXNjb25uZWN0ZWQpCnVtczA6IGRl dGFjaGVkCnVoaWQwOiBhdCB1aHViMSwgcG9ydCA1LCBhZGRyIDEgKGRpc2Nvbm5lY3RlZCkK dWhpZDA6IGRldGFjaGVkCnVnZW4xLjM6IDw4U1NDMjBGMjcxNDVWMVNSMThQMEFYUyBJbnRl Z3JhdGVkIENhbWVyYT4gYXQgdXNidXMxIChkaXNjb25uZWN0ZWQpCnVnZW4xLjQ6IDxHZW5l cmljIEdvb2RpeCBGaW5nZXJQcmludCBEZXZpY2U+IGF0IHVzYnVzMSAoZGlzY29ubmVjdGVk KQp1Z2VuMS41OiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyNj4gYXQgdXNidXMxIChk aXNjb25uZWN0ZWQpCnVidDA6IGF0IHVodWIxLCBwb3J0IDEwLCBhZGRyIDQgKGRpc2Nvbm5l Y3RlZCkKdWJ0MDogZGV0YWNoZWQKdWh1YjE6IGRldGFjaGVkCnVodWIwOiBhdCB1c2J1czAs IHBvcnQgMSwgYWRkciAxIChkaXNjb25uZWN0ZWQpCnVodWIwOiBkZXRhY2hlZAp2Z2FwY2kw OiBjaGlsZCBkcm1uMCByZXF1ZXN0ZWQgcGNpX3NldF9wb3dlcnN0YXRlCnBjaTA6IGZhaWxl ZCB0byBzZXQgQUNQSSBwb3dlciBzdGF0ZSBEMyBvbiBcMTM0X1NCXy5QQzAwLkdGWDA6IEFF X0JBRF9QQVJBTUVURVIKYWNwaTA6IGNsZWFyZWQgZml4ZWQgcG93ZXIgYnV0dG9uIHN0YXR1 cwp2Z2FwY2kwOiBjaGlsZCBkcm1uMCByZXF1ZXN0ZWQgcGNpX3NldF9wb3dlcnN0YXRlCnZn YXBjaTA6IGNoaWxkIGRybW4wIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCnZnYXBjaTA6IGNo aWxkIGRybW4wIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCnJlMDogbGluayBzdGF0ZSBjaGFu Z2VkIHRvIERPV04KdWh1YjAgb24gdXNidXMxCnVodWIwOiA8SW50ZWwgWEhDSSByb290IEhV QiwgY2xhc3MgOS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1aHViMSBv biB1c2J1czAKdWh1YjE6IDxJbnRlbCBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAz LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCmhkYWMwOiBDb21tYW5kIDB4MjAxNzA1MDAg dGltZW91dCBvbiBhZGRyZXNzIDIKaGRhYzA6IENvbW1hbmQgMHgyMDM3MDUwMCB0aW1lb3V0 IG9uIGFkZHJlc3MgMgpoZGFjMDogQ29tbWFuZCAweDIwNDcwNTAwIHRpbWVvdXQgb24gYWRk cmVzcyAyCmhkYWMwOiBDb21tYW5kIDB4MjA0M2IwODAgdGltZW91dCBvbiBhZGRyZXNzIDIK aGRhYzA6IENvbW1hbmQgMHgyMDQ3MDEwMCB0aW1lb3V0IG9uIGFkZHJlc3MgMgpoZGFjMDog Q29tbWFuZCAweDIwNDcwNzQwIHRpbWVvdXQgb24gYWRkcmVzcyAyCmhkYWMwOiBDb21tYW5k IDB4MjA0NzA4ODQgdGltZW91dCBvbiBhZGRyZXNzIDIKaGRhYzA6IENvbW1hbmQgMHgyMDRm MDkwMCB0aW1lb3V0IG9uIGFkZHJlc3MgMgpoZGFjMDogQ29tbWFuZCAweDIwNGYwOTAwIHRp bWVvdXQgb24gYWRkcmVzcyAyCmhkYWMwOiBDb21tYW5kIDB4MjA0ZjJlMDggdGltZW91dCBv biBhZGRyZXNzIDIKaGRhYzA6IENvbW1hbmQgMHgyMDQzYjAwMCB0aW1lb3V0IG9uIGFkZHJl c3MgMgp1aHViMTogNSBwb3J0cyB3aXRoIDUgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1 YjA6IDE2IHBvcnRzIHdpdGggMTYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcmUwOiBsaW5r IHN0YXRlIGNoYW5nZWQgdG8gVVAKdWdlbjEuMjogPExvZ2l0ZWNoIFVTQiBSZWNlaXZlcj4g YXQgdXNidXMxCnVrYmQwIG9uIHVodWIwCnVrYmQwOiA8TG9naXRlY2ggVVNCIFJlY2VpdmVy LCBjbGFzcyAwLzAsIHJldiAyLjAwLzUuMDEsIGFkZHIgMT4gb24gdXNidXMxCmtiZDIgYXQg dWtiZDAKdW1zMCBvbiB1aHViMAp1bXMwOiA8TG9naXRlY2ggVVNCIFJlY2VpdmVyLCBjbGFz cyAwLzAsIHJldiAyLjAwLzUuMDEsIGFkZHIgMT4gb24gdXNidXMxCnVtczA6IDE2IGJ1dHRv bnMgYW5kIFtYWVpUXSBjb29yZGluYXRlcyBJRD0yCnVoaWQwIG9uIHVodWIwCnVoaWQwOiA8 TG9naXRlY2ggVVNCIFJlY2VpdmVyLCBjbGFzcyAwLzAsIHJldiAyLjAwLzUuMDEsIGFkZHIg MT4gb24gdXNidXMxCnVnZW4xLjM6IDw4U1NDMjBGMjcxNDVWMVNSMThQMEFYUyBJbnRlZ3Jh dGVkIENhbWVyYT4gYXQgdXNidXMxCnVnZW4xLjQ6IDxHZW5lcmljIEdvb2RpeCBGaW5nZXJQ cmludCBEZXZpY2U+IGF0IHVzYnVzMQp1Z2VuMS41OiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0 IDB4MDAyNj4gYXQgdXNidXMxCnVidDAgb24gdWh1YjAKdWJ0MDogPHZlbmRvciAweDgwODcg cHJvZHVjdCAweDAwMjYsIGNsYXNzIDIyNC8xLCByZXYgMi4wMS8wLjAyLCBhZGRyIDQ+IG9u IHVzYnVzMQo= --------------j0nMJfmbvzzB9K4R9hO2pm1a-- From nobody Tue May 20 02:33:58 2025 X-Original-To: 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 4b1dst4DB7z5wsb2 for ; Tue, 20 May 2025 02:34:10 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1dsr6rVNz3QNY for ; Tue, 20 May 2025 02:34:08 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=IG+CKsIN; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org; dmarc=pass (policy=quarantine) header.from=blastwave.org Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 54K2XxBm053784 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 19 May 2025 22:34:06 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1747708446; bh=E4xd36mLQYE+MXWY04ixHxkZhkPjj1wi1taJOp+l/9Q=; h=Date:To:From:Subject; b=IG+CKsINF4DCPVfYNVYHshs2IbLMQxhCIFOk126UiykL9/8k8n5d9PDB/Q6eY+o0g 2agjtErOMQ2EMh8Njw1B4goFm3k00rkOLAz3YmRyzignYme5KIUZzMTEOU4pV3GB1e tS73A2jVUZsR/oHcv6jsJ5t+oOCpKwchT6utY23nC/iZe7KO2UUH2JwhJsFC3x7TX7 V0jFEXEIIfslzynQ+8NnV4uM93XYs5kpwlgzKiiNy9PD+3UT6kanqymt7FrOvKbx+J SMRaeNMkA20z4mTOWSi/qBdRwtDBp/96qowcXp5FJiEAlSGDcmOQ15DCjTPdb5oiZN +g27ef8uZOxAA== Message-ID: <044f6767-01d2-40a5-a8fd-b5568658c9c0@blastwave.org> Date: Mon, 19 May 2025 22:33:58 -0400 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 To: current@freebsd.org Content-Language: en-CA From: Dennis Clarke Subject: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1 Organization: GENUNIX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 54K2XxBm053784 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Queue-Id: 4b1dsr6rVNz3QNY X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[blastwave.org:+] Just an odd message to see on the console : # witness_lock_list_get: witness exhausted Looking at https://cgit.freebsd.org/src/tree/sys/kern/subr_witness.c it seems that the comment at line 370 is very clear : /* * If set to 0, lock order checking is disabled. If set to -1, * witness is completely disabled. Otherwise witness performs full * lock order checking for all locks. At runtime, lock order checking * may be toggled. However, witness cannot be reenabled once it is * completely disabled. */ static int witness_watch = 1; So I wonder how I managed to get that message "witness exhausted" ? At line 2203 I see : static struct lock_list_entry * witness_lock_list_get(void) { struct lock_list_entry *lle; if (witness_watch == -1) return (NULL); mtx_lock_spin(&w_mtx); lle = w_lock_list_free; if (lle == NULL) { witness_watch = -1; mtx_unlock_spin(&w_mtx); printf("%s: witness exhausted\n", __func__); return (NULL); } w_lock_list_free = lle->ll_next; mtx_unlock_spin(&w_mtx); bzero(lle, sizeof(*lle)); return (lle); } Where it seems that indeed witness_watch has been flipped to -1 and that functionality is now gone? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken ps: the comment at line 43 is just plain silly. From nobody Tue May 20 05:51:12 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1kFY6Y9xz5vrcB for ; Tue, 20 May 2025 05:51:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.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 4b1kFX2T7zz3YP1 for ; Tue, 20 May 2025 05:51:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=COXUvEVI; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 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=1747720286; bh=+AVVomeBiLbZJDiPW4qyL6oOlwFPlGGU7tkdnE3f66A=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=COXUvEVIvQMBqQDTj3NLHHbZ8iSw7JlWw2MmAtGTZKshV4JdTCt/7WLlbSxQu++XKSPEiuaK2edl+kH0zSzjtOhvhJo/4QuoR9vZVNQqAsOblOvRH5Rh4eUzt1gdax8wcl4mA6OKEh0kCgHf1FsG1vkNuzyfo3tpVtuhxIei0+tTiS6nTqjx204SPBdWZRKtEDnMKsNOC9XCtP/tXtPcXgpKLR2OL2ADQRqxO7QUREb5IBQ3TIFwE1ictsOb3hmr7HfQZBX5BGzOpOGLTRpd7j62VBUc93Iu6wogmFDcQ7w6VoTyy8boVxXxme1DEQLQpRyDNTh1jN7mGmgV8Qbr6w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1747720286; bh=pzmOfZP4/C8M7cRzmbTObZ3NUHDkyMGEXOJC6cUb/l/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=M/MgTmWLJmHSozIfdPngnhc2taNdtgrxtVgDhK+ydoS589fyOjIi++xAqGovi63gg1tvYn6yLxgM7tAQQhEaUwRkBU11Vd4fGFjgL1CndWeWUKzL1TaNbr/XAYj/Ljb6U7yda4Pe3Azt+uEK+rSDyMF4y1fw7CZkdwQZPza0JY4Rv1DnjbMHF6ti5l2i5FfQsXAzMn955IwNpu/2oG/+/lGqotFY9KXsy/BJgCIxoZAei66Ad/fB18NI44i24Bzv5gK6jlQoWXsc8iuEbn5dspX0L9rbzHHz6BfRVsR6CgPWXfSg3fuf2L0/Doq7JOP1ZAU+NPzz9v5a3PCtd82Sdg== X-YMail-OSG: vvv8l7YVM1nkMmPtwIFIbrF49zfK0nRKi9CATjVxRriLp9voGFNI_mKU6BLC5dJ cJF9tlG1N33o13Xx5brICXbgsVGUB1LGplDH07mbo1KjE8emDVc.CUKxQE9R9IeyFDkJPHhs2C2O lqjKo7yexIg9XhYIq4BMPdtu38ydmAZiFA43HtFIWrNThXJo14l._H5BL45Oxy5Y_N0ndwGxPcs2 dzQBxyMOQF_sEGlPk.GNu0F_L5mtYB2opttwbDWH.cauutY4hXfP.A8vk9.v56EroOZ7DMdLbfBQ oCDc3.pF37N7LuFO9yc4axdQi6gGwHZ24m2IgJYXKKE.isDnJwU9yjjd8b7kzJE4Y8Gjki6tii5A Rmbp1SYo2BtVIz8JxYrkSPWfa6wybzaZhAbNSyFVQ3omBenI.R7ImsshCE03px.0wSEYJtC3Zf2O RsJUjc5nn14Q1CLmkEgHS_z0CPLJdi5r8veI20BEfNGgcOyuaQi8Q_m3B4c7GN0jJ0i47YhNaGg8 BVtYlh.Kv2pVrg8PYvsb6YzkGWU7CBaIo6nGNU9v8qbl.NhyHLfPhcVO_c.OGF_ae9OCFxSF_oGi bLe1Vm356kcM7GXNMXtz0UdUHWw2QbS.7m2ttqulXjIeyWnC1HfHDm78vAjPS6_bqjSB9lzVNbCd FsR0UdjMOe7sD46bMUanAQHX5OUHuLY9mznczX0JUkjj_Jj6Q3aGgn6BWU5ytmT2QuTghYH3ap3t yql5IHcTi6Zc7vSUusoXm_cMeMZg5kYe4odZNrpOJg2HINJuHUArgjDKKPD9YvOqi4lZDMdzql9T hH3z9tNi7gesEQ4hxFZrULgZMrTrQ4hG2vT3JzPsqqWERY.RIpehbUA.H.qe7QpvNyYOF3nkKI2c m9TEbgLy_7NqPHYYhpJd9f7czhIbSTD3JdOWhQ2RLyfT7SBUYjOpw5zJckZRP0Hx3O7Wfs8pbduX 1M_zq1WdTSK.rxjfB3_VW6nZztQhy67JhYDgIxx7nwjB5r2mdKas_9jwF6U5aHcOcNkgskVmOHiL CrmCEejNBp2oTsuqRBnp5L9ymeYMF7ZU07rXR1cWsNpC72ORzgEUy9xmnk0uFbKHuev4Kiq6.yx1 VgDmMT8IZw9kVJoUabMMc8wtnGM7g_iyuCzeVDGKJszx2G_kKWSGkC6aKeRydJwnu4yijsar5f3t i0PujHzDp1GDQtdd1GmpKqukbXmnvHCib.4uEvW.N2Pc2s0QJT38SqcRBhZ6z10V2OYfpCpc_aL0 gxZwz2CYd9CM69_9vsvWUO34JmkN_UStZcS6XnpLUhFvGpEY__Qqm67i76j.zWpPRBNWh1627SRB oJ0Euv4Vhs8StbqPrzjjmJe1H0CzggaiPb_ObPGoTJUshDFlN4RvDyKsjyT6JlXwfsrLle_v.1D5 lOOQvGS4Wt6atJPz6b3hFhNpdfbAXn7NKJH.6pMe9hgieU9Hb1EzpbKokyKwHo1AXGgVjo63FwYB auDiarIXVvILJb.930v5UOegUw2Q.14j5QIcvjSk2FzqpvN3JIiQvLR3NaOGjvWM.YqjHsMxShvI 4hqGPpxhyyR8bwxXOvGyPdgJXsMEMczK2Yxo8zRPDiagqJu.3QOJZScAMAlMRreDd.RfBbL2dNMw BwRU9bWa8uwKEr6uNO0hVr0AE8mMZOoIFXvE6YcHUFZjuZinV9TzoeigDSDb8_8Zw5qBz.Rb9_1R ZUWpN.F2kF7Nx2S4W.ToFVwwQgQMLOHEeRIltAizJ9e.RgklE02L0IfDd6u1FsEHjHCbuUyceMb4 p48uYIZ.PXSZgnHWVLko1M_OOE6vWzVid.RAcWHdNyKbUYuN9Fo1TZCRSjMP736sD3SaP7ONhhL9 p6uHurU7LuCrfggjfwbIkg_2yb25X8WwmTj8eLPChk8dCxY1ZO0I4g_LFlPI_IcFi7lHqmpTARuB nK_0UtcbBpW1yvP99DNVO7X64mI4G1kfU.zClyhEHoed6vBTqluCJmM4vGpHhHtbU4fvPBqvT1TL r_sMnbclp03eNfPRnpTISKl4MKWmn6Xlvfd0rOPe9oo7S5jlw4WIkzSNXd0A7GEElsi.rNAtBL9l N6kvp3hxa.HZAQNLGascLiu9_El8jtMRkLFv1wo8HQPhVAqIQsUxcdAn0IHNmXZzsoocUSfHGarK 3k.LC_gWJ2cxw97HzvA0bTwSYSaMEw5bHlLOnw2flUY7itfdQMUi_bypRqE5k7glmrAOF8Z6JcDP Ws8k9vZF0VpWYktaLLle4Kml0t1hrckcSBFVgxDLIjXf9C4ZqYdYIEvzYz60JHNeyT5b.KLBGKbB u X-Sonic-MF: X-Sonic-ID: 0ac98014-c719-4d33-9c00-e0a6c7ec5745 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 20 May 2025 05:51:26 +0000 Received: by hermes--production-gq1-74d64bb7d7-f4j4n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4fb2a7615a55ae053737767c3fd14bf; Tue, 20 May 2025 05:51:22 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.600.51.1.1\)) Subject: RE: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1 Message-Id: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8@yahoo.com> Date: Mon, 19 May 2025 22:51:12 -0700 To: Dennis Clarke , FreeBSD Current X-Mailer: Apple Mail (2.3826.600.51.1.1) References: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8.ref@yahoo.com> X-Rspamd-Queue-Id: 4b1kFX2T7zz3YP1 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; 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.204:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from] Dennis Clarke wrote on Date: Tue, 20 May 2025 02:33:58 UTC: > Just an odd message to see on the console : > > # witness_lock_list_get: witness exhausted > > Looking at https://cgit.freebsd.org/src/tree/sys/kern/subr_witness.c it > seems that the comment at line 370 is very clear : > > /* > * If set to 0, lock order checking is disabled. If set to -1, > * witness is completely disabled. Otherwise witness performs full > * lock order checking for all locks. At runtime, lock order checking > * may be toggled. However, witness cannot be reenabled once it is > * completely disabled. > */ > static int witness_watch = 1; > > So I wonder how I managed to get that message "witness exhausted" ? > > At line 2203 I see : > > static struct lock_list_entry * > witness_lock_list_get(void) > { > struct lock_list_entry *lle; > > if (witness_watch == -1) > return (NULL); > mtx_lock_spin(&w_mtx); > lle = w_lock_list_free; > if (lle == NULL) { Looks to me like "out of required resources, cannot continue with the mode of use" code: an empty free list so no node is available to put to use to continue with the witness handling. > witness_watch = -1; > mtx_unlock_spin(&w_mtx); > printf("%s: witness exhausted\n", __func__); > return (NULL); > } > w_lock_list_free = lle->ll_next; > mtx_unlock_spin(&w_mtx); > bzero(lle, sizeof(*lle)); > return (lle); > } > > Where it seems that indeed witness_watch has been flipped to -1 and that > functionality is now gone? Until the next boot, anyway. === Mark Millard marklmi at yahoo.com From nobody Tue May 20 09:24:01 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1q045xxZz5w6V1 for ; Tue, 20 May 2025 09:25:08 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.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 4b1q031FQKz45K7; Tue, 20 May 2025 09:25:06 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=TnosFcm3; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=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 A5C702404EA; Tue, 20 May 2025 11:25:04 +0200 (CEST) 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 C45D4240165; Tue, 20 May 2025 11:25:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1747733102; 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=uOdG+63KDD1mbwuoffP6C+D9wpNdACf7nYKKNZwnbSI=; b=TnosFcm3aAJWRxxz9bAwOhDm/CFZW0WuoR878/5QmIAHEHXvtieHE52uEg/vMbmvlheHSo ikrBq3QhIkHVvGxcF9eJhvfp4jbGARH4PfE8Z32qvOrAXb0VLp5DYE7+cUHcI0Ib9RRV8V AdEoDNVK25NmOISXBfdoNLWRMIyJ2iR4nizoEtR3OwA/LDwHvlbdAK78O9ErU8VuRN91GS A/cpBcm/2EAB8CMUu9s1+Lw+A79zwTgUooc7+7r60KUVmBQ0mdbac8ZNkAjYw6wsQBnYX7 lhGEvZhSkbD3Bimoo0PacA4yMdZWQjH1HYSgJrB1slBqCbloLwOJ1IIEkI5vrA== Received: from thor.sb211.local (dynamic-002-245-169-065.2.245.pool.telefonica.de [2.245.169.65]) (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 4308924039C; Tue, 20 May 2025 11:25:02 +0200 (CEST) Date: Tue, 20 May 2025 11:24:01 +0200 From: A FreeBSD User To: "Patrick M. Hausen" Cc: Lexi Winter , Kristof Provost , Marek Zarychta , Alexander Leidinger , rgrimes@freebsd.org, FreeBSD CURRENT Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument Message-ID: <20250520112428.3de8301e@thor.sb211.local> In-Reply-To: References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/p3Xe/kh7kheASGxxHylfGCs"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 4023db X-Rspamd-UID: c28fcb X-Rspamd-Queue-Id: 4b1q031FQKz45K7 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.69 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from]; ARC_NA(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] --Sig_/p3Xe/kh7kheASGxxHylfGCs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tage des Herren Mon, 19 May 2025 11:22:31 +0200 "Patrick M. Hausen" schrieb: > Hi all, >=20 > > Am 19.05.2025 um 10:53 schrieb Lexi Winter : > >=20 > > the basic problem here is that putting IP addresses on a bridge member > > is a layering violation and it's just not reasonable (or even possible) > > to support this in a sensible way in bridge. this is why most dedicated > > network devices (switches, routers, etc.) don't let you do this. =20 >=20 > Adding to this, the fact that IP addresses on member interfaces are not > supported has been documented from day one of the introduction of if_brid= ge(4). So the concept is to have if_bridge() facing "towards the network", with IP= v4 and/or IPv6. My "concept" - or better "minded topology" - on how to connect computers is= probably outdated or mislead, sorry for the noise. On the host in question I was able to switch towards the correct concept wi= thout consulting the aformentioned sysctl. bridge0 has a internal IPv4, IPv6 ULA, has a phys= ical NIC (igb0) as member and a bunch of epair() vnet interfaces. I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I simply u= sed=20 rtsold_flags=3D"-iu igb0" within /etc/rc.conf. Changing this line to rtsold_flags=3D"-iu bridge0" while bridge0 is up and running doesn't work, = neither does "rtsol bridge0" show any results. Is there any othe MIB OID for if_bridge() to be aware of to achieve the des= ired behaviour? Kind regards, Oliver >=20 > A couple of months ago I did check the commit times of the code and the > relevant handbook section because exactly this discussion came up again > in a different context. >=20 > https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-b= ridging >=20 > > If the bridge host needs an IP address, set it on the bridge interface,= not on the member > > interfaces =20 >=20 > Kind regards, > Patrick --=20 A FreeBSD user --Sig_/p3Xe/kh7kheASGxxHylfGCs Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaCxKTAAKCRCxzvs8Oqok r/YIAPwKPc034Q5v5oLbJ18HbO0z4IOADtDvlMr9CfIdoDSEjwEAvjUol9yvpc8q CA6JKLpfHRbzEILoYqTVJg7lT5RjUAQ= =KU3P -----END PGP SIGNATURE----- --Sig_/p3Xe/kh7kheASGxxHylfGCs-- From nobody Tue May 20 09:29:24 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1q5M2YWwz5w6Wp for ; Tue, 20 May 2025 09:29:43 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1q5L5RyZz46Lv; Tue, 20 May 2025 09:29:42 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 2FEC06; Tue, 20 May 2025 11:29:35 +0200 From: "Patrick M. Hausen" Message-Id: <83C4319F-81D2-4FB4-B392-02AABB4C198C@hausen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_29D4D9E9-0725-48E3-93E3-4133BDA191D7" 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.500.181.1.5\)) Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument Date: Tue, 20 May 2025 11:29:24 +0200 In-Reply-To: <20250520112428.3de8301e@thor.sb211.local> Cc: Lexi Winter , Kristof Provost , Marek Zarychta , Alexander Leidinger , rgrimes@freebsd.org, FreeBSD CURRENT To: A FreeBSD User References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> <20250520112428.3de8301e@thor.sb211.local> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4b1q5L5RyZz46Lv 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:16188, ipnet:217.29.32.0/20, country:DE] X-Spamd-Bar: ---- --Apple-Mail=_29D4D9E9-0725-48E3-93E3-4133BDA191D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, > Am 20.05.2025 um 11:24 schrieb A FreeBSD User = : > I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I = simply used=20 >=20 > rtsold_flags=3D"-iu igb0" >=20 > within /etc/rc.conf. Changing this line to > rtsold_flags=3D"-iu bridge0" while bridge0 is up and running doesn't = work, neither does "rtsol > bridge0" show any results. Do you also have ifconfig_bridge0_ipv6=3D"inet6 accept_rtadv auto_linklocal" ? HTH, Patrick= --Apple-Mail=_29D4D9E9-0725-48E3-93E3-4133BDA191D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

Am 20.05.2025 um 11:24 schrieb A FreeBSD User = <freebsd@walstatt-de.de>:
I need a IPv6 prefix on = bridge0. With the "wrong/faulty" concept I simply used =

rtsold_flags=3D"-iu igb0"

within /etc/rc.conf. Changing = this line to
rtsold_flags=3D"-iu bridge0" while bridge0 is up and = running doesn't work, neither does "rtsol
bridge0" show any = results.

Do you also = have

ifconfig_bridge0_ipv6=3D"inet6 accept_rtadv = auto_linklocal"

?

HTH,
Patrick
= --Apple-Mail=_29D4D9E9-0725-48E3-93E3-4133BDA191D7-- From nobody Tue May 20 09:32:57 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1q9M2YHXz5w6vY for ; Tue, 20 May 2025 09:33:11 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1q9K64wtz490k; Tue, 20 May 2025 09:33:09 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pmh@hausen.com designates 217.29.33.228 as permitted sender) smtp.mailfrom=pmh@hausen.com; dmarc=none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 257159; Tue, 20 May 2025 11:33:08 +0200 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.500.181.1.5\)) Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument From: "Patrick M. Hausen" In-Reply-To: <83C4319F-81D2-4FB4-B392-02AABB4C198C@hausen.com> Date: Tue, 20 May 2025 11:32:57 +0200 Cc: Lexi Winter , Kristof Provost , Marek Zarychta , Alexander Leidinger , rgrimes@freebsd.org, FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <75D1AB21-8570-4BF5-A7AD-7A9120294057@hausen.com> References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> <20250520112428.3de8301e@thor.sb211.local> <83C4319F-81D2-4FB4-B392-02AABB4C198C@hausen.com> To: A FreeBSD User X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4b1q9K64wtz490k X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.25 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.46)[-0.459]; R_SPF_ALLOW(-0.20)[+a:mail2.pluspunkthosting.de]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[hausen.com]; RCVD_TLS_ALL(0.00)[] Sorry, missed a detail: > Am 20.05.2025 um 11:29 schrieb Patrick M. Hausen : >=20 > Hi all, >=20 >> Am 20.05.2025 um 11:24 schrieb A FreeBSD User = : >> I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I = simply used=20 >>=20 >> rtsold_flags=3D"-iu igb0" >>=20 >> within /etc/rc.conf. Changing this line to >> rtsold_flags=3D"-iu bridge0" while bridge0 is up and running doesn't = work, neither does "rtsol >> bridge0" show any results. >=20 > Do you also have >=20 > ifconfig_bridge0_ipv6=3D"inet6 accept_rtadv auto_linklocal" >=20 > ? To get a stable SLAAC address it also helps to have in /boot/loader.conf: if_bridge_load=3D"YES" /etc/sysctl.conf: net.link.bridge.inherit_mac=3D1 This way the bridge IF clones the MAC address of the first member IF and SLAAC works as intended. HTH, Patrick= From nobody Tue May 20 11:00:15 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1s6w11mYz5wDPq for ; Tue, 20 May 2025 11:01:12 +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 4b1s6v5YMYz3Kyr; Tue, 20 May 2025 11:01:11 +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 DDABA240456; Tue, 20 May 2025 13:01:09 +0200 (CEST) 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 3FD2A2400D4; Tue, 20 May 2025 13:01:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1747738868; 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=GeSPieXEfYCLRMndzI9KGN4lG69BvuOQiXqkQtQ68qo=; b=dYDUy+zk7TQraijU2nnNhvOzZ75KYFpIQBCr+pIGydkFgWXheD/Fx3jlfSUrOiEOruiQsu 1lFA4uNrDlTwoRZM+IQyWKbmogLOmMiyqj2zNxRHfkFYZ2iybehC4WkC0vJu7HkH1FcGqP FxFbgLurjrRAuTCrKBmgHNe1jBd79LuZk/BeMYLbeUnDdhIODEA9gpTY69z0XBHGy+fxPX O/ho/7LIeJ9ZM40BKC3i/MZRuBIlJfZNervyx8ogF9aPemuqQGg+uNQfNwNoAul13ho1Wh WceZzzaewQ/tyPEAVh9xw5zZTSfFYRgC5vEVJBF/PzLGQXDgHKiUnc/Y6pHCMw== Received: from thor.sb211.local (dynamic-002-245-169-065.2.245.pool.telefonica.de [2.245.169.65]) (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 C7F1324062A; Tue, 20 May 2025 13:01:07 +0200 (CEST) Date: Tue, 20 May 2025 13:00:15 +0200 From: A FreeBSD User To: "Patrick M. Hausen" Cc: Lexi Winter , Kristof Provost , Marek Zarychta , Alexander Leidinger , rgrimes@freebsd.org, FreeBSD CURRENT Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument Message-ID: <20250520125950.08367968@thor.sb211.local> In-Reply-To: <83C4319F-81D2-4FB4-B392-02AABB4C198C@hausen.com> References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> <20250520112428.3de8301e@thor.sb211.local> <83C4319F-81D2-4FB4-B392-02AABB4C198C@hausen.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: multipart/signed; boundary="Sig_/JTgqkFVYvRV6ie8J3v710+Z"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 2ee961 X-Rspamd-UID: ed3316 X-Rspamd-Queue-Id: 4b1s6v5YMYz3Kyr 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-Spamd-Bar: ---- --Sig_/JTgqkFVYvRV6ie8J3v710+Z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tage des Herren Tue, 20 May 2025 11:29:24 +0200 "Patrick M. Hausen" schrieb: > Hi all, >=20 > > Am 20.05.2025 um 11:24 schrieb A FreeBSD User : > > I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I simp= ly used=20 > >=20 > > rtsold_flags=3D"-iu igb0" > >=20 > > within /etc/rc.conf. Changing this line to > > rtsold_flags=3D"-iu bridge0" while bridge0 is up and running doesn't wo= rk, neither does > > "rtsol bridge0" show any results. =20 >=20 > Do you also have >=20 > ifconfig_bridge0_ipv6=3D"inet6 accept_rtadv auto_linklocal" It is in fact ifconfig_bridge0_ipv6=3D"inet6 fd11:a:b::1 prefixlen 64 auto_linklocal acce= pt_rtadv -no_radr" Regards oh >=20 > ? >=20 > HTH, > Patrick --=20 A FreeBSD user --Sig_/JTgqkFVYvRV6ie8J3v710+Z Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaCxg2gAKCRCxzvs8Oqok rwi1AQDkLb83phQL4mbrg95zOfSVsV/681WWh9iS+BiV1oKZJwD8DPOWUQtPsYaq L3r2j1dnEUUR2YAnI2Tfi084Ofvb0AM= =Wqo6 -----END PGP SIGNATURE----- --Sig_/JTgqkFVYvRV6ie8J3v710+Z-- From nobody Tue May 20 11:08:23 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1sJB2q5mz5wDxb for ; Tue, 20 May 2025 11:09:14 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.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 4b1sJ971dwz3MGN; Tue, 20 May 2025 11:09:13 +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 4A014240DD0; Tue, 20 May 2025 13:09:12 +0200 (CEST) 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 9097924033E; Tue, 20 May 2025 13:09:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1747739350; 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=yV+BuLetxISFF6m6We6JfkG0kOuOdQLYEB8ljv2Q/GQ=; b=F3Ldyd7Z1nshYwPuO1IwFOcg16B8/ORRCe/TQXoGVPJ4pcVUbbo4JlvNvxFJKQE2H9sZ77 IeRbcrteGyIUNRU6fNlxdApkplvQG3opUU372C0lrNBwhRlwxW8m3pnkYz+d18WauJavJ2 TNDx8yPVDkhwlsiepx4UGqjYgHKAx//8ptdGzD09iNWQdkCC+h57FWC0ljRRJ9YShVLwAV p9DC8wmMdKCOBh88XzC6sVCDg47Ef7AxU/U00q79ap5JXxss1ZpNfFJD4DCxVILtg5fGGg 6qq6NWY9BntA+YekAdK3nfXLft4aZ5HJ8Bn1vYDlXPSUroklJzu02Chph2jiZg== Received: from thor.sb211.local (dynamic-002-245-169-065.2.245.pool.telefonica.de [2.245.169.65]) (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 3C94524033C; Tue, 20 May 2025 13:09:10 +0200 (CEST) Date: Tue, 20 May 2025 13:08:23 +0200 From: A FreeBSD User To: "Patrick M. Hausen" Cc: Lexi Winter , Kristof Provost , Marek Zarychta , Alexander Leidinger , rgrimes@freebsd.org, FreeBSD CURRENT Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument Message-ID: <20250520130850.0a808284@thor.sb211.local> In-Reply-To: <75D1AB21-8570-4BF5-A7AD-7A9120294057@hausen.com> References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> <20250520112428.3de8301e@thor.sb211.local> <83C4319F-81D2-4FB4-B392-02AABB4C198C@hausen.com> <75D1AB21-8570-4BF5-A7AD-7A9120294057@hausen.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: multipart/signed; boundary="Sig_/hmviFr2J3Euz._K4=XXxj6Q"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 9cf3ca X-Rspamd-UID: 0aab41 X-Rspamd-Queue-Id: 4b1sJ971dwz3MGN 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-Spamd-Bar: ---- --Sig_/hmviFr2J3Euz._K4=XXxj6Q Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tage des Herren Tue, 20 May 2025 11:32:57 +0200 "Patrick M. Hausen" schrieb: > Sorry, missed a detail: >=20 > > Am 20.05.2025 um 11:29 schrieb Patrick M. Hausen : > >=20 > > Hi all, > > =20 > >> Am 20.05.2025 um 11:24 schrieb A FreeBSD User : > >> I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I sim= ply used=20 > >>=20 > >> rtsold_flags=3D"-iu igb0" > >>=20 > >> within /etc/rc.conf. Changing this line to > >> rtsold_flags=3D"-iu bridge0" while bridge0 is up and running doesn't w= ork, neither does > >> "rtsol bridge0" show any results. =20 > >=20 > > Do you also have > >=20 > > ifconfig_bridge0_ipv6=3D"inet6 accept_rtadv auto_linklocal" > >=20 > > ? =20 >=20 > To get a stable SLAAC address it also helps to have in >=20 > /boot/loader.conf: if_bridge_load=3D"YES" > /etc/sysctl.conf: net.link.bridge.inherit_mac=3D1 >=20 > This way the bridge IF clones the MAC address of the first member IF and > SLAAC works as intended. >=20 > HTH, > Patrick In my case(es), if_bridge is statically compiled into the CURRENT kernel. S= ince I have to (mis)use dyndns v6 services to identify my hosts via MAC portion, first bri= dge-attached device is the NIC I usually was using for attaching to the network (em0 or igb0, d= epending on the CURRENT host, I have several ones). Regards, oh --=20 A FreeBSD user --Sig_/hmviFr2J3Euz._K4=XXxj6Q Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaCxiwgAKCRCxzvs8Oqok r2hPAQCxOQj86VGclJEWzk00zu5ZqUVI/MJ9BVfmFGP/bgnWbwEAofdJqQnuLBbl 1ndUqwE+Up+IVp+KjkQDkTnrW8V77wY= =Gqdw -----END PGP SIGNATURE----- --Sig_/hmviFr2J3Euz._K4=XXxj6Q-- From nobody Tue May 20 15:34:00 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1z9n668sz5wYR3 for ; Tue, 20 May 2025 15:34:05 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1z9n4BNMz3nwQ for ; Tue, 20 May 2025 15:34:05 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; none Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 54KFY0s7072664 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Tue, 20 May 2025 11:34:02 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1747755242; bh=1tfhgd8OJSzqL40j1QtqPQP5lQeI3S5myOKfQq8P6j8=; h=Date:Subject:To:References:From:In-Reply-To; b=hPYL5cQgFrE6qo9lCu4sHWJ+GN+V/OQBetdO19VTZHu/AeGHgfnC+iYtVbP4aewPO T71Gv4f8ET36FsXXc9UdVRlezUZJAayuzkHQo/qSk2BIEQ60ce5ZfCFYzQfD3vcc6y N5A/1+cacw9lrTmRQZXcMbak2BB0W8L2tAjYIQRvF0wHkMTGgZ8DESc8gljErT/Fff t2Ne4893daRUYo78/UAd1hNU8t+KH0ZQ+TitXu0GSGIFNNKJhTpWTAzCUxOjoOkPbL eLmImf1U89a/hzMX7dpw1RX1MJ/XFaqAJ2nrmE3e8Hls0rQLpX5fI9Jxp/yqMNJtL9 /E+o8cCLn+JSA== Message-ID: <04528a6d-438f-4b40-86fe-3fc83d372b26@blastwave.org> Date: Tue, 20 May 2025 11:34:00 -0400 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: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1 Content-Language: en-CA To: Mark Millard , FreeBSD Current References: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8.ref@yahoo.com> <2950BB1C-6672-4110-8485-3CB9ED0DAEC8@yahoo.com> From: Dennis Clarke Organization: GENUNIX In-Reply-To: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 54KFY0s7072664 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Queue-Id: 4b1z9n4BNMz3nwQ 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:812, ipnet:108.160.240.0/20, country:CA] X-Spamd-Bar: ---- On 5/20/25 01:51, Mark Millard wrote: > Dennis Clarke wrote on > Date: Tue, 20 May 2025 02:33:58 UTC: > >> Just an odd message to see on the console : >> >> # witness_lock_list_get: witness exhausted >> >> Looking at https://cgit.freebsd.org/src/tree/sys/kern/subr_witness.c it >> seems that the comment at line 370 is very clear : >> >> /* >> * If set to 0, lock order checking is disabled. If set to -1, >> * witness is completely disabled. Otherwise witness performs full >> * lock order checking for all locks. At runtime, lock order checking >> * may be toggled. However, witness cannot be reenabled once it is >> * completely disabled. >> */ >> static int witness_watch = 1; >> >> So I wonder how I managed to get that message "witness exhausted" ? >> >> At line 2203 I see : >> >> static struct lock_list_entry * >> witness_lock_list_get(void) >> { >> struct lock_list_entry *lle; >> >> if (witness_watch == -1) >> return (NULL); >> mtx_lock_spin(&w_mtx); >> lle = w_lock_list_free; >> if (lle == NULL) { > > Looks to me like "out of required resources, cannot > continue with the mode of use" code: an empty free > list so no node is available to put to use to > continue with the witness handling. > Seems like a strange feature that simply gives up and goes away if the system gets a bit busy. This system was running a poudriere build of kde when the message appeared on the console. There was still plenty of memory available so there must be some hard coded limit in there that needs to be adjusted. >> witness_watch = -1; >> mtx_unlock_spin(&w_mtx); >> printf("%s: witness exhausted\n", __func__); >> return (NULL); >> } >> w_lock_list_free = lle->ll_next; >> mtx_unlock_spin(&w_mtx); >> bzero(lle, sizeof(*lle)); >> return (lle); >> } >> >> Where it seems that indeed witness_watch has been flipped to -1 and that >> functionality is now gone? > > Until the next boot, anyway. > A fairly stange feature that is implemented by default if one merely does a buildworld/buildkernel sequence with no adjustments. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Tue May 20 16:20:52 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b20D66JmQz5wbtp for ; Tue, 20 May 2025 16:21:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4b20D61w2dz3tF7 for ; Tue, 20 May 2025 16:21:10 +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=1747758067; bh=2wB91wCKzMjvy23uGRNahhTiAduTbqU6OSDHSvIvJ78=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=A7Yf7OlQjmvarygs5iFXCQbSmAbkJF5a07HJcHX8XNgdVkBjmjQCcVTxTrNoEE35gOmkfZPSzZRwefUSJXL7Sn3SdcABhGF+wAa3vUVjHdZO8GLbb6rYc3N3LPA7vcZybJhpavqkRCN08d3Hre/yZXx+pO15Zh/0X70B57y2C37ssmJJ2hQrQCUXa5G102OQdbnumMKAlQ8dzT8NFSVNMjNhvvqmraxb38/b+bd/ndECstAaw+Wya+TxQQcos+CTR4GoDyU3G5jOnkA6z2nRPVwKN0bCDRAlmcyU1MrjSg5Xmj/KHj1O6x3tv4DqNfX724IRQHSNvzh8OEAC/rHsKA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1747758067; bh=PuXpsqZur5uVqcRovsf1yTybi3w0FbJ1CV5rwZz4mS2=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jaBrXtsswk2u3qlsqgUtUX7j2AIOndR+TvHsl73Shh9w1sUzz1r31uhEw4pqTDTWx41uMzeIQRlc8tdjzeSvQgLlLYQ5v0mrXKyQJcFGxzRuhzbHjswYmoWfijfKUvi6F/qai0wv0bIGPct8rxbs3im+qge2ab4jRRIW7U7IS2awAS5yvM5iuivGOe66B6x/ZZpqryFTT/gteB1CMcdPfOfS6vlMxtCANwy9XvG7HNJfRKy2lUpXQZixT/T0S4bju0mxsunsIrpYZUOTtfk5/FSVHFGnTUUTDnOh12fBkaNOg1JKTdhRq+N0CGGkvDybn0VCdc61XL0DD95lBKqchw== X-YMail-OSG: HTibfMMVM1k_QX2kcseU.JuWJQPX5WyFMeojkwwW7DvfARIyGm_UAu1CjGUThed 5.2W94ncgy.tPQ4I4bLaFgefmEZWhENucmNU6YoPh.TyCEZet_2_Vbp4PMzDq2jM.X1V6s3vt71w B6PtNeza2bUAt0G86349D4Am.j018C1VLWRd49tiNeo32cPhIBpVM_W2XAE6HlQcXM2Agfc_CbNY 7dwzynea1y0hQsU8deafE7fPXAB7TwOJeSwjOv..HPnMIFxrcG3p9fuCA1EvvWYwKgqMLaKyxEKp zTKIT8KVhPWxlW6b2f7vUblRzxZDsbz7yU8NHjC9hgHbGFICrp73EmDtwtuVR8yAxDHUZyVRnMQX 1wqtKUuxyuzaQDz3TGB4fFKkHquHm5CSYSJSDdVXp7D9dWRR1Fk_1vM6eAIqPKpj.cDf8CJGLAOQ fFsnI2PuwjxD6GJawo.s6CS7ziFzKr1wfGHgchg6tNwqK8v78_QWwhBnAKs1h0Sb8tI.OCmGDTHW g5900ksuPdjbGn4hYFAscrNwhFBUTrAAF7MNXh7itVmN8ompghre44K.zpTA5QHbvMI3IhyWxXFI u2_Po3vZmxUFL1uDZ2EYtSjkrsOcXNDpgDW7i_1G7Xpr1IH3G0MaEGHKHhirGfFw3jEIJ8Kmd5j0 zigprg4m0FA5inaq4uAYd6ClBsnzbdVEfaiPxOhaxPOLXrwqA5eUmRBmX9UXjmlChDjwdGe2NARj vwYIynxEwTaesaMU.EUIRWA2pRjSq4YIlyk1wecgsklTNwKXC5Lhv._YrYhq9LutITR4AtpVpt60 q7ZVIIcWHSznZKlBxgAV0lfPpdRn4W7_z4TvxZjzbzmkeLGDFk9GhsW59fAipWmxOObNCeN3rk31 nPU0aS3ECFe99e7QCiEnhxWR6Dyn4NuKJ1M6aVrcEXyMgiXe5j2G32nTaS1MxsmOiLPOxKe.StQU h6L1G.z68qr_LC3PAjaiFmaszYpbDtDb_UAl_0w.aJjJzQxN.CP0oi7WfGU4FMhfQSPvSz.ISv.i OciUZyAba4bT3NiGLoHvgKmhjOCBKwiAVOk1qVwxv2pdcXZR8RJ6Uqk.oTomgEDjr6LJqf50ihSq TpCErs0jJxjh7Taopo.I7jCFXHUpSq6o3CQengyaJpFPm6rgEYoEklPLYf_ZPVbKsw517R.JzKOE UQwURQUmzeose5wNiKlIlR1P6eMl12bwZ9NzEesLtoBn61t7Ld2BkQ51GRqhtCV0RI_S8p6vsQQR EU5nnWfTZxXZI_xB68ssgM.1Y32CPhq1rIozF1N.jNYKr9Q790DJ5GaIRgHNLn9qrtrNoNIZh183 egdHdMD8WdefZWziA4JTQSxiWc6BkdLYL_BNQoV.hLzat8zO8WAB0WQlKCAiENff33Qs6hkSk4A7 GR9w0VA_2TZ2QkrNwcQ4Q2JutCFqMN.0RS6CWFZbNQP_Yl99PZVnosJvyuTrWut_rs7yEj82XZta rcotOurYP2pNrr5Hwq0Z.YsKvXnAKrY4OjorrWS.1NopQoXgbni85cnxDAfLF9_1q7DlqcBg8ogz 4GXWiSC53GS.lbwDpmCRvzMOmtslytL3s8cJAODmiDm_NnaIYxSJnmgtQdjwBXH34o1WF3LBvS.L ui01HozPZCL3To7H2X1f2nq2iNS401OKibObTSP32brtJC4pTCN9_EvjpWWsmHAgWwc2ht_nUL.F joS_t.Nv11W8567nX83l6h1p4NCsFGeQYJiaTdx5XidySDtCNj4RCPO3F4d_GuzMbUFOPHD3Kwtl 7ba7GI8pN_1vTWtBrtH37MPGalGDJ_oS8pB2PdhHw4QyHsAW4mm40kLgDdlkTwTbObr0yIOwkqqS bfw.SC1wr8.ZewKJ6GlU3HOfroiR_l_4qv278.VfrxquoTdDMR4YF3NLCz1Rx36uuhzSZS.zzkoF SkgMaFkSpMLnaFIHH4hA0zjlPzd0BtxneeQdc2hfhX1R8aXC1fl.4T2sFh.wgMajgeo88FDr3yGm fM30BFTuu0c9WyC8kAMM49o0BSMv2blTNPPlas7s1nN3dR2KFfhtEy8jcVtjBNPsNyvP4X3CAPgK B_Nda4YhO_tMYlot_GCrBmzig1KJu7qLPCHkSGYH.Mr01.6BpNubcEh9jSz28qOk1y8O.PMTudVj 3vmTxEr3STh.Cz_VQTXV_ltUjzIRqtxjQGx31TdlIvmmAU6FkdAVYDPLFSStp3GurMsU2QScTjzd kax_94Lrax75EkNWpNIT3hSVkqYYYE92DIY1kbCQ_9uCY_nfF4HOz4wBScpJPWtbKiTnY16OyPJZ w X-Sonic-MF: X-Sonic-ID: 476c2806-3fb4-49f5-b7e9-6a8dc20f0a50 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 20 May 2025 16:21:07 +0000 Received: by hermes--production-gq1-74d64bb7d7-grhph (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID daac92813d25fb7bcf7599d73e8bfac1; Tue, 20 May 2025 16:21:02 +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.600.51.1.1\)) Subject: Re: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1 From: Mark Millard In-Reply-To: <04528a6d-438f-4b40-86fe-3fc83d372b26@blastwave.org> Date: Tue, 20 May 2025 09:20:52 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8.ref@yahoo.com> <2950BB1C-6672-4110-8485-3CB9ED0DAEC8@yahoo.com> <04528a6d-438f-4b40-86fe-3fc83d372b26@blastwave.org> To: Dennis Clarke X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b20D61w2dz3tF7 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-Spamd-Bar: ---- On May 20, 2025, at 08:34, Dennis Clarke wrote: > On 5/20/25 01:51, Mark Millard wrote: >> Dennis Clarke wrote on >> Date: Tue, 20 May 2025 02:33:58 UTC: >>> Just an odd message to see on the console : >>> >>> # witness_lock_list_get: witness exhausted >>> >>> Looking at https://cgit.freebsd.org/src/tree/sys/kern/subr_witness.c it >>> seems that the comment at line 370 is very clear : >>> >>> /* >>> * If set to 0, lock order checking is disabled. If set to -1, >>> * witness is completely disabled. Otherwise witness performs full >>> * lock order checking for all locks. At runtime, lock order checking >>> * may be toggled. However, witness cannot be reenabled once it is >>> * completely disabled. >>> */ >>> static int witness_watch = 1; >>> >>> So I wonder how I managed to get that message "witness exhausted" ? >>> >>> At line 2203 I see : >>> >>> static struct lock_list_entry * >>> witness_lock_list_get(void) >>> { >>> struct lock_list_entry *lle; >>> >>> if (witness_watch == -1) >>> return (NULL); >>> mtx_lock_spin(&w_mtx); >>> lle = w_lock_list_free; >>> if (lle == NULL) { >> Looks to me like "out of required resources, cannot >> continue with the mode of use" code: an empty free >> list so no node is available to put to use to >> continue with the witness handling. > > Seems like a strange feature that simply gives up and goes away if the > system gets a bit busy. This system was running a poudriere build of > kde when the message appeared on the console. There was still plenty of > memory available so there must be some hard coded limit in there that > needs to be adjusted. I doubt that the kernel would take the point of view that it should be willing to take arbitrary amounts of the overall address space (RAM+SWAP) for itself. There is also the problem of needing to use the same facilities being monitored in order to do arbitrary memory management, risking deadlocks and such, for example. I normally do not use debug kernels for doing poudriere(-devel) bulk runs: it takes longer. And I got the witness notices historically unless the builds were small enough, indicating limiting of the checking. On the official package builders for main-* (So: that use a debug kernel) the builds are taking a lot longer than for the 134* and 142* builds that (apparently) use non-debug kernels. As of pkg 2.1.0+ , ampere2's main-arm64 went from taking about a week for pkg 2.0.6 to do a "bulk -c -a" to about 3 weeks for pkg 2.1.0+ being in use. (bapt is working n such issues.) The scale factor is not as large for 134* and 142* but is still notable. >>> witness_watch = -1; >>> mtx_unlock_spin(&w_mtx); >>> printf("%s: witness exhausted\n", __func__); >>> return (NULL); >>> } >>> w_lock_list_free = lle->ll_next; >>> mtx_unlock_spin(&w_mtx); >>> bzero(lle, sizeof(*lle)); >>> return (lle); >>> } >>> >>> Where it seems that indeed witness_watch has been flipped to -1 and that >>> functionality is now gone? >> Until the next boot, anyway. > > A fairly stange feature that is implemented by default if one merely > does a buildworld/buildkernel sequence with no adjustments. Witness is part of just debug kernels and main has the debug kernel by default. (I have both kernels but normally use the non-debug one.) main has a different kernel config available for building non-debug kernels. PkgBase actually supplies official kernel-NODEBUG kernels for main, not just debug ones, a first for FreeBSD to my knowledge. Again main's default is to use the debug kernel. But building from source is no longer required for using a non-debug main kernel. === Mark Millard marklmi at yahoo.com From nobody Tue May 20 20:13:15 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b25NQ0qKqz5vvfF for ; Tue, 20 May 2025 20:13:42 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2a01:4f9:c012:7a3f::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b25NP12cbz3Hw1; Tue, 20 May 2025 20:13:40 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ellael.org header.s=dkim header.b=094c9HWq; spf=pass (mx1.freebsd.org: domain of trashcan@ellael.org designates 2a01:4f9:c012:7a3f::1 as permitted sender) smtp.mailfrom=trashcan@ellael.org; dmarc=pass (policy=quarantine) header.from=ellael.org Received: from smtpclient.apple (p200300fb4f0232013807a69caff426c3.dip0.t-ipconnect.de [IPv6:2003:fb:4f02:3201:3807:a69c:aff4:26c3]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4b25N83vw2z1GQy; Tue, 20 May 2025 22:13:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1747772008; 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=Tq+bSnzubUNN5O3WtChGoJ+kY39tpt7X3dxt35x6T1s=; b=094c9HWqLfUcYX8RGKi5yC/+ffIVFKTdzRQKRCI+zA35uop3OSpeVyLABAzK16VkdtIIL9 reebczimYzDdCv59QoO+J2LxJIK1sKbhsJeSUdSM+bz+8UOuaKhxOw3YCTX5QkrAloQw+V q+1H/f8Mxci+aseJF6AeAvWAb2SnzA3hwIco+0m/7eVl+p+s94teGCuTCbM8BNfMWa4MuU +VIQ7MDAlN4wJwPjVf89sjB/2/3noAENajbo0TgrhBSsE5VOruKM5tacLSZc6WrTC7FzCO fOZ3Zg5ALiltOleNpRhSdTwyODqtin2h4ea8lribFceWVnS1/4iIsAUJZnUMPQ== 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 \(3826.600.51.1.1\)) Subject: Re: epair(4) From: Michael Grimm In-Reply-To: <47624B57-16CA-4141-9761-A51F9E3F4078@FreeBSD.org> Date: Tue, 20 May 2025 22:13:15 +0200 Cc: kp@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <75A8047F-73E0-467F-8005-7CA1ADA09788@ellael.org> References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <2D38F889-E8C9-49A9-AA80-D5A46FDFFD02@FreeBSD.org> <6e33a247-4b2a-4f7c-8e1f-14a549db27cd@plan-b.pwste.edu.pl> <47624B57-16CA-4141-9761-A51F9E3F4078@FreeBSD.org> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b25NP12cbz3Hw1 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; MV_CASE(0.50)[]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f9:c012:7a3f::1]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f9::/32, country:DE]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a01:4f9:c012:7a3f::1:from]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ellael.org:+] Kristof Provost wrote: > There=E2=80=99s no reason to ever assign IP addresses to member = interfaces. > Again, ifconfig bridge0 inet 192.0.2.1/24 is perfectly okay and will = continue to work. ifconfig bridge0 addm epair0a ; ifconfig epair0a inet = 192.0.2.1/24 is not. I have read all mails in this and the other thread's mails and I am = still puzzled by the wording: > The documentation has had this warning for a long time: =E2=80=9CIf = the bridge host needs an IP address, set it on the bridge interface, not = on the member interfaces.=E2=80=9C Das "member interfaces" *include* or *exclude* the corresponding epair0b = part? In https://docs.freebsd.org/en/books/handbook/jails/#creating-vnet-jail = I do find: | exec.start +=3D "/sbin/ifconfig ${epair}b ${ip} up"; I am following that document's way in setting up VNET jails, but I am = still uncertain if the upcoming changes will allow that regarding = ${epair}b? Regards, Michaek= From nobody Tue May 20 21:17:03 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b26nc6tSqz5w18Z for ; Tue, 20 May 2025 21:17:08 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Received: from g-cipher.net (leon.g-cipher.net [5.9.120.19]) (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 4b26nb45GPz3RGm for ; Tue, 20 May 2025 21:17:07 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of resin-freebsd@g-cipher.net designates 5.9.120.19 as permitted sender) smtp.mailfrom=resin-freebsd@g-cipher.net; dmarc=none Received: (qmail 60575 invoked from network); 20 May 2025 16:17:05 -0500 Received: from unknown (HELO ?192.168.7.176?) (resin@unknown) by g-cipher.net with ESMTPS (TLS_AES_128_GCM_SHA256 encrypted); 20 May 2025 16:17:05 -0500 Message-ID: Date: Tue, 20 May 2025 14:17:03 -0700 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 Content-Language: en-US From: Billiam Crashkopf Subject: Updating build and jail manual pages to include missing or obscure information To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4b26nb45GPz3RGm X-Spamd-Bar: / X-Spamd-Result: default: False [-0.65 / 15.00]; NEURAL_HAM_SHORT(-0.98)[-0.981]; NEURAL_SPAM_LONG(0.33)[0.328]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_SPAM_MEDIUM(0.10)[0.102]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:5.9.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[g-cipher.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] Hello all, I recently had a bit of trouble finding the proper make targets to build and install the base FreeBSD system from source into an empty directory for use in a jail.  I had scoured the build(7) manual trying to find the right workflow, but was unable to come up with a solution based solely on the information available. After some discussion on the forum it was discovered that the answer was in fact in the jail(8) manual, under the Examples section.  However, the make targets listed in the jail(8) manual are not documented in the build(7) manual.   I'd like to open a discussion around updating the documentation to make the correct information easier to find.  Specifically:   * Should the 'world' and 'distribution' targets, and examples of their use, be included in the build(7) manual?   * Is the workflow listed in the jail(8) manual currently correct?  Should it cross-reference the build(7) manual?  Is there a way to make the information more discoverable?   * Is it worth adding these instructions, or a reference to them, to the Handbook? For reference, the original discussion is here: https://forums.freebsd.org/threads/installing-world-into-an-empty-jail.97866/ My intent is to file PRs for any changes and, if it would be helpful, draft edits. Thanks, Bill From nobody Tue May 20 21:30:05 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b274f3xFxz5w1bX for ; Tue, 20 May 2025 21:30:10 +0000 (UTC) (envelope-from kp@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b274f2xGGz3ShB; Tue, 20 May 2025 21:30:10 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747776610; 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=QIZcSPFp14bDRT7uhB9BM4Syf017tRJkfRcYcNN7DGM=; b=Ot9Jfwf72ZFfLWOgaJGPgQ2xtyjczMNDS8VORgWWjyGIHakrmYOI5A83FkoVpMtp0YOlk6 vB5NJ1t6/OMoR5lTrSfXD83aBkicVxU4SLzZtiTOBM32CqF/9BUTyPrn8Tn4XOXPgdNRPb dqIOd14vCvFEDfVZnrQEvlXJjxmeIL8aZ+LV6mGU+O8Mrz6XrhrH6lk/77Q2qIk0ZQ7GVy ZKFBxQZVe9JdbRzmMD9xCtb60HQauGMcb0CUtN22/HM34IFKnypaM8G93twr+KWn3gX2kc OHv2HFUZi2PdXAqO8hhvCzjz6D6SJln+f8zoQZej2gOVia4YUlNK4BFXHGkA8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747776610; 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=QIZcSPFp14bDRT7uhB9BM4Syf017tRJkfRcYcNN7DGM=; b=l6iqNNodLdENxoqrEJbLeZkk1baTJWO2kIExmqCfNNTqyqNzDS332g+Hxx4Gm9gmrXhSdE YBKQD9TyN4NFggc3SQlje7uNXj/X3gTfDhSo7qCRrb4y0+V21WweGlipqk1hcohPYMAP3E KJf4EYz8hIR283VxN/krNFtZ7XS2zwWv5ZCGEHilbZ0tfbXbHVHiumI6vy9q5G43wjr4Il Ov0Rcn+ossoMDiRa4Eejn/PDOyiDiKbNjeHscQIgcDP9taYuTg/96guL8Vw4Odj1US967G pbqNPjI4dmqUVNCNLuymwqdkC6Gy9EOqa7W4vYZEzraXlq6k/E5DehpIGfXNGA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747776610; a=rsa-sha256; cv=none; b=j1bQsNM1rIBV8RLGXMaoYLLXZluIVuUW47OWwQx+Z5o7pHaoQ10FV8U0o1qP/ozT83h9rL O/pc4PGF6npMxy5J1l2S0EY1ljmHp9+HT22WjLPTTET9PKchLS7QSyyE5qHsTT+ezT1eW2 iA3PXQuxcBe62cFTRF30h0kxHKFIaCTFC5pzwWeXWFtI0j+Pc2dynjGnMs+2yd7i3qekmN qQeFW7S76A50BFolOhe1jxjn8xQ7/ZYhq37wXZ5I6vN2fimZ0w1Rxlq3RyJAJpGIUcZ5OK rG71Knz5VAboae8k4s7ofSuznt1rh+LAFfHN9VPsCVaW1VyB5YgqwwUGLLtoYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b274f1ThSz1D8d; Tue, 20 May 2025 21:30:10 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 01500B99C; Tue, 20 May 2025 23:30:07 +0200 (CEST) From: Kristof Provost To: Michael Grimm Cc: freebsd-current@freebsd.org Subject: Re: epair(4) Date: Tue, 20 May 2025 23:30:05 +0200 X-Mailer: MailMate (2.0r6255) Message-ID: <369F5F7C-F88E-4C92-9DE0-C0FB0E5EFD54@FreeBSD.org> In-Reply-To: <75A8047F-73E0-467F-8005-7CA1ADA09788@ellael.org> References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <2D38F889-E8C9-49A9-AA80-D5A46FDFFD02@FreeBSD.org> <6e33a247-4b2a-4f7c-8e1f-14a549db27cd@plan-b.pwste.edu.pl> <47624B57-16CA-4141-9761-A51F9E3F4078@FreeBSD.org> <75A8047F-73E0-467F-8005-7CA1ADA09788@ellael.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_CD2C9C5C-7B36-4434-9ABE-6FF3D5AF724F_=" Content-Transfer-Encoding: 8bit --=_MailMate_CD2C9C5C-7B36-4434-9ABE-6FF3D5AF724F_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 20 May 2025, at 22:13, Michael Grimm wrote: > Kristof Provost wrote: > >> There’s no reason to ever assign IP addresses to member interfaces. > >> Again, ifconfig bridge0 inet 192.0.2.1/24 is perfectly okay and will >> continue to work. ifconfig bridge0 addm epair0a ; ifconfig epair0a >> inet 192.0.2.1/24 is not. > > I have read all mails in this and the other thread's mails and I am > still puzzled by the wording: > >> The documentation has had this warning for a long time: “If the >> bridge host needs an IP address, set it on the bridge interface, not >> on the member interfaces.“ > > Das "member interfaces" *include* or *exclude* the corresponding > epair0b part? > It does not. Typically you’d insert epair0b in a different vnet, but either way, it is not a member interface of the bridge, so it can have IP addresses assigned to it. — Kristof --=_MailMate_CD2C9C5C-7B36-4434-9ABE-6FF3D5AF724F_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 20 May 2025, at 22:13, Michael Grimm wrote:

Kristof Provost kp@free= bsd.org wrote:

There=E2=80=99s no reason to ever assign IP addresses to = member interfaces.

Again, ifconfig bridge0 inet 192.0.2.1/24 is perfectly ok= ay and will continue to work. ifconfig bridge0 addm epair0a ; ifconfig ep= air0a inet 192.0.2.1/24 is not.

I have read all mails in this and the other thread's mail= s and I am still puzzled by the wording:

The documentation has had this warning for a long time: =E2= =80=9CIf the bridge host needs an IP address, set it on the bridge interf= ace, not on the member interfaces.=E2=80=9C

Das "member interfaces" include or exclude the corresponding epair0b part?

It does not. Typically you=E2=80=99d insert epair0b in a = different vnet, but either way, it is not a member interface of the bridg= e, so it can have IP addresses assigned to it.

=E2=80=94
Kristof

--=_MailMate_CD2C9C5C-7B36-4434-9ABE-6FF3D5AF724F_=-- From nobody Tue May 20 21:45:23 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b27QZ3sz0z5w2Rt for ; Tue, 20 May 2025 21:45:42 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2a01:4f9:c012:7a3f::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b27QZ0shmz3VpL; Tue, 20 May 2025 21:45:41 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (p200300fb4f0232013807a69caff426c3.dip0.t-ipconnect.de [IPv6:2003:fb:4f02:3201:3807:a69c:aff4:26c3]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4b27QP70HQz1JTD; Tue, 20 May 2025 23:45:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1747777534; 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=IfT0ZU817OGJYDdGzlyp4kzKQyAZ1IVJM5jZMtCJHoU=; b=FErImobhq1YCFCtsZXD5ij93GX4+bWbXqA8w60e/wZo4xSEEpaC/+CdT7dnIVEG4IDQSmf yLKKbVL/uLxxPshCZHcZbdnszHWAPZMzM8E/eHjJAAgKx8nQPW8VnMB9LB80iD7gvDuO7t 8YGGgZl+ToGjDmxvBjP01izk7NF6FGifFa0eWdk7KWQrxFwWqzCUkXK8kD2UcE6zJs7Kq2 nMegsSmnFFHTuFEibVKejjT7RLYvv34DdYYvJn6WPnJW1Eguv1mseIEemVXPmSi/+/tApr /7bTQuYmg8iio7eMK+4LXXpVeJ5VOrw4NbhAChqEMTKlYoiYem2188GMifPtkg== 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 \(3826.600.51.1.1\)) Subject: Re: epair(4) From: Michael Grimm In-Reply-To: <369F5F7C-F88E-4C92-9DE0-C0FB0E5EFD54@FreeBSD.org> Date: Tue, 20 May 2025 23:45:23 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <43BAB886-2553-4EFE-9341-660F4D209B10@ellael.org> References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <2D38F889-E8C9-49A9-AA80-D5A46FDFFD02@FreeBSD.org> <6e33a247-4b2a-4f7c-8e1f-14a549db27cd@plan-b.pwste.edu.pl> <47624B57-16CA-4141-9761-A51F9E3F4078@FreeBSD.org> <75A8047F-73E0-467F-8005-7CA1ADA09788@ellael.org> <369F5F7C-F88E-4C92-9DE0-C0FB0E5EFD54@FreeBSD.org> To: Kristof Provost X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b27QZ0shmz3VpL 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:24940, ipnet:2a01:4f9::/32, country:DE] X-Spamd-Bar: ---- Kristof Provost wrote: > On 20 May 2025, at 22:13, Michael Grimm wrote: >> Does "member interfaces" include or exclude the corresponding epair0b = part? > It does not. Typically you=E2=80=99d insert epair0b in a different = vnet, but either way, it is not a member interface of the bridge, so it = can have IP addresses assigned to it. Thanks for the clarification and regards, Michael= From nobody Tue May 20 22:30:24 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b28QD4b5dz5w5Rn for ; Tue, 20 May 2025 22:30:28 +0000 (UTC) (envelope-from ivy@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b28QD3vt2z3ZgN; Tue, 20 May 2025 22:30:28 +0000 (UTC) (envelope-from ivy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747780228; 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=n8FbVyo9K+4hUGVcXnIWuta8TIfIphZPTqDS4v76EkQ=; b=ukAogaPJC7VSsky/UmlFedyaZERdr8vfDUs5IbQUo7irITqaxg2rDVNZtmA8latnI/wFma 3FxtuH7bW4lGgvOB04LNlICKGptnj2Q0G8KwFkrNmw0CypNaFNmAHBMQAHCGAIJSwb+kFU +xiRJbkbMJdaof9LgU/uN3//vXRbr8zV/CYg8ke9hQyldT458xVfEdZFmYexp7EWHFQvFV lPEn7KUcVxeG3MZgbC2q/fOwpgSmQJmAPLHO7QzwdOIXPKe6l8yEBJ276V/6MpDAMSha9/ DdccNHTpQGqFpwDOYl8QrHtdAnbUQ7WoE9yJ2PFdP0UInEg7MbN+FF0tYgeEzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747780228; 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=n8FbVyo9K+4hUGVcXnIWuta8TIfIphZPTqDS4v76EkQ=; b=lV2QU3vqMbNapDmslf5nlRzVwMzUfxvKrUpZvUFxekGlxR3TQMeWf3umIv+vjtm7ErBMHJ 6bCUWk3//M2NnqPiTHAHw4F0UFhpzpAFFvlOfNR37R2/DCzfyLvW6DomjkIWQb+xt5pjXs UJSaNWoefmaaiJlxLa/CrPYZyfCGdu0B0VXp9+uBhBLa7OycaUjjqUKHzZmfWDoH818pU6 jUv8WS+NBnuq1Mi2wSiri+0x8acqXdvXUKKl8aj5ze+/0TV0lgLT2DyZP2XH6CfShTeW1n Zja2Q/zOhbUc4qbl0nRmB4JoZtx/HU9bIleP2upZ0cxqDvCi2T05FyrbpQnsQw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747780228; a=rsa-sha256; cv=none; b=c/PgLvzxMxGVhevyGgelRCsluqsDEsrDVdOutyqtQ26hrPMpyORHOKBNNVEl6MtBkV97jA adRj3ku5+CddknfqgySg+W4R0uUvtBy5hZFt8aha+bbO7TlPKONEG8HdWY3x8wbaCy0rC9 hDfQt93V2kzYzHWY9VmGrgO2VHn2iBaUFX7xqINi9wbWb8Vh3SFYc8jwT+Rfee5X3YZZ2U vkzHv5obVL+mN4j+v4wnAaSnpNMC7fg2EjQA/XHRGZwmeoc9SgONVVWGoCvyqYEqEoyXfP FyFQ15hcXqwWRglO00LTdCiygDOEnMMyhIx8yndAlqeJYRfFYi6u/0YSvBUwWA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ragweed.eden.le-fay.org (ragweed.eden.le-fay.org [IPv6:2001:8b0:aab5:c401:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b28QC5T4wz1FCJ; Tue, 20 May 2025 22:30:27 +0000 (UTC) (envelope-from ivy@FreeBSD.org) Date: Tue, 20 May 2025 23:30:24 +0100 From: Lexi Winter To: A FreeBSD User Cc: "Patrick M. Hausen" , Kristof Provost , Marek Zarychta , Alexander Leidinger , rgrimes@freebsd.org, FreeBSD CURRENT Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument Message-ID: Mail-Followup-To: A FreeBSD User , "Patrick M. Hausen" , Kristof Provost , Marek Zarychta , Alexander Leidinger , rgrimes@freebsd.org, FreeBSD CURRENT References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> <20250520112428.3de8301e@thor.sb211.local> 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-sha512; protocol="application/pgp-signature"; boundary="BkF1TdKdAQgHgnAJ" Content-Disposition: inline In-Reply-To: <20250520112428.3de8301e@thor.sb211.local> --BkF1TdKdAQgHgnAJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A FreeBSD User: > I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I > simply used=20 >=20 > rtsold_flags=3D"-iu igb0" >=20 > within /etc/rc.conf. Changing this line to > rtsold_flags=3D"-iu bridge0" while bridge0 is up and running doesn't work= , neither does "rtsol > bridge0" show any results. unfortunately, i cannot reproduce this. test1# ifconfig bridge0 create test1# ifconfig bridge0 inet6 -ifdisabled auto_linklocal accept_rtadv addm = epair2b up test1# rtsol bridge0 test1# ifconfig bridge0 bridge0: flags=3D1008843 m= etric 0 mtu 1500 options=3D0 ether ea:1f:5d:1b:70:9d inet6 fe80::e81f:5dff:fe1b:709d%bridge0/64 scopeid 0xc inet6 2001:db8:100:0:e81f:5dff:fe1b:709d/64 autoconf pltime 604800 vltime = 2592000 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: epair2b flags=3D143 ifmaxaddr 0 port 11 priority 128 path cost 2000 groups: bridge nd6 options=3D23 test1# note that there is an existing, unrelated bug[0] where the bridge will not correctly set auto_linklocal and accept_rtadv by default, so you need to do this explicitly. if that isn't the issue, can you please show the output of=20 % ifconfig bridge0 prior to running rtsol? also, i understand from your other post that you need a specific MAC address on the bridge to get the right SLAAC IP address. in that case, you will need to either change the lladdr of the bridge, or set net.link.bridge.inherit_mac=3D1 to make the bridge inherit the address of the first member. [0] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254445 --BkF1TdKdAQgHgnAJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaC0CfwAKCRD1nT63mIK/ YA2aAQDyo+qBmzR+014D1RoyftQwb3ZorvFh6hPDLGufTXx7JwEAqz51Onx77uzf jWNAvgCeNtGVvUMgkOGmxrTh8ZsgPQc= =BU8i -----END PGP SIGNATURE----- --BkF1TdKdAQgHgnAJ-- From nobody Wed May 21 07:22:29 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2NDJ1zfSz5wyfn for ; Wed, 21 May 2025 07:22:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4b2NDG4Z91z3D8m for ; Wed, 21 May 2025 07:22:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk; dmarc=none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id B40E9B0A1A for ; Wed, 21 May 2025 07:22:29 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 54L7MTqw025632; Wed, 21 May 2025 07:22:29 GMT (envelope-from phk) Message-Id: <202505210722.54L7MTqw025632@critter.freebsd.dk> To: FreeBSD CURRENT Subject: Un-sucking EINVAL (was: ip# on bridge members) In-reply-to: From: "Poul-Henning Kamp" 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: <25630.1747812149.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 21 May 2025 07:22:29 +0000 X-Rspamd-Queue-Id: 4b2NDG4Z91z3D8m X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.67 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.67)[-0.672]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[phk]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.dk]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[] The ip# on bridge member interfaces is yet another example of why "EINVAL" is the undisputedly least helpful errno of them all. The laconic "Invalid argument" leaves both the userland programmer and the user to guess what might be wrong. That's ok-ish for read(2) where the possibilities are so few that the manpage can tell you what you did wrong. It breaks down totally for ioctl(2), setsockopt(2) and similar syscalls which can attempt very, complex operations with many parameters and subparameters. Ifconfig(8) is ground zero for this and the manpage is not even trying: DIAGNOSTICS Messages indicating the specified interface does not exist, the requ= ested address is unknown, or the user is not privileged and tried to alter= an interface's configuration. We should give errno a text-partner, so kernel code can: if (p->n_mazel-vanes < 6 * p->n_dingle_arms) { error_text("Too few mazel-vanes per dingle-arm (min: 6)"); return (EINVAL) } The err(3) family of functions should retrieve the string, and when there is one, print it as part of the error message: Invalid argument: Too few mazel-vanes per dingle-arm (min: 6) -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Wed May 21 07:28:39 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2NMM0bRJz5x0BS for ; Wed, 21 May 2025 07:28:47 +0000 (UTC) (envelope-from ivy@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2NML730Xz3FTw; Wed, 21 May 2025 07:28:46 +0000 (UTC) (envelope-from ivy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747812527; 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=5YXbY+cqrz3R6Cww86ysE8b1REPg2G8eKMsRVbjXEak=; b=G/R9s9r6CFGCIk5CSLvjMYDu2+niIpUdPg2dXFTQYaZ9HVOthQ5W47jc2jyDAJS7KHqxii wqntXHuWi80Tji630g7tJeGEioKFhM0oNeJ85PITk8axG6VPtBWOA9gJpKbZw7Wn3cZbd/ WHCXUOPzNcuNG/gUe0I6QaC5gWpkIRtaFO5M0cT3h1Ewen0MKUTMo6APIrVm45uc1RHNgt Pvx0BQM3u1cShe1Xzce3gW+2FkEE2YMrHbRF2N5QDc3q6uP9iWc0yo4ov90sR7AjOHf0lS ZMs7rS5hSfCYvIt4GEISWciaDgTEeQ76fVZV5nH+rlv1vHgypjbc9nywMqNTwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747812527; 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=5YXbY+cqrz3R6Cww86ysE8b1REPg2G8eKMsRVbjXEak=; b=H+D+qHoLDzLw+bYAGsNpClppH1LwO+UNRONWNB0gkIWezFkjAdiaNsFTVI6ZfSGgwWMH5z BI8ul6LjkoXsPv+RzYV33DnyE6XTqc03RvP1SxiTb5K/lsa8MrdKTUZUw3Th7pEDTqq6ZS hePwQqplLB8PWfICGFqHjB2V/NZvHFVIJEoGGkysbXce3m7Rs4a0HsG3VTz2HFT8GXIzI5 QTOXfb1SY9b+z3desRxJSSWR0RgT8kZIkhKWSOqIiJV5XJfNnhcxGvGFlg/wRjhK8LIbWP 1wDIK3EcqRw2nKYNEfk0+4ETMY6wYFOv0tDcOiBGp6obrokdMoqZ80EHI2Yfew== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747812527; a=rsa-sha256; cv=none; b=SqhW1UuAG3LVYhI5taFyg7/5WcAb1MP7P5bcyCQsXZdySFZ315ZDEPSpYizWdq2eMIkmt1 JCXs0qjFd/LWjjHHtue2cU7uK72MmNVXNNv4Jq+xM4hMP4jgW0su0mOBKyjEY2pl+SUkoQ u0213BJNhn8sZlTAgm/snrJUm6D7BBJ4qtIZRjpaNPxc0vwhuj5rFjz77O7vd6c1wga69v tAtoT3vAGfRqLPTMgfABLhh5CkQPPAFFOn4nHTQ7OdS0O46qN3gecjygu7DG2T3+rMV1Jt TjJONZcDFtc2Y3nLTB2Y3Y0YyR1F6HMA+YYDFKiEidIlGqOdBnCk9Ocyii69xg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ragweed.eden.le-fay.org (ragweed.eden.le-fay.org [IPv6:2001:8b0:aab5:c401:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2NML4Bzxz1R0C; Wed, 21 May 2025 07:28:46 +0000 (UTC) (envelope-from ivy@FreeBSD.org) Date: Wed, 21 May 2025 08:28:39 +0100 From: Lexi Winter To: Poul-Henning Kamp Cc: FreeBSD CURRENT Subject: Re: Un-sucking EINVAL (was: ip# on bridge members) Message-ID: Mail-Followup-To: Poul-Henning Kamp , FreeBSD CURRENT References: <202505210722.54L7MTqw025632@critter.freebsd.dk> 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-sha512; protocol="application/pgp-signature"; boundary="M9e22UoTRQ4GPw55" Content-Disposition: inline In-Reply-To: <202505210722.54L7MTqw025632@critter.freebsd.dk> --M9e22UoTRQ4GPw55 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Poul-Henning Kamp: > The ip# on bridge member interfaces is yet another example of why > "EINVAL" is the undisputedly least helpful errno of them all. >=20 > The laconic "Invalid argument" leaves both the userland programmer > and the user to guess what might be wrong. =20 you are completely right. since we (for some reason, that i don't really understand) can't add new error codes to errno, we should stop using errno to indicate errors except where POSIX requires this. > We should give errno a text-partner, so kernel code can: i am open to other solutions here, but i intend to convert bridge(4) to use netlink for configuration, which allows us to return a real error message that ifconfig can print. --M9e22UoTRQ4GPw55 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaC2ApgAKCRD1nT63mIK/ YIARAP9oelK6+Xlbz+fnIq2gTtdMP/FbBh/fKw1vbw40tiScRgEA/OUPD1Brui6E Epstclm9GLBwQdgTUa6NcCiGZTPa/A4= =I8Zl -----END PGP SIGNATURE----- --M9e22UoTRQ4GPw55-- From nobody Wed May 21 07:59:36 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2P3B5DJvz5x1hN for ; Wed, 21 May 2025 07:59:50 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2P395r6xz3NGp for ; Wed, 21 May 2025 07:59:49 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 54L7xbdW027225; Wed, 21 May 2025 00:59:43 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1747814383; x=1747814983; r=y; bh=nRK8/c9jXKMxDQflN8AtLLXO0+1BwHLX3ui/1hcdpUA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=sg2V0GoBwq1pmWvQ1yuUKC+fvfbVSVxKlB5RWV0hNSA1dJ9jxMNb4QjrLtnB5gOQw vrkFN8BPR8stXZfQwJ8mskYsuXx3ituX8GHH2VVSkTv3twB6JdMYpqc6VA6e3RGl4F zAlF40+HVOlksVVL3zGgKBgXS7awLuppzlCgCLvgaiJ2dxTmLQVMrR6Jj96K2c/18Y UJLJstRTokJx8TQyAjh59y1a63OyDQsLmieYwG4qNrZd7hzzpyjRX7PhNAraBl8N/q F4ofdM+frPLAxBpo6QKiYSnUr/lL6untRJRlROWUCtUXvFY6RMHuVwGkhDtF10/2SN afpQcVocV+fzQ== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Wed, 21 May 2025 00:59:36 -0700 From: Chris To: Poul-Henning Kamp Cc: FreeBSD CURRENT Subject: Re: Un-sucking EINVAL In-Reply-To: <202505210722.54L7MTqw025632@critter.freebsd.dk> References: <202505210722.54L7MTqw025632@critter.freebsd.dk> User-Agent: UDNSMS/17.0 Message-ID: <40af90b227e3ca280d0ec8ff4f7066f2@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_5f4f776de72539acb5e7503719c86191" X-Rspamd-Queue-Id: 4b2P395r6xz3NGp 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:11404, ipnet:24.113.0.0/16, country:US] X-Spamd-Bar: ---- --=_5f4f776de72539acb5e7503719c86191 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2025-05-21 00:22, Poul-Henning Kamp wrote: > The ip# on bridge member interfaces is yet another example of why > "EINVAL" is the undisputedly least helpful errno of them all. > > The laconic "Invalid argument" leaves both the userland programmer > and the user to guess what might be wrong. > > That's ok-ish for read(2) where the possibilities are so few that > the manpage can tell you what you did wrong. > > It breaks down totally for ioctl(2), setsockopt(2) and similar > syscalls which can attempt very, complex operations with many > parameters and subparameters. > > Ifconfig(8) is ground zero for this and the manpage is not even trying: > > DIAGNOSTICS > Messages indicating the specified interface does not exist, the > requested > address is unknown, or the user is not privileged and tried to alter > an > interface's configuration. > > We should give errno a text-partner, so kernel code can: > > if (p->n_mazel-vanes < 6 * p->n_dingle_arms) { > error_text("Too few mazel-vanes per dingle-arm (min: 6)"); > return (EINVAL) > } > > The err(3) family of functions should retrieve the string, and when there > is one, print it as part of the error message: > > Invalid argument: Too few mazel-vanes per dingle-arm (min: 6) Thank you for addressing this. This has been an itch I've been dying too scratch for years. But there's always been something shinier in front of me. My first target was "network error". ie; couldn't do that; network error. That's the default for nearly *any* network error. Drives me nuts. Is it better to place them directly with the function, or would a numbered index be better? Using a linked list of numbers to error messages. Thanks again. -- sent from hardware written from and running on FreeBSD --=_5f4f776de72539acb5e7503719c86191 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_5f4f776de72539acb5e7503719c86191-- From nobody Wed May 21 14:00:13 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2Y345jKWz5vxlN for ; Wed, 21 May 2025 14:00:16 +0000 (UTC) (envelope-from garga@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2Y3451tfz3NtD for ; Wed, 21 May 2025 14:00:16 +0000 (UTC) (envelope-from garga@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747836016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=stXq1mT+ctDZoUWN9c1EFJi6SbfbDq6g6tOnr/bi83w=; b=M5R8nNOd2ZoFCRAPLRMH0HnvARRpcoO8DCL+NjQemVjOAmoXZLOQZABzCGPCW3O0kvmfpz t8C9XaJNbcGuCezCvUenDgDNRIISPnhcJ5+waQsE2qyJY+K3VbXnuHyKDkSaHlTMT9I4dt G/yvco+kXvTEpqwnXxiVv+80NpnyasP9vhEWlUE+ZH/CcPbEZ+rxxrbQiGl2EqU93AUhXk x1TWQ8GYwnMueoVZIbikZsUpsB/n6TSgVWp48wNvAc5oDiRp63IWs55GDphuek+C9iShgR 7ftEms64BakAbhIOqWXY+SZYMeLU04wEJaoiwFQHqRs7jA1iX2QcituW6nh9cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747836016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=stXq1mT+ctDZoUWN9c1EFJi6SbfbDq6g6tOnr/bi83w=; b=TUta+1GM5AVxqDWfCcKDPYf1v+RD5CU3d0UI5pov5UQS2GgQ2kF1IV6lL6nNcxxl/dSd3O 24r7cc73pvIODKP5Mix03xZ0rSGY5nqqVtwCj+Lx55zdfZdbZzaCIa6zXYHY9Vx+MbvLjT jjfhMJOkjY8eumBcRGpfjIGvJFjLiGWR81/68CsaFqrj8FDbC/KZPfAzmRiant94bPdXDn 8933FdHOXoxKKcb3Z3kpiEEzL6ACixZA2lN21w/4JcCOUlpGBodGfU8tWN69Me4bXqgU+i JVUllL9zzFm/emVT5bhZx2JUsp0Hxn5uzTllc8Ln8PQLE6Ivt5Hhj5k//DBEtg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747836016; a=rsa-sha256; cv=none; b=pK/oPn6HNgYvbButZZW+XkTqpYsQV/EY4XaN5knhx5jYKwcIXl8QIVl6sEwDpZAqAuIM03 PYbTsANblwFuA62ZWJMBUjq5Gsbpmc2LnVB90pZaUmm9WVWOXkxW3eCs+J0/AV1mXcZFxs ejsTTKdeW/dWhbRrtRn5vRQJD4qBMBNJV/WNgPlfSmI7xcXnJy4wMHL0qoNJD6OOEMXCJT NMk6irXdgGveez+gyGXF274eWyNEO21NOw1AwNRC78DVXF4u75vjQ2YmUPijIofn+KDMsQ ZTJSxGQCKuMroMqTqY20IY03FT10Xxb3esoLFiCRTASLeWvOj/k3uGRABzt0MQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2804:f1c:3c:b01:cd55:904c:d339:c978] (unknown [IPv6:2804:f1c:3c:b01:cd55:904c:d339:c978]) (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: garga) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2Y341k8Kz485 for ; Wed, 21 May 2025 14:00:16 +0000 (UTC) (envelope-from garga@FreeBSD.org) Message-ID: Date: Wed, 21 May 2025 11:00:13 -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: lid state stop changing after suspend/resume From: Renato Botelho To: Current FreeBSD References: <7c6bea8b-b16f-41a0-88d1-65d9980bc378@FreeBSD.org> Content-Language: en-US Autocrypt: addr=garga@FreeBSD.org; keydata= xsBNBGStavwBCACjNlp/9+Y+VFe9ieR2h/WWbdvjz4Mb2z/f22bGoaskzCfvVNbo/v3i34I9 H6OdgZkGqheQEAD2jNfRbmPr4z40xDMUpYGLds+1Mvg7G3Hms3j5Ef8KaLSWUNWIfwKdfSVR Qs35ccSJxAdRW5YdI6J3xZgika+3Bc4eJ05YE/nWW+PNTYevt5rqD50N3zybVYIcLoqVPpBi AZE/sf5SLiLACIJb1t/s4x+pi8vgWevxVVT9u8V1f8zYErmHSLSqjxii0B3eRZphX9NCJOv9 +tfFZhnENInhn9gT7H4e2YumUltEy3jacONHJF3CC1pvvWEa6lEyypclMOkHQwNON7DLABEB AAHNLFJlbmF0byBCb3RlbGhvIChGcmVlQlNEKSA8Z2FyZ2FARnJlZUJTRC5vcmc+wsCXBBMB CgBBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAFiEERL7Dxegbnh7xTiQ5Ob6P xxJcZXoFAmSta78CGQEACgkQOb6PxxJcZXrYlggAgaZmr6c1yIWzN8VksHrHpwt/uxONEP+h ljy3yfrMsgfS5wx5Uzgfih1xYZUFC6jiI63CetqBqJpp3g1klRS1UWYKx2NeXphDMYZEdPm/ a6sXh4bKZbk6IE8Yn0/YiRT57d9DtbvswC7Gn7Igj/MSbhl49TvTGyvuB6juaffVoYZViomx 5zMoee8Ml2o2qj3MrCJ+/K8GU54RlpOGqGRsqdwVdr9XEWub6fF2YFwR46cjmbiU3P5urFHH nkJlBGPIwKxHimTW0lZsdx9aCKRDd/D80/WOEzXmk3k8B9lv/GsvOluHmveLhJG1R1tIJ31I f2q8dfTvqsQXnu8CcWRcgc7ATQRkrWr8AQgA1DufoxScA+CWQbUR6zExIu8wXQKrhuRt4DG2 BgynT7EMUvEBadcbQRZXsBpemNfncc9Axyut/+rWiyKJf9BLQuo/9QYmSRvW1U6+0LJUYmdg kMyBeYaPk+vnssv/u9jLuvV7FVgyE0yk1iaWIKOVDD+XrQCOvGw9uSceBrQyCyo3A/eRM/+p vnDCaywR63PKE+3axk6lfNdGK3TnaWmS30/ZDCZlNsXuqprqR4JdT5wXids5o36dsuJ5EZ20 s5hNMD34s4Yr1Y1R9elH6qBsFCpozs0+jwrArxq+UJJCR6hH5W8ZEwJtRC8tzR8mRE1WywzX BXYj0YhfGztQIxZckQARAQABwsB8BBgBCgAmFiEERL7Dxegbnh7xTiQ5Ob6PxxJcZXoFAmSt avwCGwwFCQWjmoAACgkQOb6PxxJcZXr1vgf/SKXhoZcUU5I7TqcbHg0lJz9tICTupCGHWr/s SQgjh9oEM5j1wqW7FlCGP90Tl9K0g3ow9YdbhU7VK470o6pymX9V9eLHzGgkZO/KMEtGBeK1 u+5ePjCJ/MK5B21KODLSU7WrIL1VN5ceXfQPLYt02LMLtPri+oduHD6RNBeA7US1DUzleq5F 9NHGbvV2U7BdDUezpiO8NaFjFZVB11I5d99FxUM5XGVstI3VhsRKZxjY0KnqJzaQgTFsPGmv AUfZVIN1pXgXiedhPXpr8+Y64jP+pHVwpVmh1zYWL6+q3kqFOUVP6c5iiMeoEXZvgJz7x/AC ek3X5gvu8Hpcv+MZIg== In-Reply-To: <7c6bea8b-b16f-41a0-88d1-65d9980bc378@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 19/05/25 11:33, Renato Botelho wrote: > Hello! > > I have a ThinkPad E14 2nd gen and recenly installed FreeBSD 15-CURRENT > on it.  I noticed a problem with lid state not changing and started to > collect more information about it.  Here is what I got. > > I changed hw.acpi.lid_switch_state to none so the laptop doesn't sleep > when I open/close the lid and after booting it I can see the sysctl > dev.acpi_lid.0.state changing to 0 and back to 1 when I close/open the > lid.  It works just like it's expected. > > Then I put the system to sleep using `acpiconf -s 3` and resumed it. > After that, dev.acpi_lid.0.state doesn't change anymore to 0 when I > close the lid, it keeps its value as 1 until the next boot. > > I've updated BIOS to most recent version provided by Lenovo (1.64) and > configured sleep to the value `Linux S3` on BIOS setup utility. > > Attached you can see a full dmesg output.  If you need any other data > just let me know. I've created a bugzilla ticket to track this and attached acpidump -dt output. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286974 -- Renato Botelho From nobody Wed May 21 14:40:31 2025 X-Original-To: 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 4b2Yxd2HmRz5w1TT; Wed, 21 May 2025 14:40:37 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (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 4b2Yxb2CzHz3f8J; Wed, 21 May 2025 14:40:35 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=mkjSsRdi; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=sWyp2wWM; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.152 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 0323A114017F; Wed, 21 May 2025 10:40:34 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Wed, 21 May 2025 10:40:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1747838433; x=1747924833; bh=4o2529X8Lu rALBQdE5/PV1xu20kYxjPYAGBzIXIVVbE=; b=mkjSsRdioBv8iulFa9IdN5UIGT HwfC5Y89SOAFHsXjVl9/eYO+qsnwshP+slrU/DKw0c+URn1unfgMmAoXVHijUP5H PCRiV73inNXuLI5d2eIvpJKY5RcQ5ciZlwcUI4ts5bq9Y5yf0LDQEiHII/iDiTjq GyxX7WPzwBU1ovM8YqdjDhpk3j35ywBfbGhFsF1DiQeHWrqc2dr9ap7acjj5yGSj 6Tg2LFrCQkQFfenXrvDdOax3w+bMfCM92NV1DqDrIdphfsSlEvRbnMsIROIzPR6a 9pQhEeY9oy+dgR9S7Qmje7RJ0SSqutEdSO491XDvy3G3MUsESB6VdjERHIIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747838433; x=1747924833; bh=4o2529X8LurALBQdE5/PV1xu20kYxjPYAGB zIXIVVbE=; b=sWyp2wWMl79NqEQtbMhKYoBU7qxnS6ZyXLfaxQB9U0n2VG9xLnJ E+hE0OHZKz/7LX9G/UFh86JpCncw/UcOSskg816t6VsIs4Qvq8bY6OwNUpduYTsv 65Ehzp1Gse4yk+ZTtK/uRm3fkoA6IKINmaDK8R26dOHyr/M40/l3aoxWOl6zqrjf meOHBLu9GLtfojFhHlwuNks9k/qhLetXA2qZuPlbsIBbGzMNWOYj8NDEayM9jnIC 9ndtiYdbGwYLQgt9bkWS30Qc2DbtIYi5oHw9cZHnrtKr6o/nsXSSrBY6kpXcIvVQ /6/MXOet8nvtVz+ww659ayk59I7+0YHxTgg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdeffeehucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpehv ohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgvrhhnpeeggfehhfejje ekteeufeehfefhgeejgfeliedvhedvffffhffgiedtvddtgfehueenucffohhmrghinhep fhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehvohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopeefpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopehfrhgvvggsshguqdhnvghtsehfrhgvvggssh gurdhorhhgpdhrtghpthhtoheptghurhhrvghnthesfhhrvggvsghsugdrohhrghdprhgt phhtthhopehnvghtsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 21 May 2025 10:40:33 -0400 (EDT) Date: Wed, 21 May 2025 15:40:31 +0100 From: void To: freebsd-net@freebsd.org Cc: current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: 15.0-CURRENT, =?utf-8?Q?chan?= =?utf-8?Q?ge_to_bridge=284=29_might_break_some_network_configurations_wit?= =?utf-8?B?aCDigJxJbnZhbGlkIGFyZ3VtZW504oCd?= Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4b2Yxb2CzHz3f8J X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.924]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[103.168.172.152:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.152:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; MLMMJ_DEST(0.00)[current@freebsd.org,freebsd-net@freebsd.org,net@freebsd.org]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote: >although it's possible everyone who is affected by this is already aware >of the change, i thought i should send a heads up anyway, if only to >have a single place to discuss this (since there was quite a lot of >discussion). > >in short, following this commit... > >b61850c4e6f "bridge(4): default net.link.bridge.member_ifaddrs to false" >https://cgit.freebsd.org/src/commit/?id=b61850c4e6f6b0f21b36da7238db969d9090309e > >...it is now impossible to use a network interface which has an IP >address assigned to it as a bridge member, or to configure an IP >address on an interface which is a member of a bridge. Hi, for the sake of clarity, when you say "IP addresses assigned to it as a bridge member", do you mean assigned via eg rc.conf on the host, or assigned, for example within a VM, or assigned within a bridge statement? [1] I have a machine with 2x NICs with static ips assigned in the usual way in rc.conf. They are also bridge members (they have to be otherwise the tap interfaces on the bhyve VMs wouldn't work) Within each vm the interfaces are assigned either static or dynamic IPs. I don't use vm-bhyve. Do I need to worry? [2] [1] example - /etc/rc.conf snippet on the bhyve host ifconfig_bge1="inet REDACTED.REAL.IP netmask 255.255.255.248 mtu 1500 media 1000baseT mediaopt full-duplex,master" defaultrouter="REDACTED.REAL.GATEWAY" ifconfig_bge1_ipv6="inet6 accept_rtadv" # # ifconfig_bridge1="addm bge1 addm tap10 addm tap11 addm tap12 \ addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm tap19" # [2] because here bge1 has an ip addigned to it and is a bridge member -- From nobody Wed May 21 14:44:46 2025 X-Original-To: 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 4b2Z2X1rmmz5w1SV; Wed, 21 May 2025 14:44:52 +0000 (UTC) (envelope-from kp@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2Z2X19Jlz3j8b; Wed, 21 May 2025 14:44:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747838692; 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=VLM+lwDKwLXECLV+bvl/RH20iIJvIJ4vAKoVDOVsAWU=; b=C+GvPgBq2RFKtYcyXHabvzEhTl2xl9N2folYhpPo4DfRiTau3IYUMNMZZx6C1TS0bilJxt LnGRNWPi2Ry/EZFO10XTQ2ZMLEQTGiyrfzuJwb/SYcpeT2O4bekgD/10wh0qWrZr7/rz1X /ddxQT5h9HXbioEQOpzizOrPKWSa5XvEuIXqQSAu8/5kvUBn/XZOteVI7JaPW+/IaLumXt 3k8I1uTOU00QX5XXXnZgQIdLH4M4rO/fYVlglpb5JgVK85vUwQop8lwtPdUY4dA13mAfNM 182yb2CKvqZ4+glvgmyb1lwW0SRzNZM8dPbyh7keFEfH6wjeaCsUwiZ/k64EmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747838692; 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=VLM+lwDKwLXECLV+bvl/RH20iIJvIJ4vAKoVDOVsAWU=; b=ZOuk8D/TXNS9CBXLGGhS7escNXi62QaTcOTK49Ubdb61nOF+2+7XrkY56gUdrZ6TtciY+D VKWZ2M9wyxpc6mHnF7TkCVAkZzZi0GfYy8ZgaGYZmhRqJm7rMGTbTtmUGFOL/ek/GGb5j2 Q5dUqqE0tFhatI0RrbU9F6tqKKh3PAeDOWigdwe4ibXoLlFOOo8YZvNjwvSFqc7kstz/U0 nAflqSxdgJpuhWvOYiT0y/uCideEqUioOmY8oUUclVeFD4OKvwSCuW9e8wpuoiDRw6Qlqc tcFwgA7XsKRpf9/bxj5FuEj+kwpZ6rsQn2hr6oR4Dh6F9mUVc9kjT7nwe+wo+A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747838692; a=rsa-sha256; cv=none; b=KZt2gWtKgGV08PvQuK4XicA0kRjtJ6IZltPv7s62ck+/iRinXrco7BlS9GdKh58UHT4PXD 6GhBgScDXk18NhU56TQKWulFiHcu3HBU7h/BvVgvIiXx+SpHcl3o1y3cdykyg8x3V2OKon QBGCy99EJqO4nFnyOSZfUIlOqoRKF4ci5do6akKO9URNd6rK7qlyhEA13hKoN2sjTa8b7f p0rHSgUS1c/8HV3DuVUeUTxJ3nxgkY6tRAxHXiBS1Nk+aK0P+tIAF9THFLqP7DcX7x5L/g lpqDlbnXulmAEVN4N/W6z4QoKq88f5ChZQKIvNb220Eqf9GhViDM6x4tLzxEcg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2Z2W6Mxhz6jt; Wed, 21 May 2025 14:44:51 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 5B9AACB97; Wed, 21 May 2025 16:44:49 +0200 (CEST) From: Kristof Provost To: void Cc: freebsd-net@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with =?utf-8?b?4oCcSW52YWxpZCBhcmd1bWVudOKAnQ==?= Date: Wed, 21 May 2025 16:44:46 +0200 X-Mailer: MailMate (2.0r6255) Message-ID: <3647A8FC-FED1-4539-8BDE-CACCF6A5FC0A@FreeBSD.org> In-Reply-To: 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/alternative; boundary="=_MailMate_72B40741-7BCB-4D0A-A38B-C7EA3C9AC3F8_=" --=_MailMate_72B40741-7BCB-4D0A-A38B-C7EA3C9AC3F8_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable On 21 May 2025, at 16:40, void wrote: > On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote: >> although it's possible everyone who is affected by this is already = >> aware >> of the change, i thought i should send a heads up anyway, if only to >> have a single place to discuss this (since there was quite a lot of >> discussion). >> >> in short, following this commit... >> >> b61850c4e6f "bridge(4): default net.link.bridge.member_ifaddrs to = >> false" >> https://cgit.freebsd.org/src/commit/?id=3Db61850c4e6f6b0f21b36da7238db= 969d9090309e >> >> ...it is now impossible to use a network interface which has an IP >> address assigned to it as a bridge member, or to configure an IP >> address on an interface which is a member of a bridge. > > Hi, for the sake of clarity, when you say "IP addresses assigned to it = > as > a bridge member", do you mean assigned via eg rc.conf on the host, > or assigned, for example within a VM, or assigned within a bridge = > statement? [1] > > I have a machine with 2x NICs with static ips assigned in the > usual way in rc.conf. They are also bridge members (they have to be = > otherwise the tap interfaces on the bhyve VMs wouldn't work) > Within each vm the interfaces are assigned either static or dynamic > IPs. I don't use vm-bhyve. Do I need to worry? [2] > > [1] example - /etc/rc.conf snippet on the bhyve host > > ifconfig_bge1=3D"inet REDACTED.REAL.IP netmask 255.255.255.248 mtu 1500= = > media 1000baseT mediaopt full-duplex,master" > defaultrouter=3D"REDACTED.REAL.GATEWAY" > ifconfig_bge1_ipv6=3D"inet6 accept_rtadv" > # > # > ifconfig_bridge1=3D"addm bge1 addm tap10 addm tap11 addm tap12 \ > addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm = > tap19" > # > > [2] because here bge1 has an ip addigned to it and is a bridge member Yes, that is a problem. Assign REDACTED.REAL.IP to bridge1, not to bge1. =E2=80=94 Kristof --=_MailMate_72B40741-7BCB-4D0A-A38B-C7EA3C9AC3F8_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 21 May 2025, at 16:40, void wrote:

On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wro= te:

although it's possible everyone who is affected by this i= s already aware
of the change, i thought i should send a heads up anyway, if only to
have a single place to discuss this (since there was quite a lot of
discussion).

in short, following this commit...

b61850c4e6f "bridge(4): default net.link.bridge.memb= er_ifaddrs to false"
https://cgit.freebsd.org/src/commit/?id=3Db61850c4e= 6f6b0f21b36da7238db969d9090309e

...it is now impossible to use a network interface which = has an IP
address assigned to it as a bridge member, or to configure an IP
address on an interface which is a member of a bridge.

Hi, for the sake of clarity, when you say "IP addres= ses assigned to it as
a bridge member", do you mean assigned via eg rc.conf on the host, or assigned, for example within a VM, or assigned within a bridge stateme= nt? [1]

I have a machine with 2x NICs with static ips assigned in= the
usual way in rc.conf. They are also bridge members (they have to be other= wise the tap interfaces on the bhyve VMs wouldn't work)
Within each vm the interfaces are assigned either static or dynamic
IPs. I don't use vm-bhyve. Do I need to worry? [2]

[1] example - /etc/rc.conf snippet on the bhyve host

ifconfig_bge1=3D"inet REDACTED.REAL.IP netmask 255.2= 55.255.248 mtu 1500 media 1000baseT mediaopt full-duplex,master"
= defaultrouter=3D"REDACTED.REAL.GATEWAY"
ifconfig_bge1_ipv6=3D"inet6 accept_rtadv"

ifconfig_bridge1=3D"addm bge1 addm tap10 addm tap11 = addm tap12
addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm ta= p19"

[2] because here bge1 has an ip addigned to it and is a b= ridge member

Yes, that is a problem. Assign REDACTED.REAL.IP to bridge= 1, not to bge1.

=E2=80=94
Kristof

--=_MailMate_72B40741-7BCB-4D0A-A38B-C7EA3C9AC3F8_=-- From nobody Wed May 21 15:01:49 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2ZQF1b51z5w3Y8 for ; Wed, 21 May 2025 15:01:57 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a6-smtp.messagingengine.com (fout-a6-smtp.messagingengine.com [103.168.172.149]) (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 4b2ZQD1cMJz3smq for ; Wed, 21 May 2025 15:01:56 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=qUvFrW0d; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=p0+PcTEv; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.149 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id 950911380235 for ; Wed, 21 May 2025 11:01:51 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Wed, 21 May 2025 11:01:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1747839711; x=1747926111; bh=ZVMGU3s4Gm vmVD7d0lyqNkw5O9O944ewJTCfwoIgbhg=; b=qUvFrW0dmXFC0+bMjqyPjdVZYQ t3mU+rS4s7cYSs8TkpA6+D5vG0+zusFpuZJ9sqayPO9/oMzYtvJKqHyUouaV76yT ENgu+pUVChp1NNUSKEIgn3IFzj779M7gjsPfnwBKFemO69dy2gjsGt1dhw6KWcir gGT4aCHjQseK/jCnMgGkGOM3UfMyzqnmIGs/pLhJHZZtBXVUVhYyZNctDYuBoRz4 g3HkB5DoLAoIMUvkjQREtpZZBfGTE3u2J7W6DqMDoc6O6wu3CxCMBPZVGJbRA82c aI/PYLKcEuL8cotYpM2R1IeLkUY2ldCpWIDPqJRl/Uq6VXyhaxO3nPX0lh6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747839711; x=1747926111; bh=ZVMGU3s4GmvmVD7d0lyqNkw5O9O944ewJTC fwoIgbhg=; b=p0+PcTEvFPSs3ukGOSC7cjgWZQu2yASZMhRCmal3kvNYhPbgTTP 9i+rUxG3LVFLaaej2lpbgJl7W882r13A5RPbNMpCSeMxrpsZjylx3ObAXEHXIrH2 H6GF3sDLhBN/V2Y9lMlIbLlBHIdD4Y0tEmFk+0Jc91Rnr84RWohPbzcFO1sXU8Zr lewWwpCtSFSg3DczmVNJrPZsfSBonrkcLsXRDEAr7w6iRXEeGG6GG/rfsQi/2ngg hMMYqBI6dOvquS6Wbp2iqcj7z/fOz83MZGPDyjl1v0xmIzAMadKLfsscSzqrz3U0 n+gbTEB8vf1msS4HpD0whJgFdo0pRx5oltQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdeffeekucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhho ihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnheptdfhheeuteejud ffkefhtdfhfeekgedtvdeiteevgfejtdfgfeffhfeuieeltdeinecuffhomhgrihhnpehf rhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvg gvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 21 May 2025 11:01:50 -0400 (EDT) Date: Wed, 21 May 2025 16:01:49 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: HEADS UP: 15.0-CURRENT, =?utf-8?Q?chan?= =?utf-8?Q?ge_to_bridge=284=29_might_break_some_network_configurations_wit?= =?utf-8?B?aCDigJxJbnZhbGlkIGFyZ3VtZW504oCd?= Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <3647A8FC-FED1-4539-8BDE-CACCF6A5FC0A@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3647A8FC-FED1-4539-8BDE-CACCF6A5FC0A@FreeBSD.org> X-Rspamd-Queue-Id: 4b2ZQD1cMJz3smq X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.58 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.149:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] On Wed, May 21, 2025 at 04:44:46PM +0200, Kristof Provost wrote: >>[2] because here bge1 has an ip addigned to it and is a bridge member > >Yes, that is a problem. Assign REDACTED.REAL.IP to bridge1, not to bge1. Oof! Thank you for clarifying. I'm glad I asked. This bhyve host was set up following instructions from the bhyve section of the handbook. I've just checked and no mention is made of the new requirement in section 24.7.1 of the handbook at https://freebsd.org/handbook So, if a lot of people run bhyve guests as described then more people are going to be affected than one might initially presume. -- From nobody Wed May 21 15:06:56 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2ZXQ0CLCz5w43c for ; Wed, 21 May 2025 15:07:18 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4b2ZXN2yHpz3vDJ for ; Wed, 21 May 2025 15:07:16 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=X9RWj+VU; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1747840017; bh=9NezPrfGOcloa9I7CaUaOalB34Z5rFlAH+VykNmeh9c=; h=Date:From:To:Subject:In-Reply-To:References; b=X9RWj+VUMCOuNfnaZNFFmPFJjNzB07qbhsac5MHGoUl0ityMUUYRj6MYx3OXm8rvA nRphtLK26RmM7IgZ2aIOyC2QiD5WoznuMkaJ/ZjMKDmQYewnAHOhpnjZPJoYwY2VyD DRCSF353xSfaXvriX1ccur6MHaYCouU6oomWWHGHJmZ4uVJpmCkabOLf52eIa1ap1v 7QWN2xp2nscM/1lwWJiy8WxjCK7oEL3kwHXU7VglVxETQFAWOXqRsEg2d1y3zK7lBT 0FlZk3aRsPOEvpjvLWwBycPj8q8viDRuASRZVj/CDw4J6WAhdeFDSMJ8XUTkP0QYJt FwyJU31Qlz4FrvaC9y/MXS9HhNvtTpH2WYG9P0yWft+y0X0Aa59V/7KSexM5A+d2qY eAGDIutuViKOiSmDT2ZjtaBzRYv3/zlv7gn2mziN5wf6CUg/YbyaDxkK+VnLbkUUU/ G9jWDnnjd9+Y8CSleerxd88F9YBAEUP78kMB5BqNBKvzRbAuXd5JF5L7c4gwsYiwkk SLeZlSUlW3nVXvoightMY02+pF6AK18ip+roGl7a2W8DY4Nvv38lwLjw9YyflR0/ah A9Mlyv+spryZR5OUpcZyJx29NG61ZL1Z+75PaFvjUQayK3qzdaY+I4h7agozDfi+ZO mFHWYJ77lbAXDbKJ9Yk7zexs= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id D94F25B38F6 for ; Wed, 21 May 2025 18:06:56 +0300 (EEST) Date: Wed, 21 May 2025 18:06:56 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: =?UTF-8?Q?Re=3A_HEADS_UP=3A_15=2E0-CURRENT=2C?= =?UTF-8?Q?_change_to_bridge=284=29_might_b?= =?UTF-8?Q?reak_some_network_configurat?= =?UTF-8?Q?ions_with_=E2=80=9CInvalid_argument=E2=80=9D?= User-Agent: K-9 Mail for Android In-Reply-To: <3647A8FC-FED1-4539-8BDE-CACCF6A5FC0A@FreeBSD.org> References: <3647A8FC-FED1-4539-8BDE-CACCF6A5FC0A@FreeBSD.org> Message-ID: <5E86F8A9-5A78-4F71-B4ED-FF0C391AD1A3@ketas.si.pri.ee> 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-Queue-Id: 4b2ZXN2yHpz3vDJ X-Spamd-Bar: / X-Spamd-Result: default: False [-0.80 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] might also want to look at autobridge* options while you redo that config From nobody Wed May 21 16:12:08 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2bzH3Dggz5w8Wy for ; Wed, 21 May 2025 16:12:11 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2bzH29CXz3MHM for ; Wed, 21 May 2025 16:12:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747843931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mwveSdMoSznpa57V6PlWbBHHuIcbWwzx215ng/mWaoI=; b=xUd4r0pB1/zcnQP596YJbOv/i/Vi5EgKnndFp3Y3l7AzE8xh+gid45dCmguvoSgarPZp95 GsUtv9K9J+nJZG7jBXN7TFHo7gSkjHI9ZeZOln2uklueCNbB/clc/Tt1QzaYXxVsgw9ibV 3nMH35sXeWyGS6wy7poy+y/WD3qLq4o0jqUReUlcfoyLmfaUQ/eLx1fX5VkVd3spZYJoBL WXmrJIUmb7HZ/cDhC3yR+iOMOwwgWsqdEy8eLm0xuVVTLcBEy/AEFChQxqhCZB+bBfgONh 80WXiRfmbu7bpazPnpX6+TMsD3jP/pQPP2ieH4Gbf+XuIc+/sHuOi1WsHVR/uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747843931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mwveSdMoSznpa57V6PlWbBHHuIcbWwzx215ng/mWaoI=; b=wM14QbJ1koEYW/Q4W6L/gycpcOawFy08BhUKoO/H2UjoEl2h5frdEot7sxo9y+T7cu+hj0 6fvZO1iYvMh9LsTK0GVkf4yjJCZTmHlyRWHW/L7OuOgMt3H59DEvFadM6Xcn5/l0RrXJ4I b1OpgjWN6RLeOt+Zof6EYzO0QsV/agkvbOzBeAsdt7BTMPuC40lC+UOAY6ybl34wjU56xj GaP1Z0gShkPyfhOcrFjZcaiTbVd8zJBT7x3yuEAp0Qr4627DEts2yikQT00czzj9u7tgme Y/XlF9czXxlYBIEDiYtjX/QNPtp8iT1qDZxZfiAeDunTbViCuTqODmDhfTBbOw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747843931; a=rsa-sha256; cv=none; b=eySsnBngU35KVTSMIZY1A2PEAHWyeld9kpS7YotC6ypXGEHiWER8d0H+3RIx5L0WS9DUL2 L3MtdoVr7j3Nn0KMWDaCHzGDvaUpa07xZPMqixINEPHkUqQrPgNcWiRpjxlNGtdxpB2KPH aPvArW0BESCrhLNxvkhfnVLQCMMs8XYOu03b93vBkTXhJZrAeU5mmb6VCKkO/BAP+qbduH fIQR4KlCFqFBG8v+fQs6C1N1S6QgqhM2vS3Yf8XgJLCRfDA1BtQwb6N2Ozh7M1vCTkaQMR fYdaplHJ3EGV5SnW4Ew3Ti2nKBLgTOtgfMs3M7KQNNo/qVkX8Z8GVyczzsw2vA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4b2bzH06hkz8RQ for ; Wed, 21 May 2025 16:12:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <6433db6a-e106-42ee-9276-c53b56a13bd1@FreeBSD.org> Date: Wed, 21 May 2025 19:12:08 +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: =?UTF-8?Q?Re=3A_HEADS_UP=3A_15=2E0-CURRENT=2C_change_to_bridge=284?= =?UTF-8?Q?=29_might_break_some_network_configurations_with_=E2=80=9CInvalid?= =?UTF-8?B?IGFyZ3VtZW504oCd?= To: freebsd-current@freebsd.org References: <3647A8FC-FED1-4539-8BDE-CACCF6A5FC0A@FreeBSD.org> Content-Language: en-US From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 21/05/2025 18:01, void wrote: > This bhyve host was set up following instructions from the bhyve section of the > handbook. I've just checked and no mention is made of the > new requirement in section 24.7.1 of the handbook at > https://freebsd.org/handbook > > So, if a lot of people run bhyve guests as described > then more people are going to be affected than one might initially > presume. Just in case, here is the full Handbook link: https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-bhyve-prep I am quite sure that a lot of hosts with VMs are configured that way. Mine are. And I saw on developers@ other people reporting the same kind of setup. I must admit that in my rational mind I understand that a bridge is a bridge, but I always felt that a bridge combining several physical interfaces (and thus physical LANs) and/or maybe some VLAN interfaces is different from a bridge that combines a single physical or VLAN interface with several virtual interfaces (like tap or epair) that are connected to VMs. I always knew to assign an IP address to the first kind of a bridge, never to its members. But in the second case, it felt that the physical interface is the primary interface. It's *the* network interface. It must be configured fully. And the bridge is "ephemeral". Maybe I won't start any VMs and won't configure the bridge at all. Why always have that bridge? Or why change the main networking configuration when I decide to create that "VM bridge"? And this view is reflected in Handbook and also in some external tools for VM management. Take for instance vm-bhyve which seems to be a pretty popular "front-end" to bhyve. Its quick start has these steps which are equivalent to what Handbook has: 7. vm switch create public 8. vm switch add public em0 Seeing both sides of the things I am not sure what to propose here. But I certainly do not enjoy the thought that I need to change a host's network configuration in case I just want to run a VM and to bridge it to the LAN. Or I'd have to pre-configure a bridge (with a single member, initially) on every host where I might want to configure a bridged VM later. vm-bhyve links: - https://github.com/freebsd/vm-bhyve - https://github.com/churchers/vm-bhyve/wiki/Virtual-Switches -- Andriy Gapon From nobody Wed May 21 16:23:04 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2cCv0QRPz5w9Sr for ; Wed, 21 May 2025 16:23:07 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2cCt6vQSz3Qh5 for ; Wed, 21 May 2025 16:23:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747844587; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5uJqqUm7RiPpvkkDGSVFHpQYSGI3tccQY2YEE7tEXlE=; b=G1YtdP/DcIFYrvI9xQ4QecGL3HZxqKvO4ERP3aK85fY5PfArEH0EYttkQhBwzdT/m7q99O ycqU4LDewx6p5BteSn1RE3R3u+0i2cdduzNhvTBVZFdqWzO+AgDISgNqLrXweAYOCOYmy9 1VGRwjik8FmXpNKQQTi7zNHcmHKNOYnawjc6mjqMP4wI/yXz++hR9fb21ZiA6bdyTqSK0j ACRAMN/SumUy5q/14u2kBMEYeuyg6CEAMoWqwXBvlJT67AgF6vsFDSYzOZGeMmKztNZcKl VY7fEfit0LxiSPM2OTALf/4ZHE/dMDL3mPN9WQq0XaSZ92SOP7yM82IiPfoe3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747844587; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5uJqqUm7RiPpvkkDGSVFHpQYSGI3tccQY2YEE7tEXlE=; b=F+sBcTlSr0JA+8QfAeAAB7THlCpf+hE3eG9RCZFNaHVQ6WFENm4Zb6UeAR5sUDFrnmi+6Q 38z97fqjospL/Btdv2AVEPHz4aVhzsL6guCzyYR0rJJJCr+SE6q9syk6RUukQJMXZeHs5j osYrytv4WPY7Tl8ydGXkA3zS8h7G9nAccuF3JO/X3GnJ3L72pXbJuWD/dM8tbcdQjWmQ4y pUKX9BjUuheFkR0DomBxm2tvtAFDd7341xQTSTH26VFm9Gh8SjbnwV1uUkcGMcdtDBLrzY VUDLJUjbDi1828TgUmkvM3TJoOgeR+hcXdf6aYYAWkUedxZlxQYWCkNGBZx5ig== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747844587; a=rsa-sha256; cv=none; b=KE5lfGBPlWsvLoLkiQvc8DqbvcXoekyPnsgod9df9zZHr8hj0fE25TADZRbvmeXDDxCejN A3M9+yyehWnOfuE0u5745wkkFOuFw6ujXB1hBEo2K0VnCyZnjAXQz2+ahRwpfIr8R9UWXz jPwjO3Yq9iv5xn4QoMjNjhDQqIypZKpdHNZjC4x15tMOUCfio5Df0x9qjapXrp5j70d0Qx Z3HWBrWajSw99DIrMcTPVDUmSN6BULzm17MBGwQDbOmX/hjaZilatrjc83rl07NQcM4pDt mGMIhtH5+l7MPRj/XIQtKB/yAHqfJAevzijG4sdp79KhfRHrnMu/pzopyQ1l2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4b2cCt4JcCz7Xk for ; Wed, 21 May 2025 16:23:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Wed, 21 May 2025 19:23:04 +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: Un-sucking EINVAL To: freebsd-current@freebsd.org References: <202505210722.54L7MTqw025632@critter.freebsd.dk> Content-Language: en-US From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 21/05/2025 10:28, Lexi Winter wrote: > you are completely right. since we (for some reason, that i don't > really understand) can't add new error codes to errno, we should stop > using errno to indicate errors except where POSIX requires this. I once had this idea, probably not original, that if we usually use 32-bit variables to pass around error / status codes, then why not split up those bits for some special uses. E.g., lowest 10 or 12 bits could be actual error codes. But highest, say, 8 or 10 bits could encode a domain of interpretation (to use a term borrowed from IPsec). Domain number zero would be a POSIX or legacy domain and error codes in it would be the standard errno codes. Then we could have a different domain (or several) for FreeBSD-specific error codes. Some middle bits could be used to further subdivide a domain into modules or subsystems with their own error codes. There could be some private (application specific) domains. But, of course, a larger repertoire of error codes is still not as flexible and powerful as an ability to pass a specific error string along with an error code. -- Andriy Gapon From nobody Wed May 21 17:07:09 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2dBy4hDJz5wD3d for ; Wed, 21 May 2025 17:07:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 4b2dBy2XmHz3gNs for ; Wed, 21 May 2025 17:07:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-b0db0b6a677so6011609a12.2 for ; Wed, 21 May 2025 10:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1747847241; x=1748452041; 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=2lYUjSLRUFOt1rYvgm33hvFcOt9HdASTz6mq+ROhLgk=; b=AKpoVvf03KqRD/yE2VqBSQX+ur+qOlNjNn7OYdoAIySXuZ8OR9d8zdOGlgHUViWEUu lSd+5JDrV2n0TYEUpTipRDB0C7pRGol1BDEIWyIYVKFlKBqeGsAKzfrmERB7GBkGFPgO lAD0n62fNtKos26jBo8x+tVfU9ZSvdmRKMikrnIvRItlwZK3PGbn7lLsmrkvUMTBQ2ag 0BpUZWt0IP3jI0yH6yx1PdCa2Qv2vWJGaOot1N6B/uesAj5SJxNRYNUf7eG9L75i9n5r hQv+0IcB5HdMx5YMuJrjPGxsoJoad5ON34LKmQuqKz0YFT4uiSMj//k2c05qo4PESWhy 76uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747847241; x=1748452041; 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=2lYUjSLRUFOt1rYvgm33hvFcOt9HdASTz6mq+ROhLgk=; b=vdHZIaAPmcRtRE+oe5ZQ7lhtgSd7LYwvrlxTcZ8e0sWyKzBbnRnQxRoQmMSoABVJ8b TdP05lNLPmyq012a4zXq1ylx6a9+pcESJ/6kK/qLnXjunDUkZ7rxQW19C8G6liM57LBh U8XcRWU06XTv/LqHdjGAKCt4lQ7nfMxHEx7i8/8rURwW3T8mvuJJ66NFpnX8SAZIOeqw /2m57dkJ45rEMluIcaCWHMvzQCyIgjqNhoO8iCRR7mtqfgA6jGNUHSnTskDHtmxjith3 /Eugnu3hiOoIh+LMnyoppfDwAYkzrpRAM2l7Bvh/WDBP2HZovP19VOcI6l28uohNZRyv qqUQ== X-Gm-Message-State: AOJu0Yy5xbT2+wajHUdPmH3rOd9xi/4D3GYRB8GgH8eytR6gDtn33I7F 7zAKNn1tivHIwsvjXG3GfqpgG7rqIPcCSDEwJDbyVgXEgHY+AZf1vj29hLedrM2Yn8zQ4eu1rOk eq3OarFVIPPzf2Fy0qrKNktA7bcEm6T2KORSy5g7mWvVQft3/txVNjBw= X-Gm-Gg: ASbGnctxxHGkHNilFKRyuBGgju//E074MGxL9M6aW2RVzRw+zGcaOcxft6bo7/pZLeC 2P05pRkiBYo0EgyLTyy5B2UmDEB8P72WbeCDZNioW8MIQZ9Pmzt9P22+2DnQ0W8084qq0QtsTZ+ d67cgunyraVX7rGC1bmObNDIYq+7p1zwMS X-Google-Smtp-Source: AGHT+IH4+27pFnbfqoSOuQMo6jlQ2DHSktW+7afqz2GKLj/Rz4EPAX5zlBelaW3ugFdIuewnMX8Xwu2PuG2eQCAteuo= X-Received: by 2002:a17:90b:58ee:b0:30e:6ac1:3716 with SMTP id 98e67ed59e1d1-30e7d5bb679mr26231208a91.34.1747847240713; Wed, 21 May 2025 10:07:20 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202505210722.54L7MTqw025632@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Wed, 21 May 2025 11:07:09 -0600 X-Gm-Features: AX0GCFuplHz85Cgdc_umqc_fhvuifQoxm22RNu6mW-7eQigOeRLKKN8R0slytUw Message-ID: Subject: Re: Un-sucking EINVAL To: Andriy Gapon Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4b2dBy2XmHz3gNs 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-Spamd-Bar: ---- On Wed, May 21, 2025 at 10:23=E2=80=AFAM Andriy Gapon wro= te: > > On 21/05/2025 10:28, Lexi Winter wrote: > > you are completely right. since we (for some reason, that i don't > > really understand) can't add new error codes to errno, we should stop > > using errno to indicate errors except where POSIX requires this. One of the problems with new errno values is that they break our ABI. This is a paradoxical result on its surface, but the last time we added a new errno value this issue showed up. The big issue, IIRC, is for statically linked binaries could get errno values that would overflow the arrays of error messages. > I once had this idea, probably not original, that if we usually use 32-bi= t > variables to pass around error / status codes, then why not split up thos= e bits > for some special uses. > > E.g., lowest 10 or 12 bits could be actual error codes. > > But highest, say, 8 or 10 bits could encode a domain of interpretation (t= o use a > term borrowed from IPsec). > Domain number zero would be a POSIX or legacy domain and error codes in i= t would > be the standard errno codes. > Then we could have a different domain (or several) for FreeBSD-specific e= rror codes. > > Some middle bits could be used to further subdivide a domain into modules= or > subsystems with their own error codes. > There could be some private (application specific) domains. > > But, of course, a larger repertoire of error codes is still not as flexib= le and > powerful as an ability to pass a specific error string along with an erro= r code. VMS did variations of this... It was both good and bad. It was a sharp edge that you needed to understand when writing C code in early versions of VAX-C because sometimes it was hidden nicely behind the traditional Unix interfaces, and other times it wasn't. We could pass additional data back to userland. However, that too would be an ABI change. We could pass it in "R0" like we do errno, but then any assembler would need to mask it like the mask we'd add to libc. errno itself can't change: you can't require clients to mask the values and all accesses in the tree to errno are via the errno macro. However, go and rust do their own thing and would need to be modified if we tried to expand the reported value out. The other way to report this would be via something new. There's no new register we can report this on in most architectures: they all have proscri= bed roles that we can't change (or that would be unwise for use to change). The= re's some temp registers on some architectures we might get away with using since their values aren't preserved across system call boundaries. But if w= e can't use a register, then we'd have to make a note of it in the threads structure so we could add a. system call to return it, which does start to get messy = since the thread structure is somewhat optimized for size and fitting in cache li= nes. And if we're going to grow the thread structure, we'd want to maybe just store the string (though memory management issues popup).... In short, I'd love to widen the interface, but there's a number of practica= l issues in the way. Warner From nobody Wed May 21 18:37:56 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2gCl3pl0z5wKxr for ; Wed, 21 May 2025 18:38:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.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 4b2gCk5TRrz4NZr; Wed, 21 May 2025 18:38:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-32925727810so25879901fa.0; Wed, 21 May 2025 11:38:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747852689; x=1748457489; 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=qV37DmoglEWWZBrwra4AduDWxm1R0dmY5ITfY5g6mXU=; b=uXVwq04MV4VjIG/Nm2upuNs9pwf8owxC7B+YsLPuZy6fD6RfLqwfe8Gqb/rBks+31m 5ea8WmAacxLEH+RIQRNHYxlIyZdZW1l+GR+cYQo3yf3kZwjFtyWNMUe+elQFto3P+x+g vGHOw+FqzfVmBMCd8IY25bGRxV2EbH0WKoR4w8os5l0KxasIB5HgP6cexN324cv/WGXf FftzyuuEbuAKXuYVvlnzRCWE01bLf99vF4pgRxKhDsypibSFNWrTsJA41/7HYH2d4fA6 +r7g5jkzzayOnaGgFqSf/uc6nwyNFGbZkIaxS9ZArKBLNpA8Jc/hdTuYD76WzbUrBn7e fL1Q== X-Forwarded-Encrypted: i=1; AJvYcCUhxHRUHIBMa3q8vlBSl/meTQtVKt04BWZtyW7XEDi4mfnha5laYJX7bbVxoyRaUUW9arggII7XA7IfxeMk8Ss=@freebsd.org X-Gm-Message-State: AOJu0YxJ1HFPh1Ni0Zae0S2BJUwp4yCNE/csAnQWKGKiffl2h66yMU7H meqRG9NGnp3/LRY4dvK8njKU3aMU+8KCHcKbru4TUnaz4oB5hmnH0D54EYDjm/lIBT6EXG3YaQm IQUACUyxYZeaHaczxlCQtc1PLBJx9KB2vCQ== X-Gm-Gg: ASbGncv63aLr9gD5jyKCPvw/IuD/fKlocrGS83Purs21Oy+4Rm+AXgV+W0SwXfLfxHy RDnspF+7AUblKjGgOa6lBXkRegOmsimD5pFuUoLOx6YkxxdQRfm3yV8JLg8l8M00t1BprtEYv9j qG6mZPkqY0WK2FNYfYPYrLfO6AAsLlCxXWKA== X-Google-Smtp-Source: AGHT+IFuc9seGJF9B25VTQqX4uJQY9XZ+22afgbZrm8gt/d6V5HuhWeI3CiMUmCLadyCvyRdGP9ubtQjCDngKVE1LFU= X-Received: by 2002:a05:651c:552:b0:31c:31a7:4679 with SMTP id 38308e7fff4ca-328077e58ddmr76009531fa.37.1747852688544; Wed, 21 May 2025 11:38:08 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202505210722.54L7MTqw025632@critter.freebsd.dk> In-Reply-To: From: Adrian Chadd Date: Wed, 21 May 2025 11:37:56 -0700 X-Gm-Features: AX0GCFuU2h1Aas0hWTJJFdTMY6IPTchYY3GYXJyfnPc00LkU5ZsquBVZzhmTaJE Message-ID: Subject: Re: Un-sucking EINVAL To: Warner Losh Cc: Andriy Gapon , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009ed93b0635a9aa1b" X-Rspamd-Queue-Id: 4b2gCk5TRrz4NZr 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:209.85.128.0/17, country:US] X-Spamd-Bar: ---- --0000000000009ed93b0635a9aa1b Content-Type: text/plain; charset="UTF-8" On Wed, 21 May 2025 at 10:08, Warner Losh wrote: The other way to report this would be via something new. There's no new > register we can report this on in most architectures: they all have > proscribed > roles that we can't change (or that would be unwise for use to change). > There's > some temp registers on some architectures we might get away with using > since their values aren't preserved across system call boundaries. But if > we > can't use a register, then we'd have to make a note of it in the > threads structure > so we could add a. system call to return it, which does start to get messy > since > the thread structure is somewhat optimized for size and fitting in cache > lines. > And if we're going to grow the thread structure, we'd want to maybe just > store the string (though memory management issues popup).... > Having tinkered with this in our ${WORK} OS, it's not /too/ bad, as long as we'd do a couple things: * make it a syscall for now, yeah with all of the thread storage stuff you mentioned; * make fetching it a library function; (so you can change the underlying representation); * (yeah rust/go/etc language bindings will get angry at you, but that's gonna happen regardless so just be comfortable with that); * make decoding it a library function, not macros; * make getting/formatting the strings a library function, not a C array of strings; * .. and since the errors themselves can encode info IN the error, have it return a string that you MUST free(), so it can have args substituted into the string, so developers don't have to go and parse the string itself and re-invent turning the new error code(s) into a useful string; * make sure that there's always a mapping from the new error return to an existing errno, so code CAN operate by just checking errno. What was SUPER fun was learning that system programmers wanted the detailed errors for logging/telemetry/debugging, but NOT for actual code flow. They ended up wanting the top level bucket to be "how should I treat this error", which mostly mapped OK to errnos, and then the detailed error code for diagnostics. It almost felt like SMTP/NNTP/HTTP error code hierarchies too :-) -adrian > In short, I'd love to widen the interface, but there's a number of > practical > issues in the way. > > Warner > > --0000000000009ed93b0635a9aa1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, 21 May = 2025 at 10:08, Warner Losh <imp@bsdimp= .com> wrote:

The other way to report this would be via something new. There's no new=
register we can report this on in most architectures: they all have proscri= bed
roles that we can't change (or that would be unwise for use to change).= There's
some temp registers on some architectures we might get away with using
since their values aren't preserved across system call boundaries. But = if we
can't use a register, then we'd have to make a note of it in the threads structure
so we could add a. system call to return it, which does start to get messy = since
the thread structure is somewhat optimized for size and fitting in cache li= nes.
And if we're going to grow the thread structure, we'd want to maybe= just
store the string (though memory management issues popup)....

Having tinkered with this in our ${WORK} OS, it's= not /too/ bad, as long as we'd do a couple things:

* make it a syscall for now, yeah with all of the thread storage stuf= f you mentioned;
* make fetching it a library function; (so you c= an change the underlying representation);
* (yeah rust/go/etc lan= guage bindings will get angry at you, but that's gonna happen regardles= s so just be comfortable with that);
* make decoding it a library= function, not macros;
* make getting/formatting the strings a li= brary function, not a C array of strings;
* .. and since the erro= rs themselves can encode info IN the error, have it return a string that yo= u MUST free(), so it can have args substituted
=C2=A0 into the st= ring, so developers don't have to go and parse the string itself and re= -invent turning the new error code(s) into a useful string;
* mak= e sure that there's always a mapping from the new error return to an ex= isting errno, so code CAN operate by just checking errno.

What was SUPER fun was learning that system programmers wanted the = detailed errors for logging/telemetry/debugging,
but NOT for actu= al code flow. They ended up wanting the top level bucket to be "how sh= ould I treat this error", which
mostly mapped OK to errnos, = and then the detailed error code for diagnostics. It almost felt like SMTP/= NNTP/HTTP error
code hierarchies too :-)



-adrian


In short, I'd love to widen the interface, but there's a number of = practical
issues in the way.

Warner

--0000000000009ed93b0635a9aa1b-- From nobody Wed May 21 19:14:48 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2h243DSHz5wNTm for ; Wed, 21 May 2025 19:14:52 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4b2h2407mRz3Qvt; Wed, 21 May 2025 19:14:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 5EDA0B0A1A; Wed, 21 May 2025 19:14:49 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 54LJEmmd004452; Wed, 21 May 2025 19:14:48 GMT (envelope-from phk) Message-Id: <202505211914.54LJEmmd004452@critter.freebsd.dk> To: Warner Losh cc: Andriy Gapon , freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL In-reply-to: From: "Poul-Henning Kamp" References: <202505210722.54L7MTqw025632@critter.freebsd.dk> 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: <4450.1747854888.1@critter.freebsd.dk> Date: Wed, 21 May 2025 19:14:48 +0000 X-Rspamd-Queue-Id: 4b2h2407mRz3Qvt 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:1835, ipnet:130.225.0.0/16, country:EU] X-Spamd-Bar: ---- -------- Warner Losh writes: > In short, I'd love to widen the interface, but there's a number of practical > issues in the way. Not really ? Our kernel is not I18N'ed and we have no plans to do so. That means that there is absolutely no point in taking a big detour over enumerating all possible messages into some "int assistant_to_errno", we can and should simply pass the informative text-string straigt through. There is also no need to make the text-string more than a const char *. The proper detailed explanation is in the manual page, the string just needs to say enough that people know where to look. Here is the simplest implementation: 1. We add two pointers to kernel threads. 2. When an error occurs, those pointers are set to a pointer to the kld (or NULL) and to the const char *string. 3. Userland explicitly requests the information (a syscall or per-thread sysctl), the kernel validates that the kld is still present before copyout'ing the const char *. 4. Kernel code adds calls like: errmsg("Grammeter must be connected first") before return (EINVAL) Done. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Wed May 21 22:21:54 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2m9t6Wthz5wcNV for ; Wed, 21 May 2025 22:21:54 +0000 (UTC) (envelope-from brooks@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2m9t5ws4z3n44; Wed, 21 May 2025 22:21:54 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747866114; 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=VlJpNG7up74vWxdnLrdbXImjyErmXyyv+PocotLNw6Y=; b=hE0/l+Ye9n6XAKmq35xP/ORDx6tJ+DMCOHm1h7QQbqzjEZiI3EDvQ+5lDTlAYVKAc+RjNu BQ8h6oBRId2/ulwMMj2zt0lTtmcbJRrNJga4jUPXQDyeo8mSLme3bcEbwWMIE/JfvnSd0f jsuXFE2rXfLKFZK3dqhNIF+Q9PLuTUYwIBKs1AAMKwtx9wPspOWBM15f2jYp5sm1g3GyK5 61VNfC0Rjk2YqhF72JlYdv0saKfUqAf29sGUc3S0GhwqUhuyaneNxL/3r8DaP/Rs8SjluI 2f3aFriyu/JUC+1A5bwUNGWsQMyxWRyBbJsRAdQJG0O7Aea2e4UXfs4CDzKPLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747866114; 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=VlJpNG7up74vWxdnLrdbXImjyErmXyyv+PocotLNw6Y=; b=ZquPmMAk5wxxeSwU+/z1Ty93kxN2MBWR8W0+wdDA9cVCSIL9W9jVSkGHoPPsI6RrR/w6oH BrzO87LgqorjW5l9EGYJW3x7OZw66dNOidiGpwm4wam10O6ttO+n9bOq5bXFhTbn0BgKVC Zdh2GAypsLHSkezWxRm9YUmTTqBWJn2oeX6fV29ejxthGc0KwjrRupUwiwp4cY7uGVX1vk YwuTJTh9H2UsA4VyqaMwKPhG9KK7YZ245wY/1hxIgI4AuL/6IJrX6+Hr4YvNTwRT+MUs/d adymtPmnUvHDFgTqxK1M8tEKJuJg8qDxYYRk53vmFzUW8yXH4x7bwQUnd6u13g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747866114; a=rsa-sha256; cv=none; b=P4/TqMf9EThsvit+G1EYQpwAkwuacO46/1u9Elt1W8YumqOxMAGy1cEskp5m1fCjTUQLuf 6vJXn/rkVvH5hxvdK7LPUKd9cLLFA8/VgwT5Hj1keHq/KfZ05+lPPMK/+xvkAajYUHo9CR SFu0H6O59aajE2cgwj6olyOnjNgZNP13anQj2wOqCs6Wke+NJnHtLUfxzEMTH74L0pN9xe NO4DHUQ+R5hkLvG759x6LXUqjJs3Zf3Sq3iaORpTlE/vVW+XWT3AumJgrAiw0EX0odKdyZ q+vUMslBJVpvzBxS7mArbRnZ4RzkYYYYzoYkrwDzlNIBCJisaC2BFbsb7mwYHQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2m9t56rczH7F; Wed, 21 May 2025 22:21:54 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 568BC3C01A0; Wed, 21 May 2025 22:21:54 +0000 (UTC) Date: Wed, 21 May 2025 22:21:54 +0000 From: Brooks Davis To: Poul-Henning Kamp Cc: FreeBSD CURRENT Subject: Re: Un-sucking EINVAL (was: ip# on bridge members) Message-ID: References: <202505210722.54L7MTqw025632@critter.freebsd.dk> 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: <202505210722.54L7MTqw025632@critter.freebsd.dk> On Wed, May 21, 2025 at 07:22:29AM +0000, Poul-Henning Kamp wrote: > The ip# on bridge member interfaces is yet another example of why > "EINVAL" is the undisputedly least helpful errno of them all. > > The laconic "Invalid argument" leaves both the userland programmer > and the user to guess what might be wrong. > > That's ok-ish for read(2) where the possibilities are so few that > the manpage can tell you what you did wrong. > > It breaks down totally for ioctl(2), setsockopt(2) and similar > syscalls which can attempt very, complex operations with many > parameters and subparameters. > > Ifconfig(8) is ground zero for this and the manpage is not even trying: > > DIAGNOSTICS > Messages indicating the specified interface does not exist, the requested > address is unknown, or the user is not privileged and tried to alter an > interface's configuration. > > We should give errno a text-partner, so kernel code can: > > if (p->n_mazel-vanes < 6 * p->n_dingle_arms) { > error_text("Too few mazel-vanes per dingle-arm (min: 6)"); > return (EINVAL) > } > > The err(3) family of functions should retrieve the string, and when there > is one, print it as part of the error message: > > Invalid argument: Too few mazel-vanes per dingle-arm (min: 6) In CheriBSD we implemented a related system with a somewhat different target audiance. We had added half a dozen more EINVAL failures to mmap and it was too hard to debug them. Rather than extended the system call error interface we added a new ktrace type KTR_SYSERRCAUSE. Since we were aiming to aid programmers having to run ktrace seemed sufficent. FWIW, I found it useful that we made SYSERRCAUSE take a format string. When debugging complicated mmap usage errors, I often found that a bit of formatted output is the difference between having to pull out the kernel debugger and not. You can sometimes get a similar result if you decompose the complex conditionals to have multiple error messages, but it's quite disruptive and we've got enough diffs without having to break them all apart. You can see the implementation at: https://github.com/search?q=repo%3ACTSRD-CHERI%2Fcheribsd%20SYSERRCAUSE&type=code -- Brooks From nobody Wed May 21 22:27:36 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2mJW0xQPz5wcdG for ; Wed, 21 May 2025 22:27:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4b2mJV5n3dz3rFC; Wed, 21 May 2025 22:27:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id D020AB0A1A; Wed, 21 May 2025 22:27:36 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 54LMRaFm005200; Wed, 21 May 2025 22:27:36 GMT (envelope-from phk) Message-Id: <202505212227.54LMRaFm005200@critter.freebsd.dk> To: Brooks Davis cc: FreeBSD CURRENT Subject: Re: Un-sucking EINVAL (was: ip# on bridge members) In-reply-to: From: "Poul-Henning Kamp" References: <202505210722.54L7MTqw025632@critter.freebsd.dk> 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: <5198.1747866456.1@critter.freebsd.dk> Date: Wed, 21 May 2025 22:27:36 +0000 X-Rspamd-Queue-Id: 4b2mJV5n3dz3rFC 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:1835, ipnet:130.225.0.0/16, country:EU] X-Spamd-Bar: ---- -------- Brooks Davis writes: > FWIW, I found it useful that we made SYSERRCAUSE take a format string. > When debugging complicated mmap usage errors, [...] The main problem with format strings is that then we need memory (pre-)allocation. My proposal gives up that level of precision in favor of simplicity and minimum performance impact. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Wed May 21 23:23:12 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2nXc5twXz5whLm for ; Wed, 21 May 2025 23:23:12 +0000 (UTC) (envelope-from brooks@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2nXc5QZqz3K0n; Wed, 21 May 2025 23:23:12 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747869792; 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=ahoNNhp5C3Fh+maCcrO6mK5StCX0fmXf2yUFILmG1Qk=; b=aSShIbYJg4lv3AbfJ2YzFmhX6+u6tz3lW06StaHKNMiKw2sRP3WuWXcsUl/pLKbfVvJZL5 Y4QGqptRycxy/EUQ4WySGfkQwA1fI9G2139wKEDr63gaaE1L4zx8B4GpXTTZmNP6SD7Nud 10iVX9ea2n43XqHai/++RmeWTT41vrKgPUPi8uGCUnqcixBmvsd+H8tsZ4iw9LMVjd5PmA HhH1bcfMQ909himV9LEehnDU9m5id5c6an8izRhvPF91A5BarOykDg7XS+JJia3i02sl2M 2shpYk6CkqbX4y8v0URroUmjDeDR3JMwRuxsvTYUQemcPE8YeseYWK8XeVkHoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747869792; 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=ahoNNhp5C3Fh+maCcrO6mK5StCX0fmXf2yUFILmG1Qk=; b=XqVFUxhP33DWeNIXPaFcGEaKDV+R77U5yrF2HXYmGoCHZmqp2aI/ou+xBa1/PUpbdFtxH/ qI4M7YTYN+dzFmBXQBCz5tJNK/7yS6hGE2b2uwqoDlgfHZNL2p7iPUXWmQhEO0lUEjOh1Q eOpzEFhDsMwAL3Wd0K+yQM16Jl69ur58Wnm8a+PqEb440mcN9r6WcyZI2ElM0FjVvYrpp1 9bOdExT90/3NgQcmG96d8mvMk1p6olGfr4O1LDSrfuyjxPiGfAm4giazmcqWAGbTtLal4A SJynYxHsMir2yT5KBjpi5Dgre/duJXwB3FwOe5JNtM1Ws7xxe9rfKuUIpklz1w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747869792; a=rsa-sha256; cv=none; b=KPec+e4SNkDILvfKt6SPY833nCPXGYFtDKbK/eTCkewWUsYHt/7mA7AEDCPYSgC5BbI2rL /ZvlYottpDarqM39wmBzB8rujdTQvjzVTBeU3zHxq16pBZf3BySGqY6yFbi7rTnOQOMXwf AoKMeIjIJI2k8BjjAAWHJQDuHgrPczX7F/noyPxXyizB3dTJpQVNl67e5DUBH30NwdwOkq wyONO7tjJ3/1eRzZqGrgWO/Wms8Lj9yavSurQXmF0WNxMKmqTs77V7PKYgFh4lkWyY7c5C EegQuglsfMLy3ZaS8gzB3wjNuwSRGK/Mstbyfh+4npXeXcsbrsFHmhY8/8u8Ag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2nXc4tF4zHpj; Wed, 21 May 2025 23:23:12 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 357553C01A0; Wed, 21 May 2025 23:23:12 +0000 (UTC) Date: Wed, 21 May 2025 23:23:12 +0000 From: Brooks Davis To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL Message-ID: References: <202505210722.54L7MTqw025632@critter.freebsd.dk> 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: On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote: > In short, I'd love to widen the interface, but there's a number of practical > issues in the way. I think caching something in the kernel of later retrieval or adding a new return path to the ABI is the wrong way around. Instead I think the right solution is for each thread to register a userspace buffer. You end up adding one or two entries to struct thread (pointer to a structure or pointer to an buffer and length) and if the pointer is non-NULL you copyout a string to the buffer. This avoids signficant new storage in the kernel and means programs that won't use this data don't see it. It also means that the debugger can access it without needing a new PT_ argument. As a minor downside you would introduce some new error conditions if the programmer messes up registration, but we'd probably just have libthr do it in most cases (that would be more debugger friendly since you could hang it off a known location in userspace). -- Brooks From nobody Thu May 22 00:14:52 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2phQ3cH6z5wlyT for ; Thu, 22 May 2025 00:15:02 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b3-smtp.messagingengine.com (fout-b3-smtp.messagingengine.com [202.12.124.146]) (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 4b2phP1yvSz3jrw for ; Thu, 22 May 2025 00:15:01 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=HcEeJC7m; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=RSyhlZos; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.146 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfout.stl.internal (Postfix) with ESMTP id 2CAFD11404F2 for ; Wed, 21 May 2025 20:15:00 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Wed, 21 May 2025 20:15:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1747872900; x=1747959300; bh=7aA7aM6IwS mKnihZYMfeiR4Qrg16cE7dzOH1EdXddfA=; b=HcEeJC7mXckL7yIO1NTs/7D1sj lZ8mzARFhIs5e4J2s/dkfdcK0ChpCigo5d5EqOOa1SPArdMTMVY49yx08+U4aXJY oPr2/Hg2EPa4s8k7x3e2eZKuNBdaJRAbRC9h6pQH7wNd1fmMYyRD9DGmMRSRNQHf uKcXFuQ6MwdWY2+Ld5TeisyU2bVJ4msr62QxoJJvnBdvItA4mjGevbQ/lefyE/St BV1YY8ZsVUNZYFVU/Y682XcMVJw+qaazerEMT18UsXj4Vb812Qax4b1fu4LMnoDd FIQWSPzKfKyqCX7QewHF1oRdnouiRt9PE5bR91+udxXUaihadKSs7tglYrlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747872900; x=1747959300; bh=7aA7aM6IwSmKnihZYMfeiR4Qrg16cE7dzOH 1EdXddfA=; b=RSyhlZosCT7F/5g0YJKQ7r/glvciAn5vHVNbqCjSN9bbAmh61w5 kb0tKcJjP7pGsUC6fHYqALnl0M07Fasw+yqGNqZPwlxKRFAdk/AeQaZ4jOSOVnJm N/rRZalVQhDkPHh9ZKDV43S4uHPz15CtYEGkeGStL88Ypm6txiGnX4OmMMBYe+3W Vr4TYol3en0u5qu4G/72pPUlx2P4/pY4gKEA597AN4Ghg8uxg4Vcuyp4SYeU66SR Dhwxaem/+Q2lFz/Y4Zw8R3VvYzXDVVWyFU/j63sAmXQmORJm6iwA2bNhK9e9xkXT 888aaoNLW8gP9bMf5R1S6wzgglaqQhai0ng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdeggeelucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhho ihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepkeduffeijeeule ethfelleektdeuheektdefgfdvvefgtdevuedtieffgfeigeehnecuffhomhgrihhnpegr rhgthhhivhgvrdhorhhgpdhfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghr tghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsug dqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 21 May 2025 20:14:59 -0400 (EDT) Date: Thu, 22 May 2025 01:14:52 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: epair(4) Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> 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; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4b2phP1yvSz3jrw X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.146:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] On Fri, May 16, 2025 at 09:21:29PM +0100, Lexi Winter wrote: >i am not sure about this. i admit i have not done a survey :-) however, >i believe most people using jails or bhyve are not affected. the >Handbook is clear about the correct way to configure this[0], so people >who followed the handbook to configure their jails or bhyve VMs should >not run into this problem. Your belief that most people using bhyve and jails would be unaffected is, I think, misplaced. The handbook has only been clear about the "correct way to configure" this since around the middle of last year [1] https://web.archive.org/web/20240725082825/https://docs.freebsd.org/en/books/handbook/virtualization/ in 24.6.13 Prior to that, like https://web.archive.org/web/20240406173929/https://docs.freebsd.org/en/books/handbook/virtualization/ in 24.6.10 or in https://web.archive.org/web/20210301113601/https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-host-bhyve in 22.7.9 there's no mention of the now-correct way of configuring bridge in a bhyve context. Maybe it'd be an idea to have section 24.7.13 immediately following 24.7.1 in the (latest) handbook and also a note to make it clear that members of a bridge cannot, as just members, be individually assigned an ip. [1] relevant because typically bhyve hosts are high-uptime hosts. Conceivable that the network won't typically be thought to have to be reconfigured after an update/upgrade. -- From nobody Thu May 22 05:04:19 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2x6V6Dplz5vrKj for ; Thu, 22 May 2025 05:04:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2x6V3PKKz41b4; Thu, 22 May 2025 05:04:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 54M54JhL000279; Thu, 22 May 2025 08:04:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 54M54JhL000279 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 54M54JAV000278; Thu, 22 May 2025 08:04:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 May 2025 08:04:19 +0300 From: Konstantin Belousov To: Brooks Davis Cc: Warner Losh , freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL Message-ID: References: <202505210722.54L7MTqw025632@critter.freebsd.dk> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4b2x6V3PKKz41b4 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:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- On Wed, May 21, 2025 at 11:23:12PM +0000, Brooks Davis wrote: > On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote: > > In short, I'd love to widen the interface, but there's a number of practical > > issues in the way. > > I think caching something in the kernel of later retrieval or adding a > new return path to the ABI is the wrong way around. Instead I think the > right solution is for each thread to register a userspace buffer. You > end up adding one or two entries to struct thread (pointer to a > structure or pointer to an buffer and length) and if the pointer is > non-NULL you copyout a string to the buffer. This avoids signficant > new storage in the kernel and means programs that won't use this data > don't see it. It also means that the debugger can access it without > needing a new PT_ argument. > > As a minor downside you would introduce some new error conditions if the > programmer messes up registration, but we'd probably just have libthr do > it in most cases (that would be more debugger friendly since you > could hang it off a known location in userspace). I mostly agree with this proposal, and can implement it. I strongly object against blowing the kernel with MBs of strings. Userspace can register per-thread extended errno location, and kernel can copyout the ext-errno when returning error. We already have a similar mechanism for fast signals blocking, so I am talking with relatively good experience about related machanism. There is no problem with userspace not registering or messing up the registration: after the first failure the mechanism stops working, until the next registration attempt. Since registration must be per-thread, some libc/libthr wrapper would be provided to fetch the value for C runtime. Go would handle it on its own, as it already does for vdso. I do not see a problem with Rust/Java/Nodejs, since they play well with C runtime. All this is quite doable, and the biggest work is to adjust kernel to record additional metadata to places where it identifies an error condition. From nobody Thu May 22 06:05:02 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2ySl39L6z5vvrP for ; Thu, 22 May 2025 06:05:27 +0000 (UTC) (envelope-from dch@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2ySl2344z3T0W; Thu, 22 May 2025 06:05:27 +0000 (UTC) (envelope-from dch@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747893927; 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=f6WNLNWog7THXk/q6vK4ES1H82gSXxqq59t+AdMYJhE=; b=uP1XXMbHRKGYlDCQp+swXrtw8DjZDhXM2wQFBSlXSi1hm4i+5DPtdIycTJPex3IG8f81LG NXcT79zIBxo+CJJfbLc3aiBhy94JKdp5DNrkpbqBihHSjmAHw0kUBZGQY7WWAmi9L2msq4 /MTq3Ozg8klNtECXBkYFVB090Rvbvnb722EVhgEPRm0g02jQqN4OmJu20RPvYI3EcYndnI kjPIxzuh8oZYE15djedMUeQV6sC1J2lzayHrs752SDgv9EIcgD8BNvcWAAfuv0ALxAfEKV QHngZC2MojYobeqqKjOoztR7/HmG0MF7nut7i9mUvgxPrHx07hNTCwhKV4lIMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747893927; 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=f6WNLNWog7THXk/q6vK4ES1H82gSXxqq59t+AdMYJhE=; b=WCvCtSr5aSvZeqvGMltfstnToMEkxzOKnPbUlxOBx5ADEiamaFapFanrbJopGJCq0v3wSD 8ShAJzg7sN5yH2jbmGR7yPK29jChBCXhDP8Ug46MWJv6i3YsVddzn2F9U0WlNolLz4XP1l Pnvt+i448p522yoS8aR4LXeW4k483CQwDbIRYFm1gMLSJvlGNeus1AAELYC8KOBHRApZgl CHQB/42b9qjoWVlrhflrZnJI4hZBx4pnx+mVSO+YbNTGty73FRepYwuVKpfISRgyUkiqZp 4FB3JxgQE/5D5J2o9T8OJ68aQ8uAR9B1wYJCcgO8GAqaQwysd94IQQG7tVEyDQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747893927; a=rsa-sha256; cv=none; b=pB+wikUqu6mbDh45Nkn7yXY+bbaA47rci/Qfxweayppp/fxTacELpbGcFYcaeY5I3PWH7n TYYhxvWVJ9XsmoDBZtFO9XOC14uhCHh4YF82m3g/nf1g113oJO/Fe2S4UaYKp2O0FRxW/1 JH7D10vDJPf/kN9ZgeJJw84WfTXtMNDo3O/53J1uL3vnaOZIcSQn3WjJ67Bomp8zcwfUl/ wnkxOq5HPSRhq5vBVHZ0CrR3tCmHlVlhXqb4gkSPjraZf9LqnEOuiZ+UX/Pf41KyMgM6hU m35GXrwryZ247AW5KM4/XDIkBsa4yJOgxBvBvEp9LhPXUixdFoyPbMfWRed5UQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.201]) (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) (Authenticated sender: dch/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2ySl0GdHzQ3t; Thu, 22 May 2025 06:05:26 +0000 (UTC) (envelope-from dch@freebsd.org) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 7A65C1200066; Thu, 22 May 2025 02:05:26 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Thu, 22 May 2025 02:05:26 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdehvddtucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofggfffhvfevkfgj fhfutgfgsehtqhertdertdejnecuhfhrohhmpedfffgrvhgvucevohhtthhlvghhuhgsvg hrfdcuoegutghhsefhrhgvvgeuufffrdhorhhgqeenucggtffrrghtthgvrhhnpeefkeef tddtveehfeffveduvedtueeiffefhfejjeevgedvgedtffeiudetheevudenucffohhmrg hinhepfhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpegutghhodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhith ihqdduvdegledutdefgeduqdduvddufeduudejjedquggthheppehfrhgvvggsshgurdho rhhgsehfrghsthhmrghilhdrfhhmpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmth hpohhuthdprhgtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggsshgu rdhorhhgpdhrtghpthhtohepiihirggvvgesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: icedc46df:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 4F5772CC007F; Thu, 22 May 2025 02:05:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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-ThreadId: T64369be723759504 Date: Thu, 22 May 2025 06:05:02 +0000 From: "Dave Cottlehuber" To: freebsd-current Cc: "Alexander Ziaee" Message-Id: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> In-Reply-To: References: Subject: Re: Updating build and jail manual pages to include missing or obscure information Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 20 May 2025, at 21:17, Billiam Crashkopf wrote: > Hello all, > > I recently had a bit of trouble finding the proper make targets to bui= ld=20 > and install the base FreeBSD system from source into an empty director= y=20 > for use in a jail.=C2=A0 I had scoured the build(7) manual trying to f= ind the=20 > right workflow, but was unable to come up with a solution based solely=20 > on the information available. After some discussion on the forum it wa= s=20 > discovered that the answer was in fact in the jail(8) manual, under th= e=20 > Examples section.=C2=A0 However, the make targets listed in the jail(8= )=20 > manual are not documented in the build(7) manual. =C2=A0 I'd like to o= pen a=20 > discussion around updating the documentation to make the correct=20 > information easier to find.=C2=A0 Specifically: > > =C2=A0 * Should the 'world' and 'distribution' targets, and examples = of=20 > their use, be included in the build(7) manual? > > =C2=A0 * Is the workflow listed in the jail(8) manual currently corre= ct?=C2=A0=20 > Should it cross-reference the build(7) manual?=C2=A0 Is there a way to= make=20 > the information more discoverable? > > =C2=A0 * Is it worth adding these instructions, or a reference to the= m, to=20 > the Handbook? > > For reference, the original discussion is here:=20 > https://forums.freebsd.org/threads/installing-world-into-an-empty-jail= .97866/ > > My intent is to file PRs for any changes and, if it would be helpful,=20 > draft edits. > > Thanks, > > Bill Hi Bill yes to all of those I think. I believe Alex is doing some work in this area already, I'm happy to help as a reviewer btw despite my lack of knowledge of manpage macros. A+ Dave From nobody Thu May 22 07:20:02 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b30766qhWz5w0sZ for ; Thu, 22 May 2025 07:20:18 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b30764CF9z3wVw; Thu, 22 May 2025 07:20:17 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.18.1/8.18.1) with ESMTPS id 54M7K34e096981 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 22 May 2025 09:20:03 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.18.1/8.18.1/Submit) id 54M7K2Rq096980; Thu, 22 May 2025 09:20:02 +0200 (CEST) (envelope-from fuz) Date: Thu, 22 May 2025 09:20:02 +0200 From: Robert Clausecker To: Poul-Henning Kamp Cc: Warner Losh , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL Message-ID: References: <202505210722.54L7MTqw025632@critter.freebsd.dk> <202505211914.54LJEmmd004452@critter.freebsd.dk> 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: <202505211914.54LJEmmd004452@critter.freebsd.dk> X-Rspamd-Queue-Id: 4b30764CF9z3wVw 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:16276, ipnet:2001:41d0::/32, country:FR] X-Spamd-Bar: ---- Am Wed, May 21, 2025 at 07:14:48PM +0000 schrieb Poul-Henning Kamp: > > In short, I'd love to widen the interface, but there's a number of practical > > issues in the way. > > Not really ? > > Our kernel is not I18N'ed and we have no plans to do so. > > That means that there is absolutely no point in taking a big detour over > enumerating all possible messages into some "int assistant_to_errno", > we can and should simply pass the informative text-string straigt through. So basically like Plan 9's errstr? https://man2.aiju.de/2/errstr Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments From nobody Thu May 22 13:39:33 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b38Xn6hpHz5wgJc; Thu, 22 May 2025 13:39:37 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [IPv6:2a0c:5a00:149::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b38Xn4cP3z3nqp; Thu, 22 May 2025 13:39:37 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1uI690-0067xQ-GG; Thu, 22 May 2025 15:39:34 +0200 Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1uI68z-0000uk-PC; Thu, 22 May 2025 15:39:34 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1uI68z-00029a-NI; Thu, 22 May 2025 15:39:33 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline 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 Received: from [Authenticated alias (960477)] by runbox.com with http (RMM6); Thu, 22 May 2025 13:39:33 GMT From: "Alexander Ziaee" To: "Dave Cottlehuber" , "freebsd-current" CC: "doc" , "emaste" Subject: Re: Updating build and jail manual pages to include missing or obscure information Date: Thu, 22 May 2025 13:39:33 +0000 (UTC) X-RMM-Aliasid: 960477 X-Mailer: RMM6 In-Reply-To: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> Message-Id: X-Rspamd-Queue-Id: 4b38Xn4cP3z3nqp 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:50304, ipnet:2a0c:5a00::/29, country:NO] X-Spamd-Bar: ---- On 2025-05-22 02:05 -04:00 EDT, "Dave Cottlehuber" wrote: > On Tue, 20 May 2025, at 21:17, Billiam Crashkopf wrote: >> Hello all, >> >> I recently had a bit of trouble finding the proper make targets to build= =20 >> and install the base FreeBSD system from source into an empty directory= =20 >> for use in a jail.=C2=A0 I had scoured the build(7) manual trying to fin= d the=20 >> right workflow, but was unable to come up with a solution based solely=20 >> on the information available. After some discussion on the forum it was= =20 >> discovered that the answer was in fact in the jail(8) manual, under the= =20 >> Examples section.=C2=A0 However, the make targets listed in the jail(8)= =20 >> manual are not documented in the build(7) manual. =C2=A0 I'd like to ope= n a=20 >> discussion around updating the documentation to make the correct=20 >> information easier to find.=C2=A0 Specifically: >> >> =C2=A0 * Should the 'world' and 'distribution' targets, and examples of= =20 >> their use, be included in the build(7) manual? There seems to be a rough consensus that we should remove the world and ker= nel targets. https://reviews.freebsd.org/D50276 I like them, the workflow listed in jail(8) is massively simpler and faster= than the current recommended workflow of building a pkgbase jail. >> =C2=A0 * Is the workflow listed in the jail(8) manual currently correct= ?=C2=A0=20 >> Should it cross-reference the build(7) manual?=C2=A0 Is there a way to m= ake=20 >> the information more discoverable? For a long time, build(7) said to read src/UPDATING. I think for discoverability and maintainability, we should put all the exam= ples on build(7)ing the system in the examples section of build(7), and the= n reference that everywhere. That will be much easier to maintain, and the documentation on the targets = and variables is already there. >> =C2=A0 * Is it worth adding these instructions, or a reference to them,= to=20 >> the Handbook? I would like there to be a reference and not doc that will get stale. It is= very hard to maintain all the duplicated information. >> For reference, the original discussion is here:=20 >> https://forums.freebsd.org/threads/installing-world-into-an-empty-jail.9= 7866/ >> >> My intent is to file PRs for any changes and, if it would be helpful,=20 >> draft edits. >> >> Thanks, >> >> Bill >=20 > Hi Bill >=20 > yes to all of those I think. >=20 > I believe Alex is doing some work in this area already, I'm happy > to help as a reviewer btw despite my lack of knowledge of manpage > macros. Hey, thanks for cc'ing me! Yes I am working on this; everyone is invited an= d here's what I've got so far: https://reviews.freebsd.org/D48693 I have the manpage macros down; the issue is "what is the correct practice = that we want to be recommending?" and "what examples should we have or not = have?".=20 Best, Alex= From nobody Thu May 22 13:56:38 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b38wj1vYrz5whQ8 for ; Thu, 22 May 2025 13:56:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 4b38wh4Wg1z3xB5 for ; Thu, 22 May 2025 13:56:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-30e57a37294so7581940a91.2 for ; Thu, 22 May 2025 06:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1747922211; x=1748527011; 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=sBsfG/0tb5wRXzsS2oFe+PVxA54jxL/NkBLgl4RNld0=; b=EbI3aPxZrcdzLbPEGpTDt1lp/Pg8FjRn3oKCyA0NPrniijrNlx8A2RvGfw+pFwp5/l 87P7bDh0epQ+S9uxuVQogaz0ig7fFYZjrYfew67wASRIkhLHfwwIonaW146TL2Bolv9m 1m82QDhRp7E8n2JhSRW/Dko3ylL/ht+x9zj6/BkJzUf8WY79ioAkflrMPNXW1/oHer17 ODTgwd3gqHGX5gaJEP1HG7YJ95iFcJv4vbFGsRs5eZALGwY/3ZP5mblseUeCSt/jfZnl rv0h77vBONdOdTRqs2mJ18a2bUvjxE7/+hFHPQESIPye9VmPm8rl/1oPz0M3767Kqrs8 R4Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747922211; x=1748527011; 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=sBsfG/0tb5wRXzsS2oFe+PVxA54jxL/NkBLgl4RNld0=; b=P7ou8TKHr8COBjJZBsfOXhrySESQaKNH/fifaHijWCMMIafPWCejuDRXjBd3ZHKEK/ 76mV/tZXsXQIUYeMrYWbqZkj7py2nvgman8VyvAEKiKGBt7/zKffX/fyZ2EG5Amlk+1c yvefPD0nbozv7mFyr+ghJgUvW5202h1cBfCM4LnaXD2HrqBLLYlphJ93XcdOHjVvZfrF 1U0FBID4Pt82yAy3qmSiU+nVTzcLu1J3Getn9VmTT4zwX2I6glubp/KIHttgEBc3ILH4 vZCunMMpNNsqfRnSxDU/raKJjQT7pc9VIE0L3DWI6BivFDZNxmDpqTMPnxLRrlpqahC2 VJpg== X-Forwarded-Encrypted: i=1; AJvYcCWLkj7dp1NjnEBci0tj7ahjC6Z6Gr1sTfwWAsR+J4XRTqluLSHCMbq3wt+YefKf1Q76XLpdSeToIP8e6kv8NUY=@freebsd.org X-Gm-Message-State: AOJu0YxK5VPDlcc5e5mlXwosAnY+WDNqZ/3/f0RQLndFTt1odYkYg6sk pLW6PvdASoZkWdePK4Ib0TxC+C2DZMdBNwNd0MqUcm8P9A+DTVH/aKwsFP5YYVBCI/Zt+mghSCe y29boBHa93CCpDTyg7lViIEzQ2yKhoR6voSGby7ByzA== X-Gm-Gg: ASbGncun9pJ5Dxx7fzoO7o1DQTi/peSeiDMZq+FEpPhqOKY9tAnsKIcOMM3vgybh4uv GlckEqkHLmt7btRywaBTIvxIWSz5dT34ELUe84PHaD1xh56iUKIOAm7ZjBS17ur7GbEw+J6OvrW q8AHxu5TBKTpWiTos8cNgy1g6tp15wgyXBXR0YtssAhnhmzUgTpBzdIi5XVE8nDHHK3a+Ttn7PC GquvQ== X-Google-Smtp-Source: AGHT+IHeBv2tepc+udB8Pcl+YR03EpuuhM/PZsD+8CQFL5MREkQY1agx5BPQib6vmbqyBj8LIVWSU7M1oVyddyNirw8= X-Received: by 2002:a17:90b:52c8:b0:30e:382f:8b86 with SMTP id 98e67ed59e1d1-30e8312dc73mr41522466a91.15.1747922210969; Thu, 22 May 2025 06:56:50 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> In-Reply-To: From: Warner Losh Date: Thu, 22 May 2025 07:56:38 -0600 X-Gm-Features: AX0GCFvhvL06QvmLtN1NW23rAQ4sVhS080HByVwLmA7ARXTTYgShOnqoMxtfSMU Message-ID: Subject: Re: Updating build and jail manual pages to include missing or obscure information To: Alexander Ziaee Cc: Dave Cottlehuber , freebsd-current , doc , emaste Content-Type: multipart/alternative; boundary="0000000000007aefaa0635b9da76" X-Rspamd-Queue-Id: 4b38wh4Wg1z3xB5 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-Spamd-Bar: ---- --0000000000007aefaa0635b9da76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2025, 7:40=E2=80=AFAM Alexander Ziaee w= rote: > On 2025-05-22 02:05 -04:00 EDT, "Dave Cottlehuber" > wrote: > > On Tue, 20 May 2025, at 21:17, Billiam Crashkopf wrote: > >> Hello all, > >> > >> I recently had a bit of trouble finding the proper make targets to > build > >> and install the base FreeBSD system from source into an empty director= y > >> for use in a jail. I had scoured the build(7) manual trying to find > the > >> right workflow, but was unable to come up with a solution based solely > >> on the information available. After some discussion on the forum it wa= s > >> discovered that the answer was in fact in the jail(8) manual, under th= e > >> Examples section. However, the make targets listed in the jail(8) > >> manual are not documented in the build(7) manual. I'd like to open a > >> discussion around updating the documentation to make the correct > >> information easier to find. Specifically: > >> > >> * Should the 'world' and 'distribution' targets, and examples of > >> their use, be included in the build(7) manual? > > There seems to be a rough consensus that we should remove the world and > kernel targets. > > https://reviews.freebsd.org/D50276 > > I like them, the workflow listed in jail(8) is massively simpler and > faster than the current recommended workflow of building a pkgbase jail. > I object to removing these. I do agree we should document other methods, but my spidt sense is this is still in use... >> * Is the workflow listed in the jail(8) manual currently correct? > >> Should it cross-reference the build(7) manual? Is there a way to make > >> the information more discoverable? > > For a long time, build(7) said to read src/UPDATING. > I think for discoverability and maintainability, we should put all the > examples on build(7)ing the system in the examples section of build(7), a= nd > then reference that everywhere. > We recommended that to make sure people read the entries. So i wouldn't remove that, but it might make sense to trim but not remove it from UPDATING. Users only need to have more/vi working, and not man and all the things it calls. That will be much easier to maintain, and the documentation on the targets > and variables is already there. > We had a lot in Makefile to cope with a lot of churn in the early days. Plus having the docs with the code is quite helpful when trying to rebuild a system. Maybe things are settled enough we can move. Maybe the weight given to the rebuild the system can be reduced, but I worry that when things go wrong with an upgrade this may get in the way. >> * Is it worth adding these instructions, or a reference to them, to > >> the Handbook? > > I would like there to be a reference and not doc that will get stale. It > is very hard to maintain all the duplicated information. > Most of it should be in the handbook, despite the duplication. Especially the examples. The whole purpose of the handbook is to do the explaining, and a lot of the stuff in build(7) more properly belongs there.... snd that dynamic is another reason UPDATING and Makefile* have had a lot of this traditionally. I don't think it's as binary as you suggest. Warner Warner >> For reference, the original discussion is here: > >> > https://forums.freebsd.org/threads/installing-world-into-an-empty-jail.97= 866/ > >> > >> My intent is to file PRs for any changes and, if it would be helpful, > >> draft edits. > >> > >> Thanks, > >> > >> Bill > > > > Hi Bill > > > > yes to all of those I think. > > > > I believe Alex is doing some work in this area already, I'm happy > > to help as a reviewer btw despite my lack of knowledge of manpage > > macros. > > Hey, thanks for cc'ing me! Yes I am working on this; everyone is invited > and here's what I've got so far: > > https://reviews.freebsd.org/D48693 > > I have the manpage macros down; the issue is "what is the correct practic= e > that we want to be recommending?" and "what examples should we have or no= t > have?". > > Best, > Alex > --0000000000007aefaa0635b9da76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 22, 2025, 7:40=E2=80= =AFAM Alexander Ziaee <ziaee@freebs= d.org> wrote:
On 2025-05-22 = 02:05 -04:00 EDT, "Dave Cottlehuber" <dch@FreeBSD.org> wrot= e:
> On Tue, 20 May 2025, at 21:17, Billiam Crashkopf wrote:
>> Hello all,
>>
>> I recently had a bit of trouble finding the proper make targets to= build
>> and install the base FreeBSD system from source into an empty dire= ctory
>> for use in a jail.=C2=A0 I had scoured the build(7) manual trying = to find the
>> right workflow, but was unable to come up with a solution based so= lely
>> on the information available. After some discussion on the forum i= t was
>> discovered that the answer was in fact in the jail(8) manual, unde= r the
>> Examples section.=C2=A0 However, the make targets listed in the ja= il(8)
>> manual are not documented in the build(7) manual. =C2=A0 I'd l= ike to open a
>> discussion around updating the documentation to make the correct <= br> >> information easier to find.=C2=A0 Specifically:
>>
>>=C2=A0 =C2=A0 * Should the 'world' and 'distribution= 9; targets, and examples of
>> their use, be included in the build(7) manual?

There seems to be a rough consensus that we should remove the world and ker= nel targets.

https://reviews.freebsd.org/D50276

I like them, the workflow listed in jail(8) is massively simpler and faster= than the current recommended workflow of building a pkgbase jail.

I object = to removing these. I do agree we should document other methods, but my spid= t sense is this is still in use...

>>=C2=A0 =C2=A0 * Is the workflow listed in the jail(8) manual curren= tly correct?=C2=A0
>> Should it cross-reference the build(7) manual?=C2=A0 Is there a wa= y to make
>> the information more discoverable?

For a long time, build(7) said to read src/UPDATING.
I think for discoverability and maintainability, we should put all the exam= ples on build(7)ing the system in the examples section of build(7), and the= n reference that everywhere.
=
We recommended that to make sure people read th= e entries. So i wouldn't remove that, but it might make sense to trim b= ut not remove it from UPDATING. Users only need to have more/vi working, an= d not man and all the things it calls.

That will be much easier to maintain, and the documentation on the targets = and variables is already there.

We had a lot in Makefile to cope with a lot = of churn in the early days. Plus having the docs with the code is quite hel= pful when trying to rebuild a system. Maybe things are settled enough we ca= n move. Maybe the weight given to the rebuild the system can be reduced, bu= t I worry that when things go wrong with an upgrade this may get in the way= .


>>=C2=A0 =C2=A0 * Is it worth adding these instructions, or a referen= ce to them, to
>> the Handbook?

I would like there to be a reference and not doc that will get stale. It is= very hard to maintain all the duplicated information.

Most of it should be = in the handbook, despite the duplication. Especially the examples. The whol= e purpose of the handbook is to do the explaining, and a lot of the stuff i= n build(7) more properly belongs there.... snd that dynamic is another reas= on UPDATING and Makefile* have had a lot of this traditionally. I don't= think it's as binary as you suggest.

=
Warner

Warner

--0000000000007aefaa0635b9da76-- From nobody Thu May 22 15:59:14 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3Cdv38Rbz5wr3Q for ; Thu, 22 May 2025 15:59:15 +0000 (UTC) (envelope-from brooks@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3Cdv0Gzpz3cW5; Thu, 22 May 2025 15:59:15 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747929555; 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=x1J1Hy0onQrdxyNR8+wMia7S73dEMpQcgV8o8GjPKBI=; b=WzaGla+PRNDt9hY/+516UoxhNtSirKiWNn0kGkNvedL8Ja/UvUZhg1TR2mAZG2Bwes9ZJw NVhhZ+ia/ukz3FJV899HDot8kGzKCMyJXwYadPuhyv0yc75RwbZCjiROktb2v4KZUk/5n8 MYCj788QApcCJpOut1TsEmK4J3KgoM7zig/TFTw8wwXEFELDATecd+V0Dl8k07hZUEdjqX b7EEvuOjY9VKmXaD2+wtK7s5l4bCUo5crgAEqBDahZiP4f2S7G3Xw/OjaJW7/43cme7t6V ir/+ad0mCPeZlhVQD4edlUoYzGOxD/Nei1zJMfVINpsNW9yk53+Pzrc3ZWM27A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747929555; 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=x1J1Hy0onQrdxyNR8+wMia7S73dEMpQcgV8o8GjPKBI=; b=oWSebtOp4C9mw6QZaVguA9fuuSTXDHxbRO6Co5dqeED4OvBvUJFV1+0iHXiyGtmlWV4hdE vKbRaYzcPSGm/YuMVrobzI4Lcqo9PVGmbDM75/oXa+ZFiiUyPNLI3NkQFSxiNgByXd+gkx jUzuASO7XSH+D5r8WLc3nunsbYrHWGmszQ56moerjOSebC2cWimibZLjnUAZn6XMcB4BpL f3XlTMgnskO2RoIqWJOpELtD/lHLIlTuwYzkNlP/qkyJhj+KUJmsqVDrPAPoFGYwcc/w2D QLs5Ju8uZw9UnSRsfTl3qX09W4bFmVKNrTiskzUb54FTO2Tq1kfXhcigUidJtw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747929555; a=rsa-sha256; cv=none; b=AuD1OwK5g2oPRWV4T4bvgmAXMpdMye9YKjyn0jDo79QLQ2eFBUemxl2rYjyW3zXS1bL7pY yN1XOz/o6apcJtt56sYLTEx4WkugNVdY69JOexQsB5rvBYvOmupROBw93NeEQ0OrOUBU9b qV74/Xq3ByUfGokJ5prowPxSlYVsyaZcurvhr+0HJcG4WMv4XCZZGEjZCRiI4DQ9+N0Q4E Pnw7frzFAzKnsVveLJPvaWaIv8t0WFeDwg6v/lkC47GviRQLlCZ575HKoLL/moRq22xRx6 bLwjP1Sy1HaBzgFJFbFtq+j3jIb2rUs/KQRse3GJul9OAwZuMr7tk3zNzQcDvA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b3Cdt4cbjzvPw; Thu, 22 May 2025 15:59:14 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 120653C01A0; Thu, 22 May 2025 15:59:14 +0000 (UTC) Date: Thu, 22 May 2025 15:59:14 +0000 From: Brooks Davis To: Konstantin Belousov Cc: Warner Losh , freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL Message-ID: References: <202505210722.54L7MTqw025632@critter.freebsd.dk> 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: On Thu, May 22, 2025 at 08:04:19AM +0300, Konstantin Belousov wrote: > On Wed, May 21, 2025 at 11:23:12PM +0000, Brooks Davis wrote: > > On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote: > > > In short, I'd love to widen the interface, but there's a number of practical > > > issues in the way. > > > > I think caching something in the kernel of later retrieval or adding a > > new return path to the ABI is the wrong way around. Instead I think the > > right solution is for each thread to register a userspace buffer. You > > end up adding one or two entries to struct thread (pointer to a > > structure or pointer to an buffer and length) and if the pointer is > > non-NULL you copyout a string to the buffer. This avoids signficant > > new storage in the kernel and means programs that won't use this data > > don't see it. It also means that the debugger can access it without > > needing a new PT_ argument. > > > > As a minor downside you would introduce some new error conditions if the > > programmer messes up registration, but we'd probably just have libthr do > > it in most cases (that would be more debugger friendly since you > > could hang it off a known location in userspace). > > I mostly agree with this proposal, and can implement it. > I strongly object against blowing the kernel with MBs of strings. > > Userspace can register per-thread extended errno location, and kernel > can copyout the ext-errno when returning error. I really want them to be strings in the kernel. Anything else is too annoying to maintain and will interact poorly with running old versions of userspace and introduce namespace complications for downstreams. If you want the option to save the space, make the interface that copies the string out a macro and provide an option to compile them away. (Using a macro would also allow you to transparently embed e.g., file, function, or line information if desired.) -- Brooks From nobody Thu May 22 16:16:28 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3D1p0fTYz5wrnl; Thu, 22 May 2025 16:16:30 +0000 (UTC) (envelope-from ivy@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3D1n6t5Xz3jYR; Thu, 22 May 2025 16:16:29 +0000 (UTC) (envelope-from ivy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747930590; 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=oqglLz/jEi9s29JgypDvIo9Qrv6mgnz0wCVkUqO35aU=; b=O9fgzCehfWmA+Z2axPBxFH9Bje0sO0G/cFYWhUaLT4wVWiJryCY34AMy0L4TWh7rNEIjt3 WmnzHzNjKSn7lWR0q8h+U1vg5ymCUA6oIvQEyqk7vhFxy5gIjUzeco2fxRpb8/QwSBRsha o+7xNQplgBaPozGQSC5/Lpg1tbzJuMq9ASf6z2+74KAdtRFzZHVYxqNaluivoBxid3Sf5f wPZRLKascyfBBkNH6vu/ZqXmU4BF6i2kW2r0cF651krcpL8/l+TTsMGcbFy25mUJXfLrJI ncSrLWuky39gB+Mm1FIhiVN6aGTuzZGPel1R872CbcoUgNbf855c5uEg0GC+DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747930590; 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=oqglLz/jEi9s29JgypDvIo9Qrv6mgnz0wCVkUqO35aU=; b=GA6uv+4TXVjLMmD9Ql8J7O9BrhxcBrKtiSFn7lanX9nybSh6nXkCvr1YwX4TEBiZ/fXx1I 3ZFxlWXnhUzMSH2VbJqTRvMkmCNipjO5PPVhnMjAe/3/+aPiVW0Pp5u+PGDOvpVbYC5dW1 ggFhly3Gtvu4/2WyOJ3qr2q3OyhAXK9XwnOFvgN7rNiEeZsBzu9TiOHXI0qlxWIWCz6KTP hHgd9yML/HG7gnP8xqSeDqik2o1u29rym4qj0V6VNki7lrG+wImA33dtrsVmnE2rdaauQA WLRM+67KjwEU7Yc9rVlT0BTM1BTfOotjjPx08ZZoLj0oDxDE0fCFc1HTQe/0pQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747930590; a=rsa-sha256; cv=none; b=NArMGoMavTS3EsynQgPBzj7KJe0vYBFocjr+DqeWZk1mrnGiuapbteQbqRstUKKqKgBztT kxQfhhWTrvq0/KqzIe0sUiEsKhbI+QSTGjIWPKfCI+5vouGjJqZbaLKrJ924HdJGxvq8FD +2gNA5nmD3u+Tprc4Sc1Yk4541HgYbJDlvjmFYlk6wpXAwsT52UuEzVWT5/X3m40xxJ6Ts 2vDhUOtyTUefAmc+UHQM7TyFwyrZGZW+uFzZdYksXYFH4ZZiAX1kkQ4KPQL00QddQm7bFQ iTNaG8OjzYsUVRSKHhis+8Z62JR9N3PSfCtvaqY3+O3K6jREayCCJqNGXRRvaQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ragweed.eden.le-fay.org (ragweed.eden.le-fay.org [IPv6:2001:8b0:aab5:c401:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b3D1n1Kf2zw8b; Thu, 22 May 2025 16:16:29 +0000 (UTC) (envelope-from ivy@FreeBSD.org) Date: Thu, 22 May 2025 17:16:28 +0100 From: Lexi Winter To: Warner Losh Cc: Alexander Ziaee , Dave Cottlehuber , freebsd-current , doc , emaste Subject: Re: Updating build and jail manual pages to include missing or obscure information Message-ID: Mail-Followup-To: Warner Losh , Alexander Ziaee , Dave Cottlehuber , freebsd-current , doc , emaste References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pUiAu0w3ayFZj2M0" Content-Disposition: inline In-Reply-To: --pUiAu0w3ayFZj2M0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Warner Losh: > On Thu, May 22, 2025, 7:40=E2=80=AFAM Alexander Ziaee = wrote: > > There seems to be a rough consensus that we should remove the world and > > kernel targets. >=20 > I object to removing these. I do agree we should document other methods, > but my spidt sense is this is still in use... note that 'make world' already doesn't work unless you're using DESTDIR (or you set a special make knob) so it shouldn't be documented as a way of upgrading the system in general, e.g. in build(7). afaik, every invocation of 'make world' can be trivially replaced by 'make buildworld installworld', but there may be some argument for keeping it around for people who use it to build jails, for the sake of muscle memory. --pUiAu0w3ayFZj2M0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaC9N2wAKCRD1nT63mIK/ YHr0AQDPLEkrZ42dlsFtVdbfFYSLrLLBoDnb3PB0FrW4icZA6wEA68Ii7+Op0DIG w4VLJpCOYLRz6HmeMsA2y/rKzwfaOQg= =pxj2 -----END PGP SIGNATURE----- --pUiAu0w3ayFZj2M0-- From nobody Thu May 22 17:05:34 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3F6X0VrTz5wvK3 for ; Thu, 22 May 2025 17:05:40 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (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 4b3F6V5ylMz3wvF for ; Thu, 22 May 2025 17:05:38 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=U2eyR9Bu; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=eEjoCgGD; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.148 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id 2870F11400B7 for ; Thu, 22 May 2025 13:05:37 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Thu, 22 May 2025 13:05:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1747933537; x=1748019937; bh=3KKLerIVwv v8IP6eYsKkNDjntjYmSOVD5pn2P9/t10Q=; b=U2eyR9Bu3s9LqGgTe6m/kvlMkj OI703kJWb5HcZGVfD0vFZzBQzltFS7WWyIFT+Vzf5vWe/WJkRaxur3TfAq5o3Lu0 68tLS4WkLeCaJ740NXILljabIT8rl0ptwIMWRX91OGsEpl3I0Rhmqasm0c9pZJbp aX14qRSOdmmVp5t9nZlYyqJtIdmPozysNtFH4u6fmRve+yKxJhhTXq2CXw/qomPT PUc0/yXNFv1orY7c80zO3K/hrNOlwfoIoKgRd3WXvuaOp34ml5ckoXXUZxRK8zw+ lKKHM7xioxuR91E4smWUmq7GAJj0V2O0KZebyezX8pTCvqFg450fN8T8xlPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747933537; x=1748019937; bh=3KKLerIVwvv8IP6eYsKkNDjntjYmSOVD5pn 2P9/t10Q=; b=eEjoCgGDamu4AbhDDBjGs6vMC0eiu0PHorZapkFawRq3sz7bn41 yX4v7OcijcGIzOyJpTuFgL749WN+dcXDVgcSXCnW5MtFB3cwvN5ZpNtldK20KcpJ iSUl3+RnKGxGsNlQi9+CsPX3/DiY/Gfe40IHu6xz4JBKjF0ugNHxvlTEVvOwQgoj LFFzWGAHirBM1rmIULa1i1zuojvutT/7QAJ7u2qfBVgCWX96M8Ph56zYcDCsP51/ qYWTUiZUCg6CfB8ZHBDx2H2m8bzpBWR2/4K8SI+lobTOy/OpsJUUiT10r3p623VC mFEj0BESLU3oGk9DrhzE6ZNoqSN/lcEkNsA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdeiheduucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhho ihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepkeeluddvlefhie elfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgfeunecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnh gspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggv sghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 22 May 2025 13:05:36 -0400 (EDT) Date: Thu, 22 May 2025 18:05:34 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: Updating build and jail manual pages to include missing or obscure information Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.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; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4b3F6V5ylMz3wvF X-Spamd-Bar: - X-Spamd-Result: default: False [-1.35 / 15.00]; NEURAL_SPAM_SHORT(0.99)[0.989]; NEURAL_HAM_LONG(-0.98)[-0.982]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[202.12.124.148:from]; NEURAL_HAM_MEDIUM(-0.36)[-0.357]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.148:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] On Thu, May 22, 2025 at 07:56:38AM -0600, Warner Losh wrote: > >I object to removing these. I do agree we should document other methods, >but my spidt sense is this is still in use... I object also. `make kernel` is useful if only for that by using it, one doesn't need to type `make buildkernel && make installkernel`. -- From nobody Thu May 22 17:25:50 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3FYy4jpgz5wwkG for ; Thu, 22 May 2025 17:25:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 4b3FYx2Ls6z44QC for ; Thu, 22 May 2025 17:25:57 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org; dmarc=none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 54MHPovv080333 for ; Thu, 22 May 2025 17:25:50 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 54MHPotO080332 for freebsd-current@freebsd.org; Thu, 22 May 2025 10:25:50 -0700 (PDT) (envelope-from david) Date: Thu, 22 May 2025 10:25:50 -0700 From: David Wolfskill To: freebsd-current@freebsd.org Subject: Re: Updating build and jail manual pages to include missing or obscure information Message-ID: Mail-Followup-To: David Wolfskill , freebsd-current@freebsd.org References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FGK6EX52fUUxFFsi" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4b3FYx2Ls6z44QC X-Spamd-Bar: - X-Spamd-Result: default: False [-1.83 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.85)[-0.851]; NEURAL_SPAM_LONG(0.76)[0.756]; NEURAL_SPAM_MEDIUM(0.66)[0.663]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; FREEFALL_USER(0.00)[david]; DMARC_NA(0.00)[catwhisker.org]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[] --FGK6EX52fUUxFFsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2025 at 06:05:34PM +0100, void wrote: > On Thu, May 22, 2025 at 07:56:38AM -0600, Warner Losh wrote: > >=20 > > I object to removing these. I do agree we should document other methods, > > but my spidt sense is this is still in use... >=20 > I object also. `make kernel` is useful if only for that by using it, > one doesn't need to type `make buildkernel && make installkernel`. Errr.... If folks actually want to type that much ... more power to them. I find that when I type a lot, I make a lot of mistakes. I don't like making mistakes. So a whlie back (2013 or so, from revision history), I took the instructions from UPDATING under "To rebuild everything and install it on the current system" and implemnted them as a set of (csh) aliases ... after adding a bit of local "seasoning." So now I use "_bw" to do all of that stuff. (Well, I do it within script(1), in a tmux(1) session. And I copy/paste the invocation.) I'm tracking head and (currently) stable/14 daily on 3 machines, one of which is the laptop on which I'm typing this. Said laptop is presently running: g1-124(14.3-S)[4] uname -aUK FreeBSD g1-124.catwhisker.org 14.3-STABLE FreeBSD 14.3-STABLE #441 stable/1= 4-n271545-2919a487021a: Thu May 22 11:39:36 UTC 2025 root@g1-124.catwhi= sker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1403501 1403501 Information on how I do this (though, yeah, the doc lags reality a bit; sorry) is at https://www.catwhisker.org/~david/FreeBSD/upgrade.html Anyway: we have tools. We can make tools. We can make tools that make doing things easier (and less error-prone). Peace, david --=20 David H. Wolfskill david@catwhisker.org Playing croquet whilst wielding a flamingo is hard enough; I don't need someone shouting "Off with his head!" every few minutes, too. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --FGK6EX52fUUxFFsi Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaC9eHl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5U+1AP9mK+9GIcCGjXGmB2HqQEnxep2LYs0fwV6q0ChtY7ZRYAD/WqgixRN7g/1M CzycMsEo5SZZRnUgg5UiFZk93DeAoAI= =pww7 -----END PGP SIGNATURE----- --FGK6EX52fUUxFFsi-- From nobody Thu May 22 17:40:52 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3FvX549Mz5wxbm for ; Thu, 22 May 2025 17:41:12 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3FvX08r1z49pd for ; Thu, 22 May 2025 17:41:11 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 05A9EC; Thu, 22 May 2025 19:41:02 +0200 From: "Patrick M. Hausen" Message-Id: <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E1D06D2C-7E9F-4CC8-9372-6E6804F1AB48" 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.600.51.1.1\)) Subject: Re: epair(4) Date: Thu, 22 May 2025 19:40:52 +0200 In-Reply-To: Cc: freebsd-current@freebsd.org To: void References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b3FvX08r1z49pd 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:16188, ipnet:217.29.32.0/20, country:DE] X-Spamd-Bar: ---- --Apple-Mail=_E1D06D2C-7E9F-4CC8-9372-6E6804F1AB48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, > Am 22.05.2025 um 02:14 schrieb void : >=20 > On Fri, May 16, 2025 at 09:21:29PM +0100, Lexi Winter wrote: >=20 >> i am not sure about this. i admit i have not done a survey :-) = however, >> i believe most people using jails or bhyve are not affected. the >> Handbook is clear about the correct way to configure this[0], so = people >> who followed the handbook to configure their jails or bhyve VMs = should >> not run into this problem. >=20 > Your belief that most people using bhyve and jails would be unaffected > is, I think, misplaced. The handbook has only been clear about > the "correct way to configure" this since around the middle of last = year [1] > [...] The handbook has always been clear about the only correct way to = configure a bridge and member interfaces since the introduction of if_bridge(4) = and the removal of the previous bridge(4) in 2007: = https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/books/handbook/advance= d-networking/chapter.xml?revision=3D30565&view=3Dmarkup If the bridge host needs an IP address then the correct place to set this is on the bridge interface itself rather than one of the member interfaces. This can be set statically or via DHCP. Kind regards, Patrick --Apple-Mail=_E1D06D2C-7E9F-4CC8-9372-6E6804F1AB48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

Am 22.05.2025 um 02:14 schrieb void = <void@f-m.fm>:

On Fri, May 16, 2025 at = 09:21:29PM +0100, Lexi Winter wrote:

i = am not sure about this.  i admit i have not done a survey :-) = however,
i believe most people using jails or bhyve are not affected. =  the
Handbook is clear about the correct way to configure = this[0], so people
who followed the handbook to configure their jails = or bhyve VMs should
not run into this = problem.

Your belief that most people using bhyve = and jails would be unaffected
is, I think, misplaced. The handbook = has only been clear about
the "correct way to configure" this since = around the middle of last year [1]
[...]

T= he handbook has always been clear about the only correct way to = configure
a bridge and member interfaces since the = introduction of if_bridge(4) and the
removal of the previous = bridge(4) in 2007:


<= /div>
= If the bridge host needs an IP address then the = correct
        place to set this is on = the bridge interface itself rather
        = than one of the member interfaces.  This can be set = statically
        or via = DHCP.

Kind = regards,
Patrick


= --Apple-Mail=_E1D06D2C-7E9F-4CC8-9372-6E6804F1AB48-- From nobody Thu May 22 19:09:13 2025 X-Original-To: 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 4b3HsF06QHz5x2xx; Thu, 22 May 2025 19:09:21 +0000 (UTC) (envelope-from ivy@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3HsD4xxJz3pVH; Thu, 22 May 2025 19:09:20 +0000 (UTC) (envelope-from ivy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747940960; 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=EeXWhRSQj42yjAgniuWbYpfcJloiDQYBoO+7F/QXDIQ=; b=JEh7aqnqmQmGkoA2ollRy0c1RBrUJrG5PHJMnndeaoPzI4F+fMyyxUV2OFP1m9KbqwlFR3 kf5WZ/1tVmbO7xl0xb5QbSf2WxUyDC3Qgu6a1qMDZC6ttjtFGNIWcJLLtb8GkCv3U15cJU TFt2JKZZzZvXKoGU4zvt0IgHuy0d9Tb/p4uVQQDAW3DusDRJNZjgiWX95s6ApGZtnxATyR JoESLnQBSTm4x+tOK9BjpE/zmY9n5oAaUXR+CRCSf+Ger7yY7j/CW2ERWJkYZ1mDQ0Wqkc nDwT1SiviPH7lTftPfNpntAH/YigFrIJ+vAgGejX15t9XEKc16TVTASA9LmJkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747940960; 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=EeXWhRSQj42yjAgniuWbYpfcJloiDQYBoO+7F/QXDIQ=; b=oPM9JHOrNfkNsBdUfyOOmiNmi0/oiL0UPHFaYMTMmk/fHYC3gFblj+eDHjKF+Sa9wiOI0Z MeEC3ZbAysj8nGNoqENtNzFxOIbYtxYGe+V/ebEpx4IHXb0yFN+tMbwAm+HtN0bv8k7uHq xPNJVUKc8sf8qg6DUuPjuutLqTIk8r7O8FFbSLi+4lbMSjDTX+91Xy9s3t5TxdY90/DVbD HEN1ZGLDpLfrQGVO68vtLFzUM/VfLH69/z56Aj2P15d2uY9MdRuaH7e2vJ5wibFdwI3NQy 5i8X7ox7qUP2mQbAcVaO0oRuC70vjwI2t8FQZulmUZ1ccRB91G7vetsHOtzIPQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747940960; a=rsa-sha256; cv=none; b=mm4ovs7Gy8LamcYqWQ9xibwUXcQ7Fw+sdB0b/0DwdO5y+uEmWW0+JhRwDF/yhpNRPe0s3L jnrlx+Iax3kbLPXPN7YH54uO48OeR2d2OuyrGwEMwVN63BihCJHIwVuhhHi3sqpshtwpuf jqg7vqUpI1B+dpGn51Jkwo4TgM51/7/HB2+eSSLzynWtL2bgbR445+e0VCjGySiuS36iiU hwKvoid+LFOw/a085ecsslhfo1lo1Gt+xUwZ6e0zoq1MEAnktOp2khcHej9YzyLnjUI0A3 YjgCu2m0ZkLXubhrBqQ3vsFQWz3ZcLAWnXY6qh1Dv+y8Jmr6EX04nS3Ockh1iw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ragweed.eden.le-fay.org (ragweed.eden.le-fay.org [IPv6:2001:8b0:aab5:c401:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b3HsD0nWnzysj; Thu, 22 May 2025 19:09:20 +0000 (UTC) (envelope-from ivy@FreeBSD.org) Date: Thu, 22 May 2025 20:09:13 +0100 From: Lexi Winter To: void Cc: freebsd-net@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: 15.0-CURRENT, =?utf-8?Q?chan?= =?utf-8?Q?ge_to_bridge=284=29_might_break_some_network_configurations_wit?= =?utf-8?B?aCDigJxJbnZhbGlkIGFyZ3VtZW504oCd?= Message-ID: Mail-Followup-To: void , freebsd-net@freebsd.org, current@freebsd.org, net@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OQRcoOl+NE5lGdFF" Content-Disposition: inline In-Reply-To: --OQRcoOl+NE5lGdFF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable void: > On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote: > > in short, following this commit... > >=20 > > b61850c4e6f "bridge(4): default net.link.bridge.member_ifaddrs to false" > > https://cgit.freebsd.org/src/commit/?id=3Db61850c4e6f6b0f21b36da7238db9= 69d9090309e > >=20 > > ...it is now impossible to use a network interface which has an IP > > address assigned to it as a bridge member, or to configure an IP > > address on an interface which is a member of a bridge. >=20 > Hi, for the sake of clarity, when you say "IP addresses assigned to it as > a bridge member", do you mean assigned via eg rc.conf on the host, > or assigned, for example within a VM, or assigned within a bridge stateme= nt? [1] =20 this only applies when the *specific interface which is in the bridge* has an IP address assigned. epair0a is in a bridge, bridge0 has an IP address -> fine epair0a is in a bridge, epair0b is in a jail, epair0b has an IP address -> fine tap0 is in a bridge, connected to a bhyve virtio nic in a VM, the virtual interface inside the VM has an IP address -> fine epair0a is in a bridge, epair0a has an IP address -> broken basically, this only affects you if you do: % ifconfig IF inet / % ifconfig bridge0 addm IF =2E.. and IF is the same interface in both cases. =E2=80=98epair0a=E2=80= =99 and =E2=80=98epair0b=E2=80=99 are not the same interface, for example. > ifconfig_bge1=3D"inet REDACTED.REAL.IP netmask 255.255.255.248 mtu 1500 m= edia 1000baseT mediaopt full-duplex,master" > defaultrouter=3D"REDACTED.REAL.GATEWAY" > ifconfig_bge1_ipv6=3D"inet6 accept_rtadv" > ifconfig_bridge1=3D"addm bge1 addm tap10 addm tap11 addm tap12 \ > addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm ta= p19" as kp said, this is broken, but you can trivially fix it by moving the IP addresses to the bridge interface instead. note that for SLAAC to work on a bridge, you have to set =E2=80=98accept_rtadv=E2=80=99 and =E2=80= =98auto_linklocal=E2=80=99 on the bridge interface explicitly (this is an unrelated issue specific to if_bridge(4)). --OQRcoOl+NE5lGdFF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaC92WAAKCRD1nT63mIK/ YMhnAP0TkG0a4+UxtQ1+1cLiU/2kZPdEbEXIW2R7OpOjwDHAXAD/WSgCunD6d9bJ Flw22LSHL3XBj6wlCxzn3CTneH5VjAI= =SLME -----END PGP SIGNATURE----- --OQRcoOl+NE5lGdFF-- From nobody Thu May 22 19:22:33 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3J8b4Pjxz5x3hk for ; Thu, 22 May 2025 19:22:39 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Received: from g-cipher.net (leon.g-cipher.net [5.9.120.19]) (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 4b3J8Y4VjGz3wtQ for ; Thu, 22 May 2025 19:22:37 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of resin-freebsd@g-cipher.net designates 5.9.120.19 as permitted sender) smtp.mailfrom=resin-freebsd@g-cipher.net; dmarc=none Received: (qmail 92891 invoked from network); 22 May 2025 14:22:35 -0500 Received: from unknown (HELO ?192.168.7.176?) (resin@unknown) by g-cipher.net with ESMTPS (TLS_AES_128_GCM_SHA256 encrypted); 22 May 2025 14:22:35 -0500 Message-ID: <2f6b255b-696c-44ed-9c32-b70daec0ff4f@g-cipher.net> Date: Thu, 22 May 2025 12:22:33 -0700 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: Updating build and jail manual pages to include missing or obscure information To: freebsd-current References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> Content-Language: en-US Cc: doc From: resin-freebsd@g-cipher.net In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4b3J8Y4VjGz3wtQ X-Spamd-Bar: / X-Spamd-Result: default: False [0.63 / 15.00]; NEURAL_SPAM_LONG(0.96)[0.963]; NEURAL_HAM_SHORT(-0.49)[-0.493]; NEURAL_SPAM_MEDIUM(0.26)[0.262]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:24940, ipnet:5.9.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[g-cipher.net]; RCVD_TLS_ALL(0.00)[] On 5/22/25 09:16, Lexi Winter wrote: > Warner Losh: >> On Thu, May 22, 2025, 7:40 AM Alexander Ziaee wrote: >>> There seems to be a rough consensus that we should remove the world and >>> kernel targets. >> I object to removing these. I do agree we should document other methods, >> but my spidt sense is this is still in use... > note that 'make world' already doesn't work unless you're using DESTDIR > (or you set a special make knob) so it shouldn't be documented as a way > of upgrading the system in general, e.g. in build(7). > > afaik, every invocation of 'make world' can be trivially replaced by > 'make buildworld installworld', but there may be some argument for > keeping it around for people who use it to build jails, for the sake > of muscle memory. Just to share my two cents: I think all available options should be documented in the manual.  It's a reference document, so it's there to give a complete view of the interface.  Instructions on anything other than the simplest use cases should be out of scope.  Long-form how-to articles are what the handbook is for.  A README file (i.e. UPDATING) is good as a quick start, but shouldn't be complete reference or point of truth. From nobody Thu May 22 19:27:08 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3JFq0ZnQz5x44c; Thu, 22 May 2025 19:27:11 +0000 (UTC) (envelope-from ivy@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3JFq03N8z42GN; Thu, 22 May 2025 19:27:11 +0000 (UTC) (envelope-from ivy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747942031; 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=ncL6beIMIoX24rhbvxtgZZS+cINt+h9efGk1DnG2gV0=; b=O0FcHvFl7uoxrcSnfFQWLlxr1Usp0g95ndYe+lnzbqOFkgEOXnLRwDfkmIto7SlatjXskq uAUq4U7R9bauFXWzE6lax/gPmTh7QYy6gJnq7YK3nT2dczsERp7tsWbXVB5LQD7N33kFTT n0hRfW139vSNh2dIpyU/Uf2LU/2P1U0oBeg1mib0w8HE40Wh3zA3aIzXHYYCK1P2LU4pjh 1AAAFcfmTvM9tJNxNZ9vJpbpX2RicT8pNGazwIBWz96rp2ZfbAEXL0d+FCN5vG/pEarxVw i+Cy3uW+Bc8Ojw5TEoWvZt2jGMKU6+hUc1TTGy5MOdbxkYfcIoSUbHhyIRYcjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747942031; 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=ncL6beIMIoX24rhbvxtgZZS+cINt+h9efGk1DnG2gV0=; b=JjfRMY7UYXNiwFkOxGvX6hvnho6foH+4cEgrM7pcZ3JyC245giQ56E8nNyzeNT6kdH8lrF HHTCAi0lBYvQB/N4uom19bpeA8wZd0g4ToDT7rbvF0WaLaojqttOeeI2pH00z+kbiWr0zF KUU/PCEXnkB1O8+wQKL1GRG0TOLjvO3ZDIW1x027B3d1ltIeQojA3Uyb81SLiZIFJCuBws OYgHZYX9P/NbQpQmquPXyKGQY5wU9gU9r7sLaUHhDlW4ZzHnjlrbXPZKoQsCo8X9fInIcp /a8pTSD3ev79B4U9xWO69xq6p1Lw53uZt5WQxIINiql724pWFErTQBafWk+OsQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747942031; a=rsa-sha256; cv=none; b=yw2nWnAiYqyRA2vDDwwLq6Nx75Mv2FVKAWVL+k4IvkSgk/EpDDXtYhn0xObF5fzpYRwU3Y hRXdZRFek+1M/IJQPtPfe4E+Q2s9Lf8MF3+tflm1n7cg/Wo+elC6HUhFxHs7uzOhcvJzfA u+JyboPva6F63eSm+JFxBmbty0j9pClmM0nbbza2j+HiXTS5bzWJL4lSJvuC6qKtHRb8l6 f3Js1Xzow0gX6ozrmT57mbaWjteWrmYD7qQYIDYTOrshQ1jvT6Wz8hvJnHl1532exOSVY3 TIvRwhQ+FxrYVL3fWM4vBMX5HamF3D1q2nADoms4M5FJSL7L3IRMUVbtEvMDwA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ragweed.eden.le-fay.org (ragweed.eden.le-fay.org [IPv6:2001:8b0:aab5:c401:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b3JFp306zz10cR; Thu, 22 May 2025 19:27:10 +0000 (UTC) (envelope-from ivy@FreeBSD.org) Date: Thu, 22 May 2025 20:27:08 +0100 From: Lexi Winter To: resin-freebsd@g-cipher.net Cc: freebsd-current , doc Subject: Re: Updating build and jail manual pages to include missing or obscure information Message-ID: Mail-Followup-To: resin-freebsd@g-cipher.net, freebsd-current , doc References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> <2f6b255b-696c-44ed-9c32-b70daec0ff4f@g-cipher.net> 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-sha512; protocol="application/pgp-signature"; boundary="RSAiwcs4/A70kNPM" Content-Disposition: inline In-Reply-To: <2f6b255b-696c-44ed-9c32-b70daec0ff4f@g-cipher.net> --RSAiwcs4/A70kNPM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline resin-freebsd@g-cipher.net: > On 5/22/25 09:16, Lexi Winter wrote: > > note that 'make world' already doesn't work unless you're using DESTDIR > > (or you set a special make knob) so it shouldn't be documented as a way > > of upgrading the system in general, e.g. in build(7). > Just to share my two cents: I think all available options should be > documented in the manual. i'm fine with having 'make world' documented somewhere, although such documentation should probably note that it's been deprecated for over 20 years. i'm just saying it can't be documented as a way of upgrading the host system since it won't do that -- it will refuse to run unless DESTDIR is set, so it can upgrade jails, but not hosts. --RSAiwcs4/A70kNPM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaC96iwAKCRD1nT63mIK/ YKpZAQCQEt2QH5O+ZoIs6V5K0ZU4M2Ibk06qirhfQEy7rSbBhgD/a/atQ4bYOX/2 m6np4y44B3c96/3gJiaEekXqFfe3mQM= =Povw -----END PGP SIGNATURE----- --RSAiwcs4/A70kNPM-- From nobody Thu May 22 19:42:06 2025 X-Original-To: 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 4b3Jb71GFKz5vr6m; Thu, 22 May 2025 19:42:11 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b6-smtp.messagingengine.com (fhigh-b6-smtp.messagingengine.com [202.12.124.157]) (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 4b3Jb6156yz47Fh; Thu, 22 May 2025 19:42:10 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=aRFSO4oT; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="p ykqcCL"; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.157 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id 3DBDC25400E4; Thu, 22 May 2025 15:42:09 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Thu, 22 May 2025 15:42:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1747942929; x=1748029329; bh=YIr/zv5xuSEjwSabpeH94lJnI70KlX58zETlvpZtT6E=; b= aRFSO4oTO69b/fDWv416iXrjAOp6PEtyYj5Iv7wE9AlxgIWFPlclHH7ZjjMhH4Lw oevdML0nuh2oxG2fruI0aeqMmvDW+c3B5iGm9g1BcX+7zAQNMg7OaWZbHbXZCbzD KXRgW67CgaudKTbGklqyHBlGuOvm6zoN6EEtpBhBSuGxREkDeXTgYha7MV5VJtZa g1MGh4myJ3355S42yYwMr9rpdvEfQa521tr5Wkh9vdA4q5ZUlyyqi7CVHhJxgcZ5 PhKlCYlh8DPGbwkFtcIVNHxoSKRRiWI7sAVtgUjbo5Z5rkgWG4cwRIZABVZBuQ1a KW+AsP8YtYb8qaIO3p4YGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1747942929; x= 1748029329; bh=YIr/zv5xuSEjwSabpeH94lJnI70KlX58zETlvpZtT6E=; b=p ykqcCLn+pCCKkms16KEfapn2g+clx0HVqbUkKRuiSE4Ep2KiH5HR1sUxl3hS3p3S 7pVJpimqhYgqeaG9Ky9sUuysNx2T6i1rjk7tE2IXVNV4izaqmhhhvCGBBm6o2RcS KJvZuEzVHhCHqUer6pKvMcPXU55S86TLvjGZtw3do6UyrgCEi8ybzTMp2PkDHVXO Bgtjo+Em2WXWE8iec8EsUJOg3zuAIICkRfstisWjDFUEMDE9knesJLJSnlceNsap sa29G5idia9vuG+VslirBocnG3lG3rCV3sjna1cpYm7Pqu0C6tg9OtBTGZZ7Gc/O QuVwFLV9jOpj0aGzZ307Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdeikedvucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvvefukfhfgggtugfgjgesthekredttddtjeenucfhrhhomhep vhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepleekfeffle ffhfekgedvhffhhedvheehffdvieejhffhveegffdvveevffefiefhnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh dpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhr vggvsghsugdqnhgvthesfhhrvggvsghsugdrohhrghdprhgtphhtthhopegtuhhrrhgvnh htsehfrhgvvggsshgurdhorhhgpdhrtghpthhtohepnhgvthesfhhrvggvsghsugdrohhr gh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 May 2025 15:42:08 -0400 (EDT) Date: Thu, 22 May 2025 20:42:06 +0100 From: void To: freebsd-net@freebsd.org Cc: current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: 15.0-CURRENT, =?utf-8?Q?chan?= =?utf-8?Q?ge_to_bridge=284=29_might_break_some_network_configurations_wit?= =?utf-8?B?aCDigJxJbnZhbGlkIGFyZ3VtZW504oCd?= 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; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4b3Jb6156yz47Fh X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.03 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.992]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_HAM_SHORT(-0.46)[-0.455]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.157:from]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org,freebsd-net@freebsd.org,net@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+] On Thu, May 22, 2025 at 08:09:13PM +0100, Lexi Winter wrote: >as kp said, this is broken, but you can trivially fix it by moving the >IP addresses to the bridge interface instead. note that for SLAAC to >work on a bridge, you have to set ‘accept_rtadv’ and ‘auto_linklocal’ on >the bridge interface explicitly (this is an unrelated issue specific to >if_bridge(4)). Thanks, understood -- From nobody Thu May 22 20:15:42 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3KKt5n1Sz5vswc for ; Thu, 22 May 2025 20:15:46 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b7-smtp.messagingengine.com (fout-b7-smtp.messagingengine.com [202.12.124.150]) (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 4b3KKs73snz3TT6 for ; Thu, 22 May 2025 20:15:45 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=BM2ZgUhc; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=kjU6F4bK; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.150 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id B55101140117 for ; Thu, 22 May 2025 16:15:44 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Thu, 22 May 2025 16:15:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1747944944; x=1748031344; bh=zSS4T4u1r0 +FCGqvYFzTeVzDtpaWshtHIDYF36e3cxw=; b=BM2ZgUhcwrI/6T57iPIk9P1YDM /tp7cj5ZjNNlhvQx36ytYqOrHUp+Ff03kFuCX4QXinl4mUnH4h0V0WtPAZ8TodAl DgAC9uPJxMkuXJR5OwoGR3EH6SH/wy7ec+TXmCgGN+2FQtXssPgHsq/J4K8uCOah GxFoGXe1AWq5Y/wzE3JJjh2O2jB8rzQ1EsRJz9xJwvrMMd0g1iREsTOJt4m7RNuO QCJRHpttap1sja5733+fVm3bfwSvgVYkSLQFDSCGnrA42QIena4o46uFULcFCBj3 keqL7qvR3DL4ArmxBfgqr/Hj6wqMiH2G//v1WajYfBDTPlvmXU2oZ62MbWGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747944944; x=1748031344; bh=zSS4T4u1r0+FCGqvYFzTeVzDtpaWshtHIDY F36e3cxw=; b=kjU6F4bKoFZUEXeTTWA7UPw7c4SnWYv3QL9z5jKCN8V/p4wMQYZ aAgkhtWxdauz9wlGbJExF2g7yhUx4fTK8emFlf6aHSqLMl5mjhR0q6rlKHW0F1So 0s7nLyDIbrl0eNsmST67oyqX0zJVlIk9lw/ljolWXVOS0WTxAgUpbWQb7bPZlcgn dzuvGTdjhK4g3+yCOFuNFjDxGjzmMv481KAbAU0CHigeRfX8LKotJsEzCUSh/GkH eCUuosKPQTBQT0wcl9FSgKyYn7sfn4ri6Mcai+9VKROVInI/FHec9uuVJJ1uesNW Wq74zh8Dgk/CQ7xm5DxlyzI3rxW95Ws0CWA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdeikeelucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhho ihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnheptdfhheeuteejud ffkefhtdfhfeekgedtvdeiteevgfejtdfgfeffhfeuieeltdeinecuffhomhgrihhnpehf rhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvg gvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 22 May 2025 16:15:43 -0400 (EDT) Date: Thu, 22 May 2025 21:15:42 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: epair(4) Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.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; format=flowed Content-Disposition: inline In-Reply-To: <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.com> X-Rspamd-Queue-Id: 4b3KKs73snz3TT6 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.93)[-0.932]; NEURAL_HAM_MEDIUM(-0.77)[-0.769]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27:c]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.150:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] On Thu, May 22, 2025 at 07:40:52PM +0200, Patrick M. Hausen wrote: >The handbook has always been clear about the only correct way to configure >a bridge and member interfaces since the introduction of if_bridge(4) and the >removal of the previous bridge(4) in 2007: > >https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml?revision=30565&view=markup > > If the bridge host needs an IP address then the correct > place to set this is on the bridge interface itself rather > than one of the member interfaces. This can be set statically > or via DHCP. On reflection, maybe I should have said something like "the handbook has only been clear *in the virtualization section*" about the "correct way to configure" this since around the middle of last year. I think, from what other list members have written also, that many did as I did:- looked at the virtualization part of the handbook, found all what was required there to get started, and thats it. They would probably not (as I didn't) see the need to look at the advanced networking section if they were only using a bridge with bhyve or similar. Basically, I'm suggesting that maybe more noise be made about the change, especially given that it deals with a part of the system that, once the initial configuration has been done and tested, is rarely examined afterwards. -- From nobody Thu May 22 21:06:46 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3LSz6phnz5vx0L for ; Thu, 22 May 2025 21:06:59 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3LSz2j4bz3qv1 for ; Thu, 22 May 2025 21:06:59 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 29C7C3; Thu, 22 May 2025 23:06:57 +0200 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.600.51.1.1\)) Subject: Re: epair(4) From: "Patrick M. Hausen" In-Reply-To: Date: Thu, 22 May 2025 23:06:46 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.com> To: void X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b3LSz2j4bz3qv1 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:16188, ipnet:217.29.32.0/20, country:DE] X-Spamd-Bar: ---- Hi all, > Am 22.05.2025 um 22:15 schrieb void : > I think, from what other list members have written also, that many did = as I did:- looked at the virtualization part of the handbook, found all = what > was required there to get started, and thats it. They would probably = not > (as I didn't) see the need to look at the advanced networking section = if they > were only using a bridge with bhyve or similar. I have come to realise that there are two sides to this issue, both = equally valid. How to configure and use if_bridge(4) correctly was documented from day = one or very shortly thereafter. But still - for reasons I do not quite understand - more than one = platform/wrapper development ignored that documentation. FreeNAS/TrueNAS surely did and from your posts I read that more jail/VM = orchestration tools also "do it wrong". So I agree - we cannot place the burden on the users with a: "The documentation was on display in the bottom of a locked filing = cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the = Leopard.'" Which I am prone to do occasionally. Sorry about that. The technical discussion is simple. An IP address on a bridge member = never was supported and never will be. The change that is currently discussed simply prohibits a setup that = never was supported in the first place with the good intention to save people = from foot shooting. I support your suggestion to *somehow* make some more noise about that. I have been screaming at walls for years about the broken setup of = bridges in TrueNAS on the iX forum to no avail. Tickets in JIRA closed without = action ... Stuff like that. Kind regards, Patrick= From nobody Thu May 22 21:14:29 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3Ldq5pmTz5vx9B for ; Thu, 22 May 2025 21:14:39 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Received: from g-cipher.net (leon.g-cipher.net [5.9.120.19]) (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 4b3Ldp2JpSz3vd2 for ; Thu, 22 May 2025 21:14:38 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of resin-freebsd@g-cipher.net designates 5.9.120.19 as permitted sender) smtp.mailfrom=resin-freebsd@g-cipher.net; dmarc=none Received: (qmail 68652 invoked from network); 22 May 2025 16:14:32 -0500 Received: from unknown (HELO ?192.168.7.176?) (resin@unknown) by g-cipher.net with ESMTPS (TLS_AES_128_GCM_SHA256 encrypted); 22 May 2025 16:14:32 -0500 Message-ID: <08e9057e-d741-49a8-a93d-7947f79179d3@g-cipher.net> Date: Thu, 22 May 2025 14:14:29 -0700 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: Updating build and jail manual pages to include missing or obscure information To: freebsd-current , doc References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> <2f6b255b-696c-44ed-9c32-b70daec0ff4f@g-cipher.net> Content-Language: en-US Cc: Alexander Ziaee , Dave Cottlehuber , emaste From: Billiam Crashkopf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4b3Ldp2JpSz3vd2 X-Spamd-Bar: / X-Spamd-Result: default: False [0.26 / 15.00]; NEURAL_SPAM_LONG(0.94)[0.941]; NEURAL_HAM_SHORT(-0.94)[-0.937]; NEURAL_SPAM_MEDIUM(0.35)[0.354]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:5.9.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[g-cipher.net]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] On 5/22/25 12:27, Lexi Winter wrote: > resin-freebsd@g-cipher.net: >> Just to share my two cents: I think all available options should be >> documented in the manual. > i'm fine with having 'make world' documented somewhere, although such > documentation should probably note that it's been deprecated for over > 20 years. i'm just saying it can't be documented as a way of upgrading > the host system since it won't do that -- it will refuse to run unless > DESTDIR is set, so it can upgrade jails, but not hosts. Totally fair. I'm still unclear on the deprecated status of the 'world' target.  Is it deprecated because it's dangerous for the running system?  It clearly has some guard rails to prevent accidents (DESTDIR or HISTORICAL_MAKE_WORLD must be set).  If it's truly deprecated then it shouldn't be used in the jail instructions. But it also has more functionality than buildworld + installworld because it has logic for optionally making pre-world and post-world targets. Options I see are:   * Declare the 'world' target deprecated only for updating, but fine for other uses   * Declare the 'world' target deprecated for all uses; update the jail build instructions with a more verbose invocation.   * Declare the 'world' target deprecated for all uses; add an alias for the same recipe that doesn't have any legacy meaning. From nobody Thu May 22 21:57:27 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3MbS4BQVz5w0GY for ; Thu, 22 May 2025 21:57:40 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3MbS0lnqz4KjH for ; Thu, 22 May 2025 21:57:39 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 54MLvRRl003540 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 22 May 2025 23:57:27 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1747951048; bh=7IsJnrte8qM9ZPROWfIaap7FpT8xTSMcG7eYl/loP4E=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=bzLe/BWe9ir12Oc7HbqOklG8BA3pVvWysaO7gb+Ici4VGOW/URve/WndHDy5Nm5c0 rrFcA35qTFE0iVyKQU2b0TH+4jzavX7SQ/bbD5Z5sDn7fGL0mJ4fUK43ajc3TZBIsb tjIAkriHYIaaU7q44LMM+O90E3W7AfLUl6WRYJQ6tuNj/gfPHYfC69dSZgUu/nqoV7 Zh6mKhlmj3yXqIrYSvGmQ3UpCuXY5gNGj4gpmCKv6e1LVvCcEvzctSaV7QRbHkY0Jk LM1U6S7xCfHxMTxp//UzQMdAH5iEwBFpOiz4al/07xfloWgDIBcN3t9XZuLheJ5wOn ErahWWYsIcsfw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <1eb27b2a-c05a-470f-ba1b-6730e39cc1d8@plan-b.pwste.edu.pl> Date: Thu, 22 May 2025 23:57:27 +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: epair(4) To: "Patrick M. Hausen" , void Cc: freebsd-current@freebsd.org References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.com> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4b3MbS0lnqz4KjH 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:206006, ipnet:2001:678:618::/48, country:PL] X-Spamd-Bar: ---- W dniu 22.05.2025 o 23:06, Patrick M. Hausen pisze: > Hi all, > >> Am 22.05.2025 um 22:15 schrieb void : >> I think, from what other list members have written also, that many did as I did:- looked at the virtualization part of the handbook, found all what >> was required there to get started, and thats it. They would probably not >> (as I didn't) see the need to look at the advanced networking section if they >> were only using a bridge with bhyve or similar. > I have come to realise that there are two sides to this issue, both equally valid. > > How to configure and use if_bridge(4) correctly was documented from day one > or very shortly thereafter. > > But still - for reasons I do not quite understand - more than one platform/wrapper > development ignored that documentation. > > FreeNAS/TrueNAS surely did and from your posts I read that more jail/VM orchestration > tools also "do it wrong". > > So I agree - we cannot place the burden on the users with a: > > "The documentation was on display in the bottom of a locked filing cabinet stuck in a > disused lavatory with a sign on the door saying 'Beware of the Leopard.'" > > Which I am prone to do occasionally. Sorry about that. > > The technical discussion is simple. An IP address on a bridge member never > was supported and never will be. > > The change that is currently discussed simply prohibits a setup that never > was supported in the first place with the good intention to save people from > foot shooting. > > I support your suggestion to *somehow* make some more noise about that. > > I have been screaming at walls for years about the broken setup of bridges > in TrueNAS on the iX forum to no avail. Tickets in JIRA closed without action ... > Stuff like that. > > Kind regards, > Patrick > I think enough noise has been made. Regardless of its cause and intentions, this kind of noise isn't good for the FreeBSD community. I hadn’t planned to post further in this thread, but I’ve noticed the debate rising again like a phoenix from the ashes. Maybe it’s best to let it burn itself out. Now is the time to focus on more productive efforts - improving tools like vm-bhyve, helping users with migration paths, and making sure the documentation is consistent and accurately reflects the current state of affairs. Most importantly, there is a need to show the broader community (or at least not hide) that alternatives are available, such as ng_bridge(4), which allows for quickly setting up a network bridge for fast spinning up a bhyve VM for testing or running a VNET jail for short-term use. Cheers Marek From nobody Fri May 23 02:43:09 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3Tx64hM3z5wHQr; Fri, 23 May 2025 02:43:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3Tx60zF7z44dF; Fri, 23 May 2025 02:43:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 54N2h9LV036904; Thu, 22 May 2025 19:43:15 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1747968195; x=1747968795; r=y; bh=b4uamTSkL/pmj5YqXlI1SFHjLHzQwXoIroM9Hs5WxTo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=jvnx0ecfhuRV1IOSzErZOWo1WTlFqw+kwtA33YzhfL9DH1/zhb22+IC9oMlPSieTw SuoljqtkiKolGvKqvEksbmRIW4516yQ1UEHGBZUBCmRRBIdu8p4TVzun7HUNb0KWTb fYb4zbTBFwB3zoeK91XfkRuVM0X5MGVKh8cUxXb0feICJpAeGROIBt5LDu9b4o8WFw i8s4IgoUg8kU4B+ARFPwxYIHPw30++zNvCaPa7oY6xXDGtUK/Q91mfUPHJWJiHvcBN eKOdal9AnJSegyU5oy46zR1C2RHscX6tC+YOQct3Nn+FC88Z5p1LmQDjzWNQbkpcuJ hX09WBYtVOIrg== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Thu, 22 May 2025 19:43:09 -0700 From: Chris To: Billiam Crashkopf Cc: freebsd-current , doc , Alexander Ziaee , Dave Cottlehuber , emaste Subject: Re: Updating build and jail manual pages to include missing or obscure information In-Reply-To: <08e9057e-d741-49a8-a93d-7947f79179d3@g-cipher.net> References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> <2f6b255b-696c-44ed-9c32-b70daec0ff4f@g-cipher.net> <08e9057e-d741-49a8-a93d-7947f79179d3@g-cipher.net> User-Agent: UDNSMS/17.0 Message-ID: <3ca3e5c0f32228b6ea6f36d406176940@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_6858de4874d74bb1c6bdc99f5415a39f" X-Rspamd-Queue-Id: 4b3Tx60zF7z44dF 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:11404, ipnet:24.113.0.0/16, country:US] X-Spamd-Bar: ---- --=_6858de4874d74bb1c6bdc99f5415a39f Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-05-22 14:14, Billiam Crashkopf wrote: > On 5/22/25 12:27, Lexi Winter wrote: >> resin-freebsd@g-cipher.net: >>> Just to share my two cents: I think all available options should be >>> documented in the manual. >> i'm fine with having 'make world' documented somewhere, although such >> documentation should probably note that it's been deprecated for over >> 20 years. i'm just saying it can't be documented as a way of upgrading >> the host system since it won't do that -- it will refuse to run unless >> DESTDIR is set, so it can upgrade jails, but not hosts. > > Totally fair. > > I'm still unclear on the deprecated status of the 'world' target.  Is it > deprecated because it's dangerous for the running system?  It clearly has > some > guard rails to prevent accidents (DESTDIR or HISTORICAL_MAKE_WORLD must be > set).  > If it's truly deprecated then it shouldn't be used in the jail instructions. > But > it also has more functionality than buildworld + installworld because it has > logic > for optionally making pre-world and post-world targets. > > Options I see are: > >   * Declare the 'world' target deprecated only for updating, but fine for > other uses > >   * Declare the 'world' target deprecated for all uses; update the jail > build > instructions with a more verbose invocation. > >   * Declare the 'world' target deprecated for all uses; add an alias for the > same > recipe that doesn't have any legacy meaning. IMHO what's to depreciate? It has a very useful purpose that's been enjoyed for *years*. It has guard rails to prevent foot shooting for the less initiated. I don't really see where it needs to be an issue -- except perhaps to better document it's value/use case? :) -- sent from hardware written from and running on FreeBSD --=_6858de4874d74bb1c6bdc99f5415a39f Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_6858de4874d74bb1c6bdc99f5415a39f-- From nobody Fri May 23 02:47:17 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3V1n1RXCz5wJGt for ; Fri, 23 May 2025 02:47:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3V1m5DPfz46gy for ; Fri, 23 May 2025 02:47:24 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b=kLatf6US; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 54N2lHxK035326 for ; Thu, 22 May 2025 19:47:23 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1747968443; x=1747969043; r=y; bh=zcop8L46HP39GcYYDSEF6PavPWyMu7FXTHsVCwdujpM=; h=Date:From:To:Subject:In-Reply-To:References; b=kLatf6USUWksh0PidlB+x2A0Ia+E6I8mBIHBap+QnsEYEuJC7b45hdVPunb4juDzL o5uVOlT1JyVW4gFyaPiRvz5NBO0zeCoux1GSlzv8nHVPQumupYsmWsWdo4Zw7JMP7q fYwoSIqXryyHoiVZprdPLY9ztvywqyGU3EEIv4A9E6/3hr8VR8oRtH7tXJVMnygOaj sBPVhK79RFTderALoDXk8sr641VQJQCGB4j9IKgrp1C7zvWGDI22TfqitHhZYnGcKb PVgetMnB+j55f8UT+mm7LFa2QVqj66rOEXqzOC7FpkLmiybuYQ9tNdCYsHx/+PUA02 olXoqsZNUoNxA== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Thu, 22 May 2025 19:47:17 -0700 From: Chris To: freebsd-current Subject: Re: Updating build and jail manual pages to include missing or obscure information In-Reply-To: <08e9057e-d741-49a8-a93d-7947f79179d3@g-cipher.net> References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> <2f6b255b-696c-44ed-9c32-b70daec0ff4f@g-cipher.net> <08e9057e-d741-49a8-a93d-7947f79179d3@g-cipher.net> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_3bab887568a01fa3fe44b045669a39b6" X-Rspamd-Queue-Id: 4b3V1m5DPfz46gy X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [-0.20 / 15.00]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:+] X-Spamd-Bar: / --=_3bab887568a01fa3fe44b045669a39b6 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-05-22 14:14, Billiam Crashkopf wrote: > On 5/22/25 12:27, Lexi Winter wrote: >> resin-freebsd@g-cipher.net: >>> Just to share my two cents: I think all available options should be >>> documented in the manual. >> i'm fine with having 'make world' documented somewhere, although such >> documentation should probably note that it's been deprecated for over >> 20 years. i'm just saying it can't be documented as a way of upgrading >> the host system since it won't do that -- it will refuse to run unless >> DESTDIR is set, so it can upgrade jails, but not hosts. > > Totally fair. > > I'm still unclear on the deprecated status of the 'world' target.  Is it > deprecated because it's dangerous for the running system?  It clearly has > some > guard rails to prevent accidents (DESTDIR or HISTORICAL_MAKE_WORLD must be > set).  > If it's truly deprecated then it shouldn't be used in the jail instructions. > But > it also has more functionality than buildworld + installworld because it has > logic > for optionally making pre-world and post-world targets. > > Options I see are: > >   * Declare the 'world' target deprecated only for updating, but fine for > other uses > >   * Declare the 'world' target deprecated for all uses; update the jail > build > instructions with a more verbose invocation. > >   * Declare the 'world' target deprecated for all uses; add an alias for the > same > recipe that doesn't have any legacy meaning. IMHO what's to depreciate? It has a very useful purpose that's been enjoyed for *years*. It has guard rails to prevent foot shooting for the less initiated. I don't really see where it needs to be an issue -- except perhaps to better document it's value/use case? :) -- sent from hardware written from and running on FreeBSD --=_3bab887568a01fa3fe44b045669a39b6 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_3bab887568a01fa3fe44b045669a39b6-- From nobody Fri May 23 05:48:06 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3Z2M2STDz5wnNC for ; Fri, 23 May 2025 05:48:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3Z2K68kDz3H0y for ; Fri, 23 May 2025 05:48:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.32 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id I19GuLFtK9JM2ILGLuhWh7; Fri, 23 May 2025 05:48:09 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id ILGJuGO8DJhBPILGKu6XFu; Fri, 23 May 2025 05:48:09 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=QY3Fvdbv c=1 sm=1 tr=0 ts=68300c19 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=N5zWn2vpAtApM4SD0UEA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id BBBE1700 for ; Thu, 22 May 2025 22:48:06 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 732E923F; Thu, 22 May 2025 22:48:06 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-current@freebsd.org Subject: NFS Panic 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 Date: Thu, 22 May 2025 22:48:06 -0700 Message-Id: <20250523054806.732E923F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfPjjB+JuffXbIw6JFTiCpMJcvlNC/SqvSPn+3Cud6J4Fspc/kVnA0Lv1C0Wk/oGMcTwfYmy/X4BX4wJyYmk+rHr19M791nOHJQmEBw1YSfRn8C8yyfEz iOC6eK4K1nQ0GM406zcpFIoNjB8PDwYXv06tXMza4N4kE5V82PRfQVs+zEBkEZYRmuUQIt/CCU0jsX59Se6QJBTiq+y2K8K//yc= X-Rspamd-Queue-Id: 4b3Z2K68kDz3H0y X-Spamd-Bar: + X-Spamd-Result: default: False [1.04 / 15.00]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; NEURAL_SPAM_LONG(0.93)[0.925]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; R_DKIM_NA(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; REPLYTO_EQ_FROM(0.00)[] Hi, A couple of my machines have had the following panic. panic: refcount 0xfffff8008dbdabf4 wraparound^M cpuid = 3^M time = 1747977394^M KDB: stack backtrace:^M db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008d1474d0^M vpanic() at vpanic+0x136/frame 0xfffffe008d147600^M panic() at panic+0x43/frame 0xfffffe008d147660^M vput() at vput+0x67/frame 0xfffffe008d147680^M nfs_lookup() at nfs_lookup+0x3bf/frame 0xfffffe008d1479f0^M vop_sigdefer() at vop_sigdefer+0x30/frame 0xfffffe008d147a20^M vfs_lookup() at vfs_lookup+0x467/frame 0xfffffe008d147aa0^M namei() at namei+0x2ed/frame 0xfffffe008d147b00^M vn_open_cred() at vn_open_cred+0x537/frame 0xfffffe008d147c80^M openatfp() at openatfp+0x281/frame 0xfffffe008d147dd0^M sys_openat() at sys_openat+0x3d/frame 0xfffffe008d147e00^M amd64_syscall() at amd64_syscall+0x15a/frame 0xfffffe008d147f30^M fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe008d147f30^M --- syscall (499, FreeBSD ELF64, openat), rip = 0x82213d96a, rsp = 0x8209c3518, rbp = 0x8209c3550 ---^M Uptime: 22h48m25s^M Dumping 3196 out of 7994 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91 %^M Dump complete^M Automatic reboot in 15 seconds - press a key on the console to abort^M Rebooting...^M The panicking machine was the NFS client. The machine was at 30fd79b0c0a3. The NFS mount was handled by the automounter to mount my home dir from another machine. I was rsyncing a copy of src (mistakenly) to the machine. Some of the files were written to the share before it panicked. The underlying filesystem is on ZFS. Stack trace follows: __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57 57 __asm("movq %%gs:%c1,%0" : "=r" (td) (kgdb) #0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:5 7 td = #1 doadump (textdump=textdump@entry=1) at /opt/src/git-src/sys/kern/kern_shutdown.c:404 error = 0 coredump = #2 0xffffffff806fa010 in kern_reboot (howto=260) at /opt/src/git-src/sys/kern/kern_shutdown.c:524 once = 0 __pc = 0x0 #3 0xffffffff806fa547 in vpanic ( fmt=0xffffffff80b6e6f1 "refcount %p wraparound", ap=ap@entry=0xfffffe008d147640) at /opt/src/git-src/sys/kern/kern_shutdown.c:979 buf = "refcount 0xfffff8008dbdabf4 wraparound", '\000' __pc = 0x0 __pc = 0x0 __pc = 0x0 other_cpus = {__bits = {7, 0 }} td = 0xfffff8002dd42000 bootopt = newpanic = #4 0xffffffff806fa373 in panic (fmt=) at /opt/src/git-src/sys/kern/kern_shutdown.c:892 ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0xfffffe008d147670, reg_save_area = 0xfffffe008d147610}} #5 0xffffffff807faf87 in _refcount_update_saturated (count=) at /opt/src/git-src/sys/sys/refcount.h:52 No locals. #6 refcount_releasen (count=, n=1) at /opt/src/git-src/sys/sys/refcount.h:151 old = #7 refcount_release (count=) at /opt/src/git-src/sys/sys/refcount.h:171 No locals. #8 vput (vp=) at /opt/src/git-src/sys/kern/vfs_subr.c:3711 No locals. #9 0xffffffff805c7bff in nfs_lookup (ap=ap@entry=0xfffffe008d147a48) at /opt/src/git-src/sys/fs/nfsclient/nfs_clvnops.c:1438 dvp = 0xfffff80089998c08 newvp = 0xfffff8008dbdaa50 np = 0xfffffe00d0c537c0 attrflag = 0 dattrflag = 0 ncticks = -2139333169 nfhp = 0xfffffe00104e61c0 dnfsva = {na_vattr = {va_type = 80, va_mode = 33038, va_bsdflags = 65535, va_uid = 2378017360, va_gid = 4294965248, va_nlink = 18446741877053224856, va_fsid = 18446735278986613504, va_fileid = 9, va_size = 18446741878188881856, va_blocksize = 0, va_atime = {tv_sec = 0, tv_nsec = 0}, va_mtime = {tv_sec = 5632, tv_nsec = 8013448}, va_ctime = {tv_sec = 0, tv_nsec = -2195520669736}, va_birthtime = {tv_sec = 686, tv_nsec = 8}, va_gen = 0, va_flags = 18446741878188881880, va_rdev = 346, va_bytes = 8, va_filerev = 0, va_vaflags = 2159652436, va_spare = -9133229150802726348}, na_suppattr = {bits = {3132, 0, 768876544}}, na_mntonfileno = 18446741874959868352, na_filesid = { 18446744071574388420, 18446735278385405952}} nfsva = {na_vattr = {va_type = VNON, va_mode = 45765, va_bsdflags = 63488, va_uid = 663, va_gid = 0, va_nlink = 18446735280615796760, va_fsid = 18446741877053225448, va_fileid = 18446735280615796736, va_size = 18446741878188881856, va_blocksize = -2196656326896, va_atime = {tv_sec = -2140327393, tv_nsec = -8786968814592}, va_mtime = {tv_sec = -2126898064, tv_nsec = -2196656326448}, va_ctime = {tv_sec = -2139681839, tv_nsec = -8786968814592}, va_birthtime = {tv_sec = -2126898064, tv_nsec = -2196656326416}, va_gen = 18446744071569869777, va_flags = 18446735286740713088, va_rdev = 18446744071582653552, va_bytes = 18446741877053225232, va_filerev = 18446744071569869777, va_vaflags = 845322824, va_spare = -2139674112}, na_suppattr = {bits = {3502585960, 4294966784, 0}}, na_mntonfileno = 0, na_filesid = { 18446741878188881880, 416}} vattr = {va_type = VDIR, va_mode = 493, va_bsdflags = 0, va_uid = 1000, va_gid = 1000, va_nlink = 2, va_fsid = 250081247028, va_fileid = 99091, va_size = 3, va_blocksize = 512, va_atime = { tv_sec = 1747977382, tv_nsec = 958897000}, va_mtime = { tv_sec = 1747977394, tv_nsec = 313670000}, va_ctime = { tv_sec = 1747977394, tv_nsec = 313670000}, va_birthtime = { tv_sec = 1742392133, tv_nsec = 731659000}, va_gen = 0, va_flags = 0, va_rdev = 0, va_bytes = 512, va_filerev = 8013402, va_vaflags = 1747977381, va_spare = 0} nctime = {tv_sec = 1747977394, tv_nsec = 304107000} ts = {tv_sec = 82105, tv_nsec = 804860589} cnp = 0xfffffe008d147d18 vpp = 0xfffffe008d147cf0 mp = 0xfffffe00c2c1b000 flags = 346325252 error = td = 0xfffff8002dd42000 nmp = needs_nameddir = openmode = newnp = ltype = is_nameddir = opennamed = #10 0xffffffff807e5ee0 in vop_sigdefer (vop=, a=0xfffffe008d147a48) at /opt/src/git-src/sys/kern/vfs_default.c:1482 bp = 0xffffffff805c7840 prev_stops = 0 rc = #11 0xffffffff807eb327 in VOP_LOOKUP (dvp=0xfffff80089998c08, vpp=0xfffffe008d147cf0, cnp=0xfffffe008d147d18) at ./vnode_if.h:67 a = {a_gen = {a_desc = 0xffffffff810e4b90 }, a_dvp = 0xfffff80089998c08, a_vpp = 0xfffffe008d147cf0, a_cnp = 0xfffffe008d147d18} #12 vfs_lookup (ndp=ndp@entry=0xfffffe008d147c98) at /opt/src/git-src/sys/kern/vfs_lookup.c:1284 dp = 0xfffff80089998c08 error = relookup = cnp = 0xfffffe008d147d18 ni_dvp_unlocked = 0 wantparent = 0 docache = 1 lastchar = cp = prev_ni_pathlen = 9 prev_ni_next = 0xffffffffffffffff lkflags_save = 524288 tdp = pr = nulchar = rdonly = #13 0xffffffff807ea47d in namei (ndp=ndp@entry=0xfffffe008d147c98) at /opt/src/git-src/sys/kern/vfs_lookup.c:706 dp = 0xfffff80089998c08 pwd = 0xfffff8000d2e1c30 status = CACHE_FPL_STATUS_ABORTED cnp = 0xfffffe008d147d18 td = 0xfffff8002dd42000 error = #14 0xffffffff80812d57 in vn_open_cred (ndp=ndp@entry=0xfffffe008d147c98, flagp=flagp@entry=0xfffffe008d147da4, cmode=cmode@entry=0, vn_open_flags=vn_open_flags@entry=16, cred=0xfffff80051a9d300, fp=0xfffff8000e50eb90) at /opt/src/git-src/sys/kern/vfs_vnops.c:356 vp = 0x0 mp = 0xfffffe008d147c80 vat = {va_type = VLNK, va_mode = 0, va_bsdflags = 0, va_uid = 2, va_gid = 0, va_nlink = 0, va_fsid = 18446735279980743744, va_fileid = 18446741874923406336, va_size = 18446741874923406336, va_blocksize = -2196656325632, va_atime = {tv_sec = -2136993772, tv_nsec = -8794722938112}, va_mtime = {tv_sec = 1, tv_nsec = -2198749683240}, va_ctime = {tv_sec = -8794722938112, tv_nsec = -2198749683264}, va_birthtime = {tv_sec = -2139209136, tv_nsec = -2196656325728}, va_gen = 663, va_flags = 18446735280103378544, va_rdev = 18446735278986613504, va_bytes = 18446735280103378520, va_filerev = 1, va_vaflags = 2366929872, va_spare = -2140327393} first_open = false error = fmode = vap = #15 0xffffffff80808db1 in openatfp (td=0xfffff8002dd42000, dirfd=3, path=0x846ac479fd , pathseg=pathseg@entry=UIO_USERSPACE, flags=131329, mode=, fpp=0x0) at /opt/src/git-src/sys/kern/vfs_syscalls.c:1252 fp = 0xfffff8000e50eb90 nd = { ni_dirp = 0x846ac479fd , ni_segflg = UIO_USERSPACE, ni_rightsneeded = 0xfffffe008d147d80, ni_startdir = 0x0, ni_rootdir = 0xfffff8000d35b528, ni_topdir = 0x0, ni_dirfd = 3, ni_lcf = 0, ni_filecaps = {fc_rights = {cr_rights = { 144132780261900287, 288230376153808895}}, fc_ioctls = 0x0, fc_nioctls = -1, fc_fcntls = 120}, ni_vp = 0x0, ni_dvp = 0xfffff80089998c08, ni_resflags = 0, ni_debugflags = 3, ni_loopcnt = 0, ni_pathlen = 1, ni_next = 0xfffff8000d2f5008 "", ni_cnd = {cn_flags = 346325252, cn_cred = 0xfffff80051a9d300, cn_nameiop = LOOKUP, cn_lkflags = 532480, cn_pnbuf = 0xfffff8000d2f5000 "realpath", cn_nameptr = 0xfffff8000d2f5000 "realpath", cn_namelen = 8}, ni_cap_tracker = {tqh_first = 0x0, tqh_last = 0xfffffe008d147d48}, ni_dvp_seqc = 1400, ni_vp_seqc = 0} indx = -1 rights = p = fdp = 0xfffffe00c2bf8c90 pdp = 0xfffff8008ceb0c40 error = 0 cmode = 0 vp = fcaps = #16 0xffffffff80808b0d in kern_openat (dirfd=, path=, pathseg=UIO_USERSPACE, flags=, mode=, td=) at /opt/src/git-src/sys/kern/vfs_syscalls.c:1336 No locals. #17 sys_openat (td=, uap=) at /opt/src/git-src/sys/kern/vfs_syscalls.c:1147 No locals. #18 0xffffffff80acf35a in syscallenter (td=0xfffff8002dd42000) at /opt/src/git-src/sys/amd64/amd64/../../kern/subr_syscall.c:191 se = 0xffffffff8105add0 p = 0xfffffe00c2c22000 sa = 0xfffff8002dd423f0 error = sy_thr_static = true traced = _audit_entered = #19 amd64_syscall (td=0xfffff8002dd42000, traced=0) at /opt/src/git-src/sys/amd64/amd64/trap.c:1215 ksi = {ksi_link = {tqe_next = 0x4, tqe_prev = 0xfffffe008d147ee0}, ksi_info = {si_signo = -2139674112, si_errno = -1, si_code = -1928036720, si_pid = -512, si_uid = 0, si_status = 32768, si_addr = 0x8140407a2e293234, si_value = { sival_int = 3, sival_ptr = 0x3, sigval_int = 3, sigval_ptr = 0x3}, _reason = {_fault = {_trapno = 768877856}, _timer = {_timerid = 768877856, _overrun = -2048}, _mesgq = { _mqd = 768877856}, _poll = {_band = -8795324144352}, _capsicum = {_syscall = 768877856}, __spare__ = { __spare1__ = -8795324144352, __spare2__ = {-1928036352, -512, -2126898064, -1, 768876544, -2048, -2130704920}}}}, ksi_flags = 7, ksi_sigq = 0xfffff8002dd42000} #20 No locals. #21 0x000000082213d96a in ?? () No symbol table info available. Backtrace stopped: Cannot access memory at address 0x8209c3518 -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Fri May 23 06:44:27 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3bHb20v7z5wrVd for ; Fri, 23 May 2025 06:44:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3bHZ1ZMMz3cmk; Fri, 23 May 2025 06:44:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 54N6iSSc007426; Fri, 23 May 2025 09:44:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 54N6iSSc007426 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 54N6iR9F007425; Fri, 23 May 2025 09:44:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 May 2025 09:44:27 +0300 From: Konstantin Belousov To: Brooks Davis Cc: Warner Losh , freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL Message-ID: References: <202505210722.54L7MTqw025632@critter.freebsd.dk> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4b3bHZ1ZMMz3cmk 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:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- On Thu, May 22, 2025 at 03:59:14PM +0000, Brooks Davis wrote: > On Thu, May 22, 2025 at 08:04:19AM +0300, Konstantin Belousov wrote: > > On Wed, May 21, 2025 at 11:23:12PM +0000, Brooks Davis wrote: > > > On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote: > > > > In short, I'd love to widen the interface, but there's a number of practical > > > > issues in the way. > > > > > > I think caching something in the kernel of later retrieval or adding a > > > new return path to the ABI is the wrong way around. Instead I think the > > > right solution is for each thread to register a userspace buffer. You > > > end up adding one or two entries to struct thread (pointer to a > > > structure or pointer to an buffer and length) and if the pointer is > > > non-NULL you copyout a string to the buffer. This avoids signficant > > > new storage in the kernel and means programs that won't use this data > > > don't see it. It also means that the debugger can access it without > > > needing a new PT_ argument. > > > > > > As a minor downside you would introduce some new error conditions if the > > > programmer messes up registration, but we'd probably just have libthr do > > > it in most cases (that would be more debugger friendly since you > > > could hang it off a known location in userspace). > > > > I mostly agree with this proposal, and can implement it. > > I strongly object against blowing the kernel with MBs of strings. > > > > Userspace can register per-thread extended errno location, and kernel > > can copyout the ext-errno when returning error. > > I really want them to be strings in the kernel. Anything else is too > annoying to maintain and will interact poorly with running old versions > of userspace and introduce namespace complications for downstreams. > > If you want the option to save the space, make the interface that copies > the string out a macro and provide an option to compile them away. > (Using a macro would also allow you to transparently embed e.g., file, > function, or line information if desired.) D50483 Extended errors from kernel From nobody Fri May 23 07:36:22 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3cRS0Rxxz5wv3K for ; Fri, 23 May 2025 07:36:36 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3cRR2NH3z3w6T for ; Fri, 23 May 2025 07:36:35 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 171C55; Fri, 23 May 2025 09:36:32 +0200 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.600.51.1.1\)) Subject: Re: epair(4) From: "Patrick M. Hausen" In-Reply-To: <1eb27b2a-c05a-470f-ba1b-6730e39cc1d8@plan-b.pwste.edu.pl> Date: Fri, 23 May 2025 09:36:22 +0200 Cc: void , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1245F3CD-393C-44BC-BAF1-0D70AC83A0CC@hausen.com> References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.com> <1eb27b2a-c05a-470f-ba1b-6730e39cc1d8@plan-b.pwste.edu.pl> To: Marek Zarychta X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b3cRR2NH3z3w6T 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:16188, ipnet:217.29.32.0/20, country:DE] X-Spamd-Bar: ---- Hi all, > Am 22.05.2025 um 23:57 schrieb Marek Zarychta = : > I think enough noise has been made. Regardless of its cause and = intentions, this kind of noise isn't good for the FreeBSD community. I meant that strictly in the sense of raising awareness about the issue and potential unexpected breakage for users. If I did not get this conversation entirely wrong, the problem is exactly that there are probably many people running an unsupported configuration without knowing. How to reach them? I don't have a blog - anyone willing to step in? I could help drafting a short article explaining the issue. Then we could use BSDnow.TV among possibly other platforms to get the word out. Kind regards, Patrick= From nobody Fri May 23 09:56:09 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3gXT31t1z5x2Dw; Fri, 23 May 2025 09:56:09 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3gXT2bRPz3fgK; Fri, 23 May 2025 09:56:09 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747994169; 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; bh=fQufSF74pDI0Su9aEMzLCl7Mn6FZd0GV3y0480ojOVo=; b=o2X4MiyIqNw7+2b39EUR911Qu6LHQI1+Ky52hPHr4MoUCciTx/P1+JGBvlboPFlTlN2frv a7A0G/lkH4Dxi8SB0oINLL2zmYl3oUDA8i8pajGw8w0rSd42S5dBMEltlFMnDP5jm12Y8e VViVHvCT/cJoW76aigLUmWk2G1B8dRBD+vwGZkmzOt9umF6o/FZnzhrX9qGTGRoMGS+ORi xnlhjaubH5E2Kv0DkrOl7TCOkRvE7NGUrOD8sfr/sRKkVZQe1Sts7BD9ts4ygYJwGR2Pzd uc2u0YN93Dc58Gdu13Lr1vnLgxnnzRG7OdaaOSE5CSmu4P2MDJ+f94bwCcVJaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747994169; 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; bh=fQufSF74pDI0Su9aEMzLCl7Mn6FZd0GV3y0480ojOVo=; b=vl0szZHmTqvb5BpLDwa0cl9xfX1DuFY7UAkG3DsOUmeN0lgngTY66OqhreqeEPD+oV1BQb ISMc+UmX/zwvuG0CMHngmXt+2y4qUYVdWvLtC6vNzADYJhu+2dRlvs2gNcF4m0CwS2GaXN 5vxxBFYpzL/zcdqakYkG4XoCPz9Js1mfH74jeeQ0jEU7xqG+KV/CE9vdfcK+aeX414L887 gEYxweqvn0ePp3uRKg9ZtoK4ZUYf9oFYskQAwT9Bce521QfTXa72jDJKgdQpgbEdKD06dG h7RrUg2ZDs5RbbjqK68xKmumR5T4p+kpd9ZZqJF90OMAiP+1Wp1VpIaWBimKqA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747994169; a=rsa-sha256; cv=none; b=HOG5qxSPeM0LO4VdwOn2cjT2wmUqs0g/hlNh+Xw9//XBR3ABnPrZwMf3QP10ig+z1sCNBY MVt8CYnSYuH70MoZ01j3OyyjX6MX6qrSgJ0MAIN4Gapl0DtGeioBTejABMBeXB5Zw0gMRc KnASOKV7aTlAw0RoKbmQDT8n19sfjRAlXLT5DApLtkze0FA1WXOELzRhO/PWEjzLJboavF BCHfopn8FyOEyHOGPP3OAiFpfyeiU4Q+A/e4TqJPRaIG1Pux3IrglObuhTSbULMastVG8M gLwd+BIKlsxvGy5HouddHUWeDWIbIjpOIVezP5d7qIHJX0XfnMn3HodwyBFN+A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1472) id 4D302104FE; Fri, 23 May 2025 09:56:09 +0000 (UTC) Date: Fri, 23 May 2025 09:56:09 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - First Quarter 2025 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit FreeBSD Status Report First Quarter 2025 Here is the first 2025 status report, with 40 entries. As we step into a new year, the FreeBSD community continues its work with unwavering speed, intent, and purpose. The first quarter has been remarkable, with numerous reports highlighting progress across various areas. Engaging with the community through forums, mailing lists, and conversations has revealed to me more advancements than can ever be captured in a single quarterly report. We extend our heartfelt thanks to everyone who submitted reports and helped raise awareness of our activities. Your contributions are invaluable in showcasing our collective efforts. Let us build on the success of 2024 and make this the best year yet for FreeBSD and our community! Chris Moerz, on behalf of the Status Team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2025-01-2025-03/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection □ Bugmeister Team □ Source Management Team • Projects □ Infrastructure Modernization □ Automatic pkgbase conversion tool □ Framework Laptop support □ Hackathon 202503 Tokyo, Japan □ Sylve — A Unified System Management Platform for FreeBSD • Userland □ Jail metadata feature • Kernel □ Audio Stack Improvements □ DRM drivers □ Suspend/Resume Improvement □ Syzkaller Improvement for WiFi on FreeBSD □ LinuxKPI 802.11 Wireless Update □ Wireless Update • Architectures □ Pinephone Pro Support • Cloud □ FreeBSD on Microsoft HyperV and Azure □ Containers and FreeBSD: Cloud Native Buildpacks □ FreeBSD on EC2 • Documentation □ Documentation Engineering Team □ FreeBSD Wiki □ Vision Accessibility — Accessibility Handbook • Ports □ A bhyve management GUI written in Freepascal/Lazarus □ Container orchestration: Overlord, Director and AppJail □ GCC on FreeBSD □ IPv6 Support on ksocket Netgraph Module □ KDE on FreeBSD □ OpenBGPd Fix FIB handling on FreeBSD □ Improve OpenJDK on FreeBSD □ Wazuh on FreeBSD • Third Party Projects □ Chinese FreeBSD Community (CFC) □ FreeBSD Discord Server □ Framework Kernel Module □ Laptop and Desktop Work Group (LDWG) □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Project roadmap Core is collecting ideas and comments to draft Project’s roadmap. It is an item core.13 thinks is worth to continue from core.12. The roadmap is not about restricting or limiting what developers and contributors can do, but about the compiled goals and expectations of the Project and things the community can collaborate on. It will also let the FreeBSD Foundation help the Project more effectively, so, this is an important discussion item for the meetings between core and the FreeBSD Foundation. Work in Progress Core is currently working on the following items: • Policy on generative AI created code and documentation • Core and the FreeBSD Foundation are working on the 2025 edition of the Community survey • Privacy-friendly web analytics, proposed by the Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://freebsdfoundation.org/ Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://freebsdfoundation.org/journal/ Foundation Events URL: https://freebsdfoundation.org/our-work/events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to advancing FreeBSD through technical and non-technical support. Funded entirely by donations, the Foundation supports software development, infrastructure, security, and collaboration efforts; organizes events and developer summits; provides educational resources; and represents the FreeBSD Project in legal matters. The following report covers just some of the ways we supported FreeBSD in Q1 Deb Goodkin here. Is it Q2 already? Last quarter was a whirlwind of activity supporting the FreeBSD Project and community. In our report, we will highlight the work we are currently doing to ensure that FreeBSD stays viable and secure for the long term. As you know, the Foundation is here to support the project in many ways, including software development, security, legal, conferences, and infrastructure. I want to keep this section short, because we have reports throughout this status report to get more details on the work we are doing. Here is a snapshot of what we worked on last quarter, by the numbers: • 2024 funding raised (final amount is determined by February or March): $1,524,259 • Q1 2025 fundraising: $211,000 • Active software development projects: 20+ • Number of commits: 456 • Amount of technical content published: 8 • Conferences sponsored/attended: 2 • Foundation employees: 7 • Foundation contractors: 19 • Foundation’s 25th Anniversary: We are thrilled to celebrate 25 years of supporting the FreeBSD Project and community! Exciting News: Mark Phillips joined the Foundation as our Technical Marketing Manager. Get prepared for some information and helpful technical content coming your way! We also brought on another part-time developer who stepped into our Solutions Specialist role. We will announce that person soon. Advocacy In the first quarter of 2025, the Foundation continued its work to support and promote FreeBSD. In addition to our regular activities such as publishing educational and informational content, attending events, and providing travel grants to help FreeBSD contributors participate in conferences we also welcomed a new team member. Mark Phillips joined us in March as our Technical Marketing Manager. With a background in engineering and a passion for storytelling, Mark describes himself as "an engineer by training, a marketer by chance." He has already made connections within the FreeBSD community, and we are excited to see his impact grow. To learn more about Mark, visit our team page. Other highlights of our Q1 2025 advocacy efforts include: • Helped represent FreeBSD at FOSDEM 2025. Check out the trip report. • Began planning the June 2025 FreeBSD Developer Summit, taking place June 11-12, 2025, co-located with BSDCan 2025. Registration is now open • Finalized our Silver Sponsorship of BSDCan and opened the BSDCan 2025 Travel Grant Application. • Provided updates and announcements about our Software Development work including: □ Zero-Trust Builds for FreeBSD □ Improvements to the FreeBSD CI/CD systems □ Laptop Support and Usability Project Update: First Monthly Report & Community Initiatives □ January 2025 Laptop Support and Usability Project Update □ February 2025 Laptop Support and Usability Project Update □ OpenZFS RAID-Z Expansion: A New Era in Storage Flexibility • Participated in CHAOSScast Episode: GrimoireLab at FreeBSD. Learn more at: From Chaos to Clarity: How We Tackled FreeBSD’s 7,000 Bug Backlog • Published the January 2025 and February 2025 FreeBSD Foundation Newsletters. • Released the November/December 2024 issue of the FreeBSD Journal with HTML versions of the articles. OS Improvements The FreeBSD Foundation continued to support two major projects this quarter. The Foundation’s Laptop Support and Usability project began in Q4 of 2024 and is funded by the FreeBSD Foundation and Quantum Leap Research. It has a budget of $750,000, which will be used over one to two years. The goal is to deliver its public roadmap to improve key features like WiFi, audio usability, suspend and resume functions, graphics, and Bluetooth. The team will also create clear documentation and step-by-step guides to help people use the new features. Work done this quarter includes improvements to the pkg package manager and pkgbase installation, suspend/resume, USB debugging, newer WiFi standards and drivers, updated graphics drivers, performance/efficiency using heterogeneous cores, support for virtual and non-standard audio devices, and integrating donated code to support UVC webcam drivers. Refer to these dedicated report entries for details: • Audio Stack Improvements • Automatic pkgbase conversion tool • DRM drivers • LinuxKPI 802.11 Wireless Update • Suspend/Resume Improvements • Wireless Update The other major project, commissioned by the Sovereign Tech Agency is to modernize FreeBSD’s infrastructure. To learn more about the project and the updates from this quarter, refer to the Infrastructure Modernization report entry. Updates are available for three other projects in separate report entries: • Improve OpenJDK on FreeBSD • Sylve — A Unified System Management Platform for FreeBSD • Vision Accessibility and the Accessibility Handbook Overall, there were 346 src, 96 ports, and 14 doc tree commits identifying the FreeBSD Foundation as a sponsor. A sampling of that work includes: • Enhancements to SMBIOS handling, including favoring version 3 (64-bit) entry points, adding diagnostics, and improving code robustness • Ongoing work to optimize memory usage during early VM initialization • Continued development toward supporting heterogeneous CPU cores • Enabling USB driver support for the Allwinner D1 SoC • Improvements to makefs(8) for generating reproducible cd9660 images The Foundation is managing FreeBSD’s participation in the Google Summer of Code (GSoC) program. At the end of February, we were excited to learn that FreeBSD was once again selected as a mentoring organization for GSoC 2025. That marks our 21st consecutive year in the program. We received 64 applications, and we will learn which projects will be awarded slots on May 8. Continuous Integration and Workflow Improvement As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 13.5-RELEASE announcement URL: https://www.freebsd.org/releases/13.5/announce/ FreeBSD 14.3-RELEASE schedule URL: https://www.freebsd.org/releases/14.3R/schedule/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The Team managed 13.5-RELEASE, leading to the official RELEASE build and announcement in March; this was the final release from the legacy stable/13 branch. Planning has started for the upcoming 14.3-RELEASE cycle. The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronize its distributed work and communications. In this quarter, the team has worked on the following: • Regular support for FreeBSD.org user accounts. • Regular disk and parts support (and replacement) for all physical hosts and mirrors. • Cluster software refresh. • Moving more cluster services to Chicago. • Supporting the Grimoirelab dashboard effort. • Coordinate community mirrors. Moving cluster services to Chicago We started building up our new site in Chicago 2024, with a long-term goal to have Chicago as our primary location. Since 2024Q4, we began decommissioning older machines in New Jersey and moving services to the newer machines in Chicago. In 2025Q1, we started upgrading critical services in the cluster and testing to setup in Chicago. Git web interface mirrors While the project’s public read-only git repository is built by a globally distributed mirror, the web interface (cgit) is not. We found there is increasing requirement of accessing it, and for improving the response time and reliability, we setup the cgit on the mirrors around the world. FreeBSD official mirrors Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Sweden, Taiwan, United Kingdom (full mirror site), United States of America — California, Chicago, New Jersey (primary site), and Washington. Our mirror site in Taiwan is experiencing an extended outage. The effort of bringing it back is in progress. We hope to have it back online during the second quarter of 2025. The hardware and network connection have been generously provided by: • Cloud and SDN Laboratory at BroadBand Tower, Inc • Department of Computer Science, National Yang Ming Chiao Tung University • Equinix • Internet Association of Australia • Internet Systems Consortium • INX-ZA • KDDI Web Communications Inc • Malaysian Research & Education Network • MetaPeer • New York Internet • NIC.br • Sonic • Teleservice Skåne AB • Your.Org New official mirrors are always welcome. We have noted the benefits of hosting single mirrors at Internet Exchange Points globally, as evidenced by our existing mirrors in Australia, Brazil, and South Africa. If you are affiliated with or know of any organizations willing to sponsor a single mirror server, please contact us. We are particularly interested in locations on the United States West Coast and throughout Europe. See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site. Sponsors: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI Tinderbox view URL: https://tinderbox.freebsd.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI 3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&email1=testing%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet In the first quarter of 2025, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD. Important completed tasks: • Add jobs to build amd64 main, stable/14, and stable/13 with GCC 14 (jhb@) • Working with intern students to fix the failing and skipped test cases (lwhsu@) • Upgrade and switch the Jenkins server to LTS version. • Participate the Foundation’s Sovereign Tech Agency (STA) work package C: improve the project’s CI/CD Work in progress tasks: • Designing and implementing pre-commit CI building and testing and pull/ merge-request based system (to support the workflow working group) □ Improving the src/tests/ci work to support running test suites ☆ Merging CI: Add full test support □ Merging Pre-commit CI with CIRRUS-CI • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Redesigning the hardware test lab and adding more hardware for testing Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm-kmod ports building tests against -CURRENT • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Tobias C. Berner Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. In the last quarter, we welcomed Austin Shafer (ashafer@) as a new ports committer, and welcomed back Eygene Ryabinkin (rea@) and Mark Linimon (linimon@). According to INDEX, there are currently 36,450 (up from 36,332) ports in the Ports Collection. There are currently about 3,333 (down from 3,368) open ports PRs, of which 887 are unassigned. The last quarter saw 10,733 (up from 10,640) commits by 158 (up from 155) committers on the main branch and 707 (down from 733) commits by 54 (down from 61) committers on the 2025Q1 branch. The most active committers to main were: • 3029 sunpoet@FreeBSD.org • 1171 yuri@FreeBSD.org • 358 vvd@FreeBSD.org • 340 bofh@FreeBSD.org • 313 rene@FreeBSD.org • 297 jbeich@FreeBSD.org • 288 eduardo@FreeBSD.org • 243 pkubaj@FreeBSD.org • 223 fuz@FreeBSD.org • 212 diizzy@FreeBSD.org A lot has happened in the ports tree in the last three months, an excerpt of the major software upgrades are: • pkg 2.1.0 • Default version of Lazarus switched to 3.8.0 (aarch64 at 4.99) • Chromium 134.0.6998.165 • Electron 31 removed, Electron 34 added • Firefox 137.0-rc2 • Firefox-esr 128.9.0-rc2 • Gnome desktop 44.1 • KDE Frameworks 6.12.0 • KDE Plasma 6.3.3 • KDE Gear 24.12.3 • Qt6 6.8.3 • Python 3.8 removed • Ruby 3.1 removed • Ruby 3.3.7 • Rust 1.85.1 • SDL 2.32.2 • SDL 3.2.8, added to USES=sdl • Wine 10.0 One USES was removed: qca During the last quarter, pkgmgr@ ran 20 exp-runs to test infrastructure changes and various ports upgrades. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Bugmeister Team Links: FreeBSD Bugzilla URL: https://wiki.freebsd.org/Bugzilla Contact: Bugmeister In this quarter we made major progress on Base System PRs, closing over 1,000 old ones that no longer apply. Many of these were detected by carefully going over all entries in ObsoleteFiles.inc. Also in this quarter we came even closer to steady-state for ports/doc; we are dealing with incoming PRs more quickly these days. For reference: https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html&days=90. The overall number of PRs came down from slightly over 11,000 to just under 10,000. This was due to work from several people to go over entire groups of PRs. Mark Linimon attended several video calls with various src committers. They are doing some experimentation to learn what kind of effort is sustainable. The most recent effort was to evaluate the latest incoming src PRs; you will note that many of them from the past few weeks have been marked as requesting feedback. Bugmeister folks also did some passes through the database to clean up metadata: • re-checked bugs for Product: Base System, Status: In Progress. A few of these were not being actively worked on. The count is essentially holding at 186. The concept is to make sure "In Progress" has some real meaning. • edited up the 'application/mbox' patches to be 'text/plain', which Bugzilla is then able to understand. • obsoleted many stale patches where more than one patch was in the PR. The "automate harvesting PRs and evaluating whether they still apply" task has resulted in the release of patchQA.py as beta. The program can take either a number (as a single PR number), or, with some work, a full REST query. The main current problem is that the py-patch algorithm does not correctly handle fuzz. Until this is fixed, it will stay in beta. Almost all of the PRs with patches have been processed by patchQA.py and several hundreds of them have been rebased (e.g. Base System patches to be relative to the top of the src tree). We now have a sense of how many Ports patches are not actually patches to the FreeBSD port itself, but instead need to be manually applied to an extracted work/ directory. A script to try to automate this is in alpha. The other problem known with patchQA.py is that it does not know the origins of files that are installed into /etc by installworld. However, it does know enough to internally rebase Ports patches to the ports tree base if necessary. We also created 120+ new Bugzilla accounts by user request. (We no longer create them automatically because of the spammers.) Clusteradm@ helped us fend off yet more crawler sites. OTOH, we seem to be losing the war against AI bots. See also: https://wiki.freebsd.org/Bugzilla/SearchQueries ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Source Management Team Contact: srcmgr srcmgr@ is focused on finding ways to make src developers more productive, and to try and manage the large numbers of bug reports and pull requests that we receive. The team meets every two weeks to discuss src-related issues and spend time triaging bug reports and pull requests. The current members are Ed Maste, Mark Johnston, John Baldwin, and Warner Losh. Meeting minutes are available on GitHub. In January and February, srcmgr@ ran two online bug-busting sessions, each attended by roughly 12 developers. The sessions ran for three hours and focused on triaging new src bug reports. The team plans to resume hosting these sessions in the next month. The srcmgr@ team plans to lead a session at the FreeBSD Developer Summit in June. Topics will include deprecation of 32-bit platforms, and pkgbase support for the upcoming FreeBSD 15.0 release. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Infrastructure Modernization Contact: Ed Maste Contact: Alice Sowerby The project started in Q3 of 2024 and was commissioned by the Sovereign Tech Agency with a budget of $745,000, to be spent over about one year. The main goals are to improve security tools for the base system, ports, and packages, update the project’s infrastructure to speed up development, enhance build security, and make it easier for new developers to get started. Q1 update Three of the five work packages are now in progress, with the remaining two to start in April. The overall schedule has been re-planned to run through to December 2025, allowing for a more sustainable pace of work. Work Package A: Technical Debt reduction The Foundation and the FreeBSD Project’s Source Management team is working together to make bug management easier and more sustainable. There is now a bug backlog dashboard, which helps make the backlog easier to understand during "bug busting" sessions, and is already showing that more bugs are being closed than being opened. This is hosted on FreeBSD and documentation has been submitted upstream to the GrimoireLab project so others can do the same. One way to learn more about the project is to listen to the CHAOSScast episode where we talked about this work package. We have also been upgrading Bugzilla by applying patches from 2023 onward and improving the upgrade process to ensure smoother future updates. Work Package B: Zero Trust Builds Much of the foundational work has been completed to standardize all source release build cases using no-root for creation of release artifacts. We are formalizing and documenting make world and release.sh to provide joined-up documentation for users. In order to get src to build reproducibly we are creating CI tests and are working with Reproducible-Builds.org to restore the FreeBSD reproducible CI. Read their February report. Work Package C: CI/CD Automation The high-level goal is to improve CI/CD automation to streamline software delivery and operations for new and existing software. Work so far is focusing on: • Improving the quality of incoming commits by providing system-agnostic tooling and documentation so that maintainers and developers can run CI without requiring a 3rd-party service (https://reviews.freebsd.org/D48015). • Making it possible to run pre-merge CI on proposed submissions (e.g. Pull Requests) (https://reviews.freebsd.org/D36257). • Documenting the CI management process to make it easier to keep tooling up to date and patched. • Updating the Source and Ports tests to include standard linters and other relevant automated analysis tools. Work Package D: Security Controls in Ports and Packages and Work Package E: Improve Software Bill of Materials (SBOM) These work packages are scheduled to start in April. The Foundation has been collaborating with FreeBSD Project teams to scope the projects appropriately. Commissioning body: Sovereign Tech Agency ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Automatic pkgbase conversion tool Links: link:pkgbasify URL: https://github.com/FreeBSDFoundation/pkgbasify pkgbase URL: https://wiki.freebsd.org/PkgBase Contact: Isaac Freund The new pkgbasify tool automatically converts an existing FreeBSD 14+ system to use pkgbase. I’ve done my best to make pkgbasify as robust as possible and currently believe it to be as reliable as manual conversion if not better. That said, pkgbasify could use testing on more diverse systems! See the README for usage instructions and details on pkgbasify’s behavior. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Framework Laptop support Links: Framework Laptop page on FreeBSD Wiki URL: https://wiki.freebsd.org/Laptops/Framework_Laptop/ Guide on installing and using FreeBSD on Framework systems URL: https://github.com/FrameworkComputer/freebsd-on-framework Tracking ticket: Framework Laptop: Feature support, bugs and improvements URL: https://bugs.freebsd.org/262152 Contact: Daniel Schaefer Contact: Li-Wen Hsu Contact: Sheng-Yi Hong For a long time, Framework Computer Inc. has been very supportive of the FreeBSD project in many ways, including providing engineering samples to the Foundation for testing and working on compatibility. The Foundation continues to work on improving overall laptop support, and Framework laptops are one of the target platforms for the Laptop Support and Usability Project. In March, some FreeBSD developers visited Framework’s Taipei office again to test FreeBSD on pre-release Framework products, the Framework Desktop and Framework Laptop 12. The results of these tests will be used to help shape FreeBSD’s development plans, and the FreeBSD support status will be updated in document after further verification. Sheng-Yi is using the laptop provided by Framework Computer to add more device support, e.g. hwpstate: add CPPC support for pstate driver on AMD. Sponsor: The FreeBSD Foundation for Li-Wen and Sheng-Yi’s work Sponsor: Framework Computer Inc for Daniel’s work, hardware and space support ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Hackathon 202503 Tokyo, Japan Links: Hackathon/202503 Wiki Page URL: https://wiki.freebsd.org/Hackathon/202503 FreeBSD Hackathon Wiki Page URL: https://wiki.freebsd.org/Hackathon Before the AsiaBSDCon-Lite 2025 event, some members of the community gathered and held a hackathon in Tokyo. Thanks to Christoff Visser and Internet Initiative Japan Inc. who sponsored the venue. The work done or progressed in the hackathon Sheng-Yi Hung • ipheth(4): The iPhone tethering uses NCM on newer iOS, modified ipheth(4) to supporting it. Patch: https://reviews.freebsd.org/D49431 • Sccahe for FreeBSD base: the FreeBSD base supports ccache to cache the build result. For cross machine build, we need a distributed cache mechanism — that is — sccache. In Hackathon, the patch for adding sccache support is created: https://reviews.freebsd.org/D49417 Kristof Provost Wrote a test case for bsnmpd’s snmp_pf module. This revealed that the BEGEMOT-PF-MIB.txt MIB file could not be parsed by bsnmpwalk, which was also fixed. Commits: 712309a64512, c849f5333260 and 36586800803d Aymeric Wibo • Got writing to config space of USB4 routers working and successive reads on AMD USB4 controllers. • First steps to suspending USB4 routers. • Put up a bunch of preliminary patches regarding the USB4 stuff. • Tried passing through USB4 devices to Linux guest to suspend them (did not work). Mark Johnston • Worked on various syzkaller reports, e.g.: fe7fe3b175b6 • Looked for races in pf after getting some vague bug reports from the OPNsense developers and, with Gleb and Kristof, found and fixed a rare race which could cause a use-after-free: 8efd2acf07bc Philip Paeps • Fixed the libtrue website — we now have libtrue.so :-) • Worked on clusteradm technical debt • Good progress on our LDAP update • Updated a couple of internal machines Li-Wen Hsu • Project’s Git infrastructure improvements, including system updating, maintenance scripts and git hooks fixes • Plan the cluster goals and roadmap for 2025 and longer with Philip Paeps Sponsor: Christoff Visser and Internet Initiative Japan Inc. for the venue ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Sylve — A Unified System Management Platform for FreeBSD Links: GitHub URL: https://github.com/AlchemillaHQ/Sylve CI URL: https://sylve-ci.alchemilla.io Discord URL: https://discord.gg/bJB826JvXK Contact: Hayzam Sherif Sylve is a modern, unified system management platform for FreeBSD, inspired by Proxmox. It intends to provide an integrated web interface for managing virtual machines (via Bhyve), Jails, ZFS storage, networking, and firewalling. The backend is implemented in Go, while the frontend uses SvelteKit with Tailwind CSS and ShadCN UI components. The project emphasizes a minimal system footprint, currently requiring only sysutils/smartmontools and sysutils/tmux as runtime dependencies. Sylve addresses a key gap in the FreeBSD ecosystem: a user-friendly, full-featured web interface for system management. By unifying virtualization, storage, and network management, it aims to lower the barrier for users and administrators deploying FreeBSD in complex environments. We started working on the project since February and have made significant progress across several areas: • PAM-Based Authentication: Integrated support for FreeBSD’s native PAM system, with optional fallback to local authentication. • Disk Management: Users can view and manage physical disks and partitions through the web UI, with SMART-based health monitoring included. • Frontend Infrastructure: Continued development of reusable UI components and layout structure, with a responsive and accessible design. The project remains under active development and is not yet production-ready. Planned tasks for the upcoming quarter include: • ZFS Management: Implementing full support for creating and managing ZFS pools and datasets via the web interface. • Virtual Machine Management: Continuing the Bhyve integration to support VM creation, monitoring, and control. • Basic Network and Firewalling: Providing web-based interfaces for NAT, port forwarding, and firewall rule configuration. Contributions, testing, and feedback are very welcome. If you are interested in contributing, consider helping with: • UI testing and accessibility feedback • Bug reports and feature requests via GitHub Sponsor: FreeBSD Foundation and Alchemilla (development and infrastructure support) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Jail metadata feature Links: The main commit URL: https://cgit.freebsd.org/src/commit/?id=30e6e008bc06385a66756bebb41676f4f9017eca Contact: Igor Ostapenko Contact: Dave Cottlehuber The meta and env new parameters of jail(8) have been introduced. Each one is an arbitrary string associated with a jail. It can be set upon jail creation or added/modified later: # jail -cm ... meta="tag1=value1 tag2=value2" env="configuration" The values are not inherited from the parent jail. A parent jail can read both metadata parameters, while a child jail can read only env via the newly added security.jail.env sysctl. The maximum size of meta or env per jail is controlled by the global security.jail.meta_maxbufsize sysctl. Decreasing it does not alter the existing meta information. Each metadata buffer can optionally be handled as a set of key=value\n strings: # jail -cm ... meta="$(echo k1=v1; echo k2=v2)" env.1=one # jls meta.k2 env.1 meta.k1 While meta.k1="" or meta.k1= resets the value to an empty string, the meta.k1 without the equal sign removes the given key. The flua’s libjail has been updated respectively to support the key-based handling. Sponsor: SkunkWerks GmbH ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Audio Stack Improvements Contact: Christos Margiolis I have been working on the audio stack since 2024Q1. Below is a list of the previous status reports: • 2024Q1 • 2024Q2 • 2024Q3 • 2024Q4 Important work since last report: • Large refactor in sound(4)'s format conversion framework: 433e270f341c. Further simplifications and refactors in the rest of the processing chain. • Implemented AFMT_FLOAT support. • More out-of-the-box laptop support, especially Framework models. • Virtual channels are now allocated on-demand: 02d4eeabfd73 • Re-implementing /dev/dsp as a virtual/router device: D49216. Apart from the standalone benefits of this change, it will also help us improve automatic sound redirection in snd_hda(4). • More sound(4) cleanups, fixes and improvements. • New virtual_oss release: https://github.com/freebsd/virtual_oss/releases/tag/v1.3.2 • Got my audio-related BSDCan 2025 talk proposal accepted. • Put porting SOF to FreeBSD on the backburner for now. See here for an explanation. • In contact with potential GSOC students interested in porting virtual_oss to base. Future work includes: • Finish currently open tasks. • More bug fixes, support, optimizations and general improvements, in all areas of the sound stack. • Get back to audio(8) • Implement a generic MIDI layer, similar to pcm/, and improve/modernize the MIDI codebase in general. You can also follow the development process in freebsd-multimedia@, where I post regular reports. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DRM drivers Links: Update to Linux 6.7 DRM drivers URL: https://github.com/freebsd/drm-kmod/pull/332 Update to Linux 6.8 DRM drivers URL: https://github.com/freebsd/drm-kmod/pull/344 Contact: Jean-Sébastien Pédron DRM drivers are kernel drivers for integrated and discrete GPUs. They are maintained in the Linux kernel and we port them to FreeBSD. As of this report, we take the AMD and Intel DRM drivers only (NVIDIA FreeBSD drivers are proprietary and provided by NVIDIA themselves). We usually port them one Linux version at a time. This allows us to ship updates more often and it eases porting and debugging because we have a smaller delta compared to a bigger jump skipping several versions. This quarter, we ported DRM drivers from Linux 6.7 and 6.8. This effort did not hit the Ports tree yet because several patches to the FreeBSD kernel (the linuxkpi compatibility layer specifically) are still being reviewed and improved. So far, the feedback was good for GPUs that were already supported by previous versions of the drivers. For newer GPUs, especially Intel ones, panics and display corruptions were reported. At this point, it is difficult to say if we just miss fixes from Linux that were published in a later version, or if these issues are actual bugs on FreeBSD. These updates target the FreeBSD 15-CURRENT development branch for now. Once kernel patches are accepted and the DRM drivers updates merged, we will evaluate if/how we can backport the kernel patches to earlier release branches (namely 14-STABLE). If you want to try them, you will find instructions to build and install a kernel with the non-committed changes, the drivers and the firmwares, in the pull requests’ descriptions. The next steps are: 1. Finish the polishing of kernel patches and commit them 2. Review and merge the DRM drivers updates 3. Evaluate a backport of the kernel patches to release branches to allow to use these updates on older versions of FreeBSD. This work is kindly sponsored by the FreeBSD Foundation as part of the Laptop and Desktop Project. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Suspend/Resume Improvement Links: Blog URL: https://obiw.ac/s0ix/ FOSDEM talk on S0ix URL: https://youtu.be/mBxj_EkAzV0 Working Repository URL: https://github.com/obiwac/freebsd-s0ix Tip of the S0ix + AMD SMU stack URL: https://reviews.freebsd.org/D48721 USB4 suspend stack URL: https://reviews.freebsd.org/D49453 Contact: obiwac Suspend-to-idle and support for S0ix sleep is in the process of being added to FreeBSD. This will allow modern Intel and AMD laptops (e.g. AMD and newer Intel Framework laptops), some of which do not support ACPI S3 sleep, to enter low power states to increase battery life. Suspending and resuming is working on the Framework 13 AMD Ryzen 7040 series, though the deepest S0ix state (S0i3), necessary for significant power savings, cannot yet be entered on AMD systems. The major blocker for this at the moment is being able to suspend all the USB4 routers correctly, without which the power management firmware will refuse to enter S0i3. USB4 suspend support in FreeBSD is necessary as the BIOS wakes them up and runs a pre-OS connection manager for USB4 to work before an OS loads with its own connection manager, so they start off in an awake state. Work has been picked up from the initial USB4 driver Scott Long started writing, but it is not yet at a stage where the routers are being fully suspended. An amdsmu driver was written to read last suspend statistics and sleep-state residency counters (which were unavailable in the ACPI _LPI objects). The SMU is a small coprocessor on AMD CPUs which runs the power management firmware and is ultimately what decides to enter S0i3 or not. These statistics can tell us if the system entered S0i3 during the last suspend, how much time it took to enter, and which proportion of suspended time was spent in S0i3. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Syzkaller Improvement for WiFi on FreeBSD Links: google/syzkaller URL: https://github.com/google/syzkaller work repository URL: https://github.com/estarriol43/syzkaller/tree/freebsd/frame-injection-v2 Contact: Jian-Lin Li Contact: Li-Wen Hsu Syzkaller is an operating system kernel fuzzer that can look for vulnerabilities in the kernel. This project aims to improve the support of Syzkaller on FreeBSD. Based on the existing WiFi fuzzer designed for Linux, we drafted a WiFi fuzzer for FreeBSD. We planned to use wtap(4), a virtual wifi interface for testing, in order to support WiFi fuzzing. Some of the design details include: • Initialize wtap devices in Syzkaller before WiFi fuzzing • Inject 802.11 frames via the existing ioctl interface provided by wtap • Inject 802.11 frames via the Netlink interface, which is not supported by FreeBSD for now We have developed a WiFi fuzzer using existing ioctl interface provided by wtap. One can check out the result in this branch. We hope to introduce Netlink interface, which is adopted by the Syzkaller to inject 802.11 frames into Linux kernel, to FreeBSD to improve the compatibilities between Linux and FreeBSD. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ LinuxKPI 802.11 Wireless Update Contact: Bjoern A. Zeeb Contact: The FreeBSD wireless mailing list With multiple wireless projects ongoing, this report focuses on the efforts using permissively licensed Linux wireless drivers mostly unmodified on FreeBSD. The currently supported drivers are iwlwifi(4), rtw88(4), and rtw89(4) . The rtw88(4) driver was made to work (associate) again (Bugzilla PR#283142). In addition, thanks to the massive help debugging and testing by the community, the cause for leaking memory got resolved (Bugzilla PR#283903). Tunables to selectively control HT and VHT support in rtw88(4), and rtw89(4) were added. HW crypto offload was enabled by default for CCMP. It turns out that a lot of users are still using TKIP. Work is in on the way to support this and will hopefully land early in Q2. HT (11n) and VHT (11ac) support are now also compiled in by default for the LinuxKPI based drivers. The drivers and entire framework changes were merged from main to stable/14 so both branches have the same level of support. People installing firmware using fwget(8) will get HT and VHT automatically enabled for iwlwifi(4) 2200 (mostly AX200), AX210, and BE200 chipset generations. Older iwlwifi(4) chipset generations, rtw88(4), and rtw89(4) will need extra work in LinuxKPI or the driver to provide working support. It was announced that iwlwififw(4) will follow rtw88(4), and rtw89(4) firmware and be removed from the base system in April 2025 for both main and stable/14 in favor of the ports based solution and fwget(8) support (Announcement). Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wireless Update Contact: Tom Jones Contact: The FreeBSD wireless mailing list At the end of 2024 Future Crew LLC provided the source for their iwx port from OpenBSD. I opted to merge the two drivers together using the Future Crew driver as a base and importing my modifications. I worked on this driver, tidying up and removing a lot of development code and expanding support for more devices. iwx in FreeBSD should now attach to any device supported by OpenBSD. Firmware is available thanks to bz@ in the net/ wifi-firmware-iwlwifi-kmod package. iwx landed in FreeBSD on the final day of the quarter. iwx probes with a lower priority than iwlwifi to avoid breaking deployed configurations. iwx supports legacy, HT and VHT rates and some users have reported significant throughputs in test. There remain many issues around rate selection and development is continuing. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Pinephone Pro Support Links: Repository on Codeberg URL: https://codeberg.org/Honeyguide/freebsd-pinephonepro Contact: Toby Kurien The project to port FreeBSD over to the Pinephone Pro is progressing. The aim of this project is to step by step support components of the Pinephone Pro in FreeBSD so that the device one day might be usable as a highly mobile FreeBSD device. In this quarter, console output to the screen was enabled, using EFI framebuffer support. This requires using a specific version of U-boot that sets up the EFI framebuffer, which FreeBSD’s kernel is then able to use for output while booting up. While this comes with limitations (like no hardware acceleration), it is a big step forward in making FreeBSD usable on the PinePhone Pro. To make it easier to try the current code changes out, a script was added to the repository to create a flashable image for booting from an SD card. This script downloads and patches a FreeBSD CURRENT mini-memstick image with the custom device tree and kernel. The resulting image can then be copied to an SD card using dd and booted up on the phone. See the repo for details. Work on enabling the USB port was started but has stalled and help is needed, particularly from someone who understands the USB subsystem and can help move this forward. Currently, some USB controllers are detected by FreeBSD but no USB devices are visible, e.g. the internally connected modem. Help is also needed to port the WiFi driver from Linux, which would be the same driver needed for Raspberry Pi 3b+/4/5 (Broadcom 43455 wifi module connected via SDIO). Anyone wanting to assist can contact me by e-mail. See the post on the FreeBSD Forum for more: https://forums.freebsd.org/threads/porting-freebsd-to-pinephone-pro-help-needed.95948/ Sponsor: Honeyguide Group ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu , Contact: Souradeep Chakrabarti Contact: Li-Wen Hsu In this quarter, we have published the 13.5-RELEASE on Azure Marketplace. Wei Hu continues bug fixing for FreeBSD MANA NIC device. Work in progress tasks: • Automating the image publishing process and merging to src/release/. • Making the process of publishing to Azure Marketplace more smoothly. • Support FreeBSD in Azure VM utilities. Open tasks: • Update FreeBSD-related doc at Microsoft Learn • Update sysutils/azure-agent to the latest version • Upstream local modifications of Azure agent • Port Linux Virtual Machine Extensions for Azure • Adding FreeBSD support in Azure Pipelines □ https://github.com/microsoft/azure-pipelines-agent/pull/3266 □ Building and publishing snapshot builds to Azure community gallery. Sponsor: Microsoft for people in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Containers and FreeBSD: Cloud Native Buildpacks Links: Cloud Native Buildpacks (CNBs) URL: https://buildpacks.io/ GitHub Buildpacks repository URL: https://github.com/buildpacks/pack Contact: Robert Gogolok Cloud Native Buildpacks (CNBs) transform application source code into container images. Those images can run on any cloud. With buildpacks, organizations can concentrate the knowledge of container build best practices within a specialized team, instead of having application developers across the organization individually maintain their own Dockerfiles. My goal for this quarter was to enable building the tool pack on FreeBSD. With the following changes, it is now possible to compile pack on FreeBSD: • Remove obsolete // +build lines #2337 • Use unix build constraint #2339 • Support FreeBSD build phase #2357 The next steps are: • Provide missing FreeBSD functionality to lifecycle and pack. • Further investigate FreeBSD as a build target in lifecycle. • Provide lifecycle and/or pack via FreeBSD ports. • Investigate the idea of FreeBSD buildpacks for some popular languages, similar to paketo buildpacks. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on EC2 Links: EC2 Boot performance over time URL: https://www.daemonology.net/freebsd-ec2-boot-performance/ Contact: Colin Percival FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances. In the past quarter, considerable effort has gone into making "hot unplug" (e.g. detaching EBS volumes) work correctly, with several different fixes required on different instance types. This is expected to be fully functional in the upcoming FreeBSD 14.3. Sponsor: Amazon Sponsor: https://www.patreon.com/cperciva ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Engineering Team Links: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/url FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/url Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-docengurl Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. Document changes Handbook • The Filesystems chapter has been reworked. • The information about official mirrors have been updated. • Multiple examples have been updated including vnet, jails, git, etc. Porter’s Handbook The following USES were documented: • ansible • angr • apache • azurepy • electronfix • elixir • emacs • fpc • jpeg • kodi • lazarus • mlt • mpi • ocaml • trigger • waf New variables were documented for USES=samba: • SAMBA_TALLOC_PORT, • SAMBA_TDB_PORT • SAMBA_TEVENT_PORT Website • Manual pages for NetBSD 10.1 have been added. • Manual pages for Rocky Linux 8.10, 9.4 and 9.5 have been added. • Manual pages for FreeBSD 13.5 have been added. • Pages for OpenSolaris 2010.03 have been added. FreeBSD Translations on Weblate Links: Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblateurl FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/url Q3 2024 Status • 18 team languages • 246 registered users 7 new translators joined Weblate: • Squirrel-hue (ES, ES_CL) • Javier Faig (ES) • Сергей (RU) • Renan Birck Pinheiro (PT) • Davi Rodrigues (PT) • laiis akibo • Raoul Taddei (FR_FR) Languages • Chinese (Simplified) (zh-cn) (progress: 7%) • Chinese (Traditional) (zh-tw) (progress: 3%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Greek (el) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 4%) • Korean (ko) (progress: 30%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 2%) • Polish (progress: 2%) • Portuguese (progress: 0%) • Portuguese (pt-br) (progress: 23%) • Spanish (es) (progress: 36%) • Turkish (tr) (progress: 2%) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. Packages maintained by DocEng During this quarter the following work was done in packages maintained by doceng@: • www/gohugo: updated to 0.145.0 Open issues There are no open PRs assigned to doceng@. During this quarter the following PR was closed: • 276923 www/gohugo link error under poudriere ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Wiki Links: FreeBSD wiki front page URL: https://wiki.freebsd.org/FrontPage Contact: Mark Linimon Contact: Wiki admin The wiki team needs new blood. Since the last status report (2024Q3) forward progress has stalled. We have given out several dozen new accounts but most of the changes by these new authors have been to individual pages, not to the overall structure. Mark Linimon still thinks the wiki could be a great resource if people were willing to put time into it. But right now, there are more complaints about stale data than there are new contributors and new ideas. It is fair to say that right now, the wiki is on autopilot. Previous plans that have stalled Preliminary work was being done on updating the wiki software itself. Earlier, we were looking at switching implementations because MoinMoin development seemed to have stalled, leaving us with an unwanted hanging python2 dependency. However, MoinMoin now claims that they are nearing a 2.0 release. We have not yet tried an install of their latest beta version to test compatibility. Specific short-term requests for help If anyone knows about MoinMoin markup, contact Mark. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Vision Accessibility — Accessibility Handbook Link: Project Repository URL: https://gitlab.com/alfix/freebsd-accessibility Contact: FreeBSD Accessibility mailing list Contact: Alfonso Sabato Siciliano The FreeBSD Foundation is supporting a series of projects to enhance accessibility for users with visual impairments. FreeBSD offers several assistive technologies, thanks to the dedicated work of contributors and committers. An ongoing effort focuses on listing and documenting these accessibility features in a new handbook. Currently, the project centers on documenting features for blind, low-vision, and colorblind users, covering both PORTS and BASE system functionalities. For example: ports for screen magnification, screen readers (which aid users who cannot see the screen), as well as tools for adjusting colors in desktop environments. Additionally, accessibility features available in the BASE system to enhance visibility are also being documented with examples and tips: such as the ability to modify colors, fonts, and sizes in the system’s virtual console vt (4). The new handbook will be organized into sections. The first section will serve as an introduction, while the second will delve into assistive technologies for visual accessibility. The repository mentioned above provides access to the handbook’s work-in-progress, including the code (in a fork of the FreeBSD "doc" repository, accessibility-book branch) and an HTML preview. Completion and review for publication are expected soon. Future plans include adding a Section 3 for hearing accessibility, a Section 4 for interaction accessibility, and a "Miscellaneous" chapter in Section 1 to cover general aspects. A discussion on this topic is available on the accessibility mailing list. Furthermore, during this quarter, the port www/edbrowse has been updated. This is a fully command-line web browser designed for compatibility with screen readers. A solution is also being developed to facilitate easy color customization for TUI utilities in the BASE system, with the potential to set high contrast directly from the system installer bsdinstall(8). Tips and new ideas are welcome. If possible, send reports to the FreeBSD Accessibility mailing list, to share and to track discussions in a public place. Sponsored by: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A bhyve management GUI written in Freepascal/Lazarus Links: Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/ Contact: José Alonso Cárdenas Márquez Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools mostly installed on base system and some installed from ports/packages. The main goal is to be a desktop application focus on desktop user to easily and quickly setup and run virtual machines on FreeBSD hosts. During this quarter, there were many bugfixes and improvements to Bhyvemgr. These are some highlights that were added: • Improve aarch64 support • RDP Login form keeps data of resolution and username used on previous connection while bhyvemgr is running • Support for selecting TCP remote connection at com1 of LPC device • Fix zombie process bug when xfreerdp and remote-viewer are running from bhyvemgr. Now bhyvemgr uses Tthread instead of only TProcess for it • VM name and com1 connection strings can be copied to clipboard from Virtual Machine popup menu • Now xfreerdp3 loads arguments from rdp.args file • Re-use device forms. It avoids to consume memory each time that device forms are opened/used • Network device name can be added/modified manually from Network device form. Take on mind that valid names are tapX or vmnetX (e.g tap0, vmnet0) • Log messages support Bhyvemgr supports aarch64 only on 15-CURRENT and amd64 from FreeBSD 13.x to 15-CURRENT. Also, bhyvemgr can be compiled or installed from ports or pkg binaries with gtk2, qt5 or qt6 interface support. A big thank to Entersekt for sponsor my work. Now I can use a RockPro64 (aarch64) for testing bhyvemgr on aarch64. People interested in helping or supporting the project are welcome. Current version: 1.5.0 TODO • Add uart device support Sponsor: Entersekt ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Container orchestration: Overlord, Director and AppJail Links: AppJail on GitHub URL: https://github.com/DtxdF/AppJail Director on GitHub URL: https://github.com/DtxdF/Director Overlord on GitHub URL: https://github.com/DtxdF/Overlord Contact: Jesús Daniel Colmenares Oviedo AppJail is an open-source BSD-3 licensed framework entirely written in POSIX shell and C to create isolated, portable and easy to deploy environments using FreeBSD jails that behaves like an application. Director is a tool for running multi-jail environments on AppJail using a simple YAML specification. A Director file is used to define how one or more jails that make up your application are configured. Once you have a Director file, you can create and start your application with a single command: appjail-director up. Overlord is a fast, distributed orchestrator for FreeBSD jails oriented to GitOps. You define a file with the service intended to run on your cluster and deployment takes seconds to minutes. This orchestration tool uses AppJail, Director and can even create VMs with vm-bhyve, but as its philosophy is "deploy using code" you can create a single file once and deploy many times. Through a tree chaining system Overlord deploys jails on connected systems sharing their resources almost infinitely. See the wiki for articles that use Overlord. Sponsor: https://www.patreon.com/appjail ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org/ GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ GCC 13 release series URL: https://gcc.gnu.org/gcc-13/ GCC 14 release series URL: https://gcc.gnu.org/gcc-14/ Contact: Lorenzo Salvadore The exp-run to update GCC default version from 13 to 14 has been suspended. Indeed it has been noticed that FreeBSD 13.4 lacks symbols that are used by GCC 14 for linking, please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284499#c0 for a more detailed explanation. The symbols are however already present in higher FreeBSD version. Since FreeBSD 13.4 is expected to go out of support soon (on June 30th), it has been decided that it is preferable to suspend the exp-run until then. I plan to put it back on track on July 1st. In the meantime, work is being done on bugs. Bugs 276070 and 284441 have been fixed. At the time this report is written, some bugs are being discussed addressing special values of the CPUTYPE variable, please see for example 285711. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ IPv6 Support on ksocket Netgraph Module Links: Add IPv6 support for address parsing and unparsing in ng_ksocket URL: https://reviews.freebsd.org/D48204 Contact: Seyed Pouria Mousavizadeh Tehrani Support for IPv6 has been added to the ng_ksocket(4) module. The ng_ksocket node type allows users to open a socket inside the kernel and have it appear as a netgraph node. While attempting to export traffic flow using ng_netflow(4), I recognized the need for IPv6 implementation within the ng_ksocket module. There was a previous attempt to add IPv6 support to the ng_ksocket module (see Phabricator review D23788). After looking into those changes, I decided to complete the efforts and also add validation to comply with standards. The result is now available as an updated review on Phabricator. Now, we can create IPv6 sockets using the ksocket module directly within the netgraph framework. After my changes, I was able to export my traffic flows directly using netgraph without the need to enable IPv4 on my network links. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ KDE on FreeBSD Links: KDE/FreeBSD initiative URL: https://freebsd.kde.org/ FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD Contact: KDE on FreeBSD Mailing List The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team is part of desktop@, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation. It Goes to 6! The KDE ports have caught up with the current generation of upstream development and now deliver up-to-date KDE Frameworks 6, KDE Plasma 6, and KDE Gear. Where possible, the default version of every KDE application has been updated to a recent one that uses KDE Frameworks 6. Many Qt-based applications have also been updated to default to a Qt6 flavor. This positions FreeBSD alongside OpenBSD and Linux distributions with a modern KDE experience. Qt5 remains in the ports tree. KDE Frameworks 5 remain in the ports tree for some consumers. Qt5 reaches end-of-life from its upstream on May 26, 2025, so it is not recommended for use. KDE Frameworks 5 is in a similar security-only maintenance mode. Thanks to makc@, arrowd@, and kenrap@ for landing this KDE update in ports. Infrastructure • CMake received several patch-level updates • Qt and PySide (the Python bindings for Qt) were updated to 6.8.2 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenBGPd Fix FIB handling on FreeBSD Links: OpenBGPD 8.8 released URL: https://undeadly.org/cgi?action=article;sid=20250207192657 Fix crash on interface destroy URL: https://github.com/openbgpd-portable/openbgpd-portable/pull/93 Contact: Seyed Pouria Mousavizadeh Tehrani This work fixes FIB handling on FreeBSD when an interface is destroyed. I encountered this issue on one of our OpenBGPd-enabled FreeBSD servers, where destroying an interface caused all our BGP sessions to drop due to a crash in OpenBGPd. I decided to debug the issue and fix the problem; the results can be found in this GitHub pull request. Now, we can safely create or destroy virtual or cloned interfaces alongside OpenBGPd without worrying about our BGP sessions. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Improve OpenJDK on FreeBSD Links: Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/ Project repository URL: https://github.com/freebsd/openjdk Contact: Harald Eilertsen FreeBSD Java mailing list The main goal of this project is to improve OpenJDK support on FreeBSD/amd64 and FreeBSD/arm64. Java is an important runtime environment for many high performance, critical enterprise systems. Making sure Java based applications run correctly and efficiently on FreeBSD is important to ensure that FreeBSD will continue to be a viable and attractive platform for enterprises, as well as businesses and organizations of all sizes. We released a port for OpenJDK 23 for FreeBSD at the very end of last year, and have since then fixed issues with font management and some other minor improvements. We have also been following the development of OpenJDK 24 closely, and are just finishing a port for it that should be available by the time this status update is published. In parallel with porting OpenJDK 24 work has been ongoing on moving the BSD port also to the mainline OpenJDK development tree, and the first patches have been accepted upstream. Currently the focus is on reviving the OpenJDK BSD port project, as well as getting a separate project repository set up under it. A lot of the work of this quarter has gone into cleaning up the patches of the BSD port based on the development in the upstream mainline and jdk24 branches. Also a lot of time has been spent on improving the results of the built in test suites (jtreg and gtest) on FreeBSD. This has involved both changes to the tests themselves, but also various parts of the low level OpenJDK code. More work is needed to get the final few tests passing, especially on Aarch64, but compared to previous OpenJDK releases on FreeBSD the results have been improving. Finally, a significant amount of time has been spent on communicating and discussing how to approach the goal of integrating the BSD support in the mainline OpenJDK codebase. The OpenJDK project has been very open, welcoming and supportive of the effort, and seems more than willing to help make this happen in a good way. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wazuh on FreeBSD Links: Wazuh URL: https://www.wazuh.com/ Contact: José Alonso Cárdenas Márquez Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments. Wazuh solution consists of an endpoint security agent, deployed to the monitored systems, and a management server, which collects and analyzes data gathered by the agents. Besides, Wazuh has been fully integrated with the Elastic Stack or OpenSearch Stack, providing a search engine and data visualization tool that allows users to navigate through their security alerts. During this quarter, there were many bugfixes and improvements to wazuh ports. • Update bundle python to 3.11.11 • Update textproc/opensearch dependency to 2.16.x • Update textport/opensearch-dashboards dependency to 2.16.x • Update databases/py-pyarrow whl to 19.0.1 A quickly Wazuh jail installation to test it can be done using Wazuh AppJail-Makejails. A big thank to Entersekt for sponsor my work. Now I can use a RockPro64 (aarch64) for Wazuh testing/packaging. People interested in helping with the project are welcome. Current version: 4.11.0 TODO • Add Wazuh cluster-mode infrastructure AppJail makejails • Add vulnerability detection support to FreeBSD Wazuh agent • Add FreeBSD like official support platform by Wazuh Inc • Update FreeBSD SCA Policies to new FreeBSD CIS Benchmark Sponsor: Entersekt ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Chinese FreeBSD Community (CFC) Chinese FreeBSD Community (CFC) URL: https://bsdcn.org/ Community member count: QQ group 249 members, WeChat group 175 members FreeBSD-Ask Links: FreeBSD-Ask on GitHub URL: https://github.com/FreeBSD-Ask/FreeBSD-Ask FreeBSD-Ask on Website URL: https://book.bsdcn.org/ Contact: ykla Contact: Voosk FreeBSD-Ask is an open-source FreeBSD introductory guide written in Simplified Chinese, initiated by ykla from the Chinese FreeBSD Community (CFC). FreeBSD-Ask was established on March 14, 2021. Updates in this quarter: • Added: □ Installing x11/budgie □ sysutils/bsdconfig System Configuration Tool □ Installing x11-wm/fluxbox □ Installing x11-wm/icewm □ Installing net-mgmt/prometheus2 □ security/py-fail2ban (Based on IPFW, PF, IPF) □ Installing x11-wm/windowmaker □ Manual Dual-Boot Installation (Installing FreeBSD First) □ Installing FreeBSD - Based on Apple M1 & Parallels Desktop 20 □ Command Line Basics □ Installing zabbix7-server (Based on PostgreSQL) □ etc. • Rewritten: □ Installing ftp/pure-ftpd (Based on MySQL) □ Installing ftp/proftpd (Based on MySQL) □ Installing ftp/vsftpd • Added several GitHub Actions, such as automatic PDF generation, dead link checking, etc. As always, feedback and patches are welcome. Sponsors: Chinese FreeBSD Community (CFC) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Discord Server Links: Discord Server URL: https://wiki.freebsd.org/Discord/DiscordServer Contact: Setesh Strong The FreeBSD Community Discord server has grown to over 5.3K members, with over 3K members active in the last month. To help support our community’s health and pursue growth in project contribution and engagement, the BSDlabs group developed the Helper program, more than two years ago now. After several phases of growth, we have reached the point where the team has thrived enough that it has become necessary to divide it into three distinct functional teams. Our community health and culture helpers (@moderators) are led by Alexander Vereeken. Our newcomer onboarding and training helpers (@mentors) are led by Alexander Ziaee. Our event organizer and outreach helpers (@organizers) are led by Ahmad Abdulla. Since the creation of the new teams, all of our helpers have been hard at work, driving growth within the areas of their remit within the program. We are proud to share some of the outcomes of their efforts with you, as well as several of the areas of focus and objectives we will tackle in the upcoming quarter. Antranig Vartanian led the development of our recurring series of Ask the Greybeards AMAs (Ask Me Anything) with the support of other veteran sysadmins and developers. This recurring event provides an opportunity for users and those still gaining mastery of our platform to meet and learn from the depth of experience our community offers. Special thanks to Michael Dexter and many others for their engagement and support of this event. Your expertise and skills help nurture the future of our ecosystem. Significant progress into onboarding new contributors has occurred through the efforts of the newcomer helper team under Alexander Ziaee’s leadership. His work has brought newly increased activity to our docs tree. At the request of Warner Losh, we have created a workspace for # google-summer-of-code on the server. This space provides a location for those engaged with GSoC to ask questions and receive feedback and assistance. In further pursuit of our desire to bridge between silos, we are in the process of establishing a matterbridge bot. This will serve to connect with the # freebsd-gsoc IRC channel, as well as other potential links in the future with FreeBSD’s IRC and Matrix communities. We are proud to welcome developers working on FreeBSD’s wifi stack to our server. We have created the #wifi-hacking workspace to facilitate their efforts. Special thanks to Adrian Chadd for bringing this opportunity to us, and leading the way in the thriving activity in this workspace. We are currently in the process of developing our new Co-op Study Club, driven by the leadership of Jesper Schmitz Mouridsen. This will provide members of our community with the opportunity to build their skills in side-by-side study, under the guidance of our newcomer helper team. As a project driven study group, it will develop our members’ passions into strengths, while building comfort and familiarity with contributing to the project via porting, src development, and documentation testing and patching. Experienced mentorship will be on hand to provide learning resources for those who join this study group, answer questions that cannot be answered by peer support, and aiding in overcoming blockers. Our objective is to provide a roadmap and environment for achieving excellence as both developers and FreeBSD contributors. Thanks to the efforts of community helper Jessica Hawkwell, with the support of events team leader Ahmad Abdulla, we have seen the addition of a # foss-ecosystem channel. This development marks the beginning of the process of bridging between the various silos, both within the FreeBSD community, and in the larger FOSS ecosystem. If you want us to add a link to your segment of the community and it is not already contained in our directory in this channel, please reach out to us. In addition to the existing tools afforded by Discord for our server, we are currently in the process of upgrading and expanding our infrastructure. This effort focuses on ensuring the availability of Discord bot infrastructure and tooling, as well as restoring etherpad and dpaste functionality for collaboration. We seek to improve support for all of the dedicated developers within the workspaces of our community. If you are a member of the FreeBSD ecosystem and have not yet connected to our Discord presence, we invite you to do so via the invite link available on the wiki at the top of this report. If you have experience or passion for any of the areas of our current helper teams, or a passion for Discord bot infrastructure development, we would love to have you on our teams. We invite you to contact us via the above contact email, or by sending a DM on Discord (@setesh.strong). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Framework Kernel Module Links: GitHub URL: https://github.com/christian-moerz/framework-kmod Bugzilla URL: https://bugs.freebsd.org/285448 Contact: Chris Moerz The development of the framework-kmod kernel module originated from discussions and collaborative efforts within the FreeBSD Laptop and Desktop Workgroup (LDWG). This module addresses a specific need for dynamic screen dimming functionality, particularly suited for environments where full-featured desktop environments are not in use. The primary feature of the framework-kmod kernel module is to dynamically dim the screen when the computer is not in use and to restore brightness upon detecting user activity. This functionality is designed to enhance power efficiency and user experience, especially in minimalistic setups. By default, the module dims the screen very aggressively, dimming it after approximately one second of inactivity. This behavior ensures immediate power savings but may need adjustment based on user preferences. The module’s settings can be customized through sysctls, allowing users to tailor the behavior to their needs. Users can set different brightness levels for the dimmed and bright states, adjust the length of time that needs to pass without any input signal before dimming the screen, and apply different settings depending on whether the laptop is running on a power outlet or battery. Brightness levels can also be adjusted through the use of the keyboard’s brightness control keys. The module tracks input signals through evdev(4). If no input is detected within the set timeout period, the screen brightness is reduced. Upon detecting user input, the brightness is immediately restored to the previous level. The module requires drm-kmod drivers to be loaded in advance, ensuring compatibility with the necessary graphics drivers. The framework-kmod is not a general-purpose screen dimming driver. It is specifically designed for use with tty consoles or simple window managers like suckless' dwm or i3. Users of full-featured desktop environments like Gnome or KDE are advised to use the built-in screen dimming functions provided by those environments. The development of this module was driven by the needs identified during LDWG calls, highlighting the collaborative nature of the workgroup. A port of the framework-kmod has been submitted, making it accessible for broader use and further development by the FreeBSD community. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Laptop and Desktop Work Group (LDWG) Links: Desktop mailing list URL: https://lists.freebsd.org/archives/freebsd-desktop/ Wiki Page URL: https://wiki.freebsd.org/LaptopDesktopWorkingGroup YouTube URL: https://www.youtube.com/watch?v=U9SdSkfqH9U&list=PLugwS7L7NMXwHlYfDKNMXwJrjFrYVA9ca Contact: Chris Moerz The FreeBSD Laptop and Desktop Workgroup (LDWG) has continued its dedicated efforts throughout the first quarter. LDWG holds monthly meetings to discuss the state of FreeBSD on laptops and desktops and to review progress. These meetings are scheduled every second Monday at 5 PM UTC. The next meeting is set for Wednesday, May 14, at 10 AM PST / 1 PM EDT / 5 PM UTC. A survey has been initiated to explore alternative calling options that would enable participants from APAC regions to join the calls more conveniently. All calls are now available on YouTube, allowing broader access for interested parties to stay updated on the group’s activities. The group’s participants have made notable advancements in several areas: • Audio Improvements: Enhancements have been made to improve audio quality. • Documentation: Significant improvements have been made to the documentation, making it more comprehensive and user-friendly. • Wireless Speed and Stability: Efforts have led to better wireless speed and stability, enhancing overall connectivity. All activities are meticulously documented on the group’s worksheet. LDWG encourages anyone interested in contributing to add their name to the worksheet. If there is any planned or ongoing work, participants are welcome to include it in the worksheet. The established LDWG’s call agenda includes: • News Updates: Sharing news around FreeBSD on desktops and laptops, including work not otherwise covered by the workgroup. • FreeBSD Foundation Laptop Project: The project continues to progress well, with reports highlighting the need for volunteers to support testing efforts and the formation of a UX test group. • Project Reviews and Announcements: Reviewing and presenting progress, announcing new projects, and calling for actions. • Q&A Sessions: Providing a platform to ask questions about ongoing projects; serving as a rallying point to organize developers, users, and stakeholders on focus areas. LDWG is working to improve the call’s agenda in collaboration with the Enterprise Working Group. Both groups face the challenge of having more areas of interest and work streams than available resources. Therefore, a process is being developed to ensure that available time is spent on matters that have the required resources and attention. The group is open to anyone interested in the matter. We welcome anyone who wants to join the group and/or calls to do so. Hope to see you there! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on GitHub URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Bretton Vine (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a repository of Pot flavours and complete container images for usage with Pot and in many cases Nomad. During this quarter, there was a new Pot release 0.16.1 which includes a number of minor fixes. The FreeBSD port was updated accordingly. Potluck got a new OnlyOffice Documentserver image that can be used together with the Nextcloud image. Additionally, a large number of images have received improvements and bug fixes again, e.g. Nextcloud Spreed, Grafana, Vault or Consul and all images have been rebuilt for an updated base image. Last not least, we are in the process of moving the main repository to Codeberg with GitHub acting as a mirror. As always, feedback and patches are welcome. Sponsors: Nikulipe UAB, Honeyguide Group From nobody Fri May 23 10:18:01 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3h1p4R9Hz5x3FZ for ; Fri, 23 May 2025 10:18:06 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) (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 4b3h1n12Lwz3qgt for ; Fri, 23 May 2025 10:18:05 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=iJRBZHQM; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="CdD5zLM/"; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.145 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id C0F9D138028A for ; Fri, 23 May 2025 06:18:03 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Fri, 23 May 2025 06:18:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1747995483; x=1748081883; bh=2Q+J38bzDK cA8ZPPksDkbsaqf5j68tuqVhao0FwAoU4=; b=iJRBZHQMRHZu42GWRwUFvntCHe gQ2zowSvxUhkfc9UcqpUSajDo+dfzlMuncX2Y8npieLqXCFkl50C8MkZ2NAGpKAt lzFpXCAUAm36OvU/hbaGNF7Z2bRx/JteCr15I2ns/jtQC3DtjVcx5lKBb5ijVelm CJpIlQvA+z+2+RGqK6bpJDmXCbM3ETai7/qXS9uJz7S367pBGeT57KzmJRLkDBzB DAsAb+fZVpar2GTkBQI915+g1QZ63MxnJEBMiIAuSP25Q2OWoBxNyU4kjbTWeULO MwSW6vGLEGVWEEkMzqHmDPSFaJmnpeOYQJ5eDZvGX9xJQyuWLZU4Q05jEuSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747995483; x=1748081883; bh=2Q+J38bzDKcA8ZPPksDkbsaqf5j68tuqVha o0FwAoU4=; b=CdD5zLM/HlAOLdT7Ln69sSy0sExN98V3cDpfFVqiXMLVkByaePR HauzNaVP/txMUX4OWipU6hRmX5Aah+8XpcMP47fNex/uOUFpNGoVS6jG2jTkJY+J Uv4A/DXci5bGNn73EHjsPNC7zsBgJ8asoHb7HEX9QeeoFe52GeFYJzYzqd4fMCAA +yACQ3pV0KIJOG07M1X1e1r4dM9ct8dotmSOTWp3ebWS3w/1Ie62jyE9NvBYlRoe si+qIv+06IWkMEofvq76LaCyvAT4rtlN2jqfiNBMDa7++MqIlpJpV1yMlO+Z0cA3 0PkEK2KTeriMIkMoISu5audHoUNQtfrNBFA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdekheelucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhho ihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepkeeluddvlefhie elfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgfeunecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnh gspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggv sghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 23 May 2025 06:18:03 -0400 (EDT) Date: Fri, 23 May 2025 11:18:01 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: epair(4) Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20250515162552.9209B20E@slippy.cwsent.com> <20250515185919.87008219@slippy.cwsent.com> <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.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; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4b3h1n12Lwz3qgt X-Spamd-Bar: / X-Spamd-Result: default: False [0.80 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.96)[0.956]; NEURAL_HAM_SHORT(-0.56)[-0.556]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.145:from]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FROM_HAS_DN(0.00)[] On Thu, May 22, 2025 at 11:06:46PM +0200, Patrick M. Hausen wrote: >"The documentation was on display in the bottom of a locked filing cabinet >stuck in a disused lavatory with a sign on the door saying >'Beware of the Leopard.'" I enjoyed this reference :D -- From nobody Fri May 23 11:11:24 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3jFv2rS7z5x6s3 for ; Fri, 23 May 2025 11:13:39 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (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 4b3jFt2rFvz3G4d for ; Fri, 23 May 2025 11:13:38 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=DQbgQxRU; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=qWUZUCz1; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.157 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 8C6B71140104 for ; Fri, 23 May 2025 07:11:26 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Fri, 23 May 2025 07:11:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1747998686; x=1748085086; bh=qMW9t/huck I3aiEYC3rl1BoB0EDwwpwb3wzmRlAmSx4=; b=DQbgQxRU0+k3aH/4NvohPXBBVh k7AmFJpXyTLziO9Xm1FmQzy9OaTDAlfCW3YAVD4wsgDg22yK54RXJoFz5anBB0NF LdXxB/kuCVlxgxPxIliSqtrWd1qlHi1QKKAfGPq27eKOeb+w0GekU1PLSdzhEGF4 t224AKENBCpHSLk7I6LqdUC1K4nm5AoRs1bCSSU/eu53GgUNBzEkMh+NjkRMidCE HXky4xynLPO9XaoZRY+0EEyq2XMgJpawreAN2Iiq/ssKKkl2yeOL7f73YDNRsZNa nMgFCroS5lSQMBVn+clsz1WpJ5g/AF9zClUQSc7IXM0FEVL7WT6e1YHbSEsQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747998686; x=1748085086; bh=qMW9t/huckI3aiEYC3rl1BoB0EDwwpwb3wz mRlAmSx4=; b=qWUZUCz1HHYmRbXRmo7jpylozdGA9fTfoyrsGr2mVznqqOligvB q8TeTUQf5QZwyBNJHeSB1Xh+77xjUkMRLHUpd8EYc9Dl/oORpykIjgrRDy1N/Uy8 YKZWk8GxXGlrxy6+2PFVa3aGm6dza0jEy3yhWHPcfJ7bMp7j5inxmafMkAin6Dd6 3DA4n9aA/1uvqSix4Q7LGIPZBPIbgfk2prIXBNMyuT2hwrukm1PHv0M10WOPvgcd SoYdc048nBe0D09QCzEebFarhdJq83S1hQjd0wZJS+Hzmje6ivzpBi9KG6AFgT4q Q6Qq5pN+MhYaSdBPsqBJ7zWDRpQ81I6bHog== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdekjedtucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhho ihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepkeeluddvlefhie elfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgfeunecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnh gspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggv sghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 23 May 2025 07:11:25 -0400 (EDT) Date: Fri, 23 May 2025 12:11:24 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: epair(4) Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.com> <1eb27b2a-c05a-470f-ba1b-6730e39cc1d8@plan-b.pwste.edu.pl> <1245F3CD-393C-44BC-BAF1-0D70AC83A0CC@hausen.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; format=flowed Content-Disposition: inline In-Reply-To: <1245F3CD-393C-44BC-BAF1-0D70AC83A0CC@hausen.com> X-Rspamd-Queue-Id: 4b3jFt2rFvz3G4d X-Spamd-Bar: + X-Spamd-Result: default: False [1.74 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; NEURAL_SPAM_SHORT(0.35)[0.346]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27:c]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.157:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[103.168.172.157:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FROM_HAS_DN(0.00)[] On Fri, May 23, 2025 at 09:36:22AM +0200, Patrick M. Hausen wrote: > >If I did not get this conversation entirely wrong, the problem >is exactly that there are probably many people running an >unsupported configuration without knowing. > >How to reach them? I think an entry on the 15.0-RELEASE page, perhaps highlighted, in a section of the page dealing with virtualization, together with the the email announcing 15-stable, advising to examine their bridge configuration, would suffice. Because it'd be reasonable (IMO) to assume these would be read through before upgrading. -- From nobody Fri May 23 12:34:20 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3l3J50mwz5xBqk for ; Fri, 23 May 2025 12:34:36 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4b3l3H0Xt9z3vvD for ; Fri, 23 May 2025 12:34:34 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=lVv1COp2; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1748003661; bh=F5fEyKCkYok48ieojSW1SfBJlaEjljL2LdOT60hjm6I=; h=Date:From:To:Subject:In-Reply-To:References; b=lVv1COp2HVA6EfjTO5Qx87y713ws3HWK2y3yYsAUhmQg2xbClfoHeuY6r+hU9wh39 QEHU9BERb3lPZ3r9Vs/JLhaM7cFWn/QXhO4glB1cjqXUIruzMcgkC4vIE+lNDHFFdY 2uhbyKxKeFdwWo29yRtouWt4Op1VbdThidcFYJgy5e0DbDkeBrYKnGW+kvG6yTOL6p 4gKJi0ybSBrfsnSW4AO5A2TwqJpYgGag3GSzj9S4qmvzpFCHP9ADwYNx3L81GFooJU khF81cHwA55hRfSYTLwF/+dcBcKq00izWVq3XdTQejyfLN/1gfeo9+THlSG6y1sdXq dYG07FtIoQQ+mJtMui1rkeg8AoD8g+ZSDy4D9LaSESNPobGNqe0Utg9hlo+Dgcxt3a cjE/vnIDBlivTi3g0hRYpnYig6Ik4kj7b8h9FZ3LJCPqhq7VwKwba41XPkcRMHOus7 0pIxpBPIUS++d/OOowMscSzWgvyoQ67nnZSoVRe2tkuvJmdYP05CcRCuEl8v2wrfFU IJl9WTDqiUbxARtK1L/vFaQUCiV2qkaqo34R2yjrpO3A3LNvPvl7pgI+VjawM9rKVq GZjaNjBcleRbsHV1HiXZrxBvoR7Yni5tGCcZ+f850IMyx7fpVMZl5GQgwRX8CbpcyD dlNRi0eO7yu1BQNkdIaha53M= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 28E3F59D719 for ; Fri, 23 May 2025 15:34:21 +0300 (EEST) Date: Fri, 23 May 2025 15:34:20 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: epair(4) User-Agent: K-9 Mail for Android In-Reply-To: References: <45d0f49d-229b-46b4-af95-6e8c4c856661@plan-b.pwste.edu.pl> <932111f8-f5ca-46d1-9f66-983f80f6116b@protected-networks.net> <8DCF0DAB-5EE5-4FEF-8CCC-1D7AF971BA8C@hausen.com> <1eb27b2a-c05a-470f-ba1b-6730e39cc1d8@plan-b.pwste.edu.pl> <1245F3CD-393C-44BC-BAF1-0D70AC83A0CC@hausen.com> Message-ID: <69E34A33-A93D-4B9E-8C42-791E5D3C777D@ketas.si.pri.ee> 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-Queue-Id: 4b3l3H0Xt9z3vvD X-Spamd-Bar: + X-Spamd-Result: default: False [1.84 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_SPAM_LONG(0.99)[0.989]; NEURAL_HAM_MEDIUM(-0.94)[-0.945]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_SHORT(-0.41)[-0.407]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] On May 23, 2025 2:11:24 PM GMT+03:00, void wrote: >On Fri, May 23, 2025 at 09:36:22AM +0200, Patrick M=2E Hausen wrote: >>=20 >> If I did not get this conversation entirely wrong, the problem >> is exactly that there are probably many people running an >> unsupported configuration without knowing=2E >>=20 >> How to reach them? > >I think an entry on the 15=2E0-RELEASE page, perhaps highlighted, >in a section of the page dealing with virtualization, together >with the the email announcing 15-stable, advising to examine >their bridge configuration, would suffice=2E Because it'd be reasonable (= IMO) to assume these would be read through before >upgrading=2E this is not the first time the things appear, disappear or change in fbsd = with only dark secret back room discussions i have been here since 4=2E6 and if i didn't read this, i would only know = this unusual setup finally stopped working when network doesn't come up aft= er reboot yea yea yea, testing envs and everything=2E reading docs and changelogs=2E= you still hate having sometning slipped in that derails everything for mer= e perf reasons that you missed From nobody Fri May 23 15:07:04 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3pRY0PrZz5vsHw for ; Fri, 23 May 2025 15:07:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3pRW2lk4z3m7s for ; Fri, 23 May 2025 15:07:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kv2adtXW; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.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=1748012837; bh=mAZZQwb5gd6UbyIXwn/bfusGgWh1HZk5bRxnzieYWtQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=kv2adtXWzdCh/Wy/izwzs9KRuvnoINFwqGLhuU0I5Yxbb4rrN5odF5t8OiG6pLMcdu7A7dcMl5LPAw6N6aBZr1W/DaSi5Y5qje2NzMxYLO+ExOVSCvd9NJwaVdC9dQIk/2zZgeQR0qb9Atp6V/afADslTv7dX0YzwEMsz3IyiY5zRE9McIkPjIjFU4RERGf8KaA7BL4vcS5vgdrJtXQ5XTauNqgc91roe3KmS0Ie65agFwEz8qfmTnixlqD7Vhuavoz6O0ZWgbAtmHpNW57SJ3mScGEKGrG2Etj9zQ09k499pXaldfcGH9yAwfEILA2xndoS7yhwGMMv4Apxsl9ESA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1748012837; bh=6QfBeKByDxDsTuqm/dr6oEysplYFXHevdbqZ/vy7+hZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=i162fVwp4lIOvEdLQE2TB4gL2yzyhZigkvHWSHer6BoVOkhWCeNK6PjYr0uSlqPFELdjTnqsnmz465GPlUlAwtzD/KKWSyPl2hAEGwqOAQyonzOPaqBv7lnYwt9xeRVVFX2thiRfamYra4sef6t39X5vR0A+LCKTCt0cVyp7s9o+vyPVi4xB/oDraMKknmQzDiPsvF0rAnK1g0R1426r0Z5vN6YnTuaJ6D/B7m9ZBT4fbLtbRMyDL8sQmGEPBMObz7A5033WRpl4fDnNIiWoCQaxMwsKHCLDBEw2Fg6DW2Oy6X161XQ7g+WPgxl2lk5zS9R42iKo/T2RWHGvNUSUCw== X-YMail-OSG: HU0nkRoVM1loykcyRUNBXAHpdFwwe1_VYDeGxYodL0fZ65qXvEQfwvcwZmjETDL pUeQrsocZBJrJnLwMtRu.KQvjWCZZ4u_gWpMwvtyLntwkrw8_gHtsz7b017adCU9IzPtoNZn_u12 q3C772KLrYfoBrDbxG2PPX7AqANckYmN06CvfrSUoikl2pGbyyXngGUAJAaZqDORr5yf8pNKcQqT o4EBzcN_38LK0XpM57_1zcqww9cqtQaQdLIut5eRA4KSReno5k9AtwZaDmaSzoZWWxfFncssoEZy JoLi9X2NzX1AvKYEEcBcPGapbcjnez7KpR.AAGVtex535KEhZ.0DeEJyt5jo5sSNyvbzb2AVbV4f 8FJMfjKji7HuJvQDwihPmf1CLrHNxU0S4XmA7d15COgPjksoEmjGDAw7XNU9kDQNozb9rBcD4ghp c_iT5XMUCHNrzlR1uedDHZ5IMvNgxZw3amuGEqXWQliz7C10YtiEwuco_bkJLvWMaCqtOJdaKiqb gYeVYR03_5PWlWFxskeB.Gw3C3qFCZgV.2CjslosLN6GPl4nrX19PeyRQ5zxeUYXPlhzJLGPw19f z09LkDJ4zl7M1LPASG75iI_elXarBG4sDUGvUd8uQsPnlplZ9myer6BYw7o.FeFJp248_y3HBcBo .Xbk6QDb9ReynPjn0NB92EJMiRK1yO3sKjxvsIfBVA0gRbitWsrIoROU9cV7ZUchf9ngIiB0zU9w bpltpTuvN56wcAaeO41MZ3nJN7TqNV4JvyioFqBoUMKR_JQJgf9gjRKmrNdBHnn4.ngJAMRoIMfQ 5mJvu_7Hx2tHE53ZriF3cvWMUQsGKGiVJVJ6T9Z2eqAaCYASS9RRNLyFxsu9M00h0avuj.n1acjT R5yUPCrW7k2x.W_uInlTiipcZgt5gaVs4nEW.Pv_CVaHkhq1b1jyJOMbQ6p4kW5p0DyTmwUsc_g0 555MzF7CtKIcw88luEf0KXi_9m4XKV5Se8ifmHiJQHVNc7aeTM3w9iFYef1XS62vP.5Q0mYBgRUx svDzuJ3VuvrfglAArPLSrWNRS0of8SNGWDZUbYcliMQrXk6ao_b4Gj2oETWD6WahuPqHBKR_bEIP qQLuMkTekBVVkAUYHTLPyOAymNuku.uI2r.f32iv3iLGVkc8pShipLCwZlKnPscHAxQ5scOD7tkO 5f8LEneeRUWn.oQ5mzAvRJ81dXQOshXe5YlD9W3axZgdppqr3ZpIXFQew3lKxVyjIo43.rLJQW32 GPPA.xYTh48MgToroBc3u2J655LTnqcrGK5cEa4dLcCVyLjuEVk.iSw7kLO_O5nMiGsmeomv9DgQ yg0guBJGyqm2R.8td2JoAxof7QHf8duzE70BpxRVLzCzQgGhEFTGt9JAaSi9qtyalqkEZwuVDVHX 8AHcb91.Gw3lNdkFMEiLZKElal6IvylIsHwhFNWBOYxO1pM4A08S3i92LSr9V3xyWZE3lQ8oDoZZ HHZvxLIXs7dAAnAhom_eu.4xKv0l33W4t9BcnnSgK13_5s9IwysFrak2tDCk1HZI2rnnKvGOqQ8E nTT4GcQgxrm56PnWEWu_KSqOiOgONIZCUvK4VDbDIIddHtyG5UdEhiR3O5Ii2B5uaMAIACINn8yx 3JQdrlsgp1NVSrXZDZNCsv3oP2L40_h4bXrd7Xs4eN6e3jfopm_s9rnX3w0kIpKcMZx7iY_0DHPO 1vnGJ92zbkNPv0eL1FgyMWpyLQa5GRkOZEgqlaos8DO96y24kuEZowVdb2C9j.Vq_FWp9imkrqX6 EdpexMau6DCdeaCL7uiMF7gAU_bRyBQUeFcRWS22rtvs9a8L6PIwGP2bN7GwL.Ze1Ek3l.1qnfAk LX49Q3Tbvxp9rnLtle9wq4qMwbiO78PCCyltWzOWljuTJc0gHgtMn93d1f7xnAYDPYWcX1hEOkYW IMv4XEuSHh6CAuOVa2UkgGw6sxZq3ROL9RVDzjNrOz3PWj66gtm5hsmDB3FfdfchjRh2gZhzUzzx dXxFhy7ef1AFtQDw9DHHaJ_MCuaLl5XE3WvNxdlMJYDkEDzLwfHkz22CjX_0UnLnLX9Zcl1e.LYa .6HOgj2hC5pRF8hZWMbA0GzwZL2M9GbZYN0nPCVvBWQtUE96k1mjAn9Lq4gb6RYn_b064vaIJ5zl 4eha71Ucm3ZtU6O5iOUUuU8fJ8_TPOByud7hdewodz85S5sIEvTa0UjOU0jMMCCCQknaW4oJAZS9 uagtD5pdMhN6V3QlxAaI85ZUp0eShQ7AaqR6..m3sDnrpudHzy3BUw9cwZ6eKWYObKNZrWfnKVTp J_9XH.Q-- X-Sonic-MF: X-Sonic-ID: c50829bd-b1f2-4cd5-bd4e-82d9138a6127 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 23 May 2025 15:07:17 +0000 Received: by hermes--production-gq1-74d64bb7d7-tqd77 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0e96659572aee38bae7468224ee04de1; Fri, 23 May 2025 15:07:15 +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.600.51.1.1\)) Subject: RE: FreeBSD Status Report - First Quarter 2025 [GCC part of the report] Message-Id: <1B5A5EB3-15AA-42C0-83FC-B6ED304F82BF@yahoo.com> Date: Fri, 23 May 2025 08:07:04 -0700 To: Lorenzo Salvadore , FreeBSD Current X-Mailer: Apple Mail (2.3826.600.51.1.1) References: <1B5A5EB3-15AA-42C0-83FC-B6ED304F82BF.ref@yahoo.com> X-Rspamd-Queue-Id: 4b3pRW2lk4z3m7s X-Spamd-Bar: / X-Spamd-Result: default: False [0.04 / 15.00]; NEURAL_HAM_SHORT(-0.96)[-0.955]; NEURAL_SPAM_MEDIUM(0.85)[0.854]; NEURAL_SPAM_LONG(0.64)[0.642]; 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)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; 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)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[] Another issue for lang/gcc14 (and later) is that it does not build = on/for main-armv7 . In the poudriere build logs the issue shows up via the likes of: checking for library containing strerror... configure: error: Link tests = are not allowed after GCC_NO_EXECUTABLES. gmake[2]: *** [Makefile:11359: configure-stage2-libiberty] Error 1 An example of specific type of error for lang/gcc1[45]* from the config.log involved is: /usr/local/bin/ld: conftest: hidden symbol `__aeabi_unwind_cpp_pr0' in = /wrkdirs/usr/ports/lang/gcc14/work/.build/./prev-gcc/libgcc_eh.a(unwind-ar= m.o) is referenced by DSO The error is tied to statically linked contexts, which is involved in building lang/gcc14. This is tied the main-* having libsys now, which is why 13*releng-armv7 and 14*releng-armv7 do not have the issue. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri May 23 15:09:00 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3pTW5qh2z5vsJH for ; Fri, 23 May 2025 15:09:03 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 4b3pTV5BWwz3nRl for ; Fri, 23 May 2025 15:09:02 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=IxfRzwC0; spf=pass (mx1.freebsd.org: domain of ianfreislich@gmail.com designates 2607:f8b0:4864:20::b29 as permitted sender) smtp.mailfrom=ianfreislich@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e7b6d5aafd6so6810433276.3 for ; Fri, 23 May 2025 08:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748012941; x=1748617741; darn=freebsd.org; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=GdsrcYx20L17C+wfR6jYItK/YL/2PXkYOhCrtq4hzjk=; b=IxfRzwC0HJZOciiv5Tz/slFj9dtJmjACWjRvheKGT6PgxLuiwC6YPYq/PWSjl0gfkT cPCHg0cqk6uCwc5cyfPmJVsUtbkd3XVfliOSj/qbBm/I37nz3zMui9ih6wOwagGEAkxQ 3OeDGfk0kYG0QBoYHSx4gZ+mCat2QraG1ZSrCMSCsdDkGGHdpptr5gs6BTShGX2FVcL8 MxO3osWxM+UL+RRPT7TXMlowSlZjgOa0VKiQZHMXtOaBdOP+26fBpat8pZ7d5jKcEneL Mm131z1QXbPbyiKUKmBvhJONfpstyPzMyKzxwI5HGFnAM07/x9OC23urv85mbBUf/glg 2jLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748012941; x=1748617741; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=GdsrcYx20L17C+wfR6jYItK/YL/2PXkYOhCrtq4hzjk=; b=AfH/P6Tu4+6KfQr/qrbUAm9hLLb57CkDl96tNHLYGouCFV4Upexq8iFu1y2Toh9kyB GBNKlpwqnMuCeqC6S4fKv9K8U+M43hJZCYubucgmdZIukQzWJbLPdPUeItVWWw0srOP5 Fd+NQvmpbvGzaX6N3KgY0WkB0XXG0FnSGoIuSUg77eG9QnKyIkbtq2SpF5KrAPlCC1JH B4sUHqUPoRZ1sQLbThLH58INZ+0v+Nm9HlxZpPrx5ueuy9/vwcUeDx+TDQThlV1TbasK VgzBhaBAZyprZeA/b7DVV3KgxaYCoyrL/LnIxnr13qYRHsCeyib5Qs3GZVo8LV7RvlyM oWnQ== X-Gm-Message-State: AOJu0Yz4fINRsq8qA4jFizvgpKXAyKKCVv7FvtjQaczdsW4nLC/UzaPm u39YV5W1pZWAk38Gwn4cmp9DY2ny2O1ygSY84qHl5zWncxZ6Hhe7dA0wOJNlqw== X-Gm-Gg: ASbGncslzoh8Q8v+PE8MtEnGWx0lIFM4aotl0NQhxZhRGrv2kwGf+F1kCqSnUCpqXHw eeNdYP448rbvu2IdcAbjErGLYnu9CCXWL87R7IseEZ8NnYsVeJ6IMdbofXc0WP6tU0MDcD84Qno rV/mTtEteUIhJdK3q1tZKeinDzuhkH7w4q4FakTQh6Gtv8pIhgnvEhMqt4BYhk+U9BCjMNRb0Ro aioAKg1bwcU0PgLjJ909F+WvbfJKFP2hOQXaQLWV1xJ0BjPPSfFC4hUVqY6kK49sG19JA31M8/v JTbVj7M/VmqaejHIrWMj2ovmlk9zDKvbCVVc2gD8Axzh8AOn6Ib7FddCEvsDSwEHY+OJBpgKbeT 0snV71m1KLlRpXFA0v0HfAX25OSaTIw== X-Google-Smtp-Source: AGHT+IFoUQ5zlG6lgVwVHER+v1++iwZlUCIH40vwGMrM+yZlaPBww0p72Isds4/obRAgOq1yVqdAcA== X-Received: by 2002:a05:6902:1025:b0:e7d:78c3:f4c6 with SMTP id 3f1490d57ef6-e7d78c3f546mr5492114276.39.1748012941536; Fri, 23 May 2025 08:09:01 -0700 (PDT) Received: from ?IPV6:2600:1700:18f0:6812:129a:8666:ef01:3293? ([2600:1700:18f0:6812:129a:8666:ef01:3293]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e7d7ffa5649sm445183276.47.2025.05.23.08.09.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 May 2025 08:09:01 -0700 (PDT) Message-ID: Date: Fri, 23 May 2025 11:09:00 -0400 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: Thunderbird Daily To: freebsd-current@freebsd.org Content-Language: en-US From: Ian FREISLICH Subject: 7587f6d4840f8: /usr/src/sys/kern/vfs_cache.c:5276:24: error: variable 'cnp' set but not used Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4b3pTV5BWwz3nRl X-Spamd-Bar: / X-Spamd-Result: default: False [0.05 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.988]; NEURAL_HAM_SHORT(-0.95)[-0.951]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b29:from]; FROM_HAS_DN(0.00)[] Build kernel is broken by 7587f6d4840f8 Fix: diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c index f2368877ec93..b4b50b4473d7 100644 --- a/sys/kern/vfs_cache.c +++ b/sys/kern/vfs_cache.c @@ -5273,13 +5273,11 @@ static int __noinline cache_fplookup_dotdot(struct cache_fpl *fpl) { struct nameidata *ndp; - struct componentname *cnp; struct namecache *ncp; struct vnode *dvp; u_char nc_flag; ndp = fpl->ndp; - cnp = fpl->cnp; dvp = fpl->dvp; MPASS(cache_fpl_isdotdot(cnp)); From nobody Fri May 23 17:45:17 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3sxv66kpz5w4r0 for ; Fri, 23 May 2025 17:45:23 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3sxt2Fn3z451r for ; Fri, 23 May 2025 17:45:22 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=IFuVdOKj; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org; dmarc=pass (policy=quarantine) header.from=blastwave.org Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 54NHjIWj076402 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 23 May 2025 13:45:19 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1748022319; bh=oEq0cyGyC3XVlk1LRpEzufntSPgNJ7OljbSD/w/Phh4=; h=Date:To:From:Subject; b=IFuVdOKjTZKYXA0TpCYqM4m+dh2t1uhP643bA/ytOczmaQHtdskjSYtJ0221xnIs3 HARPj5VwVDwVK5tBMMzj9glJdKnaH4sdWQnydzgXzdTsdzXUK53mTqFbftSnJR6ScB g7jlYNoONCpA2gYsz7PCODBnabyxCVxw/QFhIluKu+FaDXGoNqlJt/hgIgwk3DX9KK rGg3o3XQMAhBOqwPU72Big8A3Qiu/C2nyIntRihxQBH+6vtDJKiRzwHHYjRe2SZ0fN xt8HMfl4etOk7BA2nOGJoPTHke6XE/m/c+M6i71tx3MM4/zjX8hfg+h3zwkBNi20na ZL/bmJvSfOD0w== Message-ID: <17ff4ba6-c700-4810-84ba-987da18f04b8@blastwave.org> Date: Fri, 23 May 2025 13:45:17 -0400 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 To: FreeBSD Current Content-Language: en-CA From: Dennis Clarke Subject: Is there a way to tell poudriere to allocate more memory to a pkg build? Organization: GENUNIX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 54NHjIWj076402 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Queue-Id: 4b3sxt2Fn3z451r X-Spamd-Bar: - X-Spamd-Result: default: False [-1.01 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.82)[-0.824]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_SPAM_SHORT(0.31)[0.312]; NEURAL_SPAM_LONG(0.20)[0.204]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MIME_GOOD(-0.10)[text/plain]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[blastwave.org:+]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[] I have been watching qt6-webengine-6.8.3 fail over and over and over for some days now and it takes with it a pile of other stuff. In the log I see this unscripted trash of a message : [00:05:03] FAILED: v8_context_snapshot.bin [00:05:03] /usr/local/bin/python3.11 ../../../../../qtwebengine-everywhere-src-6.8.3/src/3rdparty/chromium/build/gn_run_binary.p y ./v8_context_snapshot_generator --output_file=v8_context_snapshot.bin [00:05:03] [00:05:03] [00:05:03] # [00:05:03] # Fatal error in , line 0 [00:05:03] # Oilpan: Out of memory [00:05:03] # [00:05:03] # I can not make that stuff up. So is there a way to say that the pkg build for a particular thing is allowed to use 128G of memory or whatever it seems to want? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Fri May 23 19:00:25 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3vcs3jQpz5w9jD for ; Fri, 23 May 2025 19:00:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4b3vcr0yKvz3l43 for ; Fri, 23 May 2025 19:00:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OeXC5hlj; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 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=1748026841; bh=V0E0s6Z+DhqC70hKxfOTleHfYdeL/PWIAsGnc+x6dAA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=OeXC5hljDBhi85qda04g5/E3DlZsB9I7MmEMDg+Z1itVCjhonc85QwZ8aYzOvMZN9bnn9LT+esbWqa/wScig2G7JkG5ovPPdBAve627LbGk6IBr5QDFYlJUj5k2iqq3MQ84H7v9XefGvXaozQyd8nMvdhLBhciVtwv6OVBK9mF3K0WX/662VUNTN1wZW53hSwY7M8LUwMFoolCWU8VTLZerp+gsR+wHbKmBfNoG3D8Be8V3O0k85QyYEefqUCtGCxayWfdgy6wcCGV4/NnKc5Bvd7ICbwM1/wBfbd6Eiee/zPoNrmIv+pr6KrVbT7AYllwc1xpM5pY75GidY9dXdrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1748026841; bh=PJUe3fQfJb49Q2dXC3XfSZPT/BHjvMvTT1qYrtICBR4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NoQYiG+l0CmXdcmJR/H5SpPWxlmUfk7arPq6eSI3aILNCoJu9ZOYVrXQr+ZqyW9B1KZlNEN8RjOwTcuTAwtQAugi/cUTY6V7xRPc3I6GKGiR6POjhK3/HMUopGTRRV8Qq5FD6vYAZxiPuHJrFxv5Do3DekzLA4eAcatIocdB//krPwGSQtA/m7X5oUcYL42q0erls2A+5FU7rNTLZ9/0sSXB2F8BRhQXURzwUFfXck+r43feeQT88r8pyCZkXv+CZoqfE65D8hYU0ZLlOLw5a9xOrKUJnm69xXVCKimfItY9i9N9q2FO7o+so/4F6HR/yVb1mm8c95tm5C5Hf8k/fw== X-YMail-OSG: jAPzw98VM1l8e4TnDJnYUqUqK3RHiNU2aAL0LCxiJM8ksPDCNpr.y0KrPypaxIz r_M7AAUn4wNtDiychYATK99vdn5H5WoVXbgym0tmMhL4GGAlYK_lVpMDQRZV3soCVn3tZLh1xPsD hkWSazCKLIjMZWrvGfF_IrFCPyUREsbKbohEANRYNEEaEbYGs3vcV7o..s.euPYRpIR_lkLq7G.o wrQDfhn_dJiYDSdkZl0nMSZ33Ip9Qm1CNzjcWvbN5A1R1Ane_dXe_J2QQAcBrcsMM_3jSBPFHJCu v5CfSDJcPiPGLUNVRSFgF7PrnYiVhhJl5p5826_NQHy5c9D3L1oBiYb4EBf5_.tnLcFPvDmtD9f3 cv3QfdCrXHif36jKM8mNeEG5WTl2RXDFuPxfmKKCBRIpWA7Z9YeOZ8PcS6CMVYH8T4hJTtG73U7. YqJ9vUhckyd5Fyvvj165WJcY8b97khRhGXPjjMmEwYfLDV0BSTGRMkoAz4_QvQSH8oGL.BxIA6IF _qKq.1nqKQ5MWJelTKDC1jeOh4KRo12BlXgyxWR4O8uZLdSLZiUQvbG3Sc7qKDavmCCxWLvuoLeh Bb1WNOwourA6XfF5aVWu3yhrl_E5C6XOGWJE1nITGt.LJ241Kt5PZ.7oQQj55OFR8bzU28a8w.xC IgYJTYhXe6IOv.uzd8su1QRXWGk56MkcmbQ91tx65kwBdUV6pDfBp9ktC_.I7DQXl94NIGRyR18L j3dPfptj6j_8ApiECw3utWYmVDDwsnQMiZHeH7F60rImiyyb6IL0sSKidJ0QrmV7Bmy87qtIyMXF Rq4KN1AWnQwRacmBnAqrStdgeIe8Fdp5xjliXEH0ycmQ2XYERSfCaav7BFTIZORSokncaeFSSfHB InrtHoR7ewC8hUhNPIjXI304skEV1Ip8vgUuKouT.rvwtGJ0sxoKe4zI9X.ZST8WbRp37wL7DxfY r8gO0EeXgh2MxTW4Lguk9QM_oofsMkGpNKn8f1FYl0RWCHVkh4fnSQWwsBP2faBjQPsv242nAlHy 24mTXQP3igqGQgUWvqn9rQqGR.cVqD34ZvM88lh1Rh2FK3.rU8ic_da0cgRqmydxC1F_8Jjp4GPM mqGzg.UjFdwZsqwO95xawUa_OI2ml7OtEofjsjR30RQmxel1hq7unctEDYrb3s2u6F_myAadhBd1 9lhprprZBorLCyTARxdHhubsKXFMaM5APvTnHNVr3OEz0xBLZDL0kv_klsrl5TnYbm1bG_vM.E1h 504.oIDZHUSn7FuZz9QOeLuc3XIHF5JUbQjnC7rrb1FQbUhfE0TDD4F2aegoyw_Y45PaPlp9GnX2 .reERpHVUVNB0ZlRyHirfAdM_FRE9gSDl635.m1T7L5i0ZeLYicPUt6pmFSu3Ou3JrbT83_NI1qn C1Dz13ViiGvP_9Vd7MdMLNtmp_vFWDj6njh9Tpk2czzOgVdYwdjcHjXox4NSGTcpJ9MJDbQw3J2J fXNBx0UjkMZczYkYA0n6PzQupW8e7o572vY5XvGZR5J9I5AsH27jflVgWLZMvIPGQBsmroWZ_96o yuQ610PFq_JltwY6mguaNhL2UKzJ1uwdQTXcJnvYaRkf91kNhkDaJHYfkwL2kMnMslARMNGg2.r3 C7fG3u.16ZrXjgqBVsrAINZJYtd1PJ0GayJD60GyPgPii5tuKd9o39Si_MU1DD7FQ0L0vLtkVwOF sOa3FjhMLVEtc1NDuRO9w.fWu3ihyDBZoDaFQt.75mk0c4b5PFf2Eqtkbi3tu0KLlKZFu5Juyc94 F5gn5zWSutaOlLGgfKPplnD8DtzUZLZtbyoulhsVYV3H2.fsOCRY126D454D5FaWJZ2AdasFVdCD xeSEgTB5ielAS.G_sFBX7dSVXZgkOYLM4ewt4.Xdh4Fxofas.mzwLG8rQFOPdZpANdQ2fNeAXXqU NXFaUUpujt.pxOn14KcrzTD4QNI8_YrUVb.e.qHMx.IWRriBxQUYsJda4HpEJ5L3MYRCNpTTmn1V adsbSypvNuckzwyKZs8eYUb_nAZUqkIFwHehReFicDBZXTrrKmavIbZFgkE9qlnsz69lvFiV2ack MLG9v.semaKOCON14LlvTHO528jQ4dxlml0NqWTLOZJQGkQu_r2.SMfaJhTvGliUi3ppNkCfqBBA G8zLODqXDymfUsOtK6Is2.BY0QV59jy0KWEip5BJG4UJkBcV4pr_2UNC8xqm1fEDVZUawVz9Dddm NZzi7j0KyRVwF1EooS3k2i3.DMEGqHrSYtZjxUmnq6Qi88DMdKvz2N8tvec67.iMO5NIWhPQVndn cTKy5Mg-- X-Sonic-MF: X-Sonic-ID: 6655b780-07ec-40dd-9ba9-0943c093d85d Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 23 May 2025 19:00:41 +0000 Received: by hermes--production-gq1-74d64bb7d7-45lk9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fb4ba86f99369047ab4c2937b1d0c5ec; Fri, 23 May 2025 19:00:36 +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.600.51.1.1\)) Subject: RE: Is there a way to tell poudriere to allocate more memory to a pkg build? Message-Id: <30CF8464-32D1-4752-865C-1EB1CA9DB4E2@yahoo.com> Date: Fri, 23 May 2025 12:00:25 -0700 To: Dennis Clarke , FreeBSD Current X-Mailer: Apple Mail (2.3826.600.51.1.1) References: <30CF8464-32D1-4752-865C-1EB1CA9DB4E2.ref@yahoo.com> X-Rspamd-Queue-Id: 4b3vcr0yKvz3l43 X-Spamd-Bar: / X-Spamd-Result: default: False [0.51 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; NEURAL_SPAM_LONG(0.87)[0.868]; 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]; NEURAL_SPAM_SHORT(0.13)[0.133]; MIME_GOOD(-0.10)[text/plain]; 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]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; 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.65.31:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from] Dennis Clarke wrote on Date: Fri, 23 May 2025 17:45:17 UTC : > I have been watching qt6-webengine-6.8.3 fail over and over and over > for some days now and it takes with it a pile of other stuff. >=20 > In the log I see this unscripted trash of a message : >=20 > [00:05:03] FAILED: v8_context_snapshot.bin > [00:05:03] /usr/local/bin/python3.11=20 > = ../../../../../qtwebengine-everywhere-src-6.8.3/src/3rdparty/chromium/buil= d/gn_run_binary.p > y ./v8_context_snapshot_generator = --output_file=3Dv8_context_snapshot.bin > [00:05:03] > [00:05:03] > [00:05:03] # > [00:05:03] # Fatal error in , line 0 > [00:05:03] # Oilpan: Out of memory > [00:05:03] # > [00:05:03] # Way to little context so all I can do is basically form questions at this point. I assume that you have not explicitly restricted the memory space for any processes, so that RAM+SWAP is fully available to everything. If not, you need to report on the details. How much RAM? How much SWAP space? (So: how much RAM+SWAP?) (RAM+SWAP does not vary per process tree or per builder, presuming no deliberate restrictions have been placed.) Do you even have "whatever it seems to want" configured for the RAM+SWAP? (I'm guessing that you do not know that the "128G" figure is in fact involved.) How many parallel builders are active in the bulk run as the bulk build approaches the failure? How much RAM+SWAP in use by other builders or other things on the system as the system progresses to that failure (not after the failure)? What USE_TMPFS=3D setting is in use? What about TMPFS_BLACKLIST use? (So: is v8_context_snapshot.bin all being put in RAM+SWAP? Put on media instead?) I'll note that even inactive builders can hold tmpfs space that had been in use in the prior build in the builder. So looking at such use could potentially be relevant. Any general other system use of tmpfs that might be competing for RAM+SWAP to some significant degree? ZFS (and its ARC)? UFS? If ZFS: Any tuning? Basically: all the significant sources of competing for RAM+SWAP? Watching top as the system approaches the failure and reporting on what it showsd could be useful. Going in another direction: notes appropriate for other folks to try to well approximate the the context and then try to replicate the issue? > I can not make that stuff up. >=20 > So is there a way to say that the pkg build for a particular thing > is allowed to use 128G of memory or whatever it seems to want? It goes the other way: you can prevent other things for competing for RAM+SWAP. Also, you may be able to increase RAM+SWAP (but avoiding mistuning via too much SWAP for the amount of RAM). (For 64-bit contexts, the system tends to complain somewhat above, say, SWAP=3D3.6*RAM, so above RAM+SWAP=3D4.6*RAM . The detailed figure varies some from build to build and the "3.6" has some margin to avoid detailed tracking of the variations.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri May 23 19:13:37 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b3vvq6Dhvz5wBpr for ; Fri, 23 May 2025 19:13:43 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b3vvq2sL4z3s4Q for ; Fri, 23 May 2025 19:13:43 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; none Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 54NJDbmJ078729 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Fri, 23 May 2025 15:13:39 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1748027619; bh=+zxkadMXQ0Pm2o7ATlV+9DNwwSNbyxkAUBZguxYDI/g=; h=Date:Subject:To:References:From:In-Reply-To; b=h1RtV6WIJ7c4CM4zrGZ4Kea8tGYKuhl7it7b/FAUtx0q6C68Wl9h9ENVtMtO7uZMu Df7Y30XPq+AUlwwjFhuq+SF0CUMVd7AbjVIQv5GO3x+ruwlM1mGOOjAeuoHKHDH5mP QG5zTtKk1ZB8y7/dK7q0wFjeRmfV3bRHh61n1ldJ1ePIUlhNcfe4q1dMpOXNGDyvnu Isg/GPXIhjO/GukjP/tC7eP39fmhnSVkyyCrUpdGAcIRwUykLvD8d15H43TqtiqXep onJxDRyfoeJPAa5A7g65vVhAeUXzhp4zbR71UC8TcPr1SstwU0bwK6RVTk66FrFWBU OBgbC/3CdXv3w== Message-ID: Date: Fri, 23 May 2025 15:13:37 -0400 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: Is there a way to tell poudriere to allocate more memory to a pkg build? Content-Language: en-CA To: Mark Millard , FreeBSD Current References: <30CF8464-32D1-4752-865C-1EB1CA9DB4E2.ref@yahoo.com> <30CF8464-32D1-4752-865C-1EB1CA9DB4E2@yahoo.com> From: Dennis Clarke Organization: GENUNIX In-Reply-To: <30CF8464-32D1-4752-865C-1EB1CA9DB4E2@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 54NJDbmJ078729 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Queue-Id: 4b3vvq2sL4z3s4Q 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:812, ipnet:108.160.240.0/20, country:CA] X-Spamd-Bar: ---- On 5/23/25 15:00, Mark Millard wrote: > Dennis Clarke wrote on > Date: Fri, 23 May 2025 17:45:17 UTC : > >> I have been watching qt6-webengine-6.8.3 fail over and over and over >> for some days now and it takes with it a pile of other stuff. >> >> In the log I see this unscripted trash of a message : >> >> [00:05:03] FAILED: v8_context_snapshot.bin >> [00:05:03] /usr/local/bin/python3.11 >> ../../../../../qtwebengine-everywhere-src-6.8.3/src/3rdparty/chromium/build/gn_run_binary.p >> y ./v8_context_snapshot_generator --output_file=v8_context_snapshot.bin >> [00:05:03] >> [00:05:03] >> [00:05:03] # >> [00:05:03] # Fatal error in , line 0 >> [00:05:03] # Oilpan: Out of memory >> [00:05:03] # >> [00:05:03] # > > Way to little context so all I can do is basically form > questions at this point. > Sorry ... I just realized that other people replied to me OFF-LIST and that is not helpful to others. So the machine titan is fairly beefy : titan# titan# uname -apKU FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #1 main-n277353-19419d36cf2a: Mon May 19 20:40:28 UTC 2025 root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1500043 1500043 titan# titan# sysctl hw.model hw.model: Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz titan# titan# sysctl hw.ncpu hw.ncpu: 64 titan# titan# sysctl hw.physmem hw.physmem: 549598998528 titan# titan# sysctl hw.freemem sysctl: unknown oid 'hw.freemem' titan# titan# sysctl kstat.zfs.misc.arcstats.memory_free_bytes kstat.zfs.misc.arcstats.memory_free_bytes: 404796436480 titan# sysctl vm.kmem_map_free vm.kmem_map_free: 431405096960 titan# Also plenty of storage and local NVMe stuff etc etc and dual NVidia GPU's that do nothing at all. For now. We ( myself and others ) have already found that the problem was me. No big surprise. USE_TMPFS=yes TMPFS_LIMIT=32 MAX_MEMORY=32 # MAX_FILES=1024 MAX_EXECUTION_TIME=172800 PARALLEL_JOBS=64 PREPARE_PARALLEL_JOBS=64 That was the problem in the poudriere config. I commented out the MAX_MEMORY and TMPFS_LIMIT and then watched as www/qt6-webengine built just fine. Guess the jail needed more than 32G eh? > I assume that you have not explicitly restricted the memory > space for any processes, so that RAM+SWAP is fully available > to everything. If not, you need to report on the details. > Yup .. I had restrictions in place. Those very very few packages are hogs. Just massive running pigs for memory it seems. > How much RAM? How much SWAP space? (So: how much RAM+SWAP?) > (RAM+SWAP does not vary per process tree or per builder, > presuming no deliberate restrictions have been placed.) 512G mem and 32G swap which never gets touched. > > Do you even have "whatever it seems to want" configured > for the RAM+SWAP? (I'm guessing that you do not know that > the "128G" figure is in fact involved.) > I commented out those restrictions. Makes me worry that some other packages will come along and fail because they need 384G of mem or something silly like that. I have been advised ( in the last hour ) that chromium ports generate +40000 source files and such. That is just abusive but the way of the future I am sure. > How many parallel builders are active in the bulk run > as the bulk build approaches the failure? I think 64 max. > > How much RAM+SWAP in use by other builders or other things > on the system as the system progresses to that failure (not > after the failure)? > .... *sigh* The problem was me. > ZFS (and its ARC)? UFS? If ZFS: Any tuning? > No tuning. It just works(tm) and that is ZFS. > Basically: all the significant sources of competing for > RAM+SWAP? > > .... > === > Mark Millard > marklmi at yahoo.com > > It feels like the correct approach is just give everything to the poudriere bulk situation and then watch for flames. No flames? No smoke? Great .. it is working. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Fri May 23 23:39:10 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b41pP06HPz5wm23 for ; Fri, 23 May 2025 23:39:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 4b41pN27hHz3yYj for ; Fri, 23 May 2025 23:39:24 +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=1748043562; bh=3LzUmuAUorc78/9rjYnLl7FXE0DHnla4mGRjXJT9Ff4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y1mlQFl/CihaBAN4I9L5FajKRk5fSbGEQbK0HXH5C3nVHwUaoA2F0YTVJdIJkxIz5x1S1tuKhsLjyu/kExeisVvP7Dq9tkpgVV6uT7rn2KMASgRhzEQ6E0na+csYrkXGDijRfOAw/7rFS7udpLSJKdGt5TrDZvx3QwvtMCfmgAjPC/QXTqcoTgZbylMJis/0W89VJn2j9XnWhybGJI5yTIm60VvVZpheHRL3uSiysCW75beqewuDY7euSRSvzmyD3QHl9Hv19DU7aKaI7SVZHObtwCcc23MaqR4Wfn0U3Q1YVgKFi7wzpt9ikJRNkkt7+S9rr6LlMPm7xWF5Lu25Pw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1748043562; bh=+6XOW2aa5ki5ck7uc6Fds5vC2sfY/ZUG3TdTins3zj5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=U9uYJHmz78Ob/L1EAUz620tm1ZxielZQD4Z22iesbdKrxjJMzYjwge+Z5vbwSt8TUO+1IHliG5059eqCosgDgOjgkxsrRX5ChHfZjLbjkhOmtjNj358u/NSbjhVF/NDFyNs9h+GHncVf8h5FPs/0lZ7COPZDula+k3tBtuPv4ElA5k/5eWrkO1bYqXPtuTOx2Cj0l8EahbfyWAl6YANAwLmn590lO6HSpJjkpNddwCEM+1bGKYAGxrQPqsmHgSshABU4V34Sri2bAayTKI8BLdQDOT9zG6rEVKVyMDgDOG7CC2fkH+iD/T+gcJdiD7KyA6Dy8dRpGhCKU/DT8PNk1Q== X-YMail-OSG: xHWvmWsVM1kX0TsDQwztnDKVrYsp3a5dxPR42yLuvICUW39vNQV8wqQute2vT_T 8RlATP.7_1.diES1oz.zQ2q9j.wkurQcdX1auyD3XwJ5_6.CKNJp9YP6OqObgeiFMsZ9_r9hQY4u mWj6JEcq.AwciAGzvut8NmkoR1GoPgf6Yibwj_Ct84P_J3N_uni3K_gnhavauTjnQf12uFxqjVb. Xq44VQ2jvr0HA2mdzt8Ckp1R.DwWEO7Satbuzdw8w7GxGHtKdMa3p2fKC5QnVMHVRdnAYxguj093 YF2hhoUxYV4Oa_ApTUmLxuB5F3FX1_CNHcGcYsH_s.u2GFsy0YgvShmaLUl7I.sx29AiM.onVTLC yU1nIocmyv9nCkCGHpNm9fhhSozBBXBiVvJSb7LSEbczLlWqTNUWF.kP0SVvni3LxbTZDKQ.xwnv yBuKJTW9DYLonDUURXCuvloP55aDe.I_l1IsoW8DTaHPGxefyJg_UX.cmGQDRECtbHzWtz7sd50S rfiO8h196shK30knMX4Dmb99aSiY7lxE..ZZQUEnDJgw2G24CeMupP_E7sQ_Qn.HjEepEkzm8sdq LA4dnzusRQogoMZlPfLce88o3V7KL4dg8FBRNP9ED4ysPPaIsqeP6KW4UvmsJ_9IWKZJM3fdO5.I VtDdAmdGrKoheYQ7Gketdcxn8OxU9_mEBDJg9VH.daYh_0HWGOdEFxju8skNpSqhXSfRFzAccW8K ViSyhcvssYp9yS4UlqoFfU4ejmtYiGuRWOkRiVu1RDor3HakNHMRSHXhqutoGe7Eby1fGK8HUYja cvVRMITcj4azi847u6gwpq13JefALGyZXSG4ld3.MR_dvA3B2ii6jZPoBLxTkSUq3VcFtYF5bvF_ 6OCf5QE4dlNw7kX.GbDeZexEzyUBybLIzvBSUuq.dGQHtYI96DAB3nvzoxHR5jl.qamEAUNA3XQz SASwJYrmMB72FBx3JmB56O6xLLgE_qLs08ExhsnSr.FX5NaYjqwddnOUQvMZbzzy7c2IT_f5lQeN 0tUU7U43tgSfR2R69YWJ1scEIoMNqv4eYOmaVeKRiPRAcQiNWiyYmrox7ReYJ6JCL_RS9Gh87v03 6e4o_oA5.QK6u_QAfmLk9FOxuAyMyUxLxhpt_pcJx29B1rq0xmbzcfQYmxufiRc2iDPGeMDKMVv9 1QcTYozm4HWG09dxFjJzkXKDcYA1l5ZwcMrfTlbHMrwLvEbEm5.xV1FSNC6cbfeYNs98WdSJkC9o UWrAyB0PQ_t657tfGnXTO1l0jnj3Mbn.QMtofACFx0GEJU2WQwCjU4jCt9jLSSWbJ7OQXxP94m_a SsT1KKvddeGYeXERhM_8a0_gSCCMm.5ku4VDkwx9Nw4mTO6s1XcoQ5ivcmkDLL.RNM_edjkjxS3R 2VLSUXkQ6XF6r0TcGjwaMqTDr2lLglf1BF7DojILiD5.uB3j174pcGYeYHHEm6QZZ4fg6NPnlJRB 12nop5nQQ8TaiEMlOfFGj4TwayVqzNGstr9geoPqMw7nhKoqikg45wBLB_iYlpCkTGzSbqD00UpJ Wdtl0jgZ5hBtWsxiEyXZSf_O8Zmpncu4I.62U3cYQjJE0Mu2fIQXizCYUVR28XU11IxZqcsiKxVQ Dd1pSJ4jQGZmX43..nvzCXy0UmYnLiZCMx9CejIQR5OHkAQvHkxt2YUXI6lQYXriPOE2fEsM6kFw m7P2DxZGt4Fy2hRtLGxNr4P1CKFDwURNEU.9pmv00RnrEs7.ZlogryZCCvGUW5MvO7YXjUj5dmum g7NIPp83LkaZIVOtLn.zzF27kynIrYzDbl_xWy1YI1KtdC3H2zkG5hiubXFnlaPvT5narN7T2TZH x2a49cR9Cisfd5L5g7wfGPXx4ASWtevdxSpcNQ3Wo9lesUrJ.iD4rBHeXjkBg5WniK.DZWJ47DAu cScL03cQAMsVgMMq7xEPVkcZi65pJbAJc6fmcOQZQCdAr87g1URfrvzuZ8aVo4vwcdi6LzkLiU0I RXNwd8wuUjw5Rg8b43mphnZ4_FPdMT6ZuuV_Kqn7O5AvogsCB085PscH4QYWeYMAccOcppCr4ALO uBV.72u.Zw402MNK4m9RC7CyUtQA2Oukzfed7diJruy1RrGGWty9ASdS3YEx7.33_hnraT9kF3_J W25Q.x7dE11WB1qGGUKS9nmxEuOXQWmN2fqhMW_r._G47wRuTfPXrvG2Ui_.gppRkazdGVO_XOLW d_TvaPJzUoxhBM6trjVy.bJF960JaXqF.T_x_grgyZrT0jOr7pQHmyNTQEGQGEhpvpekvolqUZVK OBLBwE7Y- X-Sonic-MF: X-Sonic-ID: e6d10402-c6cf-4081-a53d-2cf316d826b3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 23 May 2025 23:39:22 +0000 Received: by hermes--production-gq1-74d64bb7d7-tqd77 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1de00a6d2894e1a9cec4dd2db81e871d; Fri, 23 May 2025 23:39:21 +0000 (UTC) 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 \(3826.600.51.1.1\)) Subject: Re: Is there a way to tell poudriere to allocate more memory to a pkg build? From: Mark Millard In-Reply-To: Date: Fri, 23 May 2025 16:39:10 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <46F6ED96-CA4C-4BFE-812F-86FFA4E3B758@yahoo.com> References: <30CF8464-32D1-4752-865C-1EB1CA9DB4E2.ref@yahoo.com> <30CF8464-32D1-4752-865C-1EB1CA9DB4E2@yahoo.com> To: Dennis Clarke X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b41pN27hHz3yYj 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-Spamd-Bar: ---- On May 23, 2025, at 12:13, Dennis Clarke wrote: > On 5/23/25 15:00, Mark Millard wrote: >> Dennis Clarke wrote on >> Date: Fri, 23 May 2025 17:45:17 UTC : >>> I have been watching qt6-webengine-6.8.3 fail over and over and over >>> for some days now and it takes with it a pile of other stuff. >>>=20 >>> In the log I see this unscripted trash of a message : >>>=20 >>> [00:05:03] FAILED: v8_context_snapshot.bin >>> [00:05:03] /usr/local/bin/python3.11 >>> = ../../../../../qtwebengine-everywhere-src-6.8.3/src/3rdparty/chromium/buil= d/gn_run_binary.p >>> y ./v8_context_snapshot_generator = --output_file=3Dv8_context_snapshot.bin >>> [00:05:03] >>> [00:05:03] >>> [00:05:03] # >>> [00:05:03] # Fatal error in , line 0 >>> [00:05:03] # Oilpan: Out of memory >>> [00:05:03] # >>> [00:05:03] # >> Way to little context so all I can do is basically form >> questions at this point. >=20 > Sorry ... I just realized that other people replied to me OFF-LIST and > that is not helpful to others. >=20 > So the machine titan is fairly beefy : >=20 > titan# > titan# uname -apKU > FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #1 = main-n277353-19419d36cf2a: Mon May 19 20:40:28 UTC 2025 = root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1500043 = 1500043 > titan# > titan# sysctl hw.model > hw.model: Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz > titan# > titan# sysctl hw.ncpu > hw.ncpu: 64 > titan# > titan# sysctl hw.physmem > hw.physmem: 549598998528 > titan# > titan# sysctl hw.freemem > sysctl: unknown oid 'hw.freemem' > titan# > titan# sysctl kstat.zfs.misc.arcstats.memory_free_bytes > kstat.zfs.misc.arcstats.memory_free_bytes: 404796436480 > titan# sysctl vm.kmem_map_free > vm.kmem_map_free: 431405096960 > titan# >=20 > Also plenty of storage and local NVMe stuff etc etc and dual > NVidia GPU's that do nothing at all. For now. >=20 > We ( myself and others ) have already found that the problem was > me. No big surprise. >=20 > USE_TMPFS=3Dyes > TMPFS_LIMIT=3D32 > MAX_MEMORY=3D32 > # MAX_FILES=3D1024 > MAX_EXECUTION_TIME=3D172800 > PARALLEL_JOBS=3D64 > PREPARE_PARALLEL_JOBS=3D64 >=20 > That was the problem in the poudriere config. >=20 > I commented out the MAX_MEMORY and TMPFS_LIMIT and then watched > as www/qt6-webengine built just fine. Guess the jail needed more > than 32G eh? >=20 >> I assume that you have not explicitly restricted the memory >> space for any processes, so that RAM+SWAP is fully available >> to everything. If not, you need to report on the details. >>=20 >=20 > Yup .. I had restrictions in place. Those very very few packages > are hogs. Just massive running pigs for memory it seems. >=20 >=20 >> How much RAM? How much SWAP space? (So: how much RAM+SWAP?) >> (RAM+SWAP does not vary per process tree or per builder, >> presuming no deliberate restrictions have been placed.) >=20 > 512G mem and 32G swap which never gets touched. So RAM+SWAP =3D=3D 544 GiBytes 544 GiBytes / 64 jobs =3D=3D 8.5 GiBytes/job [mean] Some builders will exceed that, for sure. But you are really managing the total across the 64 jobs (adjusting the jobs count would be a possibility). I do things like: For 32 GiBytes of RAM: RAM+SWAP =3D=3D 150 GiBytes (so: RAM+SWAP =3D=3D 4.6875*RAM) So for 8 hw threads (and, so, 8 jobs): 150 GiBy=E2=80=A0es / 8 jobs =3D=3D 18.75 GiBytes/job [mean] For 64 GiBytes of RAM: RAM+SWAP =3D=3D 300 GiBytes (so: RAM+SWAP =3D=3D 4.6875*RAM) So for 12 performance hw threads (and, so, 12 jobs): 300 GiBy=E2=80=A0es / 12 jobs =3D=3D 25 GiBytes / jobs [mean] But for 16 hw threads (and, so, 16 jobs): 300 GiBy=E2=80=A0es / 16 jobs =3D=3D 18.75 GiBytes / job [mean] For 192 GiBytes of RAM: RAM+SWAP =3D=3D 704 GiBytes (so: RAM+SWAP =3D=3D 3.66...*RAM, I had other reasons to constraint this context more) So for 32 hw threads (and, so, 32 jobs): 704 GiBytes / 32 jobs =3D=3D 22 GiBytes / job [mean] But I also use TMPFS_BLACKLIST extensively with USE_TMPFS=3Dall to avoid having much probability of running out of resources. (This actually uses less than All but does not eliminate tmpfs use from being involved for the blacklisted package builds.) This is for use of ALLOW_MAKE_JOBS=3Dyes (so a high load average context much of the time). I do end up with examples of SWAP being used for paging. In a couple of those hw contexts, I, on very rare occasion, do a 'bulk -c -a' run (as a test), also with ALLOW_MAKE_JOBS=3Dyes . (I generally do not use MAKE_JOBS_NUMBER_LIMIT or the like.) A bias is to keep the hw threads busy with already-available useful work to do without having to systematically wait for the next unit of work. (Of course, other tradeoffs are also managed.) Note: My original questions should have asked about ALLOW_MAKE_JOBS and the likes of MAKE_JOBS_NUMBER_LIMIT use as well. (Not that such matters now.) >> Do you even have "whatever it seems to want" configured >> for the RAM+SWAP? (I'm guessing that you do not know that >> the "128G" figure is in fact involved.) >>=20 >=20 > I commented out those restrictions. Makes me worry that some other > packages will come along and fail because they need 384G of mem or > something silly like that. I'd be more worried about multiple jobs that each use more than 8.5 GiBytes that happen to lead to the total being more than (RAM+SWAP) [544 GiBytes]. Side note: I'll note that at one point in a past 'bulk -c -a' run test, a process got a run-way error that rapidly wrote to the log file without bound. Not good if the log file is in tmpfs. But such has happened only with one vintage of the ports tree. It is the only context I've seen that would reach or pass 384 GiBytes for one builder. > I have been advised ( in the last hour ) > that chromium ports generate +40000 source files and such. That is > just abusive but the way of the future I am sure. rust with USE_TMPFS=3Dall and not in TMPFS_BLACKLIST can use 27+ GiBytes of RAM+SWAP. And it is not the largest example around. >> How many parallel builders are active in the bulk run >> as the bulk build approaches the failure? >=20 > I think 64 max. >=20 >> How much RAM+SWAP in use by other builders or other things >> on the system as the system progresses to that failure (not >> after the failure)? >=20 > .... >=20 > *sigh* >=20 > The problem was me. >=20 >> ZFS (and its ARC)? UFS? If ZFS: Any tuning? >>=20 >=20 > No tuning. It just works(tm) and that is ZFS. Most of my use is UFS based. Only the machine with the most hw threads and RAM is ZFS based these days. (Part of that is to be a UFS test case since its use for such activities is less common: At one time, I noticed and reported that 'bulk -c -a' was at the time broken under UFS because of reaching a UFS limitation that was later adjusted.) >> Basically: all the significant sources of competing for >> RAM+SWAP? >> .... =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 >=20 > It feels like the correct approach is just give everything to the > poudriere bulk situation and then watch for flames. >=20 > No flames? No smoke? Great .. it is working. I did experimentation with 'bulk -c -a' to arrive at configuration choices that would survive such and left sizable margins for handling growth without regular adjustments. So my flame tests were more up front. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat May 24 00:06:02 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b42PR3FXfz5wnVC for ; Sat, 24 May 2025 00:06:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 4b42PR029Gz44r8 for ; Sat, 24 May 2025 00:06:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-ad1a87d93f7so56573366b.0 for ; Fri, 23 May 2025 17:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748045176; x=1748649976; 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=Sdb2wkVSapuLSr0GBcYTUo96oeW2+xeaKhyjzFfbkgA=; b=czmXU9dFgLZYhcAklP4+/+b474HNwWuKSosvUdEfm/XOpaQa1uosF0lJWWGmusSw7i LL+NtauGL0G52eQNmS2ZDV37OsY0TT4sw9q6ODFyFbUi9U1rM1YVI/h91QePcUntLwHi esTMRpqT8BsPil5k4G6rc3sEmsok159MPV41Rh4vvx7WLjUn/ZYqXDIbIQonEteKG1kc bRDhqQ5Y3oThQ3/B2AWfX79CMy4Ly4JYgu50cPwIfwt7hFwFOtcYGZCALUj2ZLqxDO8z 1Pl4TtstEsB0E+thAnwnDZsl+Z9SFi+cOHDq7y6vwbsd3GinBFOzud2perLRpqi/R8CC Wi2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748045176; x=1748649976; 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=Sdb2wkVSapuLSr0GBcYTUo96oeW2+xeaKhyjzFfbkgA=; b=wU8z/t522zEByDONYTZx5YPBttehp9kq1coGgN3hr2MDlf+ZSxEr65htg9XB5PwFyI nmZknV3q6Oq8Zh8AfBOVV024a5Ih5xBwtxYbivOv6N3hRtYrj/zE49JyGKnj9rvw4SNL Mq9A62RkNROYU+OWwsC2PsbzmVpqTj/lBK6X2BbbejshrByyoBtmBKsPMSvwPTbancAv F/cmdUJBavWEExk7Q7QdWj4eCpLupbvnGgVavuUkHZxAk/5cMU+bwEVZJ89+aWq0+kE/ LHyVnqL3O+hG9U/kTge3E3lqYXscG7dV9bFRChJXsTJKcn7zTBXphxfNxIFwsTRSeAhF B4Jw== X-Gm-Message-State: AOJu0YweKH0oX4zselBJkpbp1ZREOltGncqglUV2fXS7w38iexmmp21k qwvO7dIAdy+q5k0ZMt8FBWJC3/gCdKw9cwnkj0R2pkeo4il7oNLbE7DGLyLyIvzyjXDDJaAxBI5 MIS4VztpsWaRCvb0flAr5LfXnzJzLiBO/kTqJiQ== X-Gm-Gg: ASbGncvo4i2cR+n/CbsrekvAWu3E9GYhPjydl2j32vD7o6+RyUt9MrYdywlycVeJjHc rsGsSDx1jmGkWHsRtkBraFOFdhAhomodk5sMtCriAnbz3r3DvMexxOGr5IBGG/y1slLOTDwtquU ckp00sSkJxCA12aYjJRjnigY6VUS/JmxONHHMzDgMxXxI7ZnZJYLHr6EN1I5BBpkSwcuCLaRn/t w== X-Google-Smtp-Source: AGHT+IEfLcuHo8z5sTMAxj8825wKK29AE+7F2yxCW3wmOHj3zROrVQNLCZ+bRlmqqXAhpGwHjOgJhfZkXRbStZ/E4ZE= X-Received: by 2002:a17:907:d06:b0:ad2:2ef3:d487 with SMTP id a640c23a62f3a-ad85b329c74mr90037866b.58.1748045175748; Fri, 23 May 2025 17:06:15 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <20250523054806.732E923F@slippy.cwsent.com> In-Reply-To: <20250523054806.732E923F@slippy.cwsent.com> From: Rick Macklem Date: Fri, 23 May 2025 17:06:02 -0700 X-Gm-Features: AX0GCFuiSHLdbOa9bWdvGEkVFeG_jt3kcFoXLIKhVYwxma0kAprpT1nIinKcJ5U Message-ID: Subject: Re: NFS Panic To: Cy Schubert Cc: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="000000000000c0ae7f0635d67be9" X-Rspamd-Queue-Id: 4b42PR029Gz44r8 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-Spamd-Bar: ---- --000000000000c0ae7f0635d67be9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2025 at 10:48=E2=80=AFPM Cy Schubert wrote: > > Hi, > > A couple of my machines have had the following panic. > > panic: refcount 0xfffff8008dbdabf4 wraparound^M > cpuid =3D 3^M > time =3D 1747977394^M > KDB: stack backtrace:^M > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe008d1474d0^M > vpanic() at vpanic+0x136/frame 0xfffffe008d147600^M > panic() at panic+0x43/frame 0xfffffe008d147660^M > vput() at vput+0x67/frame 0xfffffe008d147680^M > nfs_lookup() at nfs_lookup+0x3bf/frame 0xfffffe008d1479f0^M > vop_sigdefer() at vop_sigdefer+0x30/frame 0xfffffe008d147a20^M > vfs_lookup() at vfs_lookup+0x467/frame 0xfffffe008d147aa0^M > namei() at namei+0x2ed/frame 0xfffffe008d147b00^M > vn_open_cred() at vn_open_cred+0x537/frame 0xfffffe008d147c80^M > openatfp() at openatfp+0x281/frame 0xfffffe008d147dd0^M > sys_openat() at sys_openat+0x3d/frame 0xfffffe008d147e00^M > amd64_syscall() at amd64_syscall+0x15a/frame 0xfffffe008d147f30^M > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe008d147f3= 0^M > --- syscall (499, FreeBSD ELF64, openat), rip =3D 0x82213d96a, rsp =3D > 0x8209c3518, > rbp =3D 0x8209c3550 ---^M > Uptime: 22h48m25s^M > Dumping 3196 out of 7994 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%.= .91 > %^M > Dump complete^M > Automatic reboot in 15 seconds - press a key on the console to abort^M > Rebooting...^M > > The panicking machine was the NFS client. The machine was at 30fd79b0c0a3= . > The NFS mount was handled by the automounter to mount my home dir from > another machine. I was rsyncing a copy of src (mistakenly) to the machine= . > Some of the files were written to the share before it panicked. The > underlying filesystem is on ZFS. I think the attached patch should fix it. When I did the named attribute pa= tch, I somehow deleted an initialization of newvp. If you can try the patch, let me know if it fixes the problem. Thanks for reporting it, rick > > Stack trace follows: > > __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57 > 57 __asm("movq %%gs:%c1,%0" : "=3Dr" (td) > (kgdb) #0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.= h:5 > 7 > td =3D > #1 doadump (textdump=3Dtextdump@entry=3D1) > at /opt/src/git-src/sys/kern/kern_shutdown.c:404 > error =3D 0 > coredump =3D > #2 0xffffffff806fa010 in kern_reboot (howto=3D260) > at /opt/src/git-src/sys/kern/kern_shutdown.c:524 > once =3D 0 > __pc =3D 0x0 > #3 0xffffffff806fa547 in vpanic ( > fmt=3D0xffffffff80b6e6f1 "refcount %p wraparound", > ap=3Dap@entry=3D0xfffffe008d147640) > at /opt/src/git-src/sys/kern/kern_shutdown.c:979 > buf =3D "refcount 0xfffff8008dbdabf4 wraparound", '\000' time > s> > __pc =3D 0x0 > __pc =3D 0x0 > __pc =3D 0x0 > other_cpus =3D {__bits =3D {7, 0 }} > td =3D 0xfffff8002dd42000 > bootopt =3D > newpanic =3D > #4 0xffffffff806fa373 in panic (fmt=3D) > at /opt/src/git-src/sys/kern/kern_shutdown.c:892 > ap =3D {{gp_offset =3D 16, fp_offset =3D 48, > overflow_arg_area =3D 0xfffffe008d147670, > reg_save_area =3D 0xfffffe008d147610}} > #5 0xffffffff807faf87 in _refcount_update_saturated (count=3D) > at /opt/src/git-src/sys/sys/refcount.h:52 > No locals. > #6 refcount_releasen (count=3D, n=3D1) > at /opt/src/git-src/sys/sys/refcount.h:151 > old =3D > #7 refcount_release (count=3D) > at /opt/src/git-src/sys/sys/refcount.h:171 > No locals. > #8 vput (vp=3D) at /opt/src/git-src/sys/kern/vfs_subr.c:3= 711 > No locals. > #9 0xffffffff805c7bff in nfs_lookup (ap=3Dap@entry=3D0xfffffe008d147a48) > at /opt/src/git-src/sys/fs/nfsclient/nfs_clvnops.c:1438 > dvp =3D 0xfffff80089998c08 > newvp =3D 0xfffff8008dbdaa50 > np =3D 0xfffffe00d0c537c0 > attrflag =3D 0 > dattrflag =3D 0 > ncticks =3D -2139333169 > nfhp =3D 0xfffffe00104e61c0 > dnfsva =3D {na_vattr =3D {va_type =3D 80, va_mode =3D 33038, > va_bsdflags =3D 65535, va_uid =3D 2378017360, va_gid =3D 4294= 965248, > va_nlink =3D 18446741877053224856, va_fsid =3D 18446735278986= 613504, > va_fileid =3D 9, va_size =3D 18446741878188881856, va_blocksi= ze =3D 0, > va_atime =3D {tv_sec =3D 0, tv_nsec =3D 0}, va_mtime =3D {tv_= sec =3D 5632, > tv_nsec =3D 8013448}, va_ctime =3D {tv_sec =3D 0, > tv_nsec =3D -2195520669736}, va_birthtime =3D {tv_sec =3D 6= 86, > tv_nsec =3D 8}, va_gen =3D 0, va_flags =3D 1844674187818888= 1880, > va_rdev =3D 346, va_bytes =3D 8, va_filerev =3D 0, > va_vaflags =3D 2159652436, va_spare =3D -9133229150802726348}= , > na_suppattr =3D {bits =3D {3132, 0, 768876544}}, > na_mntonfileno =3D 18446741874959868352, na_filesid =3D { > 18446744071574388420, 18446735278385405952}} > nfsva =3D {na_vattr =3D {va_type =3D VNON, va_mode =3D 45765, > va_bsdflags =3D 63488, va_uid =3D 663, va_gid =3D 0, > va_nlink =3D 18446735280615796760, va_fsid =3D 18446741877053= 225448, > va_fileid =3D 18446735280615796736, va_size =3D > 18446741878188881856, > va_blocksize =3D -2196656326896, va_atime =3D {tv_sec =3D -21= 40327393, > tv_nsec =3D -8786968814592}, va_mtime =3D {tv_sec =3D -2126= 898064, > tv_nsec =3D -2196656326448}, va_ctime =3D {tv_sec =3D -2139= 681839, > tv_nsec =3D -8786968814592}, va_birthtime =3D {tv_sec =3D > -2126898064, > tv_nsec =3D -2196656326416}, va_gen =3D 1844674407156986977= 7, > va_flags =3D 18446735286740713088, va_rdev =3D 18446744071582= 653552, > va_bytes =3D 18446741877053225232, > va_filerev =3D 18446744071569869777, va_vaflags =3D 845322824= , > va_spare =3D -2139674112}, na_suppattr =3D {bits =3D {3502585= 960, > 4294966784, 0}}, na_mntonfileno =3D 0, na_filesid =3D { > 18446741878188881880, 416}} > vattr =3D {va_type =3D VDIR, va_mode =3D 493, va_bsdflags =3D 0, > va_uid =3D 1000, va_gid =3D 1000, va_nlink =3D 2, va_fsid =3D > 250081247028, > va_fileid =3D 99091, va_size =3D 3, va_blocksize =3D 512, va_at= ime =3D { > tv_sec =3D 1747977382, tv_nsec =3D 958897000}, va_mtime =3D { > tv_sec =3D 1747977394, tv_nsec =3D 313670000}, va_ctime =3D { > tv_sec =3D 1747977394, tv_nsec =3D 313670000}, va_birthtime = =3D { > tv_sec =3D 1742392133, tv_nsec =3D 731659000}, va_gen =3D 0, > va_flags =3D 0, va_rdev =3D 0, va_bytes =3D 512, va_filerev =3D= 8013402, > va_vaflags =3D 1747977381, va_spare =3D 0} > nctime =3D {tv_sec =3D 1747977394, tv_nsec =3D 304107000} > ts =3D {tv_sec =3D 82105, tv_nsec =3D 804860589} > cnp =3D 0xfffffe008d147d18 > vpp =3D 0xfffffe008d147cf0 > mp =3D 0xfffffe00c2c1b000 > flags =3D 346325252 > error =3D > td =3D 0xfffff8002dd42000 > nmp =3D > needs_nameddir =3D > openmode =3D > newnp =3D > ltype =3D > is_nameddir =3D > opennamed =3D > #10 0xffffffff807e5ee0 in vop_sigdefer (vop=3D, > a=3D0xfffffe008d147a48) at /opt/src/git-src/sys/kern/vfs_default.c:14= 82 > bp =3D 0xffffffff805c7840 > prev_stops =3D 0 > rc =3D > #11 0xffffffff807eb327 in VOP_LOOKUP (dvp=3D0xfffff80089998c08, > vpp=3D0xfffffe008d147cf0, cnp=3D0xfffffe008d147d18) at ./vnode_if.h:6= 7 > a =3D {a_gen =3D {a_desc =3D 0xffffffff810e4b90 = }, > a_dvp =3D 0xfffff80089998c08, a_vpp =3D 0xfffffe008d147cf0, > a_cnp =3D 0xfffffe008d147d18} > #12 vfs_lookup (ndp=3Dndp@entry=3D0xfffffe008d147c98) > at /opt/src/git-src/sys/kern/vfs_lookup.c:1284 > dp =3D 0xfffff80089998c08 > error =3D > relookup =3D > cnp =3D 0xfffffe008d147d18 > ni_dvp_unlocked =3D 0 > wantparent =3D 0 > docache =3D 1 > lastchar =3D > cp =3D > prev_ni_pathlen =3D 9 > prev_ni_next =3D 0xffffffffffffffff addres > s 0xffffffffffffffff> > lkflags_save =3D 524288 > tdp =3D > pr =3D > nulchar =3D > rdonly =3D > #13 0xffffffff807ea47d in namei (ndp=3Dndp@entry=3D0xfffffe008d147c98) > at /opt/src/git-src/sys/kern/vfs_lookup.c:706 > dp =3D 0xfffff80089998c08 > pwd =3D 0xfffff8000d2e1c30 > status =3D CACHE_FPL_STATUS_ABORTED > cnp =3D 0xfffffe008d147d18 > td =3D 0xfffff8002dd42000 > error =3D > #14 0xffffffff80812d57 in vn_open_cred (ndp=3Dndp@entry=3D0xfffffe008d147= c98, > flagp=3Dflagp@entry=3D0xfffffe008d147da4, cmode=3Dcmode@entry=3D0, > vn_open_flags=3Dvn_open_flags@entry=3D16, cred=3D0xfffff80051a9d300, > fp=3D0xfffff8000e50eb90) at /opt/src/git-src/sys/kern/vfs_vnops.c:356 > vp =3D 0x0 > mp =3D 0xfffffe008d147c80 > vat =3D {va_type =3D VLNK, va_mode =3D 0, va_bsdflags =3D 0, va_u= id =3D 2, > va_gid =3D 0, va_nlink =3D 0, va_fsid =3D 18446735279980743744, > va_fileid =3D 18446741874923406336, va_size =3D 184467418749234= 06336, > va_blocksize =3D -2196656325632, va_atime =3D {tv_sec =3D -2136= 993772, > tv_nsec =3D -8794722938112}, va_mtime =3D {tv_sec =3D 1, > tv_nsec =3D -2198749683240}, va_ctime =3D {tv_sec =3D -879472= 2938112, > tv_nsec =3D -2198749683264}, va_birthtime =3D {tv_sec =3D -21= 39209136, > tv_nsec =3D -2196656325728}, va_gen =3D 663, > va_flags =3D 18446735280103378544, va_rdev =3D 1844673527898661= 3504, > va_bytes =3D 18446735280103378520, va_filerev =3D 1, > va_vaflags =3D 2366929872, va_spare =3D -2140327393} > first_open =3D false > error =3D > fmode =3D > vap =3D > #15 0xffffffff80808db1 in openatfp (td=3D0xfffff8002dd42000, dirfd=3D3, > path=3D0x846ac479fd , > pathseg=3Dpathseg@entry=3DUIO_USERSPACE, flags=3D131329, mode=3D, > fpp=3D0x0) at /opt/src/git-src/sys/kern/vfs_syscalls.c:1252 > fp =3D 0xfffff8000e50eb90 > nd =3D { > ni_dirp =3D 0x846ac479fd 0x846ac > 479fd>, ni_segflg =3D UIO_USERSPACE, ni_rightsneeded =3D 0xfffffe008d147d= 80, > ni_startdir =3D 0x0, ni_rootdir =3D 0xfffff8000d35b528, ni_topd= ir =3D > 0x0, > ni_dirfd =3D 3, ni_lcf =3D 0, ni_filecaps =3D {fc_rights =3D {c= r_rights =3D > { > 144132780261900287, 288230376153808895}}, fc_ioctls =3D 0= x0, > fc_nioctls =3D -1, fc_fcntls =3D 120}, ni_vp =3D 0x0, > ni_dvp =3D 0xfffff80089998c08, ni_resflags =3D 0, ni_debugflags= =3D 3, > ni_loopcnt =3D 0, ni_pathlen =3D 1, ni_next =3D 0xfffff8000d2f5= 008 "", > ni_cnd =3D {cn_flags =3D 346325252, cn_cred =3D 0xfffff80051a9d= 300, > cn_nameiop =3D LOOKUP, cn_lkflags =3D 532480, > cn_pnbuf =3D 0xfffff8000d2f5000 "realpath", > cn_nameptr =3D 0xfffff8000d2f5000 "realpath", cn_namelen =3D = 8}, > ni_cap_tracker =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe008= d147d48}, > ni_dvp_seqc =3D 1400, ni_vp_seqc =3D 0} > indx =3D -1 > rights =3D > p =3D > fdp =3D 0xfffffe00c2bf8c90 > pdp =3D 0xfffff8008ceb0c40 > error =3D 0 > cmode =3D 0 > vp =3D > fcaps =3D > #16 0xffffffff80808b0d in kern_openat (dirfd=3D, > path=3D, pathseg=3DUIO_USERSPACE, flags=3D, > mode=3D, td=3D) > at /opt/src/git-src/sys/kern/vfs_syscalls.c:1336 > No locals. > #17 sys_openat (td=3D, uap=3D) > at /opt/src/git-src/sys/kern/vfs_syscalls.c:1147 > No locals. > #18 0xffffffff80acf35a in syscallenter (td=3D0xfffff8002dd42000) > at /opt/src/git-src/sys/amd64/amd64/../../kern/subr_syscall.c:191 > se =3D 0xffffffff8105add0 > p =3D 0xfffffe00c2c22000 > sa =3D 0xfffff8002dd423f0 > error =3D > sy_thr_static =3D true > traced =3D > _audit_entered =3D > #19 amd64_syscall (td=3D0xfffff8002dd42000, traced=3D0) > at /opt/src/git-src/sys/amd64/amd64/trap.c:1215 > ksi =3D {ksi_link =3D {tqe_next =3D 0x4, tqe_prev =3D 0xfffffe008= d147ee0}, > ksi_info =3D {si_signo =3D -2139674112, si_errno =3D -1, > si_code =3D -1928036720, si_pid =3D -512, si_uid =3D 0, > si_status =3D 32768, si_addr =3D 0x8140407a2e293234, si_value= =3D { > sival_int =3D 3, sival_ptr =3D 0x3, sigval_int =3D 3, > sigval_ptr =3D 0x3}, _reason =3D {_fault =3D {_trapno =3D 7= 68877856}, > _timer =3D {_timerid =3D 768877856, _overrun =3D -2048}, _m= esgq =3D { > _mqd =3D 768877856}, _poll =3D {_band =3D -8795324144352}= , > _capsicum =3D {_syscall =3D 768877856}, __spare__ =3D { > __spare1__ =3D -8795324144352, __spare2__ =3D {-192803635= 2, > -512, > -2126898064, -1, 768876544, -2048, -2130704920}}}}, > ksi_flags =3D 7, ksi_sigq =3D 0xfffff8002dd42000} > #20 > No locals. > #21 0x000000082213d96a in ?? () > No symbol table info available. > Backtrace stopped: Cannot access memory at address 0x8209c3518 > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > > --000000000000c0ae7f0635d67be9 Content-Type: application/octet-stream; name="lookup-crash.patch" Content-Disposition: attachment; filename="lookup-crash.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mb1gyc5e0 LS0tIG5mc19jbHZub3BzLmMuc2F2CTIwMjUtMDUtMjMgMTY6NTk6NTQuNDU1Mjc1MDAwIC0wNzAw CisrKyBuZnNfY2x2bm9wcy5jCTIwMjUtMDUtMjMgMTY6NTk6NTUuNTE3ODUyMDAwIC0wNzAwCkBA IC0xNDIxLDYgKzE0MjEsNyBAQCBuZnNfbG9va3VwKHN0cnVjdCB2b3BfbG9va3VwX2FyZ3MgKmFw KQogCU5GU1VOTE9DS01OVChubXApOwogI2VuZGlmCiAKKwluZXd2cCA9IE5VTExWUDsKIAlORlNJ TkNSR0xPQkFMKG5mc3N0YXRzdjEubG9va3VwY2FjaGVfbWlzc2VzKTsKIAluYW5vdXB0aW1lKCZ0 cyk7CiAJZXJyb3IgPSBuZnNycGNfbG9va3VwKGR2cCwgY25wLT5jbl9uYW1lcHRyLCBjbnAtPmNu X25hbWVsZW4sCg== --000000000000c0ae7f0635d67be9-- From nobody Sat May 24 03:26:48 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b46rr47F1z5x1RQ for ; Sat, 24 May 2025 03:26:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b46rq3yMpz3T4S for ; Sat, 24 May 2025 03:26:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.32 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror) Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id IeatuN84c9JM2IfX8u90A1; Sat, 24 May 2025 03:26:50 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id IfX7uHEIKWbOaIfX7umVXJ; Sat, 24 May 2025 03:26:50 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Q5lx4J2a c=1 sm=1 tr=0 ts=68313c7a a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=nANpaBTGJXAnN7kKxhwA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 9E2F8E2; Fri, 23 May 2025 20:26:48 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 932DE132; Fri, 23 May 2025 20:26:48 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Cy Schubert , freebsd-current@freebsd.org Subject: Re: NFS Panic In-reply-to: References: <20250523054806.732E923F@slippy.cwsent.com> Comments: In-reply-to Rick Macklem message dated "Fri, 23 May 2025 17:06:02 -0700." 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 Date: Fri, 23 May 2025 20:26:48 -0700 Message-Id: <20250524032648.932DE132@slippy.cwsent.com> X-CMAE-Envelope: MS4xfL+nb9wx3Y2WLDyUqMuhNAQi/L1xRSrRi45F7OPxfzhrLdhH6l8BVLWhd6ulFHdPazsSU/i2Ddrr3175WqiWTtk7ys/uAGIyqRkfPeyHEN4xSTOD3Slp dl4UyoQEdVqtDRxA3MubILsBfqqXuiJ5n6fkjWfAjUl34ksGerWbb01+PCoMfHQayVmfUHQka5+9ynGOx6ewLrQsOHdeyR8qjPWdABxpKN9e4yUH+nJIciv0 Lu18G4WrZKekI9PvRJ5Kjw== X-Rspamd-Queue-Id: 4b46rq3yMpz3T4S X-Spamd-Bar: / X-Spamd-Result: default: False [0.57 / 15.00]; NEURAL_HAM_SHORT(-0.97)[-0.972]; NEURAL_SPAM_MEDIUM(0.83)[0.831]; NEURAL_SPAM_LONG(0.61)[0.608]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[] In message , Rick Macklem writes: > --000000000000c0ae7f0635d67be9 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Thu, May 22, 2025 at 10:48=E2=80=AFPM Cy Schubert .com> wrote: > > > > Hi, > > > > A couple of my machines have had the following panic. > > > > panic: refcount 0xfffff8008dbdabf4 wraparound^M > > cpuid =3D 3^M > > time =3D 1747977394^M > > KDB: stack backtrace:^M > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe008d1474d0^M > > vpanic() at vpanic+0x136/frame 0xfffffe008d147600^M > > panic() at panic+0x43/frame 0xfffffe008d147660^M > > vput() at vput+0x67/frame 0xfffffe008d147680^M > > nfs_lookup() at nfs_lookup+0x3bf/frame 0xfffffe008d1479f0^M > > vop_sigdefer() at vop_sigdefer+0x30/frame 0xfffffe008d147a20^M > > vfs_lookup() at vfs_lookup+0x467/frame 0xfffffe008d147aa0^M > > namei() at namei+0x2ed/frame 0xfffffe008d147b00^M > > vn_open_cred() at vn_open_cred+0x537/frame 0xfffffe008d147c80^M > > openatfp() at openatfp+0x281/frame 0xfffffe008d147dd0^M > > sys_openat() at sys_openat+0x3d/frame 0xfffffe008d147e00^M > > amd64_syscall() at amd64_syscall+0x15a/frame 0xfffffe008d147f30^M > > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe008d147f3= > 0^M > > --- syscall (499, FreeBSD ELF64, openat), rip =3D 0x82213d96a, rsp =3D > > 0x8209c3518, > > rbp =3D 0x8209c3550 ---^M > > Uptime: 22h48m25s^M > > Dumping 3196 out of 7994 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%.= > .91 > > %^M > > Dump complete^M > > Automatic reboot in 15 seconds - press a key on the console to abort^M > > Rebooting...^M > > > > The panicking machine was the NFS client. The machine was at 30fd79b0c0a3= > . > > The NFS mount was handled by the automounter to mount my home dir from > > another machine. I was rsyncing a copy of src (mistakenly) to the machine= > . > > Some of the files were written to the share before it panicked. The > > underlying filesystem is on ZFS. > I think the attached patch should fix it. When I did the named attribute pa= > tch, > I somehow deleted an initialization of newvp. > > If you can try the patch, let me know if it fixes the problem. > > Thanks for reporting it, rick > The patch fixes the panic. Thanks for the fix. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat May 24 12:35:42 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b4M2Z2gf1z5w6xy for ; Sat, 24 May 2025 12:36:06 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com [202.12.124.158]) (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 4b4M2Y0wB5z3Pyg for ; Sat, 24 May 2025 12:36:05 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=plA2r386; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=ShhmFcHg; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.158 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id 09C8625400D5 for ; Sat, 24 May 2025 08:36:04 -0400 (EDT) Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-02.internal (MEProxy); Sat, 24 May 2025 08:36:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1748090163; x=1748176563; bh=yOO2frNGZNAkmcC/s1xZSsRenReGDofLO/F1T+7KUvY=; b= plA2r386tDaY91HBlAfmEDT+3w2sg6848wledSZRvK5xumWlqwPp7AzF6p3qFoZd 0o9Me2HS3lMvrwA+rg+d0/gAmYt/utCOSoAloooom5NL+C1dnz/4AHrvj78vf8Sn MqV1Oxbk8pMprW+7SmwVO19Cmm9x9vL2XY0DfeTDTTdIcR4mg6bmdg8nKoGFv+/g n3Y38n3CS5I/AlP8PrFs3U1hRGGFH7P0fWpEk+uzFg3mcISAsz8+sHQSib8DS0oX 708ZdrxedKDJR+vwzAr6It9DXSaIuvrwr1ivV95j4MtFoJbpnR6EzGbsuQephXN+ sW+WNuwYq5pEFlo+1e7FZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1748090163; x=1748176563; bh=y OO2frNGZNAkmcC/s1xZSsRenReGDofLO/F1T+7KUvY=; b=ShhmFcHgQhdd8U+yD f17zoPflpD28tfJqm+YorTEWN9xVsg1GK/uMsiTDj6o7yl3uLCKsJaU04nwRbmBj mtH65CbzULANnmt7ugJGVxQLeEk8h6D8fblJ40QvedaqxZxDeNnVLVyaJKHKfLRI SCJqse3SeBPdJiafUa8s4ro/AvhOvBdh0wGp3m5V3rZkv7A5uG4/G2SFqXofSbEM wFzNJWq6NRXM2eX9KTLkfIRdgEWXThGfXbBP+qcGgmsWTslqgfXTxIsBiedFlbqm T4nfKGqK4PKJpeVyYsUKFB7YcY46q/yfRi0z9h+8Q+26Uw3xMHba7KG6YS7T/Bl3 yxwVg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdduudejfeculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecunecujfgurhepofggfffhvffkjghfufgtgfesthejredtredttdenucfhrhhomhep vhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepiedtfeeife etiefffeefgfejueevffeltdehffegtdffhfefuefggfeuhfekgfdvnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh dpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhr vggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 9F74918C0062; Sat, 24 May 2025 08:36:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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-ThreadId: Te950e6ee9806d0e1 Date: Sat, 24 May 2025 13:35:42 +0100 From: void To: freebsd-current Message-Id: In-Reply-To: <17ff4ba6-c700-4810-84ba-987da18f04b8@blastwave.org> References: <17ff4ba6-c700-4810-84ba-987da18f04b8@blastwave.org> Subject: Re: Is there a way to tell poudriere to allocate more memory to a pkg build? Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4b4M2Y0wB5z3Pyg X-Spamd-Bar: / X-Spamd-Result: default: False [0.79 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; NEURAL_HAM_SHORT(-0.27)[-0.268]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; NEURAL_SPAM_MEDIUM(0.15)[0.146]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.158:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[f-m.fm]; TO_DN_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FROM_HAS_DN(0.00)[] Hello, On Fri, 23 May 2025, at 18:45, Dennis Clarke wrote: > I have been watching qt6-webengine-6.8.3 fail over and over and over > for some days now and it takes with it a pile of other stuff. I'm using a dual xenon @3GHz with 512GB ram for amd64 poudriere builds. This has hyperthreading turned *off* in both the bios and in /boot/loader.conf [machdep.hyperthreading_allowed="0"] so ncpu=16 Some tips, learned over time, to not run out of resources in this context: PARALLEL_JOBS=3 # this appears to help avoid conflicts, and gives appreciable speedups. ALLOW_MAKE_JOBS=yes MAX_FILES=8192 MUTUALLY_EXCLUSIVE_BUILD_PACKAGES="irid* llvm* rust* gcc* electr* libre* firef* npm* node* nerd* qt* ghc webkit*" # this also helps avoid conflicts TMPFS_BLACKLIST_TMPDIR is *commented out* Hope this helps, -- From nobody Sat May 24 12:38:32 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b4M5q0gnkz5w7Vp for ; Sat, 24 May 2025 12:38:55 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com [202.12.124.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b4M5p3TJ9z3Rl1 for ; Sat, 24 May 2025 12:38:54 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=AWrXTlsd; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=cGsMxIV5; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.158 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id B0AD4254009B for ; Sat, 24 May 2025 08:38:53 -0400 (EDT) Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-02.internal (MEProxy); Sat, 24 May 2025 08:38:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1748090333; x=1748176733; bh=xuS2aEhYR+OcfJF280kPBzULSAEGC360xzeaA06920I=; b= AWrXTlsdOltWcpkvxMWkbvEwim1lT0SSPHHdsltuF4epe71wZIz/UEWzrdE9Wpzl puIQHnK+qtzHmoR4+gAIa4Njppt+pnEiSduXiZsPJwDq5yT2dsu1RToBsNZu1Hfb LyT8RlqB3XZiCmP8X2xQJZf3wle9/x9H6yQhXW1IQkavp1uT9IJX6Ry4Epz0T/mt kacNrwA0Efj9AmxVCFPEcCi1drD/yyatdJXH/GAnwELoIk3X0t5zO/fwktsUyAiG vQzdLtAN63TUiGHIok/3vD++Wlysn4t3/7KLirrW2SqXYRbOyjyBn5AFPrH7XDqQ pDWZVT6qDzmZ6AlO9bgfOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1748090333; x=1748176733; bh=x uS2aEhYR+OcfJF280kPBzULSAEGC360xzeaA06920I=; b=cGsMxIV5NvqZifkks EaAQIPn+GRsPzSfmhSm3/nHqjaB2fPYJbsRqhxydFyuNZyH+zkBo6VwwktW8byco 4v6W641xwsvYUd11HksHtzSDGLihhZqdHPVIw00iwOG2RyWsbO8UyVpJ9XkGYqNE 4WD6aKLzxSsfAyK9w9vldcgoRnGzhTcxFUzUK4e3P9nve7ePKpoBanXpLj1NpH7s CHYaolsAJryihi35sbUbQcl3Herac/Txk4yZ3XrlWACLSSAHiB4Lh6h2fIA8j0TB NXGGB5Db7utVkj0D/6IN8UB9KJgD3DvVc+1F+0ws641J82GNXsHDk+x6g+9A6Eu6 b3Ubw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdduudejheculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecunecujfgurhepofggfffhvffkjghfufgtgfesthejredtredttdenucfhrhhomhep vhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepiedtfeeife etiefffeefgfejueevffeltdehffegtdffhfefuefggfeuhfekgfdvnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh dpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhr vggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 524CD18C0063; Sat, 24 May 2025 08:38:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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-ThreadId: Te950e6ee9806d0e1 Date: Sat, 24 May 2025 13:38:32 +0100 From: void To: freebsd-current Message-Id: In-Reply-To: References: <17ff4ba6-c700-4810-84ba-987da18f04b8@blastwave.org> Subject: Re: Is there a way to tell poudriere to allocate more memory to a pkg build? Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4b4M5p3TJ9z3Rl1 X-Spamd-Bar: + X-Spamd-Result: default: False [1.35 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_LONG(1.00)[0.999]; NEURAL_SPAM_MEDIUM(0.73)[0.730]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; NEURAL_HAM_SHORT(-0.29)[-0.294]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.158:from]; XM_UA_NO_VERSION(0.01)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FROM_HAS_DN(0.00)[] > PARALLEL_JOBS=3 # this appears to help avoid conflicts, and gives > appreciable speedups. > ALLOW_MAKE_JOBS=yes > MAX_FILES=8192 > > MUTUALLY_EXCLUSIVE_BUILD_PACKAGES="irid* llvm* rust* gcc* electr* > libre* firef* npm* node* nerd* qt* ghc webkit*" # this also helps avoid > conflicts > > TMPFS_BLACKLIST_TMPDIR is *commented out* I forgot to mention: USE_TMPFS=all -- From nobody Sat May 24 21:37:06 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b4b2y1MhTz5x298 for ; Sat, 24 May 2025 21:37:14 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b4b2w2LGlz4JPp for ; Sat, 24 May 2025 21:37:12 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=Wnhuqpyv; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org; dmarc=pass (policy=quarantine) header.from=blastwave.org Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 54OLb6JT010991 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sat, 24 May 2025 17:37:08 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1748122628; bh=2teMMyQfeTqwy1xaRI8sJFiwWwJAsKbzBamMWJu5YoQ=; h=Date:From:Subject:To; b=WnhuqpyvTmyb2Lz7iP7BTH/LG7LnQjIE6C1QxGBj2YmlPrAsSAFbSevy6Mcyvh0ss TKF8XzXrfDt8amYlk4YBl3aLanY7w8PQFFdhFPE4tP2qtAlwltY2ZLCtSCzTo50LP1 NUeQKn544t56lQ4nEzO7xNua1JtyilSsYeEHnEbnrvgN+vebgmium3+8996/PVca+W 1TYJyyKPbJbu5AaBmpMXL+9Z2azy7tULEsmrc6oJQU3wETNuDRMptAQ9XUlUa4h6xY mOW9r4n01zTL35CtHx2MSBbOJxBbQ+YQCAS7LFZqBTb4KtQO1j2aMHV2xxDKihoYDK OOmoORvHLNmhg== Message-ID: <24cacc7b-3539-4765-8852-43b02764c911@blastwave.org> Date: Sat, 24 May 2025 17:37:06 -0400 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: Dennis Clarke Subject: With poudriere how does one create a jail of a slightly older RELEASE ? To: FreeBSD Current Content-Language: en-CA Organization: GENUNIX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 54OLb6JT010991 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Queue-Id: 4b4b2w2LGlz4JPp X-Spamd-Bar: - X-Spamd-Result: default: False [-1.93 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_MEDIUM(-0.50)[-0.495]; NEURAL_SPAM_SHORT(0.26)[0.257]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[blastwave.org:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[] This may seem trivial but trying to create a jail for a release from just a few years ago is not working well : t# poudriere jails -c -a amd64 -j 132amd64 -v 13.2-RELEASE [00:00:00] Creating 132amd64 fs at /export/poudriere/jails/132amd64... done [00:00:00] Fetching MANIFEST for FreeBSD 13.2-RELEASE amd64 fetch: https://download.freebsd.org/releases/amd64/amd64/13.2-RELEASE/MANIFEST: Not Found fetch: https://download.freebsd.org/releases/amd64/amd64/13.2-RELEASE/MANIFEST: Not Found [00:00:01] Error: Failed to fetch from https://download.freebsd.org/releases/amd64/amd64/13.2-RELEASE/MANIFEST [00:00:01] Error while creating jail, cleaning up. [00:00:01] Removing 132amd64 jail... done [00:00:01] Cleaning 132amd64 data... done t# That makes perfect sense. So then build from source? That does not work either : t# t# uname -apKU FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #1 main-n277353-19419d36cf2a: Mon May 19 20:40:28 UTC 2025 root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1500043 1500043 t# t# cc --version FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) Target: x86_64-unknown-freebsd15.0 Thread model: posix InstalledDir: /usr/bin Build config: +assertions t# t# env | sort BLOCKSIZE=K ENV=/root/.shrc HOME=/root LANG=C.UTF-8 MAIL=/var/mail/root MM_CHARSET=UTF-8 OLDPWD=/root PAGER=less PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin PWD=/root SHELL=/bin/sh TERM=xterm USER=root t# t# /usr/bin/time -p idprio 0 poudriere jail -c -j 132amd64 -a amd64 \ -v releng/13.2 \ -J 1 -b -D -m git+https -U https://git.freebsd.org/src.git [00:00:00] Creating 132amd64 fs at /export/poudriere/jails/132amd64... done [00:00:00] Checking out the sources with git+https... done [00:04:25] Starting make buildworld with 1 jobs make[1]: /export/poudriere/jails/132amd64/usr/src/Makefile.inc1:340: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: /export/poudriere/jails/132amd64/usr/src/Makefile.inc1:345: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. -------------------------------------------------------------- >>> World build started on Sat May 24 21:12:02 UTC 2025 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp cd /export/poudriere/jails/132amd64/usr/src/tools/build; make DIRPRFX=tools/build/ DESTDIR=/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy installdirs mkdir -p /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/bin /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/lib/casper /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/lib/geom /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/include/casper /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/include/private/ucl /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/include/private/zstd /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/libdata/pkgconfig /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/libexec ln -sfn bin /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/sbin ln -sfn ../bin /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin ln -sfn ../bin /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/sys" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/casper" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/ufs/ufs" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/ufs/ffs" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/fs/msdosfs" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/sys/disk" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/machine" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/rpc" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/crypto/chacha20" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/x86" cd /export/poudriere/jails/132amd64/usr/src/tools/build; make DIRPRFX=tools/build/ DESTDIR=/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy host-symlinks Linking host tools into /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/bin rm -f /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/libexec/flua cp -pf /usr/libexec/flua /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/libexec/flua -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- . . . ********************************************************* * Here I just wait and let things happen. I have tried * * this with -J 32 and it fails everytime. So I figure * * using -J 1 may keeps things in chronological order. * ********************************************************* . . . mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/machine" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/rpc" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/crypto/chacha20" mkdir -p "/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy//usr/include/x86" -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /export/poudriere/jails/132amd64/usr/src; INSTALL="sh /export/poudriere/jails/132amd64/usr/src/tools/install.sh" TOOLS_PREFIX=/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp PATH=/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp MAKEFLAGS="-m /export/poudriere/jails/132amd64/usr/src/tools/build/mk -j 1 -J 15,16 -m /export/poudriere/jails/132amd64/usr/src/share/mk" make -f Makefile.inc1 DESTDIR= OBJTOP='/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/obj-tools' OBJROOT='${OBJTOP}/' MAKEOBJDIRPREFIX= BOOTSTRAPPING=1500043 BWPHASE=bootstrap-tools -DNO_CPU_CFLAGS -DNO_LINT -DNO_PIC -DNO_SHARED MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FORMAT=no MK_CLANG_FULL=no MK_HTML=no MK_MAN=no MK_PROFILE=no MK_RETPOLINE=no MK_SSP=no MK_TESTS=no MK_WERROR=no MK_INCLUDES=yes MK_MAN_UTILS=yes MK_LLVM_TARGET_ALL=no bootstrap-tools ===> lib/clang/libllvmminimal (obj,all,install) . . . objcopy --only-keep-debug vtfontcvt.full vtfontcvt.debug objcopy --strip-debug --add-gnu-debuglink=vtfontcvt.debug vtfontcvt.full vtfontcvt sh /export/poudriere/jails/132amd64/usr/src/tools/install.sh -s -o root -g wheel -m 555 vtfontcvt /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin/vtfontcvt sh /export/poudriere/jails/132amd64/usr/src/tools/install.sh -o root -g wheel -m 444 vtfontcvt.debug /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib/debug/usr/bin/vtfontcvt.debug ===> usr.sbin/zic (obj,all,install) [Creating objdir /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.sbin/zic...] echo zic.full: /usr/lib/libc.a /usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib/libegacy.a >> .depend /usr/local/bin/ccache cc -O2 -pipe -fno-common -I/export/poudriere/jails/132amd64/usr/src/contrib/tzcode -include tzconfig.h -g -MD -MF.depend.zic.o -MTzic.o -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I/usr/obj/export/poudriere/jails/132amd64/usr/src/amd64.amd64/tmp/legacy/usr/include -c /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/zic.c -o zic.o /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/zic.c:464:8: error: an attribute list cannot appear here 464 | static ATTRIBUTE_NORETURN void | ^~~~~~~~~~~~~~~~~~ /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/private.h:471:30: note: expanded from macro 'ATTRIBUTE_NORETURN' 471 | # define ATTRIBUTE_NORETURN [[noreturn]] | ^~~~~~~~~~~~ /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/zic.c:471:8: error: an attribute list cannot appear here 471 | static ATTRIBUTE_NORETURN void | ^~~~~~~~~~~~~~~~~~ /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/private.h:471:30: note: expanded from macro 'ATTRIBUTE_NORETURN' 471 | # define ATTRIBUTE_NORETURN [[noreturn]] | ^~~~~~~~~~~~ /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/zic.c:669:8: error: an attribute list cannot appear here 669 | static ATTRIBUTE_NORETURN void | ^~~~~~~~~~~~~~~~~~ /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/private.h:471:30: note: expanded from macro 'ATTRIBUTE_NORETURN' 471 | # define ATTRIBUTE_NORETURN [[noreturn]] | ^~~~~~~~~~~~ /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/zic.c:3778:8: error: an attribute list cannot appear here 3778 | static ATTRIBUTE_NORETURN void | ^~~~~~~~~~~~~~~~~~ /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/private.h:471:30: note: expanded from macro 'ATTRIBUTE_NORETURN' 471 | # define ATTRIBUTE_NORETURN [[noreturn]] | ^~~~~~~~~~~~ 4 errors generated. *** [zic.o] Error code 1 make[3]: stopped making "all" in /export/poudriere/jails/132amd64/usr/src/usr.sbin/zic make[3]: 1 error make[3]: stopped making "all" in /export/poudriere/jails/132amd64/usr/src/usr.sbin/zic make[2]: stopped making "bootstrap-tools" in /export/poudriere/jails/132amd64/usr/src make[1]: stopped making "buildworld" in /export/poudriere/jails/132amd64/usr/src make: stopped making "buildworld" in /export/poudriere/jails/132amd64/usr/src [00:08:18] Error: Failed to 'make buildworld' [00:08:18] Error while creating jail, cleaning up. [00:08:18] Removing 132amd64 jail... done [00:08:21] Cleaning 132amd64 data... done real 501.40 user 619.18 sys 158.12 t# So perhaps there is a way to create a jail for an older release using just some tarballs extracted and then I can hack up something that looks correct in /usr/local/etc/poudriere.d/jails/132amd64 directory. Something similar to : t# t# ls -lap /usr/local/etc/poudriere.d/jails/142amd64/ total 13 drwxr-xr-x 2 root wheel 9 May 19 22:25 ./ drwxr-xr-x 4 root wheel 4 May 24 21:31 ../ -rw-r--r-- 1 root wheel 6 Apr 16 23:00 arch -rw-r--r-- 1 root wheel 31 Apr 16 23:00 fs -rw-r--r-- 1 root wheel 5 Apr 16 23:00 method -rw-r--r-- 1 root wheel 33 Apr 16 23:00 mnt -rw-r--r-- 1 root wheel 2 Apr 16 23:01 pkgbase -rw-r--r-- 1 root wheel 11 May 19 22:25 timestamp -rw-r--r-- 1 root wheel 16 Apr 16 23:02 version t# t# t# cat /usr/local/etc/poudriere.d/jails/142amd64/method http t# t# cat /usr/local/etc/poudriere.d/jails/142amd64/mnt /export/poudriere/jails/142amd64 t# t# cat /usr/local/etc/poudriere.d/jails/142amd64/pkgbase 0 t# t# cat /usr/local/etc/poudriere.d/jails/142amd64/timestamp 1747693542 t# t# cat /usr/local/etc/poudriere.d/jails/142amd64/version 14.2-RELEASE-p3 t# t# cat /usr/local/etc/poudriere.d/jails/142amd64/fs zroot/poudriere/jails/142amd64 t# t# cat /usr/local/etc/poudriere.d/jails/142amd64/arch amd64 t# Well the "method" will not be http as that does not work. Is there any other way to build a jail for an older release? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Sat May 24 22:40:26 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b4cTv2KqWz5vsbh for ; Sat, 24 May 2025 22:42:11 +0000 (UTC) (envelope-from grembo@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b4cTv1trrz3kRQ; Sat, 24 May 2025 22:42:11 +0000 (UTC) (envelope-from grembo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748126531; 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=JSbV/HIEpGsCWbr3N7gE7W/4pgLqBNWEqHU7HkbKGfE=; b=QAsnuMDInV4R+95hjg9SAOTtm9QzBtOOsbNESq+PMIEI6hUbjEiwOT2ktsknnGJPRdPcsB M0ieU6BaxZghtzBu8qMl4WBdDGp83LbKT3y/bjiK2MTSdVZOX6dJrySNJFrhRWyjLEr4EQ izPgi8iUv5o2Aa4EXPpBks0W3OPn0aN2gSbARfmV+g2RWhrwl7LYfrnqGBaGosaSCrQ9vc vEOfwRxXvTIbLQS6pTPd0eGKTUlO779r6ra/0yL6KAjkZEDQIT5gSgKOuDGAip7qAZsnZR 4K3kBmJIgCPlhnAiG+mrhQtqULWUbbizUmAPlVps2XKMYZxjwfEKN/sjxYXWYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748126531; 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=JSbV/HIEpGsCWbr3N7gE7W/4pgLqBNWEqHU7HkbKGfE=; b=wQC+QYoOV6bfpM/WiKHmdIqu+GrBVE2/Nci9EXZnKcxIVXLEHMJkxYjACgksZfPyCFQ/n8 Qj6S4T2L+TFuz4gQCa9j5pfcI3ed/zEjvKg/vKOnrRZ5NQVvOwpLvgTmdg6OignV9Bi8fI 078eQJ4crpZxAgcL+li7dgo3o4nByGxl+EfMDOHa2VA4Vf+g3CqCT7ZRHbc3ZvgyQcLCpV 3Xct70vJjshU2gkK3vvC+JTsJqtwMfy0iG2NpAthx/BayuF0h8UzDWwufy1aHb4Jq0Uc3h 2kc/QlQdsZLU63drn0AKLAGNUAzPMnkX49x5XtvoCkSKC7jfeD75cPNqgCgBdQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1748126531; a=rsa-sha256; cv=none; b=LnMUOgMXWy/ktgkPnF9EsTULTMa4dTSd/SP3w4hG5vwNKqyWcavFtcAX6Btp5lJi6uIRVK Xo+3HEkg7ACVGbwOUAevfcja542dacAKeqP6xl4KV5+PhTsp1f6VVMdlziK4CkwVFqbzt0 MXzZ4InVZsRmkZ2OXzLZiL6ZyUUHU+37Su0epWNWQOpe8XQa+CVCzBoxiBOqfX9oBL/NaK j0cZzGhRAHcsBx9j1CbdNFQq1tnR6KTXP1vNXx8LciofD7hTd5BTQ8OvYztvMt+jLduwBL 3LWwDgtYTSqvcoG0niBGZmTFjzibstIhv9iTpSWl6zXNxMsdkPVSki+H34txgw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: grembo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b4cTt6Cl2z17Jv; Sat, 24 May 2025 22:42:10 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id b39af55c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 24 May 2025 22:42:08 +0000 (UTC) Date: Sun, 25 May 2025 00:40:26 +0200 From: Michael Gmelin To: Dennis Clarke Cc: FreeBSD Current Subject: Re: With poudriere how does one create a jail of a slightly older RELEASE ? Message-ID: <20250525004026.4b28a210.grembo@freebsd.org> In-Reply-To: <24cacc7b-3539-4765-8852-43b02764c911@blastwave.org> References: <24cacc7b-3539-4765-8852-43b02764c911@blastwave.org> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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 On Sat, 24 May 2025 17:37:06 -0400 Dennis Clarke wrote: > This may seem trivial but trying to create a jail for a release > from just a few years ago is not working well : > > t# poudriere jails -c -a amd64 -j 132amd64 -v 13.2-RELEASE > [00:00:00] Creating 132amd64 fs at > /export/poudriere/jails/132amd64... done [00:00:00] Fetching MANIFEST > for FreeBSD 13.2-RELEASE amd64 fetch: > https://download.freebsd.org/releases/amd64/amd64/13.2-RELEASE/MANIFEST: > Not Found > fetch: > https://download.freebsd.org/releases/amd64/amd64/13.2-RELEASE/MANIFEST: > Not Found > [00:00:01] Error: Failed to fetch from > https://download.freebsd.org/releases/amd64/amd64/13.2-RELEASE/MANIFEST > [00:00:01] Error while creating jail, cleaning up. > [00:00:01] Removing 132amd64 jail... done > [00:00:01] Cleaning 132amd64 data... done > t# > > That makes perfect sense. > This works: poudriere jail -c -j 132amd64 -v 13.2-RELEASE \ -m url=https://archive.freebsd.org/old-releases/amd64/13.2-RELEASE/ Cheers Michael -- Michael Gmelin From nobody Sat May 24 22:46:18 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b4cZm5zL6z5vsw7 for ; Sat, 24 May 2025 22:46:24 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b4cZl1NzQz3m6K for ; Sat, 24 May 2025 22:46:23 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b="Z8Qv22z/"; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org; dmarc=pass (policy=quarantine) header.from=blastwave.org Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 54OMkIUl012041 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sat, 24 May 2025 18:46:20 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1748126780; bh=87LuG8MB0pU/jyEpBwXHCl1moH5xqVGob/Jm2+/oHm4=; h=Date:Subject:To:References:From:In-Reply-To; b=Z8Qv22z/TXyGmaPeUd8T8ZEHyn2j1A9kjQ0aqmCPRoYZHKHaTv2YXzuYPkneYNCbs wQxHfKjyXw7RwUtTp2NCWhda85aHsXC/kQaSG3YlIzFWizADDoE6N+6R70WhkwxCWe Iy4EHkrEON3vssIhx68W4R7B4zsVb1qrt6UJkMEsmuRuXC7kHuevmLs7HQ3Dj3ZZsT YNo1NBiTAMtAmzAIbVfTYY9lef4rtdhiX3e+rnB23MBNNeUEuN/OnvOwI8b5ZdqlQu AgNxezoL/Ey0kzaU4QyNl95ibwMrPyGS0vftqUJZnU0adYiohdmM3HBs1tIGrKaPjc ffJF189rKgvEw== Message-ID: <5af18f07-4a6b-4e77-ac2a-e65c12c3a0b3@blastwave.org> Date: Sat, 24 May 2025 18:46:18 -0400 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: With poudriere how does one create a jail of a slightly older RELEASE ? Content-Language: en-CA To: freebsd-current@freebsd.org References: <24cacc7b-3539-4765-8852-43b02764c911@blastwave.org> <20250525004026.4b28a210.grembo@freebsd.org> From: Dennis Clarke Organization: GENUNIX In-Reply-To: <20250525004026.4b28a210.grembo@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 54OMkIUl012041 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Queue-Id: 4b4cZl1NzQz3m6K X-Spamd-Bar: / X-Spamd-Result: default: False [0.02 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_SHORT(0.99)[0.990]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_MEDIUM(-0.30)[-0.297]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.03)[0.031]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[blastwave.org:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; FROM_HAS_DN(0.00)[] On 5/24/25 18:40, Michael Gmelin wrote: > >> That makes perfect sense. >> > > This works: > > poudriere jail -c -j 132amd64 -v 13.2-RELEASE \ > -m url=https://archive.freebsd.org/old-releases/amd64/13.2-RELEASE/ > > Cheers > Michael > wow ... archive ? Well why not and yes I will give that a whirl. Still doesn't clear up why I can not build from source but that is a whole other matter. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Sun May 25 01:47:45 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b4hcP3pPvz5wqkW for ; Sun, 25 May 2025 01:48:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4b4hcM4nQnz3g2r for ; Sun, 25 May 2025 01:48:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hLZy9nLa; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 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=1748137681; bh=4EySVA5lue5+NPLesI5oloQPU5agKaae5so770A0NP0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=hLZy9nLanCQSIx0cF1oFam279hUG9IH7IspUxBXJpPjaY5YEhMeLvbXgzb85W8bGdbyfSB28xn/eqBQ9o9qybxOcEa8vFiSjsY9jneb8hVfYxptCDQwbsts+XFLz0tbLfFyhuBS+Gv7pruK6P23bfsWjpE1YZYI4Nr7t8miAHuKf5KUVzZgv+s9aRrUGbkn/Igu2cVfs4UHQM6YbuFFYiVmSvF5rBn+33bkhXsNlK89yXbwVzIkSxk2u0ORX5exaBVc9yYBpNgPLEogwv7UcB0KEnAemCooi3O+nN+mL4iJ4Xe2MUoYwgFm4mkZRvT6jqpCsAh5FgnTxU1mm9lpUQg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1748137681; bh=YFsdQ3eDS/exucbuIOuBfiQLbqn0P+tZrkFCADHAGXa=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=CgGxGTfkm1lAUTRb/ZgAHVzsGk/hPfTsb3LCqH2YLpeiuI4nkWnQpu/Lz7vHjjUEhOZLkXMikUi7iVhH2CQtuAA5uTW3Xfc1+7QiQ15qDBwCLo8XZbgzki7VUx6TEZfU02tza99RfUcQbflGmhoKBbmMQUEEmQ0CWoJWGHieIYvoiQ9CFMCqsCB9LlvSCvvzAgjDpyll7uMMDNymrgY+gYt0wFazr/snngQ4owbISkVwFGje+N6dSzC/kZdItYj/aFwDRwXnaUjDll/U/slXFULGnEws5oVbBDirhegB7qHB4dGzgwxIiHRpBwrIJZ/YoB/KTVhzXPEikUXnbr7Fhw== X-YMail-OSG: cSI6qYgVM1mwfhrpqPsi2E0UX0KSOs_T1qEUBwgwR5tIBakpvQIlORUpGAts7.H LjrF9iGn9hbPbcFvf8xvPzaXZi8Mv6aUpo1ev7q9iNHdI08fdinO7gyWDKFL2YOFYOkRcNO3ixuY K8d080SMUM2zhw3b51iQEN0O9hMmxE1_tx1Q73jy9CXxTnINLCGgBZUbk0Mbv1My_E3Xbu8VMfWp RE0gxgXGEyUwc.AYQ26UnXTiQ4JnDPW0rkkDhtVFe0wFOBh_PS6KlRNfd6lXQAAnRC1VpPddxh0B AIhxn.80P90YVGwmY9uVG7QRX77SGVcYoaRbM2EVHgwn7uzvbmXPQErBWgJB3SFzMQvJH7IH4iZK idb2tmJCRyiJrkIWkAMrhKcEvwyc1by0Z1UvcTJpbvswIFL60uP6.qBtkRQ7WvfI8lJTOxW7daj8 8JNQOgxen43GWB98yY7Vb53qhD_g1MdCmX1I1f6tjvYz.xV.t.EilpFl0iyCx97Gsnbyttsa1Ge6 gsbpY6saf77X0ZhcJ8bqGRZlhE.gfGvhrP18miDkivx871FvAAigAMEsn6QfE1aGHbshPMMYZi8Y JBXNkO1DTPj2gqL815opG2Q4PuQy.yGExwjg09t_RPU7Hl.usgSENgcNWmH3pIlGymsJOV48lh2y 9i4dSx.BfjaaZiBLLdvs7EV7Cx0ClwQz11o5K2o6Bm6pVypdniW71HyCMOkQc1wk7nyfXY.NdNjw yZM2SgDfclolKxu_vkcdX1Jor75Kt_R0fA4dK3UBi.iTTtDPfCNaeSM1G7aXT9ml8MsPd0Fmt8Fc A.rJxCevZ0fW20hcOrlW6zOHWNIf3m06C.VtSUkPxYTaQFRCQE0Mz8_LFWN.5FCsCsr1FDrk.ilM m.RBSIyK1fd7dqWYzrWFaJ.PRgUd7ZhogpJu0EmYsuH2w1LVYji3Oic6xM9OmLt35cAszwH_dHF_ ajdotwKekOWGLoQUqfa1DIghwdmQkr95oKxqpXP1RxHReGxYFmg44RN3r60ds.G6Do1YMqSYByr4 VOL9Nvq79mo4g8o_T8qWXaWX03c0XksNISnTX9dw3hD9s6GRT3169gEnfnI7ELCuTtMgmRebaLNg k.7aqLCmtARhXk4Q3BulqudlV_Bs8Jrz1yTmBN3qzraadcW2ExOt2EkFM7sgrDm.GskB1jsf1MDv kl0pdmHprPmVn.bG5LWbw7xk2pdL740UwHR5Gv1wQXJ1DWz0dIvT6ZQRzRtmnr2EerC_MmCIeIzz noA7l0bxTWkQETdKxFYmeMyAhm51o4dZ6gRjuEsAUlCONd1d6VaQz_G985BCwxt83BLlggPc4_pk HOlxRgETHnBH1i0fVkkCKCcnRsiplo8j0rcWTNrw6C_DZM9EIDQrX3cY8hOIYrhJ_iOWILOvuQsr pJW_cOb5Ev_AO2dYerQ4nfjv.iZjzkpknq4LO5Xj8..NkkkyNz9H0sSCR2XIDV.dXMnekZP0FStw 6TXwrLEYDfChs6NB7Nqm5Jzd6J1NKvgHnPz2wDW3QhvV_U3SjDOB0MdIgCy.yT_LUXi4_lk0Q3a0 6JGWiZ25YDCsVIXlaJZUoQt_R5LzLRF_FjyXrYV5QqOzib8E5hrZCQazVazk06leAwue1nBLU.VY ugR_UrgLxp.kzmAwIuSxjwjAK8m6c3Z0sUoXKz5mtNUdm5Yohn_fdPfdTo9F2JtdxhyRtDT9783t AXk4oj_cLAG8i3mqQFqvomlCtQvayDcY2G60NCSbJdAg9Iaf9JinVd2z8V0yK4m_jVpPlbwmrcmI gMcj7pYsbJw6uDyPSIAA_ta8Q2yUlYCTMLf006zo0ggOcOKtvWFqkqc6HEVRafazu9FhtR0jney2 sbqShzOJdR63yftGuUoGP9Uom.MFb3FoM1d1eThPz2Soy0ZqiARzh63iN4W8cjPCADXGThWxeNrP hdX_2m_Rt.g3cshJsocLYzVarMCFKuO1m8SaZDa_uUEy18e61uFY9PiOaYJsKBB7qn2iVrNpKbvH le09I4VmLb.kSSg4IYQL88SEyJkHRobwMBb3YpW2XeQ_AnIOHqTWq4AjLZHikCbo4e2pHDG.99Wr bMPC2bILJi.8gQOiY4GE7iWGs6xEuWwgrTfcSo7MUbaVH_Ugf3fMLjdosdnh.Rsy7NPRuH5v8oYJ 6Ti5l1WnESMYqseL0.KkS9riF3VQUgjAPCPqXT86zHymGqLyBWPHs0sYmGMrOu_Ilt_ujQO0yMsy ZK0a6eQj4RGSwvgYhYt2czbewLvw7.DHDctfdSN8lxHcJ8dXCH.ae6.JEs4J8PjFcqUp5tA3UUcj wWVCCYeopiJ7fW7dRKAnZi3I- X-Sonic-MF: X-Sonic-ID: fbdbf7e3-fd58-4b18-8c9c-c8e8788e88c4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 May 2025 01:48:01 +0000 Received: by hermes--production-gq1-74d64bb7d7-4jn9v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 166ed2b406d98e0e6687d4f1daf80510; Sun, 25 May 2025 01:47:55 +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.600.51.1.1\)) Subject: Re: With poudriere how does one create a jail of a slightly older RELEASE ? Message-Id: Date: Sat, 24 May 2025 18:47:45 -0700 To: Dennis Clarke , FreeBSD Current X-Mailer: Apple Mail (2.3826.600.51.1.1) References: X-Rspamd-Queue-Id: 4b4hcM4nQnz3g2r X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.12 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.982]; NEURAL_HAM_MEDIUM(-0.90)[-0.902]; NEURAL_HAM_LONG(-0.74)[-0.739]; 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.68.84:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from] Dennis Clarke wrote on Date: Sat, 24 May 2025 22:46:18 UTC : > On 5/24/25 18:40, Michael Gmelin wrote: > >=20 >=20 > >> That makes perfect sense. > >> > >=20 > > This works: > >=20 > > poudriere jail -c -j 132amd64 -v 13.2-RELEASE \ > > -m url=3Dhttps://archive.freebsd.org/old-releases/amd64/13.2-RELEASE/ > >=20 > > Cheers > > Michael > >=20 >=20 > wow ... archive ? Well why not and yes I will give that a whirl. >=20 > Still doesn't clear up why I can not build from source but that is a=20= > whole other matter. MFC's do not go back through the whole history making source files compatible with updated toolchains. Even something like llvm18 can have where syntax is allowed corrected before llvm19, disallowing what should not have been allowed in the first place. And source can be corrected to be where both llvm18 and llvm19 based clang will tolerate the syntax, even if llvm18 is not updated to be more accurate about intent. In general things are set up to go forward in small enough jumps, not to go backwards. The MFC of the source correction to 13.* was made to 13.3, not to 13.2. See: = https://cgit.freebsd.org/src/commit/contrib/tzcode/zic.c?h=3Dreleng/13.3&i= d=3D7ef70d24eee731375fe17a8ef1a30573338d9468 that was made in order to avoid the likes of: /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/zic.c:464:8:=20 error: an attribute list cannot appear here 464 | static ATTRIBUTE_NORETURN void | ^~~~~~~~~~~~~~~~~~ = /export/poudriere/jails/132amd64/usr/src/contrib/tzcode/private.h:471:30:=20= note: expanded from macro 'ATTRIBUTE_NORETURN' 471 | # define ATTRIBUTE_NORETURN [[noreturn]] | ^~~~~~~~~~~~ . . . and for: ATTRIBUTE_REPRODUCIBLE ATTRIBUTE_MALLOC ATTRIBUTE_FORMAT The attributes go before the static , not after. There could well be more from 13.3+ needed to get 13.2 to build from what you reported as: # uname -apKU FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #1=20 main-n277353-19419d36cf2a: Mon May 19 20:40:28 UTC 2025=20 root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1500043=20= 1500043 t# t# cc --version FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git=20= llvmorg-19.1.7-0-gcd708029e0b2) Target: x86_64-unknown-freebsd15.0 Thread model: posix InstalledDir: /usr/bin Build config: +assertions =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun May 25 05:21:09 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b4nLg25Zvz5x4Ng for ; Sun, 25 May 2025 05:21:31 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (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 (secp384r1) client-digest SHA384) (Client CN "prime.gushi.org", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b4nLf6BM9z3Lv3 for ; Sun, 25 May 2025 05:21:30 +0000 (UTC) (envelope-from freebsd@gushi.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple ([IPv6:2601:602:57f:d384:10b6:2fb9:a39c:4976]) (authenticated bits=0) by prime.gushi.org (8.18.1/8.18.1) with ESMTPSA id 54P5LPIn099359 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 25 May 2025 05:21:25 GMT (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 54P5LPIn099359 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1748150485; bh=5++zbUVWRm6GA0KhhHkJyrG10Jdsd1rYA3uLUhaI8vA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; z=From:=20"Dan=20Mahoney=20(Ports)"=20|Subject:= 20Re:=20With=20poudriere=20how=20does=20one=20create=20a=20jail=20 of=20a=20slightly=20older=0D=0A=20RELEASE=20?|Date:=20Sat,=2024=20 May=202025=2022:21:09=20-0700|In-Reply-To:=20|Cc:=20Dennis=20Clarke=20,=0D=0A=20FreeBSD=20Current=20|To:=20Mark=20Millard=20|References:=20=0D=0A=20; b=pBoAN+gLYLwD2iyz0mHQJ+XgPYTsrD8LC0GkTz0Hr5FdEJ1dRs2moqyjswfETkXCK F8/3G4mo23gIhwjfQFeRY8x461ce9cQzD+xTWSoZpFqKvOv8gXkT5s+fQ/RRo8s7CB WGwJL9TnhGDRuBebOCoctsb1nk+U7LlTCXqaEMLH1fhVZgNlSboEYZ3e+pclunhiyy AxVVZvUfdog8zbfh3xzEs0zMQnGYID/oHr4CNDMdS1X/aKH6Z0w40mIDCOnnZpLhHP Vc2j2XHAWWLiKeM5lbx/AuEs0NaIzP1b8bTf/VTWBWtRYBPchPLuVRG2GrJcA4IJ4X kq3wknjZQW6vQ== X-Authentication-Warning: prime.gushi.org: Host [IPv6:2601:602:57f:d384:10b6:2fb9:a39c:4976] claimed to be smtpclient.apple From: "Dan Mahoney (Ports)" Message-Id: <32EA40DC-0B63-4037-BC6C-C1C26122DE65@gushi.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_6DEB5D74-848D-4E3D-B57B-65656D86F0B3" 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.600.51.1.1\)) Subject: Re: With poudriere how does one create a jail of a slightly older RELEASE ? Date: Sat, 24 May 2025 22:21:09 -0700 In-Reply-To: Cc: Dennis Clarke , FreeBSD Current To: Mark Millard References: X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b4nLf6BM9z3Lv3 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:393507, ipnet:2620:137:6000::/44, country:US] X-Spamd-Bar: ---- --Apple-Mail=_6DEB5D74-848D-4E3D-B57B-65656D86F0B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 24, 2025, at 18:47, Mark Millard wrote: >=20 > Dennis Clarke wrote on > Date: Sat, 24 May 2025 22:46:18 UTC : >=20 >> On 5/24/25 18:40, Michael Gmelin wrote: >>>=20 For a while I had some EOL (but very hardened) systems out in the wild = (this was when 8 and 9 were EOL, but 10 was current). These were boxes = that ran basically one protocol on one port and only spoke any other = network protocols to our own routers. There were some hardware = challenges that blocked our ability to upgrade, as well as some issues = getting remote hands. (This happened again circa 2020 for *some = reason*). To be able to deploy a clean version of a critical piece of software, I = maintained our own poudriere farm, just in case. To cover my butt in all edge cases (and just for retrocomputing fun, to = be able to pull up systems to see when things had changed or how far = back a regression went), I did: poudriere jail -c -j FreeBSD:9:amd64 -v 9.3-RELEASE poudriere jail -c -a i386 -j FreeBSD:9:i386 -v 9.3-RELEASE poudriere jail -c -m ftp-archive -j FreeBSD:8:amd64 -v 8.4-RELEASE poudriere jail -c -a i386 -m ftp-archive -j FreeBSD:8:i386 -v = 8.4-RELEASE (Note: ftp-archive is NOT fast) I was then able to get ports trees that were known to work with those = older versions via: poudriere ports -c -m svn -B tags/RELEASE_8_EOL -p RELEASE_8_EOL poudriere ports -c -m svn -B tags/RELEASE_9_EOL -p RELEASE_9_EOL =46rom which point I was able to MFC the critical application from a = modern ports tree and build with poudriere testport/bulk as usual. -Dan= --Apple-Mail=_6DEB5D74-848D-4E3D-B57B-65656D86F0B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On May 24, 2025, at 18:47, Mark Millard = <marklmi@yahoo.com> wrote:

Dennis Clarke = <dclarke_at_blastwave.org> wrote on
Date: Sat, 24 May 2025 = 22:46:18 UTC :

On 5/24/25 18:40, = Michael Gmelin wrote:


For a while I had some EOL (but very hardened) systems out in the = wild (this was when 8 and 9 were EOL, but 10 was current).  These = were boxes that ran basically one protocol on one port and only spoke = any other network protocols to our own routers.  There were some = hardware challenges that blocked our ability to upgrade, as well as some = issues getting remote hands.  (This happened again circa 2020 for = *some reason*).

To be able to deploy a clean version of a critical piece = of software, I maintained our own poudriere farm, just in = case.

To cover my butt in all edge cases (and just = for retrocomputing fun, to be able to pull up systems to see when things = had changed or how far back a regression went), I = did:

poudriere = jail -c -j FreeBSD:9:amd64 -v 9.3-RELEASE

poudriere = jail -c -a i386 -j FreeBSD:9:i386 -v 9.3-RELEASE

poudriere jail -c  -m = ftp-archive -j FreeBSD:8:amd64 -v 8.4-RELEASE

poudriere jail -c -a i386 -m = ftp-archive -j FreeBSD:8:i386 -v 8.4-RELEASE


(Note: ftp-archive is NOT fast)


I was then = able to get ports trees that were known to work with those older = versions via:


poudriere = ports -c -m svn -B tags/RELEASE_8_EOL -p RELEASE_8_EOL

poudriere ports -c -m svn -B = tags/RELEASE_9_EOL -p RELEASE_9_EOL


=46rom which point I was able to MFC = the critical application from a modern ports tree and build with = poudriere testport/bulk as usual.


-Dan

= --Apple-Mail=_6DEB5D74-848D-4E3D-B57B-65656D86F0B3-- From nobody Sun May 25 17:43:54 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b55sJ4ly9z5xnY6 for ; Sun, 25 May 2025 17:45:40 +0000 (UTC) (envelope-from grembo@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b55sJ4J21z3qqv; Sun, 25 May 2025 17:45:40 +0000 (UTC) (envelope-from grembo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748195140; 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=4naBJUvKhElhjupWTuQRcIazyMhwY4pVShgNdQCLPIo=; b=XKJCJgE6+Ivhmxzkt1s0J2diSuUTOOV1LXcllj7cap194oPtq9sbQCKSv1ETiWmlngUv7f N8dcn8pM2cTNE7dD1vph9Tiz533/yFGUSQ96s1YQxLTyZjZu76Ri8md5ZfSRWWB/zeThCA fGf6SVGDuvSrVNbzVg0RcDiNHGa0wJx2WtIs5THoMFeRokxahvz80msbIE5z3PYJtRxjoG lHzMeHdx3R9h7jPHEUBOI1n3wRPSoqwArrP6ZRNds21gOshH4yIvPi7KwqlQS9xwXeobKp 13NAlPbjlvBN4fUPK9pRXp4q/zi4rDjI8N28zdei9+rM8O9y/U0BAh35oWytXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748195140; 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=4naBJUvKhElhjupWTuQRcIazyMhwY4pVShgNdQCLPIo=; b=DFOYQA6tO2g1Zq7NEztFIrCm0IOmOexZyUkN9ugVH7wqKKZ5kLQJ/yw7Xfsko09QQ2SC/I cTYG6xSf2BCHxYc8gVm7mMkFH7KJnamMjRAeZTcxoUivGXbpvs5SLTGHmuFKaDp56qgwm0 W74BIZdIMFUB167LCqkuFJa1Df8mZcmlpT7ylEOUSQLbK6o5sxHsY24Q0+kJJsCrVlhz1r unzk935TKHYjcoSXv28w7dl+YILCNxYAc5Bp/phTdZ8PQfpO+5ovlBjyY+0eEpawEmzbpV Ow3ZuXBjzU0xhwAkFyKOKZ9OD91ceKg+wtcnlwSFNm5Iq1QMRos+3g4a9oNIrg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1748195140; a=rsa-sha256; cv=none; b=VEeMs+ek+Ukr62+mkRs+Y8kCRX6N4YKFHnwk0QSto/xlka6x7DdDqWTpDvp9ia4gLKWwTW 6Drq9COpc6Vn1VjUeeiooXIcEXAPgJswAhUUwZum7PRecAMy8EPZdWdlPWU4lYEuUi7Nh6 XgBn3iFdIaL3zfcyJ2yN2IMHelv4spgNgWHQ6oOOiMzb2KTiXIO6AzIL//FtG6W2GzCYlm isa1yjPG4tr+XjLpVWtMy1NDXWw54ll5TBgOw1rlTteETZpN20IMjkj4maLrwEARrkagBc ZHGy27FJPRYFmdSj724cDBmX8zSIBATwu8Yvxb3lbzlqYXDZkAgPK4PcZ4QN2A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: grembo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b55sJ1FB1zJQC; Sun, 25 May 2025 17:45:40 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 0bd4afdd (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 25 May 2025 17:45:38 +0000 (UTC) Date: Sun, 25 May 2025 19:43:54 +0200 From: Michael Gmelin To: Dennis Clarke Cc: freebsd-current@freebsd.org Subject: Re: With poudriere how does one create a jail of a slightly older RELEASE ? Message-ID: <20250525194354.67147f6c.grembo@freebsd.org> In-Reply-To: <5af18f07-4a6b-4e77-ac2a-e65c12c3a0b3@blastwave.org> References: <24cacc7b-3539-4765-8852-43b02764c911@blastwave.org> <20250525004026.4b28a210.grembo@freebsd.org> <5af18f07-4a6b-4e77-ac2a-e65c12c3a0b3@blastwave.org> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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 On Sat, 24 May 2025 18:46:18 -0400 Dennis Clarke wrote: > On 5/24/25 18:40, Michael Gmelin wrote: > > > > >> That makes perfect sense. > >> > > > > This works: > > > > poudriere jail -c -j 132amd64 -v 13.2-RELEASE \ > > -m > > url=https://archive.freebsd.org/old-releases/amd64/13.2-RELEASE/ > > > > Cheers > > Michael > > > > wow ... archive ? Well why not and yes I will give that a whirl. > > Still doesn't clear up why I can not build from source but that is a > whole other matter. > The specific issue you're describing was discussed here: https://lists.freebsd.org/archives/freebsd-current/2023-December/005137.html Basically, clang got more strict about what it accepts. -m -- Michael Gmelin From nobody Sun May 25 17:50:01 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b55yY6Md9z5xnbV for ; Sun, 25 May 2025 17:50:13 +0000 (UTC) (envelope-from otis@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b55yY5Pcwz3smT for ; Sun, 25 May 2025 17:50:13 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748195413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=OsfCEjrRnquix8wKgITveGq/qp219RBCZuJY8T0zDHE=; b=lWDJLT4Vp8wfkabwOGxKO8FZBD/UGqYbKe6Cclo5yR3zd/A4bxV8d5q8w9NDjDGXxpFlbk 6AxEE3rVmDbgXMBLahLd49Kik/hzum75HBLlDzocfnHM60svVnDbzRsOdFDtGe0EBlje3x JRb0fB9Ci02sLI6Lszcf0CTqVYYT1Q0zKujqMbKKf9WluE3ifxp76NlLd2PtHcfkd5InDc kLQP/xGLk3tqYb/QxwzzyH8irTwsYl6LCabyjdXbVYDUPgNGpF7cnJow+NHt0U/xduBI4c gPcNTCpAbRe4W//MzO3ANrQ86qsOAl+FJKqESn/hIeEe1ZY8wd2XXxNMRzdQOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748195413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=OsfCEjrRnquix8wKgITveGq/qp219RBCZuJY8T0zDHE=; b=q9wMRfETB90mB9R4/O+E/NcLS8h/kJM9S4sgFW/MiRBoa9jWEfwk58/aOzlI/b2lQwn9R8 3SSef0YT35DjNdOvVJ9cSt6O6W0JLhXty9w5K527lfPsYIE00BVNLSGIf8VCmd7x2guNpj aPos1CXI0JEnsyrNOvDl1ukm2JmDMJAvLz7YH7YJlXfdfmRuHGuQZkNLeVM46xulk5vP8+ Muw9cAVyMdgVwmHfGYN2qPomftPUVKLUGWZUSRwNYPUyvpYpcCjJz7gIlCO7OOm5uXVQaU oK3okgouIuLAe2qFoE68Yb5I0d9b5eDyih2R4wijAoP7ivqaXOgZSxDVNe8hvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1748195413; a=rsa-sha256; cv=none; b=Jkz+l41bb2IxrMCLW8Ip2JiDnKaIGaspY5qN+8d4c+sfYbhWUsVvgUspxb8fmgIQjvBN3O 37KvtzcE9F0KxoOJH5Ylh2FpykZua3NuE3hifOHICCWRSEsiEHgZ2uycBoX63smhyLo+Sb 7GNN8nt2uB6j69brQmmKOksyt2Z/ujxkxV2qSYFv1brw+Vvg6lbmv/BTcO69wzJsSV14X4 drDP+X70yBLqmdcgKqF7XMvVMWZTJYmvbmv96aWN7JFxVYJ6YMv2cGLnoOATGyJCkHHqjt T3c8yrecGC6O+o+MOc7ZHqG5fLY0M0balZJy86n0LH0hAZKXv/XkbkVNbGg1EQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 (prime256v1) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "E6" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b55yY3ySHzJm2 for ; Sun, 25 May 2025 17:50:13 +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 F3FF5621AC for ; Sun, 25 May 2025 19:50:11 +0200 (CEST) From: Juraj Lutter 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.500.181.1.5\)) Subject: New command ts(1) Message-Id: <1CECB087-9202-4FDE-8DD5-A3D26A125819@FreeBSD.org> Date: Sun, 25 May 2025 19:50:01 +0200 To: "freebsd-current@freebsd.org" X-Mailer: Apple Mail (2.3826.500.181.1.5) Hi, I=E2=80=99ve opened a diff https://reviews.freebsd.org/D35694 with ts(1) = imported from OpenBSD. If someone could have a look and eventually do a review, I=E2=80=99d be = thankful. Cheers, =E2=80=94 Juraj Lutter Fediverse: otis@bsd.network BlueSky: @wilbury.net LinkedIn: https://www.linkedin.com/in/jurajlutter/ GSM: +421907986576 From nobody Sun May 25 20:03:21 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b58wQ48Vsz5whxl for ; Sun, 25 May 2025 20:03:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b58wQ0gskz3f0V for ; Sun, 25 May 2025 20:03:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-af51596da56so715273a12.0 for ; Sun, 25 May 2025 13:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1748203412; x=1748808212; 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=yo1rEGu/J+KHrE0LpZFer35aSAudIhz7J1cw7NCHXKA=; b=QJ/6JWmwG3KRjuDhWCzQffCH19pN7jSu0xvXRZjyogAcUAnnVzKmFM5WFTXjxXDmvf dW0lkiHVyYMcoBItwDPaz/dDH5ghHGlFGdAW8UObeU7H5NajfDwQIEefAzPPdFgrK9aZ WV+/fhGaMsAdLYXpzayzDp7ncFOKFA/vcjWnMeYv9MFtBJd6HOfgwvLXVkX1MkjmeF1+ xOFKmVHbo8Z5LTsZoUef9QJdAa/+jbneKwt3AqAIB2O9A0oZEKqxhx+78cQ90YF+pDGV BF2xSd6whLXN8LVenVgM4tF7PRP3LpKW/6bhu7jUgrmAbazlfCrPtxsYWqc3095jtt4Z SbCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748203412; x=1748808212; 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=yo1rEGu/J+KHrE0LpZFer35aSAudIhz7J1cw7NCHXKA=; b=PnWSjn/DBdCpvYYUs47alpFUkjcoHlRsLQWKzdkDxNQMbpUJZKSNZspH0GZ9hINfjz 8rp+UPhZ2ZoDSkIFHo23ddpzuJc2FNlXonTo14jDa8xLJ4WM5ppMZ6V6x+5KTzEs5w/3 WFUJpDnl+Kgd4QWLQgZvJIHurfIie7pdTUKKx+y40N4Wn0gD0zoVPPmGZQmyGzrpR5dX pto52osVtR8jsMHrS/ukYd4XKtKkaP71B7J0uw+ejOo4q8qNh6V5KILAnw2C870bBAMf VK6IJyU6Fw81kon5e/bGRhmYC01t+2RFILP55JOLDQsoqBnmYwu9lMCEvn0+/PPMZ8WQ EG/Q== X-Gm-Message-State: AOJu0Yy7gcHW/J+gRXrG7EE5MC+zhELlqNbC8Di9aTTaFZaB0pc7rg36 dCuO/6rs0ZI/gCDKW7JpYOpkgDl7TxEaLbxmgaXfBaJZBzGENtsNQ2Stn/nq6VaGORrNokBCq/q Dv/x6umeo/IHL9q3EFk3uTtAi+cFvlQJwtcZdbTlUCg== X-Gm-Gg: ASbGncsqlzDima9NYHOGk099ikbQb78YkT2vjZlYEhUHdc75Evs3mHTGixxPu6sGHxI h2o0n6Newit+otuurdc3n+MtuZs9AR1/h97fPwBOGWLljk01iFuADzpUyp/YUhTTsF1XV2JaMMw MRTdcuE0UeIzz+gDpz5I+nXdtrkrnMQi9ruODhyMvn4sAKY2aUtaDP8QoAFvCskjsAUlc3KDGqb ygg X-Google-Smtp-Source: AGHT+IH3KTa1WyiVmr9R93ub/k8tt/XKVd4UKxjtMWP91Uz/uxwbYOKIhgurZ9J/Jsym2uk871LlEO/0anDxzzLyYsA= X-Received: by 2002:a17:90b:164a:b0:310:8d73:c54f with SMTP id 98e67ed59e1d1-3110f0ee051mr10716623a91.2.1748203412437; Sun, 25 May 2025 13:03:32 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <1CECB087-9202-4FDE-8DD5-A3D26A125819@FreeBSD.org> In-Reply-To: <1CECB087-9202-4FDE-8DD5-A3D26A125819@FreeBSD.org> From: Warner Losh Date: Sun, 25 May 2025 14:03:21 -0600 X-Gm-Features: AX0GCFvlmzHwdwXumiucHGs91BOAfF4UugcdSPMwFP83vdzjrX-tYnGiLoMwmvM Message-ID: Subject: Re: New command ts(1) To: Juraj Lutter Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000064cff40635fb537e" X-Rspamd-Queue-Id: 4b58wQ0gskz3f0V 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-Spamd-Bar: ---- --00000000000064cff40635fb537e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 25, 2025, 11:50=E2=80=AFAM Juraj Lutter wrot= e: > Hi, > > I=E2=80=99ve opened a diff https://reviews.freebsd.org/D35694 with ts(1) = imported > from OpenBSD. > > If someone could have a look and eventually do a review, I=E2=80=99d be t= hankful. > I think this would make a great addition. Warner Cheers, > =E2=80=94 > Juraj Lutter > Fediverse: otis@bsd.network > BlueSky: @wilbury.net > LinkedIn: https://www.linkedin.com/in/jurajlutter/ > GSM: +421907986576 > > > --00000000000064cff40635fb537e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 25, 2025, 11:50=E2= =80=AFAM Juraj Lutter <otis@freebsd.= org> wrote:
Hi,

I=E2=80=99ve opened a diff https://reviews.freebsd.org/= D35694 with ts(1) imported from OpenBSD.

If someone could have a look and eventually do a review, I=E2=80=99d be tha= nkful.

I think this would make a great addition.=C2=A0

Warner=C2=A0

Cheers,
=E2=80=94
Juraj Lutter
Fediverse: otis@bsd.network <mailto:otis@bsd.network>
BlueSky: @wilbury.net <https://bsky.app/pr= ofile/wilbury.net>
LinkedIn: https://www.linkedin.com/in/jurajlutter= /
GSM: +421907986576


--00000000000064cff40635fb537e--