From nobody Sun Dec 31 11:28:55 2023 X-Original-To: freebsd-stable@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 4T2xhd49Ymz55Xmw for ; Sun, 31 Dec 2023 11:29:05 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4T2xhb6Sqsz3VY3; Sun, 31 Dec 2023 11:29:02 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:7400:8808:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org; dmarc=pass (policy=none) header.from=catflap.org X-Catflap-Envelope-From: X-Catflap-Envelope-To: dim@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 3BVBStBR055671; Sun, 31 Dec 2023 11:28:55 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 3BVBStrp055670; Sun, 31 Dec 2023 11:28:55 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202312311128.3BVBStrp055670@donotpassgo.dyslexicfish.net> Date: Sun, 31 Dec 2023 11:28:55 +0000 Organization: Dyslexic Fish To: kostikbel@gmail.com, freebsd@omnilan.de Cc: freebsd-stable@FreeBSD.org, dim@FreeBSD.org Subject: Re: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2 References: <72107B4B-F279-471B-8A8F-5B94C5EEDA47@FreeBSD.org> <62cc8fed-6acd-45fb-a138-ac7cd218191a@omnilan.de> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Sun, 31 Dec 2023 11:28:55 +0000 (GMT) X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.79)[-0.792]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@FreeBSD.org]; FREEMAIL_TO(0.00)[gmail.com,omnilan.de]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; FREEFALL_USER(0.00)[jamie]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4T2xhb6Sqsz3VY3 X-Spamd-Bar: --- Harry Schmalzbauer wrote: > My bad, sorry. > Confused machines. This indeed was wrong target CPU, stupid me. > Previously I tested tih CPUTYPE?=haswell, which editors/vim survives > currently. > Will run a base build with CPUTYPE?=haswell over the weekend and report > back. Can't you simply set the CPUTYPE to native? It should work it out automatically then. Here's the example results of a test program, to show what "native" enables: source [ https://www.catflap.org/jamie/freebsd/show-clang-native-features ] | jamie@catseye% show-clang-native-features | Clang "native" target for this machine: skylake (Triple: x86_64-unknown-freebsd12.1) | | Features enabled (+) : sse2, cx16, sahf, bmi2, fsgsbase, popcnt, aes, mmx, xsave, 64bit, invpcid, avx, cx8, fma, bmi, rdrnd, sse4.1, sse4.2, avx2, fxsr, sse, lzcnt, pclmul, f16c, ssse3, cmov, movbe, xsaveopt, sse3 | Features disabled (-) : tbm, avx512ifma, sha, gfni, fma4, vpclmulqdq, prfchw, cldemote, ptwrite, xsavec, avx512bitalg, movdiri, xsaves, avx512er, avx512vnni, avx512vpopcntdq, pconfig, clwb, avx512f, clzero, pku, lwp, rdpid, xop, rdseed, waitpkg, movdir64b, sse4a, avx512bw, clflushopt, avx512vbmi2, avx512vl, avx512cd, vaes, rtm, enqcmd, mwaitx, wbnoinvd, prefetchwt1, sgx, shstk, avx512vbmi, avx512bf16, avx512dq, adx, avx512pf | jamie@catwalk% show-clang-native-features | Clang "native" target for this machine: znver3 (Triple: x86_64-unknown-freebsd13.2) | | Features enabled (+) : cx16, sahf, sha, crc32, prfchw, bmi2, fsgsbase, popcnt, aes, xsaves, clwb, xsavec, clzero, pku, mmx, rdpid, rdseed, sse4a, clflushopt, xsave, 64bit, invpcid, avx, cx8, fma, bmi, rdrnd, sse4.1, sse4.2, avx2, fxsr, wbnoinvd, sse, lzcnt, pclmul, f16c, ssse3, cmov, movbe, xsaveopt, sse2, adx, sse3 | Features disabled (-) : avx512pf, tsxldtrk, tbm, avx512ifma, fma4, vpclmulqdq, cldemote, ptwrite, amx-tile, uintr, gfni, widekl, avx512bitalg, movdiri, avx512er, avxvnni, avx512fp16, avx512vnni, amx-bf16, avx512vpopcntdq, pconfig, avx512f, lwp, xop, waitpkg, kl, movdir64b, avx512bw, avx512vbmi2, avx512vl, serialize, hreset, avx512cd, vaes, avx512bf16, rtm, enqcmd, mwaitx, prefetchwt1, sgx, shstk, avx512vbmi, amx-int8, avx512vp2intersect, avx512dq From nobody Mon Jan 1 06:06:35 2024 X-Original-To: freebsd-stable@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 4T3QVG2Vwcz5638C for ; Mon, 1 Jan 2024 06:06:46 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from egress.chen.org.nz (egress.chen.org.nz [170.75.172.82]) by mx1.freebsd.org (Postfix) with ESMTP id 4T3QVF23L0z3Tv4 for ; Mon, 1 Jan 2024 06:06:45 +0000 (UTC) (envelope-from jonc@chen.org.nz) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jonc@chen.org.nz designates 170.75.172.82 as permitted sender) smtp.mailfrom=jonc@chen.org.nz; dmarc=none Received: from mail.chen.org.nz (unknown [210.54.37.164]) by egress.chen.org.nz (Postfix) with ESMTP id 078C3111E1D for ; Mon, 1 Jan 2024 19:06:32 +1300 (NZDT) Received: from mail.chen.org.nz (localhost [127.0.0.1]) by filter.inside.chen.org.nz (Postfix) with ESMTP id F1F91684B1 for ; Mon, 1 Jan 2024 19:06:35 +1300 (NZDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ametrine.inside.chen.org.nz Received: from [192.168.1.10] (jade.inside.chen.org.nz [192.168.1.10]) by mail.chen.org.nz (Postfix) with ESMTPS id E84BF684B0 for ; Mon, 1 Jan 2024 19:06:35 +1300 (NZDT) Message-ID: <3611bca4-5157-4d7e-abb6-16a34bac8d99@chen.org.nz> Date: Mon, 1 Jan 2024 19:06:35 +1300 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: freebsd-stable@freebsd.org From: Jonathan Chen Subject: sysutils/screen compilation oddities on stable-14 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.18 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.991]; R_SPF_ALLOW(-0.20)[+a:egress.chen.org.nz]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[chen.org.nz]; ARC_NA(0.00)[]; ASN(0.00)[asn:174, ipnet:170.75.160.0/20, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4T3QVF23L0z3Tv4 X-Spamd-Bar: --- Hi, I'm running a somewhat recent stable-14/amd64 (refreshed 27-Dec-2023), and I wonder if someone can explain what is happening... I've got a dev-host which I use as a repo-builder. I have discovered that if I have linux_enable="YES" on the repo-builder, the resultant executable from the sysutils/screen package produced will only behave as expected on other hosts that also have linux_enable="YES". On hosts where linux_enable is *not* defined (ie linux_enable="NO"), `screen' will start up and then immediatly quit. There are no core-dumps, or any other noticeable error-messages. If I set linux_enable="NO" on the repo-builder, the executable from the sysutils/screen package produced will work as expected on _all_ hosts, ie linux_enable=YES|NO. Can someone explain why this is so? Cheers. -- Jonathan Chen From nobody Tue Jan 2 19:50:56 2024 X-Original-To: freebsd-stable@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 4T4Nky6DTlz56B2q for ; Tue, 2 Jan 2024 19:51:06 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4T4Nkx3zKvz4Q1q for ; Tue, 2 Jan 2024 19:51:05 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:7400:8808:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org; dmarc=pass (policy=none) header.from=catflap.org X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 402JouF7077683; Tue, 2 Jan 2024 19:50:56 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 402Jouvv077682; Tue, 2 Jan 2024 19:50:56 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202401021950.402Jouvv077682@donotpassgo.dyslexicfish.net> Date: Tue, 02 Jan 2024 19:50:56 +0000 Organization: Dyslexic Fish To: freebsd-stable@freebsd.org, jamie@catflap.org, freebsd@omnilan.de Subject: Re: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2 References: <72107B4B-F279-471B-8A8F-5B94C5EEDA47@FreeBSD.org> <62cc8fed-6acd-45fb-a138-ac7cd218191a@omnilan.de> <202312311128.3BVBStrp055670@donotpassgo.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Tue, 02 Jan 2024 19:50:57 +0000 (GMT) X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.905]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US]; FREEFALL_USER(0.00)[jamie]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4T4Nkx3zKvz4Q1q X-Spamd-Bar: --- > Sometimes this might be best, but usually I compile on a dedicated > machine and redistribute to others via local repo. Ahhh, that would be a good reason not to use native then! :-) Still, the "show-clang-native-features" does help identify what features clang things can be enabled on a certain CPU. > At least my latest SIGILL crashes were caused simply by mismatching > target CPU :-( Embarassing... apologies for the noise again. > I didn't know that skylake-avx512 isn't the sequentially the next-Gen., > post SkyLake identifyer, so my assumption that my v6 Xeon would support > AVX512 was simply wrong.  Now I know better. And IceLake continues > confusion... (some AlderLakes do have PCONFIG, others not, WBNOINVD > seems completely mainstream-unavailable and tons of feature-flags/units > I never heard before.. (http://instlatx64.atw.hu/)  World isn't getting > less complicated... I haven't had recent experience, but I can well believe it! A few years ago, I used to chase feature flags with each release, and there were some weird goings on occasionally. I seem to remember weirdness with BMI at one stage (around 2014), but that was fixed. > Will try to reproduce my -march=haswell crahes I initially recognized > some months ago and in case it is reproducable, pick up this thread again. I know this is a bit of a "go-faster-stripes" issue, but what flags do you use generally? I know I'm opening myself up to ridicule, but my general cflags on most machines maps to : -O2 -pipe -march=native -mtune=native -ftree-vectorize -fstack-protector-strong -fno-strict-aliasing -Wl,-znow -Wl,-zrelro -- some of that added by me, some of it by the FreeBSD build system. > Happy new year to everybody! Cheers, and the same to you and everybody else! From nobody Tue Jan 2 21:15:24 2024 X-Original-To: freebsd-stable@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 4T4QcJ5wsyz55qmm for ; Tue, 2 Jan 2024 21:15:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (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 4T4QcJ1Y8Jz4g0d for ; Tue, 2 Jan 2024 21:15:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id KfaDrrU5CB0n0Km6hrngtQ; Tue, 02 Jan 2024 21:15:27 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id Km6frbXm4U5YWKm6grNYg1; Tue, 02 Jan 2024 21:15:26 +0000 X-Authority-Analysis: v=2.4 cv=CZQbWZnl c=1 sm=1 tr=0 ts=65947cee a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=R8vwMfuDAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=EwV3vBmd4GpVq5g1y6kA:9 a=CjuIK1q_8ugA:10 a=EiJSw4IFYIBf4ttFM9wd:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 1799B6F3; Tue, 2 Jan 2024 13:15:25 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id D54EA249; Tue, 2 Jan 2024 13:15:24 -0800 (PST) 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: Jonathan Chen cc: freebsd-stable@freebsd.org Subject: Re: sysutils/screen compilation oddities on stable-14 In-reply-to: <3611bca4-5157-4d7e-abb6-16a34bac8d99@chen.org.nz> References: <3611bca4-5157-4d7e-abb6-16a34bac8d99@chen.org.nz> Comments: In-reply-to Jonathan Chen message dated "Mon, 01 Jan 2024 19:06:35 +1300." List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jan 2024 13:15:24 -0800 Message-Id: <20240102211524.D54EA249@slippy.cwsent.com> X-CMAE-Envelope: MS4xfFzqpCHaRDC2/TreUOaG6P6tznWYdDFWv0h1500iXEdFr2yhrVhNawHIhakRn07G0RVETqNcOPU9DSY9IYZnI7tn+6cE/7oQP0HUkwKjOaecR6O4unAu T+ZTB12mBtdrVUpDqlI/S5JC+hz6jtBF3b5PwjZKq97G0U9G77GP3Q6/iIbnSsJfaz0+oE/vGkUhJrSs0g0kPijxwGllXkRTyVAlaY0DkplHMn2haSny3wm8 X-Spamd-Result: default: False [-1.61 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.911]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com] X-Rspamd-Queue-Id: 4T4QcJ1Y8Jz4g0d X-Spamd-Bar: - In message <3611bca4-5157-4d7e-abb6-16a34bac8d99@chen.org.nz>, Jonathan Chen wr ites: > Hi, > > I'm running a somewhat recent stable-14/amd64 (refreshed 27-Dec-2023), > and I wonder if someone can explain what is happening... > > I've got a dev-host which I use as a repo-builder. I have discovered > that if I have linux_enable="YES" on the repo-builder, the resultant > executable from the sysutils/screen package produced will only behave as > expected on other hosts that also have linux_enable="YES". On hosts > where linux_enable is *not* defined (ie linux_enable="NO"), `screen' > will start up and then immediatly quit. There are no core-dumps, or any > other noticeable error-messages. Is there anything in /var/log/messages or dmesg? > > If I set linux_enable="NO" on the repo-builder, the executable from the > sysutils/screen package produced will work as expected on _all_ hosts, > ie linux_enable=YES|NO. How does your repo-builder build packages? Using poudriere? > > Can someone explain why this is so? I use screen on 15-CURRENT without linux_enable. I build using poudriere. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Jan 2 22:56:58 2024 X-Original-To: freebsd-stable@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 4T4SsW1mYTz563h7 for ; Tue, 2 Jan 2024 22:57:03 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from egress.chen.org.nz (egress.chen.org.nz [170.75.172.82]) by mx1.freebsd.org (Postfix) with ESMTP id 4T4SsV3VpXz3Q6n for ; Tue, 2 Jan 2024 22:57:02 +0000 (UTC) (envelope-from jonc@chen.org.nz) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jonc@chen.org.nz designates 170.75.172.82 as permitted sender) smtp.mailfrom=jonc@chen.org.nz; dmarc=none Received: from mail.chen.org.nz (unknown [210.54.37.164]) by egress.chen.org.nz (Postfix) with ESMTP id 47C00111E19; Wed, 3 Jan 2024 11:56:54 +1300 (NZDT) Received: from mail.chen.org.nz (localhost [127.0.0.1]) by filter.inside.chen.org.nz (Postfix) with ESMTP id A4E94685F7; Wed, 3 Jan 2024 11:56:59 +1300 (NZDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ametrine.inside.chen.org.nz Received: from [192.168.1.10] (jade.inside.chen.org.nz [192.168.1.10]) by mail.chen.org.nz (Postfix) with ESMTPS id 98266685F6; Wed, 3 Jan 2024 11:56:59 +1300 (NZDT) Message-ID: <99fe4b1a-d0f7-421a-8835-394816832506@chen.org.nz> Date: Wed, 3 Jan 2024 11:56:58 +1300 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: sysutils/screen compilation oddities on stable-14 From: Jonathan Chen To: freebsd-stable@freebsd.org References: <3611bca4-5157-4d7e-abb6-16a34bac8d99@chen.org.nz> Content-Language: en-US Cc: David Wolfskill , Cy Schubert In-Reply-To: <3611bca4-5157-4d7e-abb6-16a34bac8d99@chen.org.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.02 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.83)[-0.829]; R_SPF_ALLOW(-0.20)[+a:egress.chen.org.nz]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:174, ipnet:170.75.160.0/20, country:US]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[chen.org.nz]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4T4SsV3VpXz3Q6n X-Spamd-Bar: --- On 1/01/24 19:06, Jonathan Chen wrote: > Hi, > > I'm running a somewhat recent stable-14/amd64 (refreshed 27-Dec-2023), > and I wonder if someone can explain what is happening... > > I've got a dev-host which I use as a repo-builder. I have discovered > that if I have linux_enable="YES" on the repo-builder, the resultant > executable from the sysutils/screen package produced will only behave as > expected on other hosts that also have linux_enable="YES". On hosts > where linux_enable is *not* defined (ie linux_enable="NO"), `screen' > will start up and then immediatly quit. There are no core-dumps, or any > other noticeable error-messages. > > If I set linux_enable="NO" on the repo-builder, the executable from the > sysutils/screen package produced will work as expected on _all_ hosts, > ie linux_enable=YES|NO. After an interesting inspection with ktrace and a look-thru' of rc.d/linux, I've managed track the cause of this to pty.ko. This module is loaded with linux_enable=YES, and interferes with the screen package build. With pty.ko loaded, the screen executable generated will expect old style pseudo-terminal names; which is not what is available on a standard STABLE-14 host. When pty.ko is _not_ loaded, the screen executable generated will work on hosts with linux_enable=YES|NO. I don't know whether the FreeBSD package builders will be affected, but this factoid will be useful for the archives. Cheers. -- Jonathan Chen From nobody Tue Jan 2 23:16:36 2024 X-Original-To: freebsd-stable@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 4T4TJ76pPyz565l2 for ; Tue, 2 Jan 2024 23:16:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.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 4T4TJ769Mkz3TkW for ; Tue, 2 Jan 2024 23:16:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id KlnxrReM98jpTKnzzrkRt8; Tue, 02 Jan 2024 23:16:39 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id KnzxroAOvnCF0KnzyrzKtY; Tue, 02 Jan 2024 23:16:39 +0000 X-Authority-Analysis: v=2.4 cv=MPFzJeVl c=1 sm=1 tr=0 ts=65949957 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=dEuoMetlWLkA:10 a=XldT38RWNwACPDQzwzUA:9 a=R8vwMfuDAAAA:8 a=OqWOwpgv5ggFgBU2SnsA:9 a=CjuIK1q_8ugA:10 a=mDV3o1hIAAAA:8 a=UZ1dF0cVKI0oLvgvNl8A:9 a=De_Ol2h6w80A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=ics_IjAVWSmO8OVX31YA:9 a=BOg4e644cxQA:10 a=EiJSw4IFYIBf4ttFM9wd:22 a=_FVE-zBwftR9WsbkzFJk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id DF795136; Tue, 2 Jan 2024 15:16:36 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id CE0857A; Tue, 2 Jan 2024 15:16:36 -0800 (PST) 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: Jonathan Chen cc: freebsd-stable@freebsd.org, David Wolfskill , Cy Schubert Subject: Re: sysutils/screen compilation oddities on stable-14 In-reply-to: <99fe4b1a-d0f7-421a-8835-394816832506@chen.org.nz> References: <3611bca4-5157-4d7e-abb6-16a34bac8d99@chen.org.nz> <99fe4b1a-d0f7-421a-8835-394816832506@chen.org.nz> Comments: In-reply-to Jonathan Chen message dated "Wed, 03 Jan 2024 11:56:58 +1300." List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1704237382_35790" Date: Tue, 02 Jan 2024 15:16:36 -0800 Message-Id: <20240102231636.CE0857A@slippy.cwsent.com> X-CMAE-Envelope: MS4xfPQHNnsGO44zsXk+2J/NoJU4E2hrn2pv4Y9JLDopCGkfdZCvqdmcN33kmZc21snzhf28IMzs2bNP7ptOMjwdVvWtCiR0OZ6iBh5hqo3FayAqCq9cvaF/ xJoRXqVcMyF2g8SctKqoE8M5Apl23SiKxRY0c7s7LXyRIWmnixN90AXbuq6MaXtKM2Pim26w555KPKGdP5WO1xxN6hBvdGpq9IZy7w/iM6oior7EBMFI0Ih9 IgWMg1rpkXDnTZbt0pYnWyr12atFx4YKvE1FZcsF/nY= 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:16509, ipnet:3.96.0.0/15, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T4TJ769Mkz3TkW This is a multipart MIME message. --==_Exmh_1704237382_35790 Content-Type: text/plain; charset=us-ascii In message <99fe4b1a-d0f7-421a-8835-394816832506@chen.org.nz>, Jonathan Chen wr ites: > On 1/01/24 19:06, Jonathan Chen wrote: > > Hi, > > > > I'm running a somewhat recent stable-14/amd64 (refreshed 27-Dec-2023), > > and I wonder if someone can explain what is happening... > > > > I've got a dev-host which I use as a repo-builder. I have discovered > > that if I have linux_enable="YES" on the repo-builder, the resultant > > executable from the sysutils/screen package produced will only behave as > > expected on other hosts that also have linux_enable="YES". On hosts > > where linux_enable is *not* defined (ie linux_enable="NO"), `screen' > > will start up and then immediatly quit. There are no core-dumps, or any > > other noticeable error-messages. > > > > If I set linux_enable="NO" on the repo-builder, the executable from the > > sysutils/screen package produced will work as expected on _all_ hosts, > > ie linux_enable=YES|NO. > > After an interesting inspection with ktrace and a look-thru' of > rc.d/linux, I've managed track the cause of this to pty.ko. This module > is loaded with linux_enable=YES, and interferes with the screen package > build. With pty.ko loaded, the screen executable generated will expect > old style pseudo-terminal names; which is not what is available on a > standard STABLE-14 host. > > When pty.ko is _not_ loaded, the screen executable generated will work > on hosts with linux_enable=YES|NO. > > I don't know whether the FreeBSD package builders will be affected, but > this factoid will be useful for the archives. > > Cheers. > -- > Jonathan Chen Can you give the attached patch a try? --==_Exmh_1704237382_35790 Content-Type: text/plain ; name="screen.diff"; charset=us-ascii Content-Description: screen.diff diff --git a/sysutils/screen/Makefile b/sysutils/screen/Makefile index 0ca99d2f6c9a..fe7f443fb75e 100644 --- a/sysutils/screen/Makefile +++ b/sysutils/screen/Makefile @@ -1,5 +1,6 @@ PORTNAME= screen PORTVERSION= 4.9.1 +PORTREVISION= 1 CATEGORIES= sysutils MASTER_SITES= GNU \ ftp://ftp.gnu.org/gnu/screen/ \ diff --git a/sysutils/screen/files/patch-configure.ac b/sysutils/screen/files/patch-configure.ac index 77608dbebb05..9ca352d08b0a 100644 --- a/sysutils/screen/files/patch-configure.ac +++ b/sysutils/screen/files/patch-configure.ac @@ -1,5 +1,5 @@ --- configure.ac.orig 2023-08-15 17:29:26.000000000 -0700 -+++ configure.ac 2023-08-19 07:32:42.246552000 -0700 ++++ configure.ac 2024-01-02 15:13:06.080297000 -0800 @@ -669,7 +669,7 @@ tgetent((char *)0, (char *)0); ],, @@ -9,7 +9,40 @@ AC_CHECKING(libcurses) AC_TRY_LINK([ #include -@@ -900,11 +900,11 @@ +@@ -777,32 +777,6 @@ + [AC_CHECK_LIB(util,openpty, [AC_DEFINE(HAVE_OPENPTY)] [LIBS="$LIBS -lutil"])]) + fi + +-if test "$cross_compiling" = no ; then +-AC_CHECKING(for ptyranges) +-if test -d /dev/ptym ; then +-pdir='/dev/ptym' +-else +-pdir='/dev' +-fi +-dnl SCO uses ptyp%d +-AC_EGREP_CPP(YES_IS_DEFINED, +-[#ifdef M_UNIX +- YES_IS_DEFINED; +-#endif +-], ptys=`echo /dev/ptyp??`, ptys=`echo $pdir/pty??`) +-dnl if test -c /dev/ptyp19; then +-dnl ptys=`echo /dev/ptyp??` +-dnl else +-dnl ptys=`echo $pdir/pty??` +-dnl fi +-if test "$ptys" != "$pdir/pty??" ; then +-p0=`echo $ptys | tr ' ' '\012' | sed -e 's/^.*\(.\).$/\1/g' | sort -u | tr -d '\012'` +-p1=`echo $ptys | tr ' ' '\012' | sed -e 's/^.*\(.\)$/\1/g' | sort -u | tr -d '\012'` +-AC_DEFINE_UNQUOTED(PTYRANGE0,"$p0") +-AC_DEFINE_UNQUOTED(PTYRANGE1,"$p1") +-fi +-fi +- + dnl **** pty mode/group handling **** + dnl + dnl support provided by Luke Mewburn , 931222 +@@ -900,11 +874,11 @@ dnl dnl **** utmp handling **** dnl @@ -23,7 +56,7 @@ #include #define utmp utmpx #else -@@ -917,11 +917,11 @@ +@@ -917,11 +891,11 @@ [int x = DEAD_PROCESS; pututline((struct utmp *)0); getutent();], AC_DEFINE(GETUTENT), olibs="$LIBS" LIBS="$LIBS -lgen" @@ -37,7 +70,7 @@ #include #define utmp utmpx #else -@@ -931,13 +931,13 @@ +@@ -931,13 +905,13 @@ #define pututline _pututline #endif ], --==_Exmh_1704237382_35790 Content-Type: text/plain; charset=us-ascii Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 --==_Exmh_1704237382_35790-- From nobody Wed Jan 3 13:47:31 2024 X-Original-To: freebsd-stable@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 4T4rd82MJ1z55vNT for ; Wed, 3 Jan 2024 13:47:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (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 "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T4rd7344Hz4Kph; Wed, 3 Jan 2024 13:47:39 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.17.1/8.16.1) with ESMTPS id 403DlW8d033984 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Wed, 3 Jan 2024 08:47:33 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:68ce:55e5:bcca:69f5] ([IPv6:2607:f3e0:0:4:68ce:55e5:bcca:69f5]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 403DlVSN090578 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 3 Jan 2024 08:47:31 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <6d0ff65b-0e0f-40c0-b1b7-b1dd22e426d8@sentex.net> Date: Wed, 3 Jan 2024 08:47:31 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD-STABLE Mailing List From: mike tancsa Subject: RELENG_13 kernel breakage Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 64.7.153.18 X-Spamd-Bar: / X-Spamd-Result: default: False [0.50 / 15.00]; NEURAL_SPAM_SHORT(0.89)[0.886]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[mike]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCPT_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; DMARC_NA(0.00)[sentex.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4T4rd7344Hz4Kph Hi,     Both my i386 and amd64 kernels wont build this AM. It seems to be due to https://cgit.freebsd.org/src/commit/?h=stable/13&id=e7044084cf813bfb66cbea8e9278895b26eda5d2 -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- cd /usr/src; TOOLS_PREFIX=/usr/obj/usr/src/amd64.amd64/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/amd64.amd64/tmp  MAKEFLAGS="-m /usr/src/tools/build/mk  -D WITHOUT_CLEAN -m /usr/src/share/mk" make  -f Makefile.inc1  DESTDIR= OBJTOP='/usr/obj/usr/src/amd64.amd64/tmp/obj-kernel-tools' OBJROOT='${OBJTOP}/'  MAKEOBJDIRPREFIX=  BOOTSTRAPPING=1302509 -DNO_CPU_CFLAGS  -DNO_LINT  -DNO_PIC  -DNO_SHARED  MK_CTF=no MK_HTML=no  MK_MAN=no  MK_PROFILE=no  MK_SSP=no  MK_RETPOLINE=no MK_WERROR=no kernel-tools mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/usr mtree -deUW -f /usr/src/etc/mtree/BSD.usr.dist  -p /usr/obj/usr/src/amd64.amd64/tmp/usr >/dev/null -------------------------------------------------------------- >>> stage 3.1: building everything -------------------------------------------------------------- cd /usr/obj/usr/src/amd64.amd64/sys/GENERIC; MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd13.2 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++  -target x86_64-unknown-freebsd13.2 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd13.2 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" AS="as" AR="ar" ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip" INSTALL="install -U" PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin make  -D WITHOUT_CLEAN -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ cc -target x86_64-unknown-freebsd13.2 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common    -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD  -MF.depend.sym_hipd.o -MTsym_hipd.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-error=array-parameter -Wno-error=deprecated-non-prototype -Wno-error=strict-prototypes -Wno-error=unused-but-set-variable -Wno-error=unused-but-set-variable -Wno-format-zero-length -mno-aes -mno-avx  -std=iso9899:1999 -Werror /usr/src/sys/dev/sym/sym_hipd.c /usr/src/sys/dev/sym/sym_hipd.c:5462:13: warning: variable 'dp_sgmin' set but not used [-Wunused-but-set-variable]         int dp_sg, dp_sgmin, resid = 0;                    ^ 1 warning generated. ctfconvert -L VERSION -g sym_hipd.o cc -target x86_64-unknown-freebsd13.2 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common    -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD  -MF.depend.vfs_vnops.o -MTvfs_vnops.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-error=array-parameter -Wno-error=deprecated-non-prototype -Wno-error=strict-prototypes -Wno-error=unused-but-set-variable -Wno-error=unused-but-set-variable -Wno-format-zero-length -mno-aes -mno-avx  -std=iso9899:1999 -Werror /usr/src/sys/kern/vfs_vnops.c /usr/src/sys/kern/vfs_vnops.c:3361:7: error: use of undeclared identifier 'outsize'                     outsize <= *outoffp + (inva.va_size - *inoffp)) {                     ^ 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src 1{build13tor}# From nobody Wed Jan 3 13:55:49 2024 X-Original-To: freebsd-stable@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 4T4rpq2y7hz55wMj for ; Wed, 3 Jan 2024 13:56:03 +0000 (UTC) (envelope-from freebsd@oldach.net) Received: from nuc.oldach.net (hmo.in-vpn.de [IPv6:2001:67c:1407:60::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 "hmo.in-vpn.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T4rpn6c1gz4N18 for ; Wed, 3 Jan 2024 13:56:01 +0000 (UTC) (envelope-from freebsd@oldach.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@oldach.net designates 2001:67c:1407:60::1 as permitted sender) smtp.mailfrom=freebsd@oldach.net Received: from nuc.oldach.net (localhost [127.0.0.1]) by nuc.oldach.net (8.17.2/8.17.2) with ESMTPS id 403DtnBN033682 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 3 Jan 2024 14:55:49 +0100 (CET) (envelope-from freebsd@oldach.net) Received: (from hmo@localhost) by nuc.oldach.net (8.17.2/8.17.2) id 403DtnM1033680; Wed, 3 Jan 2024 14:55:49 +0100 (CET) (envelope-from freebsd@oldach.net) Message-Id: <202401031355.403DtnM1033680@nuc.oldach.net> Subject: Re: RELENG_13 kernel breakage In-Reply-To: <6d0ff65b-0e0f-40c0-b1b7-b1dd22e426d8@sentex.net> from mike tancsa at "3 Jan 2024 08:47:31" To: mike@sentex.net (mike tancsa) Date: Wed, 3 Jan 2024 14:55:49 +0100 (CET) Cc: freebsd-stable@freebsd.org From: freebsd@oldach.net (Helge Oldach) X-No-Archive: Yes List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: inspected by milter-greylist-4.6.4 (nuc.oldach.net [0.0.0.0]); Wed, 03 Jan 2024 14:55:49 +0100 (CET) for IP:127.0.0.1 DOMAIN:localhost HELO:nuc.oldach.net FROM:freebsd@oldach.net RCPT: X-Spamd-Bar: / X-Spamd-Result: default: False [0.68 / 15.00]; NEURAL_SPAM_SHORT(0.98)[0.985]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; ASN(0.00)[asn:29670, ipnet:2001:67c:1400::/45, country:DE]; R_DKIM_NA(0.00)[]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[oldach.net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MISSING_XM_UA(0.00)[] X-Rspamd-Queue-Id: 4T4rpn6c1gz4N18 Hi Mike, mike tancsa wrote on Wed, 03 Jan 2024 14:47:31 +0100 (CET): > Hi, > >     Both my i386 and amd64 kernels wont build this AM. It seems to be > due to > > https://cgit.freebsd.org/src/commit/?h=stable/13&id=e7044084cf813bfb66cbea8e9278895b26eda5d2 Please see PR 276045 Kind regards Helge From nobody Wed Jan 3 15:46:40 2024 X-Original-To: freebsd-stable@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 4T4vGh4861z5685b for ; Wed, 3 Jan 2024 15:46:52 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T4vGh2S3Sz4bTL for ; Wed, 3 Jan 2024 15:46:52 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-28c0d8dd88bso4569991a91.2 for ; Wed, 03 Jan 2024 07:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704296811; x=1704901611; 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=9CbmSmp13meTTTPq5DEWMipoc4NRjOF6pKjeVQrpbSQ=; b=EQIKfCKLgnVc52pQpLhFyJjTmtvvyPddgeSv20HmOtfkUzQDQrFe2E0/vDMLCjcI2j BZxcgPLsv8Sek9wKJuEAC7ad3/ZafMo6xvT8IWXCvt2PRW0KfEOv1ypOPUvWdr8hd8an BsGIq7NMER0t3WNNC0SkHTeuLthF9nbR1h5Z5WxQdHhoO4yu2Gq9IcoHQJEtfOW2GeiR Tx+Ul6fNDZPHvAMOV4XoNmP4VYVrlSQ6GQQeF9Jnf81Bdtyri2BANp6cmhJD4iu579iA Gq2qzbTPAihb5D1UMMng9Gz4OMK8m6wQL0PmT+P1SaTj0WIZybVtAAUFrHKcqxy4jA/L DetA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704296811; x=1704901611; 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=9CbmSmp13meTTTPq5DEWMipoc4NRjOF6pKjeVQrpbSQ=; b=ILB1jauNeimBqJAueOEKkYuP8gIyMTmm+uWEOt76eEDviSZ+cPwCUBhTusddMJd9+Z nXp/6+wNnXQ4rrn6l1cBfSRdIfbR4VCIQfdHEIc1cGGmvNx/TsJy4f/uGOtxWLLcYyN5 wyeUGLQTdkSksUI2bC8WNGr2k4L/oVwMp2MO4MeH/IdApFR+Qc0BNFxKRk97OXhzlvtb x6elrMAbEFVu99AbMFW0+7ircDNDPOFR1USsecEnqq0Sf96ifNGVU/MXgoZk8FSb2xm4 owmX59IAJVaNO6i+8pVqYnyIvlqSbgd0k2aDrYmZAG3MY/7GikjxILNp8LT3j9p/Pvh6 Cbxw== X-Gm-Message-State: AOJu0YzdowvA7ZYVPXjC7izc7PmDQQmlfFC6vksciZcuLMkrNkIw90TJ xSgynsp+NPM7YBWXQbQQFLrk8pnVqhdLOqdzIg== X-Google-Smtp-Source: AGHT+IHoHvFlcCj1JNlX1NqYeG3Op7ZbLmCUUCrn++Ftmhooz4otX8JNfK2pgcuBEr0D5Pgyu30xFk58tJ11etn6dT8= X-Received: by 2002:a17:90a:53e6:b0:28c:4b9:4fcc with SMTP id y93-20020a17090a53e600b0028c04b94fccmr6430758pjh.74.1704296810628; Wed, 03 Jan 2024 07:46:50 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <6d0ff65b-0e0f-40c0-b1b7-b1dd22e426d8@sentex.net> <202401031355.403DtnM1033680@nuc.oldach.net> In-Reply-To: <202401031355.403DtnM1033680@nuc.oldach.net> From: Rick Macklem Date: Wed, 3 Jan 2024 07:46:40 -0800 Message-ID: Subject: Re: RELENG_13 kernel breakage To: Helge Oldach Cc: mike tancsa , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T4vGh2S3Sz4bTL X-Spamd-Bar: ---- 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:2607:f8b0::/32, country:US] Pointy hat goes on me. This should be fixed now, rick On Wed, Jan 3, 2024 at 5:56=E2=80=AFAM Helge Oldach wr= ote: > > Hi Mike, > > mike tancsa wrote on Wed, 03 Jan 2024 14:47:31 +0100 (CET): > > Hi, > > > > Both my i386 and amd64 kernels wont build this AM. It seems to be > > due to > > > > https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3De7044084cf813bf= b66cbea8e9278895b26eda5d2 > > Please see PR 276045 > > Kind regards > Helge > From nobody Wed Jan 3 16:23:52 2024 X-Original-To: freebsd-stable@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 4T4w5Z3pPbz56CTY for ; Wed, 3 Jan 2024 16:24:02 +0000 (UTC) (envelope-from freebsd@oldach.net) Received: from nuc.oldach.net (hmo.in-vpn.de [IPv6:2001:67c:1407:60::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 "hmo.in-vpn.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T4w5Y1R38z4fsx for ; Wed, 3 Jan 2024 16:24:01 +0000 (UTC) (envelope-from freebsd@oldach.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@oldach.net designates 2001:67c:1407:60::1 as permitted sender) smtp.mailfrom=freebsd@oldach.net Received: from nuc.oldach.net (localhost [127.0.0.1]) by nuc.oldach.net (8.17.2/8.17.2) with ESMTPS id 403GNqOO085733 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 3 Jan 2024 17:23:52 +0100 (CET) (envelope-from freebsd@oldach.net) Received: (from hmo@localhost) by nuc.oldach.net (8.17.2/8.17.2) id 403GNq2T085731; Wed, 3 Jan 2024 17:23:52 +0100 (CET) (envelope-from freebsd@oldach.net) Message-Id: <202401031623.403GNq2T085731@nuc.oldach.net> Subject: Re: RELENG_13 kernel breakage In-Reply-To: from Rick Macklem at "3 Jan 2024 07:46:40" To: rick.macklem@gmail.com (Rick Macklem) Date: Wed, 3 Jan 2024 17:23:52 +0100 (CET) Cc: mike@sentex.net, freebsd-stable@freebsd.org From: freebsd@oldach.net (Helge Oldach) X-No-Archive: Yes List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: inspected by milter-greylist-4.6.4 (nuc.oldach.net [0.0.0.0]); Wed, 03 Jan 2024 17:23:52 +0100 (CET) for IP:127.0.0.1 DOMAIN:localhost HELO:nuc.oldach.net FROM:freebsd@oldach.net RCPT: X-Spamd-Bar: / X-Spamd-Result: default: False [0.63 / 15.00]; NEURAL_SPAM_SHORT(0.93)[0.927]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:29670, ipnet:2001:67c:1400::/45, country:DE]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[oldach.net]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4T4w5Y1R38z4fsx Rick Macklem wrote on Wed, 03 Jan 2024 16:46:40 +0100 (CET): > This should be fixed now, rick It does. Thanks for the swift response! Kind regards Helge From nobody Thu Jan 4 23:35:43 2024 X-Original-To: freebsd-stable@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 4T5jrW07nkz55ZWC for ; Thu, 4 Jan 2024 23:45:31 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (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 "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T5jrS193kz4Xsg; Thu, 4 Jan 2024 23:45:28 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=pmc@citylink.dinoex.sub.org; arc=pass ("uucp.dinoex.org:s=M20221114:i=1") Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.0.2/8.17.2) with ESMTPS id 404Nj6CU070060 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Jan 2024 00:45:07 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1704411909; cv=none; b=gla0T+T13yL8E0cSAlxN/5HCthTwPvWdd+gzGEmgVdR9ufdwVuaT/fj7ihPmEhSv7T6p3A35dDsbFjSc/7FJVlwo7MzYERaV2eLcbqt2WjDrn3Ndg/ACPw6ZbzE90RG8ZC5xQsef87j2zK8clFY2OS0jh0utZYsxkftCa7As3FE= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1704411909; c=relaxed/simple; bh=vfD8vmVxHGukZVw6hNAITI3t/ir+RpdOq6n62l/5bsk=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:X-Milter:X-Greylist; b=RVKNKEtPAm+W5Ls7df+yiXzny5gdyG20IeWqzWt5KDFygg7TKnCP/xGH7eoEEQIVS3amN9/L/5+BCyi82PL06WZ6x46mWHfGCd6tWCR3rlhDF96Hj/Z8jN3kqv0/mzrRAvKCw1uSthbZG/+C4jsVK+UvHwm23V/ftPsNCSC/OAg= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.0.2/8.17.2/Submit) with UUCP id 404Nj65s070059; Fri, 5 Jan 2024 00:45:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 404NbsLl079467 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Fri, 5 Jan 2024 00:37:54 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 404NZh3i011601 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Jan 2024 00:35:44 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.17.1/8.17.1/Submit) id 404NZhk9011600; Fri, 5 Jan 2024 00:35:43 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Fri, 5 Jan 2024 00:35:43 +0100 From: Peter To: freebsd-stable@freebsd.org Cc: bapt@freebsd.org, alfix86@gmail.com, asiciliano@freebsd.org Subject: ports-mgmt/portconfig surprize Message-ID: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Fri, 05 Jan 2024 00:45:09 +0100 (CET) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.30 / 15.00]; ARC_ALLOW(-1.00)[uucp.dinoex.org:s=M20221114:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; HAS_XAW(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; DMARC_NA(0.00)[sub.org]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4T5jrS193kz4Xsg Folks, somebody got the idea to replace the dialog4ports options configuring interface by something named 'ports-mgmt/portconfig'. (And they did not even find it worth mentioning this in the UPGRADING file.) Now this one looks terrible, the screen is garbled, and it is quite unintellegible which line is currently entered. See pictures here (old and new): https://forums.freebsd.org/threads/2024q1-portbuild-trouble.91770/post-636816 What is happening: I am starting a shell script. That fires up a bhyve. In the bhyve 'make' is run with stdio connected to the second COM. In the script on the host, bhyve is put in background, 'cu' is started and connected to that second COM. There the dialog appears. Since the script on the host is run from remote, it is run within tmux. Point is: it did work before. disappointed, PMc From nobody Fri Jan 5 00:03:41 2024 X-Original-To: stable@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 4T5kFv1sdkz55cNl for ; Fri, 5 Jan 2024 00:04:03 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T5kFv16Z0z4Zlm for ; Fri, 5 Jan 2024 00:04:03 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704413043; 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=eIPI0MGxiu7wkS3JhtO7UyHe1WxkIaYFiw7G210KJPk=; b=UsbNVkZLqOW1Z6/fAhrCfewws71CxMUzmx6/gdHUKZQACurCszUIod3w+vu9zvA85mU4Pe DeUsrkOapU6Tk0OgTs3vFjZpDwViSWGT7wn3llx7ce4hDUwffuRcffblvvBE6fA3CnAooE Uv3IOF6Xm2/vC2mokrOb5emea1SXLNIvzoc2Z9K+ZTtry6qlpR260tZBuKq4o8pVjrz+ej n6fKvfVPxWWrl6D+nxF/pi8rDHSk8mUcAkKf3EdsMWnzfO5Xc5XIWAl/+8CsphRD7vH0j1 cxVcv4yNkjpuTkfs7y/2m+Kln0bZWb6C6qSPKvmLNl2t7W5GDyf8ffby2KSPXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704413043; 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=eIPI0MGxiu7wkS3JhtO7UyHe1WxkIaYFiw7G210KJPk=; b=Juz7lszWimV/Gkc4IzOYJm/dRp0A8d9horWG3be7vWE5T+TvJ2nn9CI/UYAcqfjiEmMyPO vee9m7cyX5lUtb/n820l1Kqk0jD5g2vB7zsZQWrH1xyo3RC3pWRJD8S0bedeFO49PRnT3q 0HEdMOjtGZeqtyUQzAOFsrYKrKGv4nRTQflWqIHjqpY6Q3yjOeeujutqQTfPbFS21qObKg 5tlbEoKDg7Mf1SocsL+OZ/4blUMwXf2MCZfHTZqQujyJMPpv+deoMvbPkEWvudT89eZxXC 2jGNe2BA5pL5WADnu1sM3dyqFPUmMKEXjsBS9E7xSaz4WgtfrDKnBHtLNmeqoQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704413043; a=rsa-sha256; cv=none; b=s7H5vYsLP6pkzywY5zL0iW2B0/Cm04Ze9PBOfeyo916IP0H8MLEAuRCSH30AbcNMtZYjjM EPQMRTnzZd3baCa6tn563gnmaYpLhdEnt8Gzc8/UDpiDEaih1N0vUBZH6LVmBx1iIsa2HH 0G0YJeoDTiq3VEFnl4AzdNNuYoz6KtodJ1F1S04gK5TxiWOQvkbhV89HYABWqQzmIG0QeK MPKeIQb/C7jUGhlP8SscCAIEKKWoHe7qBn88hp6KbzZ9yqDtIfRFSGsjrRuW2rnAErzDb8 9/rTl1+pXBnILFlE720hrEn5LEIbs4lZ/FFKknpfZgTrFdhiY7R9EdUXJb/eEw== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T5kFt67Jdz1h1r for ; Fri, 5 Jan 2024 00:04:02 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <1e86e122-87dd-4bdc-aeda-3062518bc9b4@FreeBSD.org> Date: Thu, 4 Jan 2024 18:03:41 -0600 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ports-mgmt/portconfig surprize Content-Language: en-US To: stable@freebsd.org References: From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/4/24 17:35, Peter wrote: > Folks, > > somebody got the idea to replace the dialog4ports options > configuring interface by something named 'ports-mgmt/portconfig'. > (And they did not even find it worth mentioning this in the > UPGRADING file.) > > Now this one looks terrible, the screen is garbled, and it is > quite unintellegible which line is currently entered. > See pictures here (old and new): > https://forums.freebsd.org/threads/2024q1-portbuild-trouble.91770/post-636816 > > What is happening: > I am starting a shell script. That fires up a bhyve. In the bhyve 'make' > is run with stdio connected to the second COM. > In the script on the host, bhyve is put in background, 'cu' is started > and connected to that second COM. There the dialog appears. > Since the script on the host is run from remote, it is run within > tmux. > Point is: it did work before. > > disappointed, > PMc > Bug reports are generally more productive than complaining to a largely unrelated mailing list. Thanks, Kyle Evans From nobody Fri Jan 5 15:56:16 2024 X-Original-To: freebsd-stable@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 4T67Nh5XgDz55BTt for ; Fri, 5 Jan 2024 15:56:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.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 4T67Nh3D0Rz4ss0; Fri, 5 Jan 2024 15:56:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id LhI3r6UzYxDxGLmYVrAaLH; Fri, 05 Jan 2024 15:56:19 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id LmYTr6BlVwbmvLmYUrJXbg; Fri, 05 Jan 2024 15:56:19 +0000 X-Authority-Analysis: v=2.4 cv=O6wqATxW c=1 sm=1 tr=0 ts=659826a3 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=gjTRX17sQYlPIeVhgt0A:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 0C1CB2261; Fri, 5 Jan 2024 07:56:17 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 03436679; Fri, 5 Jan 2024 07:56:17 -0800 (PST) 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: Peter cc: freebsd-stable@freebsd.org, bapt@freebsd.org, alfix86@gmail.com, asiciliano@freebsd.org Subject: Re: ports-mgmt/portconfig surprize In-reply-to: References: Comments: In-reply-to Peter message dated "Fri, 05 Jan 2024 00:35:43 +0100." List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jan 2024 07:56:16 -0800 Message-Id: <20240105155617.03436679@slippy.cwsent.com> X-CMAE-Envelope: MS4xfMMC3NKWD+N3/Lm8nBtFtP6zPGGwLll7GDAQly62KMXaa9M+lAjQJo/ck3pusq1HGNxR+rHyB+XQdU1HonMEh4O4aqBFIKdQwOGz69bXp1BQavB72txh MLAWGUNOW4Tk5oqigymPk2Z+ordLvozlLnDPjWurbLQT6XMdSg4WdtwfSs6RQAVtsLBsRkc0XlyGnscquTDrrv+x2kE3F2BHOdl84ArThRe+YhSGwJ7Jv8KR RY7SrGxdLMlpILuXnY9VXj8SoB8BQCE+z3AtCrsr3cch/mq0yvJ2sO6N0Ere7z5HSdurvOODxh2R1rt7l5SfGEMV54F40VYJDRLeb0ISyPA= X-Rspamd-Queue-Id: 4T67Nh3D0Rz4ss0 X-Spamd-Bar: ---- 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:16509, ipnet:3.96.0.0/15, country:US] In message , Peter writes: > Folks, > > somebody got the idea to replace the dialog4ports options > configuring interface by something named 'ports-mgmt/portconfig'. > (And they did not even find it worth mentioning this in the > UPGRADING file.) > > Now this one looks terrible, the screen is garbled, and it is > quite unintellegible which line is currently entered. > See pictures here (old and new): > https://forums.freebsd.org/threads/2024q1-portbuild-trouble.91770/post-636816 > > What is happening: > I am starting a shell script. That fires up a bhyve. In the bhyve 'make' > is run with stdio connected to the second COM. > In the script on the host, bhyve is put in background, 'cu' is started > and connected to that second COM. There the dialog appears. > Since the script on the host is run from remote, it is run within > tmux. > Point is: it did work before. > > disappointed, > PMc > This should have been posted to freebsd-ports@. Next time use the correct ML. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Fri Jan 5 17:28:55 2024 X-Original-To: freebsd-stable@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 4T69Rc6tZ6z55NxV; Fri, 5 Jan 2024 17:29:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T69Rc6Jqjz56Jg; Fri, 5 Jan 2024 17:29:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704475740; h=from:from:reply-to: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=9flr6SSfYF155xUHIMgvwpRLAu/oCTD80kkHszSIMkc=; b=h2Gm9janLRzJPwjOrlkEuARFDT1ogG7HG6C6YzlxYzrX0X8CAJa3Ksx9Ew8EhXmsugg/mi kBnBloPZMjuFI5WxeGTxWydBam4oAyGhgaHueJBzzMVFVLqT+9YTEm7yGwoUzZdW8jzwa9 5kaVu8D3jL1+rpvQmhT8VidBOl7EvwUwad32uEeYu2WBUst3XoXIJGBbIXJ9tQAZdFSx34 Y6gkEGK0he7d0o/Vsmjpk+fgWJPpWAms29sFCUEKGizXZckvFuOHeMizh2ncr5RE7C3v6e dQKEJC8YQgI/LVwdiSYFc01cRuaT7wqJKDYJmIS7l/IGxBC0hDYAYimsTcrSNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704475740; h=from:from:reply-to: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=9flr6SSfYF155xUHIMgvwpRLAu/oCTD80kkHszSIMkc=; b=KbYU3d/Up4oiZMGymCAmitdGBecwsePuKlokgVJR9XD7F0mS8Qu5IyXMqRwDW2OuXgw4mQ +LMm4iSqRcO9clJSkW81f8lIbTFJayMXgFtFUbINyvIMw4/KFvZgnf+WWRFPsoGBxwXnqG 06jEHoZ46Bd0pAQa0fuFdB8CnaM+prUjpQbKLQp6hHEbmVThW7yXxmlU2nrLRfBeaB+XEM 07SgTlf9x2wambSJYnVt7aflQ+T3s/hX3/oiOoQTALo4mw/oJdgwHZO62cxx6/lgosGYy3 5leNeLj4lGJ9wXHQMlrKSiO1GFeTg4EreOm5orQGMzPYHQdhw7unyHypzNffBw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704475740; a=rsa-sha256; cv=none; b=dOvTpHrvAuB/fJgphZgQK7wEEzCMvViAOYTp4Iuo+6sG+cBC9K60IOmoOkZEDII+dVwM19 ayfs8hrDS+/LXz32mQBnEuZKn98UjkwCvrhN/e6uEFy8FsESTJ4HrxcdBHvi+fs8qwr7gD MxRk8XgYnK/cnWmgWLtnZnnX79BnuSK05xf9L8lOMqfKzC6cSql45oOx5J4Z7eLEBbw5Jr Qs6NLIvpjaVnGEr/qOAqHy3kYpNXuby5hOGH7cVDFSP7dKh/aZQOlhkCQXtzhCzCZNsYe4 Qco0tojjjp8UZWZkrb446gAigYtXbi1qA4pNADAKXG4W4sXc5+495sbWo9OWTw== Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (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: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T69Rc4bYtzYZ7; Fri, 5 Jan 2024 17:29:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [IPV6:2001:470:923f:1:8c5d:e3a1:bb4c:7024] (unknown [IPv6:2001:470:923f:1:8c5d:e3a1:bb4c:7024]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 4287E15; Fri, 5 Jan 2024 20:28:56 +0300 (MSK) Message-ID: Date: Fri, 5 Jan 2024 18:28:55 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: freebsd-fs , freebsd-stable , Alexander Motin Content-Language: en-US From: Lev Serebryakov Reply-To: lev@FreeBSD.org Subject: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Organization: FreeBSD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello! I have (remote) physical server with 2 SATA disks. These disks were partitioned with GPT into "freebsd-boot" (ada{0|1}p1, legacy one, not EFI), "freebsd-swap" (ada{0|1}p2) and "freebsd-zfs" (ada{0|1}p3). Both disks were 512/512 (it looks important). I have only one ZFS pool "zroot", mirror of "ada0p3" and "ada1p3". I have very fresh "gptzfsboot" on both "ada0p1" and "ada1p1". Now, ada0 failed. It was replaced by DC support with new disk, which is 512/4096. After that my server fails to boot, gtpzfsboot from second disk (ada1) reports several "zio_read error: 5" and ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool zroot after that. I've booted to rescue Linux (unfortunately, there is NO rescue FreeBSD at Hetzner anymore), and Linux could import (degraded) pool no problem. But Linux has problems with detecting pool on partition, so I don't do nothing under Linux. I've checked "live" disk under Linux, though: it reads, SMART is clear, everything is Ok. I've booted FreeBSD 13.2 from installation ISO under qemu with physical devices as disks. Then I partitioned fresh HDD and started disk replacement in mirror. It worked, but resilver was unbearable slow. I stopped VM with FreeBSD to continue process after normal boot. NO LUCK. "zio_read error: 5", boot failed. Then I've overwrite ada0 (new disk) with FreeBSD memstick IMG and boot it - it can import pool from ada1p3 but, of course, resilver is stopped. I've removed all faulted components, effectivly converting mirror to "simple" device. But "zpool status" shows that there is resilver! And "gptzfsboot" still CAN NOT read this ZFS pool and find loader! Ok, I've converted swap to UFS boot form UFS. It works. It can use pool as root. But pool still is "reslivering". Now I have very strange situation: (1) I have ZFS pool with 1 device which says: % zpool status -v zroot pool: zroot state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Fri Jan 5 19:24:07 2024 750G scanned at 472B/s, 40.5G issued at 25B/s, 974G total 0B resilvered, 4.16% done, no estimated completion time config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 errors: No known data errors % (2) gtpzfsboot from very this system version can not read this pool and bot from it (3) kernel can use this pool as source of root (and all other) filesystems. -- // Lev Serebryakov From nobody Fri Jan 5 23:00:13 2024 X-Original-To: freebsd-stable@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 4T6Jp4571Vz56J83 for ; Fri, 5 Jan 2024 23:00:28 +0000 (UTC) (envelope-from alfix86@gmail.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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T6Jp43CChz4Zxw; Fri, 5 Jan 2024 23:00:28 +0000 (UTC) (envelope-from alfix86@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-28c075ad8e7so88217a91.2; Fri, 05 Jan 2024 15:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704495626; x=1705100426; 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=vNI2CaNw7+S66hItx74u8eEqVHha/229BnCdxSR/lws=; b=BWsCgKc0yY2TS1dpGfm5z1pyOOQ1RJHFkgf9uTNiA+iNpsu22M42+gJGBsVKPF9l/y Z30lqzwibz0ATqqYDwozvMY+AAsp6EcRAM25ASjNqGxuZKm5ASXpXA7HA3b4SpdVLuqn sMsFoX2c0PNxnvp86FBJbDGMWQSJQJSQRwYcRQFKZx/J2gl64SqwqJc0RV0ZwYSTXoyU uxwSMKSiNTOpZnxe/VFbTPRMfvU1Oy67pVhYnWpBTvZB/zu98kjXmBf+eRtqKFbUA4BA OzS5zsIMYskrgtgbCeoHVaCiJ7wk6GKlEClwehBkBvJrXDHBdenibPePHNE3iNU+HJxU ZB+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704495626; x=1705100426; 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=vNI2CaNw7+S66hItx74u8eEqVHha/229BnCdxSR/lws=; b=OrR/oEcIYEsaz4KTjCWiRUQ9vo6AyVZ6v0ahSnBptEyo5K7ZWWG2iGDi1u3uIR351/ xLXK72pqxX/PYm7HzM+D/ns95R2Pdz10x3pDGRaBWn/9LC88SFMBM/dELKq214rev1U8 ht7JysYQndzu9aavnVfDk7zxuLKoTAcZLhIw+8odMf7ryRacnYuIO7YhtbGw6CWUHcvP DodY9OJV4Qg8qkLgevxXffn9QXBGlnMSbGLXJ79nUcr+VRZqXbS0JeYbKCKpq4iUghNy Jxoa/KOrWoDIJ1+X/qiIsvFdx+WpUnEkRYgdeQqkVu1KItBCJAfLhZaZoDqItqKEAH3E ccLQ== X-Gm-Message-State: AOJu0YyU6hx4g0lRPKV63JGjWcojQxSO27F/PpiUT8Lr24g7wWU8l3fP JVgtgx8EK/RJMsQ7jSN4Cecolc16SNyUlvrwqwkNctfA X-Google-Smtp-Source: AGHT+IE8iPs994kpxleKmyJ/w5342z+t8HbYk/kITWOElkUn6jT/somRw7r2SCl8P3DibxTz43YILBxXHa+Ec/Yd2Gs= X-Received: by 2002:a17:90a:9b0a:b0:28d:15a:4c05 with SMTP id f10-20020a17090a9b0a00b0028d015a4c05mr167505pjp.94.1704495626210; Fri, 05 Jan 2024 15:00:26 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alfonso Sabato Siciliano Date: Sat, 6 Jan 2024 00:00:13 +0100 Message-ID: Subject: Re: ports-mgmt/portconfig surprize To: Peter Cc: freebsd-stable@freebsd.org, Baptiste Daroussin , "Alfonso S. Siciliano" Content-Type: multipart/alternative; boundary="000000000000525371060e3ad0d1" X-Rspamd-Queue-Id: 4T6Jp43CChz4Zxw X-Spamd-Bar: ---- 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] --000000000000525371060e3ad0d1 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 5, 2024, 00:45 Peter wrote: > Folks, > > somebody got the idea to replace the dialog4ports options > configuring interface by something named 'ports-mgmt/portconfig'. > (And they did not even find it worth mentioning this in the > UPGRADING file.) > > Now this one looks terrible, the screen is garbled, and it is > quite unintellegible which line is currently entered. > See pictures here (old and new): > > https://forums.freebsd.org/threads/2024q1-portbuild-trouble.91770/post-636816 > > What is happening: > I am starting a shell script. That fires up a bhyve. In the bhyve 'make' > is run with stdio connected to the second COM. > In the script on the host, bhyve is put in background, 'cu' is started > and connected to that second COM. There the dialog appears. > Since the script on the host is run from remote, it is run within > tmux. > Point is: it did work before. > > disappointed, > PMc > Thank you for the report I am in a rural place far from my laptop. I'll investigate the problem on Monday. However you could run: # pkg install dialog4ports and adding DIALOG4PORTS=${LOCALBASE}/bin/dialog4ports to /etc/make.conf you can use the previous utility instead of portconfig to set up ports options via a TUI. Please next time open a new issue to https://gitlab.com/alfix/portconfig to report a problem about portconfig. Alfonso --000000000000525371060e3ad0d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jan 5, 2024, 00:45 Peter <pmc@citylink.dinoex.sub.org> wrote:
Folks,

=C2=A0 somebody got the idea to replace the dialog4ports options
configuring interface by something named 'ports-mgmt/portconfig'. (And they did not even find it worth mentioning this in the
UPGRADING file.)

Now this one looks terrible, the screen is garbled, and it is
quite unintellegible which line is currently entered.
See pictures here (old and new):
https://foru= ms.freebsd.org/threads/2024q1-portbuild-trouble.91770/post-636816

What is happening:
I am starting a shell script. That fires up a bhyve. In the bhyve 'make= '
is run with stdio connected to the second COM.
In the script on the host, bhyve is put in background, 'cu' is star= ted
and connected to that second COM. There the dialog appears.
Since the script on the host is run from remote, it is run within
tmux.
Point is: it did work before.

disappointed,
PMc



Thank you for the report=C2=A0

I am in a rural place far from my laptop.
= I'll investigate the problem on Monday.

However you could run:
# pkg ins= tall dialog4ports
and adding
= DIALOG4PORTS=3D${LOCALBASE}/bin/dialog4ports
to /etc= /make.conf you can use the previous utility instead of portconfig to set up= ports options via a TUI.

Please next time open a new issue to https://gitlab.com/alfix/portconfig to report a problem abo= ut portconfig.

Alfonso

--000000000000525371060e3ad0d1-- From nobody Fri Jan 5 23:05:17 2024 X-Original-To: freebsd-stable@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 4T6K0J3f4Wz56KBP for ; Fri, 5 Jan 2024 23:09:20 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (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 "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T6K0J2Cgvz4ctw; Fri, 5 Jan 2024 23:09:20 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.0.2/8.17.2) with ESMTPS id 405N951X087184 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jan 2024 00:09:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1704496148; cv=none; b=L+cWNSkTYvoBMUAWyefc0efRkUzMNLV1+SCG2ZDNT844BEmq6zre/m/MgUXlrID1z+Wnum7xSXrmk+0Kq8Cjj9ZnndtZIYnrIZj8kLFkXf7wFztfAqLIx2KQKsKCZITzWIDyWdi+Gzhom9bf9Dr1piReU79gBVUNGzu573a1qO8= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1704496148; c=relaxed/simple; bh=HQejeDDwgxdp68fcZ9kbse/PLJTOdSDf9CJqIx/2464=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:X-Milter:X-Greylist; b=VafE9ZPMi0wrqTTXLOwdji3MtFaLent6/zdFKTwJM17avtoX+Vvmb25zBP0IsHaNuf4DXYLDHU1F9J17Uoc++fCbRG0v8BVBy0tpOGspeN3GNeHoymVDZWfzFs93TRDrWAmyPtQ5PriWifxHeEPDzqVXB40r3X3ugrge3CSC7pk= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.0.2/8.17.2/Submit) with UUCP id 405N95ex087183; Sat, 6 Jan 2024 00:09:05 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 405N8H9N057736 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Sat, 6 Jan 2024 00:08:17 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 405N5H6W006782 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jan 2024 00:05:17 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.17.1/8.17.1/Submit) id 405N5H38006781; Sat, 6 Jan 2024 00:05:17 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Sat, 6 Jan 2024 00:05:17 +0100 From: Peter To: Cy Schubert Cc: freebsd-stable@freebsd.org, bapt@freebsd.org, alfix86@gmail.com, asiciliano@freebsd.org Subject: Re: ports-mgmt/portconfig surprize Message-ID: References: <20240105155617.03436679@slippy.cwsent.com> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240105155617.03436679@slippy.cwsent.com> X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Sat, 06 Jan 2024 00:09:08 +0100 (CET) X-Rspamd-Queue-Id: 4T6K0J2Cgvz4ctw X-Spamd-Bar: ---- 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:205376, ipnet:2a0b:f840::/32, country:DE] On Fri, Jan 05, 2024 at 07:56:16AM -0800, Cy Schubert wrote: ! ! This should have been posted to freebsd-ports@. Next time use the correct ! ML. Hi, I was thinking -ports is for malfunctioning individual ports. Whereas the matter at hand is about general infrastructure (every server needs some ports) and deploy. I currently have no idea where to find the people interested in that, but the port options setting being unconditionally interactive is a conflict with any automated deploy. I always have to hack and refactor this - and that new tool doesn't improve anything (in that regard), it just adds some malfunction (and forces me to understand the new code). But okay, when I'm in a relaxed mood again I will try and do a writeup of the issue and send it to -ports. Let's see if anybody there is interested... cheers, PMc From nobody Fri Jan 5 23:21:01 2024 X-Original-To: freebsd-stable@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 4T6KFs593kz56M6L for ; Fri, 5 Jan 2024 23:21:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.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 4T6KFs2SCzz4fnC; Fri, 5 Jan 2024 23:21:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id LpHJr6rixxDxGLtUurC3Ae; Fri, 05 Jan 2024 23:21:04 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id LtUsruuad0nMNLtUtrHgIJ; Fri, 05 Jan 2024 23:21:04 +0000 X-Authority-Analysis: v=2.4 cv=Qcx1A+Xv c=1 sm=1 tr=0 ts=65988ee0 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=EntaZpDbBpCAXUEWyd0A:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id CA88030C; Fri, 5 Jan 2024 15:21:01 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 79B3F1A2; Fri, 5 Jan 2024 15:21:01 -0800 (PST) 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: Peter cc: Cy Schubert , freebsd-stable@freebsd.org, bapt@freebsd.org, alfix86@gmail.com, asiciliano@freebsd.org Subject: Re: ports-mgmt/portconfig surprize In-reply-to: References: <20240105155617.03436679@slippy.cwsent.com> Comments: In-reply-to Peter message dated "Sat, 06 Jan 2024 00:05:17 +0100." List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jan 2024 15:21:01 -0800 Message-Id: <20240105232101.79B3F1A2@slippy.cwsent.com> X-CMAE-Envelope: MS4xfK/0VTQUPF9yZqWvQAfESfrJxiW5/Z95td0GNo3i5dpDOknM5qCOmW2R3MsKuI3lHj6SXVo7KclwHdpQfGwB1gusKo24p361n0Y2yMmo6oP54jHd8Olc ziXEGCaX2/q2cCNDreCkyfUH5XqVV/PnChOPtCDpi1UH72wVpgzjRVpHscWZtqAoYqiSNaTb3qSXmkFdAKSBQ9NUHDwL54y8XbDXjRINlr5E8qVmRmzG73zi Qui9jQtA5gbogBK+5o4dt6TT9bsmH52ZZPS5oTjUjK59q5OqrOf7Ljxe+Tp+PwMIAi1xiQkGZjJTwNICPjkN0z2i3D0Na2GiyEt9yJr2oFA= X-Rspamd-Queue-Id: 4T6KFs2SCzz4fnC X-Spamd-Bar: ---- 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:16509, ipnet:3.96.0.0/15, country:US] In message , Peter writes: > On Fri, Jan 05, 2024 at 07:56:16AM -0800, Cy Schubert wrote: > ! > ! This should have been posted to freebsd-ports@. Next time use the correct > ! ML. > > Hi, > > I was thinking -ports is for malfunctioning individual ports. > Whereas the matter at hand is about general infrastructure (every server > needs some ports) and deploy. > > I currently have no idea where to find the people interested in that, > but the port options setting being unconditionally interactive > is a conflict with any automated deploy. I always have to hack and > refactor this - and that new tool doesn't improve anything (in that > regard), it just adds some malfunction (and forces me to understand > the new code). > > But okay, when I'm in a relaxed mood again I will try and do a writeup > of the issue and send it to -ports. Let's see if anybody there is > interested... > > cheers, > PMc portconfig and dialog4ports are not part of FreeBSD base. Both ports and it is the ports infrastructure, in /usr/ports/Mk, that calls them. Complaining about them on -current or -stable is a waste of everyone's time and will fall on deaf ears. portmgr made the decision to deprecate dialog4ports on Tue Oct 10 13:53:44 2023 (in /usr/ports/Scripts/dialog4ports.sh). If you have concerns about it, that's the forum to discuss it, or a PR. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Fri Jan 5 23:40:03 2024 X-Original-To: freebsd-stable@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 4T6Knm6DpLz56PtW for ; Fri, 5 Jan 2024 23:45:16 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (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 "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T6Knm4Tslz4kZk; Fri, 5 Jan 2024 23:45:16 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.0.2/8.17.2) with ESMTPS id 405Nj5DE013793 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jan 2024 00:45:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1704498308; cv=none; b=bSiV7I5CrXjaeXIqWiIbmT8kL1ofE1THoy2o/x6u3X0eYmvnFgXqGjGpvdgrGM3AHI+5tXgeXttC4n0sw2fmoeEYMuFFtLZXNoEh6PCYAPxv46ZVlurzOc40Y/GFO7v3XCfETMV1AGC4QVEQTLpCiPk3H1LfhCNXzJTLa57LOwc= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1704498308; c=relaxed/simple; bh=DhDOW2ZuDB248BsTDtDm4Wn8hv4dyp8X8EFxCY4xr1I=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:X-Milter:X-Greylist; b=DCdDRcmmerrkx4F4g/PGTIMWNIIQOnujPljva6XjwkIk34Bkcke+Xvl9XZIMWW7XLLGupnU2dKWEmzD6ymzgW5oZvwM/FW380N4BYZTl8gD03pRFQgZwqtJLZu14YEuEEuwELKMiRXQmsel7WHDKQd0OWw6tZn/i7/6a1oVn9OI= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.0.2/8.17.2/Submit) with UUCP id 405Nj56P013792; Sat, 6 Jan 2024 00:45:05 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 405NfI3B082119 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Sat, 6 Jan 2024 00:41:18 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 405Ne37l007008 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jan 2024 00:40:03 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.17.1/8.17.1/Submit) id 405Ne3Co007007; Sat, 6 Jan 2024 00:40:03 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Sat, 6 Jan 2024 00:40:03 +0100 From: Peter To: Alfonso Sabato Siciliano Cc: freebsd-stable@freebsd.org, Baptiste Daroussin , "Alfonso S. Siciliano" Subject: Re: ports-mgmt/portconfig surprize Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Sat, 06 Jan 2024 00:45:08 +0100 (CET) X-Rspamd-Queue-Id: 4T6Knm4Tslz4kZk X-Spamd-Bar: ---- 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:205376, ipnet:2a0b:f840::/32, country:DE] On Sat, Jan 06, 2024 at 12:00:13AM +0100, Alfonso Sabato Siciliano wrote: ! Thank you for the report ! ! I am in a rural place far from my laptop. ! I'll investigate the problem on Monday. Hi, thank You very much for reporting back! Take Your time, relax, enjoy the country; this is not an issue of hurry. So let's find a place where we collect the info, next week. ! However you could run: ! # pkg install dialog4ports ! and adding ! DIALOG4PORTS=${LOCALBASE}/bin/dialog4ports ! to /etc/make.conf you can use the previous utility instead of portconfig to ! set up ports options via a TUI. Thank You, that is fine - but then, I have to adapt my deploy system to the new tooling, anyway, sooner or later. (This is an automated system that provides for OS updates, images and pkgs in an integrated fashion.) ! Please next time open a new issue to https://gitlab.com/alfix/portconfig to ! report a problem about portconfig. Lucky You, I'm actually a customer of that company and therefore allowed to login and participate. cheerio, PMc From nobody Sat Jan 6 07:06:41 2024 X-Original-To: freebsd-stable@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 4T6Wbq1K3nz55fTC for ; Sat, 6 Jan 2024 07:07:19 +0000 (UTC) (envelope-from freebsd@oldach.net) Received: from nuc.oldach.net (hmo.in-vpn.de [IPv6:2001:67c:1407:60::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 "hmo.in-vpn.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T6Wbn65N5z4YHW; Sat, 6 Jan 2024 07:07:17 +0000 (UTC) (envelope-from freebsd@oldach.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@oldach.net designates 2001:67c:1407:60::1 as permitted sender) smtp.mailfrom=freebsd@oldach.net Received: from nuc.oldach.net (localhost [127.0.0.1]) by nuc.oldach.net (8.17.2/8.17.2) with ESMTPS id 40676gFD057547 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jan 2024 08:06:42 +0100 (CET) (envelope-from freebsd@oldach.net) Received: (from hmo@localhost) by nuc.oldach.net (8.17.2/8.17.2) id 40676fN6057546; Sat, 6 Jan 2024 08:06:41 +0100 (CET) (envelope-from freebsd@oldach.net) Message-Id: <202401060706.40676fN6057546@nuc.oldach.net> Subject: Re: ports-mgmt/portconfig surprize In-Reply-To: from Peter at "5 Jan 2024 00:35:43" To: pmc@citylink.dinoex.sub.org (Peter) Date: Sat, 6 Jan 2024 08:06:41 +0100 (CET) Cc: freebsd-stable@freebsd.org, bapt@freebsd.org, alfix86@gmail.com, asiciliano@freebsd.org From: freebsd@oldach.net (Helge Oldach) X-No-Archive: Yes List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: inspected by milter-greylist-4.6.4 (nuc.oldach.net [0.0.0.0]); Sat, 06 Jan 2024 08:06:42 +0100 (CET) for IP:127.0.0.1 DOMAIN:localhost HELO:nuc.oldach.net FROM:freebsd@oldach.net RCPT: 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.996]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; ARC_NA(0.00)[]; ASN(0.00)[asn:29670, ipnet:2001:67c:1400::/45, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[oldach.net]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4T6Wbn65N5z4YHW Peter wrote on Fri, 05 Jan 2024 00:35:43 +0100 (CET): > Folks, > > somebody got the idea to replace the dialog4ports options > configuring interface by something named 'ports-mgmt/portconfig'. > (And they did not even find it worth mentioning this in the > UPGRADING file.) > > Now this one looks terrible, the screen is garbled, and it is > quite unintellegible which line is currently entered. > See pictures here (old and new): > https://forums.freebsd.org/threads/2024q1-portbuild-trouble.91770/post-636816 > > What is happening: > I am starting a shell script. That fires up a bhyve. In the bhyve 'make' > is run with stdio connected to the second COM. > In the script on the host, bhyve is put in background, 'cu' is started > and connected to that second COM. There the dialog appears. > Since the script on the host is run from remote, it is run within > tmux. > Point is: it did work before. I suspect that this has to do with the fact that Mk/Scripts/dialog4ports.sh *enforces* the C.UTF-8 locale even if the terminal doesn't support it well, or not at all. (Note that also your first screenshot shows artifacts left to the '[' character.) That is PR 275364? Kind regards Helge From nobody Sat Jan 6 12:02:26 2024 X-Original-To: freebsd-stable@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 4T6f8m08kkz56841 for ; Sat, 6 Jan 2024 12:02:48 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from mail.punkt.de (mail.punkt.de [217.29.41.227]) (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 4T6f8l18BFz46lV for ; Sat, 6 Jan 2024 12:02:47 +0000 (UTC) (envelope-from hausen@punkt.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 217.29.41.227 as permitted sender) smtp.mailfrom=hausen@punkt.de Received: from smtpclient.apple (unknown [IPv6:2003:a:d59:3800:d560:1b09:a6af:fc15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.punkt.de (Postfix) with ESMTPSA id 76B2A6F768; Sat, 6 Jan 2024 13:02:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: Odd values for various memory metrics via SNMP From: "Patrick M. Hausen" In-Reply-To: <25996.34932.339497.605798@hergotha.csail.mit.edu> Date: Sat, 6 Jan 2024 13:02:26 +0100 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <1EDAF2AC-3A2B-43BE-B66B-E095F5A80C2C@punkt.de> <84B7C7D7-BC06-4944-A7E0-5AFC47B6BC0E@punkt.de> <8f4cf72e-8320-4bfd-a4d9-3db34db4580d@aetern.org> <25996.34932.339497.605798@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.77 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.992]; NEURAL_HAM_SHORT(-0.98)[-0.982]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:217.29.32.0/20]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[punkt.de]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4T6f8l18BFz46lV Hi all, > Am 27.12.2023 um 21:26 schrieb Garrett Wollman = : >=20 > < said: >=20 >> Now only "virtual memory" is left - according to the book that should = be >> the sum of physical memory and swap space - and for my single Linux >> host it is. >=20 >> For the FreeBSD systems this is the one left that still looks = nonsensical. >=20 >> OPNsense (8G RAM, 8G swap): 4.91 of 4.99G used. >> TrueNAS (64G RAM, 32G swap): 627 of 628G used. >> TrueNAS 2 (32G RAM, 32G swap): 512 of 516G used. >=20 > This is computed by the function vmtotal() in sys/vm/vm_meter.c. It > walks all VM objects in the system, skipping those that are > unreferenced, and adds up all of their sizes. There is one VM object > for every open file and every running executable, shared library, and > mmap()ed region, plus one for every copy-on-write mapping for each > process that has modified it, which includes the data segment of every > executable and shared library. This has no connection to either > physical memory or swap space. Why does FreeBSD calculate the values this way while MWL's book clearly states differently? Who's wrong here? Browsing the host resources MIB I can only find the syntactical = definition of the hrStorage subtree but nowhere was I able to find a definitive = documentation on the semantics what certain entries like "virtual memory" are supposed = to mean? I'll go ask MWL where he got what he wrote in his book, but I'm still = confused. There must be some standard for meaningful values, right? Kind regards, Patrick --=20 punkt.de GmbH Patrick M. Hausen .infrastructure Sophienstr. 187 76185 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de info@punkt.de AG Mannheim 108285 Gesch=C3=A4ftsf=C3=BChrer: Daniel Lienert, Fabian Stein From nobody Sun Jan 7 14:49:56 2024 X-Original-To: freebsd-stable@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 4T7KqD32d4z578pB; Sun, 7 Jan 2024 14:50:00 +0000 (UTC) (envelope-from lev@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7KqD2Wztz4pdX; Sun, 7 Jan 2024 14:50:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704639000; h=from:from:reply-to: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=gYfVJWNu+kitpVo9SMKxn+PcNuADexH3WNKXqEykXFo=; b=VpKj1zOhiFFPHvBCDFs5v4aVcGhXH6RCi19v/7NmvIz6lwrEu6GQmXSRuIVMvx3mhzVjMD 2EKAYn1sC8wiTWAX99ZFBVk6jFHKwJacu/D7LHN5jsD5QfEnnh0X+0aiM6jAhQCXUejXp+ 3GXRStIFmpmPEMzIbrlPtHvvu2oef2sklvgH3VHXYrefmRA2wFV6pM6rQ09sps/39LfUCy U5ll2YrZL2rPuLw9VC+4wm2s8tafmYyCEM1WsbbLGBQgZaVM44GsHulynsM4Ws+b6sYzN6 N5EWktwoj7d/F6nFDEJ/jgCe8AqUgUw2qt34xEz1H3bIshsWKCOg0E3TW3Zl2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704639000; h=from:from:reply-to: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=gYfVJWNu+kitpVo9SMKxn+PcNuADexH3WNKXqEykXFo=; b=gpotw3RbJew7sOentpih9HyrQADRJmGat650wnda3L3Xt2JupTUoHWBWRrJuGeOIlNgl+7 6vZqLWsVYAbTKPcy42NGGzjwRLKvXbnV3ryXHR5zT/P1V3cYUcSYA7xtcSyL7+jHr/JJ5L dFNqW8ugDkgl7zs3MBGcVDCTPRTCvIcKXtYe1io+rEEKvR5chcf+9rF+Ys1E40YIARmTp2 zxP4+McajxnE3fBfK/51lnFwcgPXBBab/QoaDs+3Ak44KTBGkHCKGPMmPaU+MlBjBjQW69 EVFLzjEsXegKL0zV3x3OLQDL3LyOGTvZ6l5eWK8f/CVxc2imsKMXrFOFXDJmUA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704639000; a=rsa-sha256; cv=none; b=UHNdG9v3tUDqzM+LKJW39onk/jgYrdWPHhopwjDxxnDGU23kNLn7PHcjg7mk5P9vCnqvnu Ibw2ZsFGQl4id1IqOmPhpEiOIvkL/mAMWkr+uLhuzmijbX+N6hcW7JLeEz0jV3+8/xJD/X 9exX1edPdSJFJLRIDE/HBYxiVz+OyqkoLPI6bn/0ZxrRdGi342PLEJDyLwuI4lpY9JmITf pvMx7Rq2WjCDNqbqyAW3fBae+vyhyHtU1I6JyIlNK+iarqZagyxCx+1ODcVDsJDEqAPVvt z6vr77dUV7B9a5MJgruWsp2EDOhg23qXYC46263Etymzas6MNAmH4xYe8f+8gw== Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.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 did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7KqD0pMbzSQM; Sun, 7 Jan 2024 14:50:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [IPV6:2001:470:923f:1:795b:6f6e:6bbc:d02c] (unknown [IPv6:2001:470:923f:1:795b:6f6e:6bbc:d02c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 20BAA50; Sun, 7 Jan 2024 17:49:57 +0300 (MSK) Message-ID: Date: Sun, 7 Jan 2024 15:49:56 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US From: Lev Serebryakov To: freebsd-fs , freebsd-stable , Alexander Motin Reply-To: lev@FreeBSD.org, lev@FreeBSD.org References: Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 05.01.2024 18:28, Lev Serebryakov wrote: >    After that my server fails to boot, gtpzfsboot from second disk (ada1) reports several "zio_read error: 5" and > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zroot > >    after that. I've re-created pool from scratch zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroot && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3 but gptzfsboot still can not boot from it with same diagnostics :-( -- // Lev Serebryakov From nobody Sun Jan 7 14:51:35 2024 X-Original-To: stable@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 4T7KsC5QqBz5792C for ; Sun, 7 Jan 2024 14:51:43 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4T7KsB5D7vz4r6t for ; Sun, 7 Jan 2024 14:51:42 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (096-033-195-197.res.spectrum.com [96.33.195.197]) by colo1.denninger.net (Postfix) with ESMTP id A363C2110CF for ; Sun, 7 Jan 2024 09:51:47 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id B99513B1443 for ; Sun, 7 Jan 2024 09:51:35 -0500 (EST) Message-ID: <11878eab-a60e-4d5c-8eef-b9a87c73dfc5@denninger.net> Date: Sun, 7 Jan 2024 09:51:35 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US To: stable@freebsd.org References: From: Karl Denninger In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040504040301020006080308" X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.89 / 15.00]; SIGNED_SMIME(-2.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)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[karl]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4T7KsB5D7vz4r6t This is a cryptographically signed message in MIME format. --------------ms040504040301020006080308 Content-Type: multipart/alternative; boundary="------------VNCAIOy90YegVwEwiwRwXJSo" --------------VNCAIOy90YegVwEwiwRwXJSo Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/7/2024 09:49, Lev Serebryakov wrote: > On 05.01.2024 18:28, Lev Serebryakov wrote: > >>     After that my server fails to boot, gtpzfsboot from second disk >> (ada1) reports several "zio_read error: 5" and >> >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read MOS of pool zroot >> >>     after that. >  I've re-created pool from scratch > >  zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroot > && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3 > >  but gptzfsboot still can not boot from it with same diagnostics :-( > Are you SURE gptzfsboot is up to date on that second drive? If its older that can definitely happen. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------VNCAIOy90YegVwEwiwRwXJSo Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/7/2024 09:49, Lev Serebryakov wrote:
On 05.01.2024 18:28, Lev Serebryakov wrote:

    After that my server fails to boot, gtpzfsboot from second disk (ada1) reports several "zio_read error: 5" and

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot

    after that.
 I've re-created pool from scratch

 zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroot && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3

 but gptzfsboot still can not boot from it with same diagnostics :-(

Are you SURE gptzfsboot is up to date on that second drive?

If its older that can definitely happen.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------VNCAIOy90YegVwEwiwRwXJSo-- --------------ms040504040301020006080308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yNDAxMDcxNDUxMzVaME8GCSqGSIb3DQEJBDFCBECbFV5rSB8BozXlDyxQ x1LkvpJpFvDc3W6T5lVHvkUPGSdVr6JY99KeZAEi9+Y/34s3y+uyzvn7383LMusE1A8FMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgBdymsYyaliSIBi1lyNhWR/pABoAoOWonJKthrP mKJ3MfnMAbr24+KBKGAk7vCjOc5GrSxGKgL29VqAZVjEBijfns0MN1yQg+trK/tRFWk/FzJE eu5TXW9yF9I7NBa5xgniDV9qd6MHhGZ9CpMrdyrTNwNgA5i8C8Bw4aWmL80em54ntvakGpbw jx9L5CBKz6JLjSKDsnlIDVJ4QZGG2xHUKZ0vY7B1k0cudZlrENQyElVAbw6YO7Cxe7t7Udwi 8ypvxNnNBYQE66LZhUPBF39BbvKHZ52PclTPeCaYjEapal26TuAJ9q/Zuwuxtr6XXO/qgHSx Yz2ft3vXprCZkNqw26cM5Gy22LDRhHBQiqMBfiZJgXELN9uE8E9JqbUEzWOnYvqWV84KuVxK ej82qQLWm/nyZAaAAGg+jmIT+zbK5ylG9VgOJxSZJfhYVDHpBaUUhWjCIQx31uPfFhhmyjs3 0PmF4xP/SeAGtDvCewGuKxJa5tQQ1oBuPs90tqDKlPV4V++goB0+5EmOP+RDpATqXUhKOqN0 dja+prgv77s1yPNDas0tmBqD+WLXDLFkAqytSB6ePD7bwT3Chaq6sg8sFpA36ripjZNdzlNu gfmsA6E07XxyUQM/6gZ33N0UwPiXdxhpssRT+nhO0/vfL0zIpICW0jwvwAn4CIeP3NcWbQAA AAAAAA== --------------ms040504040301020006080308-- From nobody Sun Jan 7 14:56:27 2024 X-Original-To: freebsd-stable@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 4T7Kyl0ZG5z579w0 for ; Sun, 7 Jan 2024 14:56:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7Kyk6n1bz4sdP for ; Sun, 7 Jan 2024 14:56:30 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704639390; h=from:from:reply-to: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=/PHfAwHqHh7Ja3wxtjF55rutUuu6a0KoeQJJnFzTL4g=; b=QIZmz0+9hbpi5b4oxH9ZwbM08rnDkDZkbFPDxJToJ+yDzBZ6nTIZzNczd/F1kqWzPiH6hk iEE3JPFw3OVPj4QCTeOZe+bzcSLjseTn2eOOHRY3PSaMwCDIFWNlnxW+LnU9MUFjTMmguQ 7LPMpiEf3vEZA8EF1sv0ssHMuIcIWbp77cngF1hqPdN9h94UhsccKFW6PHgCYJ8RjxhrYm 2RQYuRF4WSM5xN3fxyBB+1o1Yk9V8gTqwKdG9Qp0CIUhFBsYNUaiYopAKubSCSSuwY4XMN GINKPEZo6Mt/VE4WzNMGeMSF3+SjPVXQMSZgmBpKx8NcAQaSTpLT+q0aCwNCVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704639390; h=from:from:reply-to: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=/PHfAwHqHh7Ja3wxtjF55rutUuu6a0KoeQJJnFzTL4g=; b=oQmhkv5AN8SUvgF7qOWsNN+bsrhLBIDuH/30u3RdDfqAddmpNTtcXyabJkIrlnkfod6T1t VNWPJGMBq5fbNMlkHtJlKxaYjWVbMEKMEdPivSldO6QhLDwGp/09Qa8CFIqnX0qIW+Ri6L wn1ir8RsQhsQb6fVFVgGo1pMfCzCZ1CKoueVIy4KeJ2N5BTQPyL4M9DY0uui6xlljjFoMq JyNnei2xzdekYSmmch7gxg8rfkfq7/6usUHHvZN8Do54UWfzbGU4JswXqOPqCb7ZHt0Mpt 9nD5iDh2NUUvWHFfRhnw0Ed9iQh/9dEK3QBAN0aePPM4rbsNif9ZLILlq61/Dw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704639390; a=rsa-sha256; cv=none; b=o1wrVteQUMV2ksgmC5DBbtV7/M56/yLLTG0ThLTpMvGpT8HGijmcA6EsE2/slc5nZyvL11 CtRyQkW7At4WzeIkV+kt2CPCFiEaP4LlX2fxlVwz1YlENmfMhU1SqGcrL7THxy519AuRmU uvTSpwkNrggrVK2aXUQly22CiDaO3vsGJ4yqoYuWY03nBxYvnAwbILdBm9qtN5Y5XJBnOV orL0/f5onhzy2qPYq15D8tdVkcQjtwMCqCvQgkpnse+UKJwosoZYFpOJVNC5EPAB3MEca5 1ncqWx4zwnOvP1Iv7LEEhoreGYw562W9YV29dZElel4lXb/1yYdH9T0Byz6VQw== Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (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: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7Kyk58TKzSH5 for ; Sun, 7 Jan 2024 14:56:30 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [IPV6:2001:470:923f:1:795b:6f6e:6bbc:d02c] (unknown [IPv6:2001:470:923f:1:795b:6f6e:6bbc:d02c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id DFAD3199 for ; Sun, 7 Jan 2024 17:56:27 +0300 (MSK) Message-ID: <3a87b24a-35aa-4a7d-9f49-1947d5b21adf@FreeBSD.org> Date: Sun, 7 Jan 2024 15:56:27 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: freebsd-stable Content-Language: en-US From: Lev Serebryakov Reply-To: lev@FreeBSD.org Subject: devfs_set_rulesets="path=devfsrules_hide_all path=devfsrules_unhide_basic" doesn't work after upgrade from 12-STABLE to 13-STABLE Organization: FreeBSD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello! I've upgraded server from 12-STABLE to 13-STABLE. This sever has several limited devfses for chrooted software. These devfses are configured in /etc/fstab and are limited via devfs_set_rulesets="" devfs_set_rulesets="${devfs_set_rulesets} /path1/dev=devfsrules_hide_all /path1/dev=devfsrules_unhide_basic" devfs_set_rulesets="${devfs_set_rulesets} /path2/dev=devfsrules_hide_all /path2/dev=devfsrules_unhide_basic" And now I get these errors on boot: devfs rule: ioctl DEVFSIO_SUSE: Inappropriate ioctl for device ... devfs rule: ioctl DEVFSIO_SAPPLY: Inappropriate ioctl for device ... and nothing is hidden. I've read /usr/src/UPDATING and can find nothing about devfs -- // Lev Serebryakov From nobody Sun Jan 7 15:04:36 2024 X-Original-To: stable@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 4T7L876sWmz57BNf for ; Sun, 7 Jan 2024 15:04:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7L876Hjwz4tj6; Sun, 7 Jan 2024 15:04:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704639879; h=from:from:reply-to: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=pr+GvXPfwT1f5YnvdMGwMSjSB/QoWjWxRi7spPr6M7c=; b=sD6fmblpy9JlvPdLXuY0COsk00hnelleGnjW3tyOEoimjCIAPWGmB3NC+TlrmTFPYg9W7g TaQiHeu6t/LJylF0re+91XA5GnnQXoxX+1qBaiYuEPwenmopJxIyjrkmKkwPw6M32ELB15 kzrnMUIQQimlsfbFJmh0sMwT3SvL7OxEpz74f5wWgS9u9zhraxdrDYx+ZfWg1qvHu7gcFr i7YhL/MleeFAYLZwU+4gayDGd/HSpHenrpRsoY8kohqBDnutXlHYaMH69VQyBFQxw0X4Dj LmPC98z5KJlO11BJV0FJBCGjYoulYbE0RSVJkKNIJpJJir4bWhREyKkZzZ3uZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704639879; h=from:from:reply-to: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=pr+GvXPfwT1f5YnvdMGwMSjSB/QoWjWxRi7spPr6M7c=; b=ASz7aPT4PdWQ9YE5B72N9KodQ0ZT/hDo00v4aAJXM2Es8ptEthNEcQJOO1c56tO7vVpI1C IVNA9hLpfFSxMmSWkbs8RhRzFhShiLIkpQCWCVo+q3rKF/I77aCp0VFAIrnjbbYerWBvgX bITVYXCgQ3RsVRvJagCajAnpFM3ydxJaUulO9mOseGoZ8FxfoeEqTnpVJiRPmfBZ65aRY9 JmkvlobJKdtVQ73mpKxqxd9Xvwd0zskqXlwWlmz1f6CvzqzYsxXHWbbXbHd39HUalbhj33 zifB8bRW7GIY/oAPz/iZJCF90cxOF3+GpHCDTiOLxs3EBUVWSPbi3xaocRLoRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704639879; a=rsa-sha256; cv=none; b=jdQUjAslKTEhkQtwkoNfC3I1NhCuXvQhKpDzZMhyrywJuNw4igKcE4QnmHU3JTl+Y0svB/ uAHhpzq/FDvbZi5q4OBKVnj8RIALc2COJh16tlJ4LHuU0GZczIM+zccW03XuEsjYuK75fG 5aSmIWGabJQ73TFEU+yNWkpLgVmK39e//TgNJ+dgViEC8xWC+iDATisCoU9+QsZMutNfaR 77H72GBbKv1Ci8rb/AwUwYTabAqV+XvxPzx7iDgXbbOU3zrOwrr6oorhiYap1TwQFCyFcD 84hwKeon7h/YVbigT2qPUXd4k7Yy5wuhnG6SBfKWoO9usjW4482Nkx1cK00Czw== Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.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 did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7L874TsWzSRk; Sun, 7 Jan 2024 15:04:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [IPV6:2001:470:923f:1:795b:6f6e:6bbc:d02c] (unknown [IPv6:2001:470:923f:1:795b:6f6e:6bbc:d02c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 5D8EC294; Sun, 7 Jan 2024 18:04:37 +0300 (MSK) Message-ID: <68958573-e2cf-4af2-9f32-0fb25809169a@FreeBSD.org> Date: Sun, 7 Jan 2024 16:04:36 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US To: Karl Denninger , stable@freebsd.org References: <11878eab-a60e-4d5c-8eef-b9a87c73dfc5@denninger.net> From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD In-Reply-To: <11878eab-a60e-4d5c-8eef-b9a87c73dfc5@denninger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07.01.2024 15:51, Karl Denninger wrote: >>>     After that my server fails to boot, gtpzfsboot from second disk (ada1) reports several "zio_read error: 5" and >>> >>> ZFS: i/o error - all block copies unavailable >>> ZFS: can't read MOS of pool zroot >>> >>>     after that. >>  I've re-created pool from scratch >> >>  zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroot && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3 >> >>  but gptzfsboot still can not boot from it with same diagnostics :-( >> > Are you SURE gptzfsboot is up to date on that second drive? > > If its older that can definitely happen. I'm 100% sure that gtpzfsboot are from 13.2-RELEASE ISO (system is 13.2-STABLE stable/13-n257023-d32f39bd5fbf) on both disks. I've reinstalled it more than 10 times now... Now BIOS set to boot from ada0. Now I'm booting via "gptboot" at ada0p1/ada1p1 and small freebsd-ufs partition on ada0p2/ada0p3 with only "/boot" as temporary measure (this partition was created instead of swap temporary, to revive server). Unfortunately, it is hard to experiment with different bootcode, as it needs remote console which is in limited availability (Hetzner!) and don't give you access to BIOS anyhow. (it is pity, that our new bootloaders have less features than old 512-byte "boot0" which allows to select different HDDs without any BIOS interaction! We can several megabytes of code on these new bootloaders, and still they are DUMB) -- // Lev Serebryakov From nobody Sun Jan 7 15:38:04 2024 X-Original-To: freebsd-stable@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 4T7Ltp0qtLz57FRW; Sun, 7 Jan 2024 15:38:10 +0000 (UTC) (envelope-from SRS0=GM30=IR=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4T7Ltn50P6z41wg; Sun, 7 Jan 2024 15:38:09 +0000 (UTC) (envelope-from SRS0=GM30=IR=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C20E7D788C; Sun, 7 Jan 2024 16:38:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1704641886; bh=957MXApsj9xlddtQHv/VyW8E2u9tQcdfWlSGlI4FFSk=; h=Date:Subject:To:References:From:In-Reply-To; b=Bjfvc/xkdYJzwV/5aZgJS/kvstrmKPvGTOdKxFWU6PvacCJu6lj+FXW45eut3GdRL aGIo0z1CvA+JmQQRdnGLFQML1eBr6YqkVoMNJZIMNMC/XWjriYFGb3uJzMVWWn+igP O8otu3zufJ2i03eyySuMrBO+SJKoVKUXRYxySsK4= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 29193D7888; Sun, 7 Jan 2024 16:38:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1704641885; bh=957MXApsj9xlddtQHv/VyW8E2u9tQcdfWlSGlI4FFSk=; h=Date:Subject:To:References:From:In-Reply-To; b=KcDUPi1Ljaay3dlxi4Pvm/iSpwFVkyD8VgIfarwyCj3DrpmY2hYy/5fZS6qMilNCd HD/bIgGz7lUwHB1Hv/3g7k7fWmXbWomp33EDPrnSHNAcLRxEPi2etgup9eg0VDQ0PY teyRDtv1m3BC3ATXj+JQlClOwFRACQ4no3svSrec= Message-ID: Date: Sun, 7 Jan 2024 16:38:04 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US To: lev@FreeBSD.org, freebsd-fs , freebsd-stable , Alexander Motin References: From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4T7Ltn50P6z41wg X-Spamd-Bar: ---- 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:42000, ipnet:94.124.104.0/21, country:CZ] On 07/01/2024 15:49, Lev Serebryakov wrote: > On 05.01.2024 18:28, Lev Serebryakov wrote: > >>     After that my server fails to boot, gtpzfsboot from second disk >> (ada1) reports several "zio_read error: 5" and >> >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read MOS of pool zroot >> >>     after that. >  I've re-created pool from scratch > >  zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroot > && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3 > >  but gptzfsboot still can not boot from it with same diagnostics :-( How large are your disks in a question? I was bitten by this not a long time ago when migrating my 2TB pool by zfs send to larger disks (4TB), then I see the error: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool zroot As far as I search the internet it is caused by the boot code (later stage which is in a file in /boot directory) was moved too far from the beginning of the disk and some old BIOS cannot allow the system to continue booting. I am not a boot expert so my words can be wrong but I hope you get the point. It can be result of the system update, or zfs send | zfs recv. In my case the pool was unbootable in HP Miniserver Ge 8 but boots perfectly fine in an old Supermicro with X9SCA-F board. The problem is not in a pool, nor disks, nor FreeBSD but in a BIOS. I solved it by creating new mirrored pool of the size about 40GB at the beginning of the disks (40GB GPT partition for freebsd-zfs) where I installed the FreeBSD system and next freebsd-zfs partition covering the rest of the 4TB disks for data storage. Everything works fine. You can also have just a small /boot partition for the boot and later overlayed by main ZFS pool, but it seems to me as bad for maintaining. example of my partitions layout # gpart show -p => 40 7814037088 ada0 GPT (3.6T) 40 1024 ada0p1 freebsd-boot (512K) 1064 40960 ada0p2 efi (20M) 42024 83886080 ada0p3 freebsd-zfs (40G) 83928104 20971520 ada0p4 freebsd-swap (10G) 104899624 7707033600 ada0p5 freebsd-zfs (3.6T) 7811933224 2103904 - free - (1.0G) It can also be avoided if your machine supports EFI boot, but my HP Microserver Gen 8 does not support it. Kind regards Miroslav Lachman From nobody Sun Jan 7 15:50:19 2024 X-Original-To: stable@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 4T7M8v01yzz57GQt for ; Sun, 7 Jan 2024 15:50:23 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4T7M8t0Kp6z43kp for ; Sun, 7 Jan 2024 15:50:22 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (096-033-195-197.res.spectrum.com [96.33.195.197]) by colo1.denninger.net (Postfix) with ESMTP id 832CD2110CF for ; Sun, 7 Jan 2024 10:50:32 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 9753D3B1791 for ; Sun, 7 Jan 2024 10:50:20 -0500 (EST) Message-ID: Date: Sun, 7 Jan 2024 10:50:19 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US To: stable@freebsd.org References: From: Karl Denninger In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090201060502050605020208" X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.87 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx:c]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[karl]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; RCPT_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4T7M8t0Kp6z43kp This is a cryptographically signed message in MIME format. --------------ms090201060502050605020208 Content-Type: multipart/alternative; boundary="------------ipUfD8unXJhYrrBeDY0TfUUu" --------------ipUfD8unXJhYrrBeDY0TfUUu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/7/2024 10:38, Miroslav Lachman wrote: > On 07/01/2024 15:49, Lev Serebryakov wrote: >> On 05.01.2024 18:28, Lev Serebryakov wrote: >> >>>     After that my server fails to boot, gtpzfsboot from second disk >>> (ada1) reports several "zio_read error: 5" and >>> >>> ZFS: i/o error - all block copies unavailable >>> ZFS: can't read MOS of pool zroot >>> >>>     after that. >>   I've re-created pool from scratch >> >>   zpool create znewroot ada0p3 && zfs send zroot | zfs receive >> znewroot && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3 >> >>   but gptzfsboot still can not boot from it with same diagnostics :-( > > How large are your disks in a question? > > I was bitten by this not a long time ago when migrating my 2TB pool by > zfs send to larger disks (4TB), then I see the error: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zroot > > ..... > > It can also be avoided if your machine supports EFI boot, but my HP > Microserver Gen 8 does not support it. > > Kind regards > Miroslav Lachman Yes, gptzfsboot (non-EFI) uses BIOS calls to read the headers and ultimately the kernel; if the pool you wish boot from is not contained entirely within the first 2TB of the drive (which can certainly happen on a disk larger if you are not segregating the boot pool separate from the rest of the space on a drive larger than that) it can fail to load because some of the data it has to read is beyond the 32 bit block offset that can be used. If you have (for example) 4Tb drives the way to avoid this is to have the boot pool be of sufficient size to hold the operating system and then a second pool (that can be of any size) which holds all your other data, with the boot pool comprised of vdevs that have all blocks with in the first 2Tb. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ipUfD8unXJhYrrBeDY0TfUUu Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/7/2024 10:38, Miroslav Lachman wrote:
On 07/01/2024 15:49, Lev Serebryakov wrote:
On 05.01.2024 18:28, Lev Serebryakov wrote:

    After that my server fails to boot, gtpzfsboot from second disk (ada1) reports several "zio_read error: 5" and

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot

    after that.
  I've re-created pool from scratch

  zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroot && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3

  but gptzfsboot still can not boot from it with same diagnostics :-(

How large are your disks in a question?

I was bitten by this not a long time ago when migrating my 2TB pool by zfs send to larger disks (4TB), then I see the error:

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot

.....

It can also be avoided if your machine supports EFI boot, but my HP Microserver Gen 8 does not support it.

Kind regards
Miroslav Lachman

Yes, gptzfsboot (non-EFI) uses BIOS calls to read the headers and ultimately the kernel; if the pool you wish boot from is not contained entirely within the first 2TB of the drive (which can certainly happen on a disk larger if you are not segregating the boot pool separate from the rest of the space on a drive larger than that) it can fail to load because some of the data it has to read is beyond the 32 bit block offset that can be used.

If you have (for example) 4Tb drives the way to avoid this is to have the boot pool be of sufficient size to hold the operating system and then a second pool (that can be of any size) which holds all your other data, with the boot pool comprised of vdevs that have all blocks with in the first 2Tb.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------ipUfD8unXJhYrrBeDY0TfUUu-- --------------ms090201060502050605020208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yNDAxMDcxNTUwMjBaME8GCSqGSIb3DQEJBDFCBEBth1Cogkg3TZXHJ87G f6umxdRP5GE5V7ibvFWApuf+FLWTq6Y7B3bOubQtZosQDiGzmtPkHLAq+2QunvReKcZXMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgCnFWFkHY35wYwPoA8P28KTfCtF1Vz0q0FGPDjn sdKnKyRjbJsreBn+Xs6ruKCZDiLNCa3V0RFfOwbxgakYnG0BGDT5wNlqyBY6ubDyvZTVmCzk vJV5+ZfIioUGDcoPyJ0ymAScVi0zSsmWLt1fEQVXPEjawV1OMNofVfv6WJnKJ4IZT8+lm+Jz yp4hit0+nL++seVJALoA3PbaG83nhEw6odKusKl6Tg+3O3ef2cVGv3iFk5VmTVAp3f7ZL26/ SAX6PTDTP92J7aG6nO4aI7MVdUpdRDjj22cHiAfmPdT0UNCeaasG55PDH1ss+Ai3jRnSMG1h 5QRSFwojLe8F+Kyzxsf5eGGGc/RqAIz5eKnvQp/Rzlv3DHqlJr+RRapwHT9mCzOSvYxiOt/V 28z9FynpEo6sp2a3Q7WmSYHQQfKnLxKael9GWvqjxuk+DLdOZTGOIu/S9CC2IS33AJ5UCWuH KXCb7uRQHNmS/P/2Ticc4Ru2MawvSx6gGHOQ5N71fMixvvje6WU3/ND5pJSFCXZ7h915/H5W 9dVFyGcd2d+Hm4W0l634HJbR8uJ3rIyt7HrC/BC54yf/tVOeFObUng44wioUT9Y5nb0xJyJR tFYJB19HA9FXx8d665q8doEfhU+omTjd04UjJvZP1Sr9SrqpJ3l5zvhMx1O4jVXYk5P1wgAA AAAAAA== --------------ms090201060502050605020208-- From nobody Sun Jan 7 17:56:58 2024 X-Original-To: freebsd-stable@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 4T7Pz32LZ9z55YG6; Sun, 7 Jan 2024 17:57:03 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7Pz31Swrz4V98; Sun, 7 Jan 2024 17:57:03 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704650223; h=from:from:reply-to: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=HGStHKmNPazPmWtR7oEhpy4qTf/4ZQS3U6FARk4litA=; b=YPo4TFZL6YB3hlmj+HJufyanbFOpa6ue5NfRu2VuCK3MzBUGqPUpNr7XRJha9jeKL/ssDp kxga4vuYplfSf+Xx11iTiNODpvKLbUemBAcTQzFWSeBGCpKsAXjCMNu+IVjzRoQC2Jxu18 XExiDiKjvoh2NwKdY6RRpv2F1XNZ5DRl9sx2GdjPnnzHDjTH/CkIkiH0HsLILWcju/Ye+x MJEwZWhU2HH3WNK71IWcb8qORdwKdZpRGjzr9F5CPxmqZzPXULmooqC8p8Fml2YCc8vJUK KA7ZKCv01g9BGJZbfj2dKQkQonkKJQviKtCTgzEBjaep9FA+iaNyn+AmkiWBxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704650223; h=from:from:reply-to: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=HGStHKmNPazPmWtR7oEhpy4qTf/4ZQS3U6FARk4litA=; b=T8jezpsaLvh9H8GkUrTk0mUdicBztmqMszrxBAezk3deotfczbWjqtC3kbT+0zGJSKlMrw A40oj1K3Gav37YuxNydhq3f+Ps1mD0am/5Fj6mt2oRcN2mPkfuUXuVRjG9fimuVeEVLDDz pZveXAm480cxptM50rSk3fKpwzB+u1cyUXvzIVXQBQfvg4pu7cUq4kEkA+RCOjoJTRob6k D0JbMUFsZvslNsHn2fbCbAvRrdSMSnSGlI3Btb61ER1iM4Ze6jjwB5kWRjnCSWKtsmVm7X 4h/xMhK+quFtwDU5Z+nR3lWQZWZjg9hbh723Lxt0tMGSsNgI25nY0mEYBQuvww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704650223; a=rsa-sha256; cv=none; b=dU/oNAnFZZW9ojUI59q4iwTL6BDrMNJvp6i8ivyVaih4OmHOpJA58CSn0YOyp4403lOUEi qhus5eJ7UzbfRmuQjKfyi76m2VPSu4nvSijINWi23E9uwpJMIKjJvw9RMQZkR314XQg1Wx uYNBEoTHdz9Ha8x4t8gSXjUXnfts4hpXeUVImTzRn7tLmxXTTkFqwQ3Ghfv3S6WLhXfkG9 ZzJGguDMG3MaJ9aTF9jhNgGL3FDtkIqfVL13GbrSLEokHeOvX7Fycipjyf4D9qaeVMApbq ZOTyoqsGxKxQf+lXuaGZi+SzW51N3nQ0Is5eNyiP2Z6gAa7A3S8vvuJGNyzpiQ== Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (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: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7Pz26tRszVLM; Sun, 7 Jan 2024 17:57:02 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.136.24] (83-84-181-95.cable.dynamic.v4.ziggo.nl [83.84.181.95]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 1EDA532D; Sun, 7 Jan 2024 20:56:58 +0300 (MSK) Message-ID: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> Date: Sun, 7 Jan 2024 18:56:58 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: lev@FreeBSD.org Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-fs , freebsd-stable References: Content-Language: en-US From: Lev Serebryakov Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07.01.2024 16:38, Miroslav Lachman wrote: >>> ZFS: i/o error - all block copies unavailable >>> ZFS: can't read MOS of pool zroot >>> >>>     after that. >>   I've re-created pool from scratch >> >>   zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroot && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3 >> >>   but gptzfsboot still can not boot from it with same diagnostics :-( > > How large are your disks in a question? 2TB ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number K5HPZZLD ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA8-ACS SATA 3.x device ada1: Serial Number WD-WMC1P0504169 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors) > As far as I search the internet it is caused by the boot code (later stage which is in a file in /boot directory) was moved too far from the beginning of the disk and some old BIOS cannot allow the system to continue booting. Oh, it is good hypothesis. It is Haswell-time MSI board (old Hetzner EX40 instance)... > It can also be avoided if your machine supports EFI boot, but my HP Microserver Gen 8 does not support it. I'll try to switch to EFI, but it needs some luck to get to BIOS with provided KVM, it is very unstable :-) -- // Lev Serebryakov From nobody Sun Jan 7 18:34:06 2024 X-Original-To: freebsd-stable@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 4T7Qp46NNYz55dm5 for ; Sun, 7 Jan 2024 18:34:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7Qp370rBz4ZLf for ; Sun, 7 Jan 2024 18:34:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a271a28aeb4so104263266b.2 for ; Sun, 07 Jan 2024 10:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704652458; x=1705257258; 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=dBMcbWknmEeiLCmm6juxjLzU8YNhAOJUpO5ANn/muuc=; b=ZvEWqX1IqdTdeCWQ04qqte+y193MLyB+/LSQZtnC5PZxRCNQ77+1FhUHlDZp/4wIm6 0VQdG7J5XJtLCisDytqG0dpGxUsilVTitK4mQYwMyB6/ZuSqTrKVcYyFP+r7beR1pAWB hq0Y9juNtKujr91CYjmWW37FaN+XMrbhuiYGLgzNXGzBf/NudE5NR+qiqDchTWF+gCWw QjGDbN0yxceAD92Npi+6Fa0lbF3mNrNnph5h/nXZFS8qJn16Ipzjx7ut0vDPFXmasVw2 qhIMbyzJ5ugyvz0hVg2YCoaLoN5XuOCwT6bBhN0/1SuTuJaBnXjj+DPp2mcx5HSpIJRG usmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704652458; x=1705257258; 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=dBMcbWknmEeiLCmm6juxjLzU8YNhAOJUpO5ANn/muuc=; b=O6IykYfBNmj5DNwanMuqHb0aulkmYmb/0YW/2xmrZu37ShZBaD69mMIhCxten0+qOR xU9xApG335kyS/ypg5jAdZiXoYtT15k9FQcCCcUyLA7w7dQtAqpFGF6HTi1BRXKsNZjX nUC+SJbVVNkwJtobr0YflaXz0Rv8B8yvXssHcHlivibxRvf+WyibUSj4wl/RY4olGFgm yJogQVk7g5AG051f6Mrv2pgDD9z/+RpGXFzVe0e2e9BhambaYlUDcaksg6OwA4Mihrpy LhI8LW1ZjQ3Nkye3xX30dU8VsV2dASpTGSwNk6xIAgFXAnBKzvuBTIwGwNbslaT+KHF9 cAZg== X-Gm-Message-State: AOJu0YzN+aZzbgMjaFBI/VBOmogdGMDo9GIBAK18UNIMi8fM7ePTQUtC bexxOnWY8LlN8TrcIXP05MDomKsS/6pyPSRqlLnivgQFFkFPPw== X-Google-Smtp-Source: AGHT+IE66MuDCSajV1hdhhJ/pX7xKewBtGmG4U3kYk05yB0o/S1q7cZjTiCCNWFUrjfEOkoG9z/kjxjVvVpO2TwVIRs= X-Received: by 2002:a17:906:d9c7:b0:a27:5343:d3e8 with SMTP id qk7-20020a170906d9c700b00a275343d3e8mr1068109ejb.97.1704652457829; Sun, 07 Jan 2024 10:34:17 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> In-Reply-To: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> From: Warner Losh Date: Sun, 7 Jan 2024 11:34:06 -0700 Message-ID: Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. To: lev@freebsd.org Cc: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-fs , freebsd-stable Content-Type: multipart/alternative; boundary="00000000000036f5f2060e5f548d" X-Rspamd-Queue-Id: 4T7Qp370rBz4ZLf X-Spamd-Bar: ---- 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:2a00:1450::/32, country:US] --00000000000036f5f2060e5f548d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 7, 2024 at 10:57=E2=80=AFAM Lev Serebryakov w= rote: > On 07.01.2024 16:38, Miroslav Lachman wrote: > > >>> ZFS: i/o error - all block copies unavailable > >>> ZFS: can't read MOS of pool zroot > >>> > >>> after that. > >> I've re-created pool from scratch > >> > >> zpool create znewroot ada0p3 && zfs send zroot | zfs receive znewroo= t > && zpool destroy zroot && zpool attach znewroot ada0p3 ada1p3 > >> > >> but gptzfsboot still can not boot from it with same diagnostics :-( > I must have missed it. What were the diagnostics? > > How large are your disks in a question? > 2TB > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number K5HPZZLD > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 1907729MB (3907029168 512 byte sectors) > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA8-ACS SATA 3.x device > ada1: Serial Number WD-WMC1P0504169 > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 1907729MB (3907029168 512 byte sectors) > < 4294967296 sectors should be good. So these drives shouldn't see this problem. the BIOS interfaces should have no trouble here. > > As far as I search the internet it is caused by the boot code (later > stage which is in a file in /boot directory) was moved too far from the > beginning of the disk and some old BIOS cannot allow the system to contin= ue > booting. > Oh, it is good hypothesis. It is Haswell-time MSI board (old Hetzner > EX40 instance)... > Yes. If the drives are > 2TB you lose. BIOS is not for you... Unless you make special partitions that are in the first 2TB of the drive and only boot off of those. Also, if the drives are 4k, you likely lose, though it's hit or miss. Those are the hard limits of the BIOS ABI. > It can also be avoided if your machine supports EFI boot, but my HP > Microserver Gen 8 does not support it. > I'll try to switch to EFI, but it needs some luck to get to BIOS with > provided KVM, it is very unstable :-) > BIOS booting is dying. It will be unsupportable in not too many more years and the code removed. The rapid proliferation of ZFS crypto and compression types is hastening the race to see who can use up the most space in the boot loader. We can do marginal things to make it better wrt the 640k limit, sure, but then we hit other limits like the 2TB address space, like not being able to reliably support 4k drives, etc. BIOS booting likely will support an increasingly small subset of all possible booting methods as we go forward. The current crazy mix of different alternative firmwares makes it hard to know what will survive, but as we hit these limitations, it will make it harder and harder to configure, deploy and manage these systems. The Linux on ZFS root pages, btw, recommend having two pools on two partitions on the disk. One that's a few GB that's the bool that has the kernel in it, and the other, rest of the disk, that's rpool for the root pool. If people want to continue to support BIOS booting (or rather, booting using the CSM interfaces), then somebody is going to need to step up to the plate and implement a similar option in bsdinstall, bectl, freebsd-update, etc. Warner --00000000000036f5f2060e5f548d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 7, 2024 at 10:57=E2=80=AF= AM Lev Serebryakov <lev@freebsd.org> wrote:
On= 07.01.2024 16:38, Miroslav Lachman wrote:

>>> ZFS: i/o error - all block copies unavailable
>>> ZFS: can't read MOS of pool zroot
>>>
>>> =C2=A0=C2=A0=C2=A0 after that.
>> =C2=A0=C2=A0I've re-created pool from scratch
>>
>> =C2=A0=C2=A0zpool create znewroot ada0p3 && zfs send zroot= | zfs receive znewroot && zpool destroy zroot && zpool att= ach znewroot ada0p3 ada1p3
>>
>> =C2=A0=C2=A0but gptzfsboot still can not boot from it with same di= agnostics :-(

> How large are your disks in a question?
=C2=A0 =C2=A02TB

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <HGST HUS726020ALE610 APGNTD05> ACS-2 ATA SATA 3.x device
ada0: Serial Number K5HPZZLD
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 1907729MB (3907029168 512 byte sectors)
ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1: <WDC WD2000FYYZ-01UL1B1 01.01K02> ATA8-ACS SATA 3.x device
ada1: Serial Number WD-WMC1P0504169
ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 1907729MB (3907029168 512 byte sectors)

<=C2=A04294967296 sectors should be good. So these drives shouldn= 't see this problem. the BIOS interfaces should have no trouble here.
=C2=A0
> As far as I search the internet it is caused by the boot code (later s= tage which is in a file in /boot directory) was moved too far from the begi= nning of the disk and some old BIOS cannot allow the system to continue boo= ting.
=C2=A0 =C2=A0Oh, it is good hypothesis. It is Haswell-time MSI board (old H= etzner EX40 instance)...

Yes. If the dr= ives are > 2TB you lose. BIOS is not for you...=C2=A0 Unless you make sp= ecial partitions that are in the first 2TB of the drive and only boot off o= f those. Also, if the drives are 4k, you likely lose, though it's hit o= r miss. Those are the hard limits of the BIOS ABI.

> It can also be avoided i= f your machine supports EFI boot, but my HP Microserver Gen 8 does not supp= ort it.
=C2=A0 =C2=A0I'll try to switch to EFI, but it needs some luck to get t= o BIOS with provided KVM, it is very unstable :-)

=
BIOS booting is dying. It will be unsupportable in not too many = more years and the code removed. The rapid proliferation of ZFS crypto and = compression types is hastening the race to see who can use up the most spac= e in the boot loader. We can do marginal things to make it better wrt the 6= 40k limit, sure, but then we hit other limits like the 2TB address space, l= ike not being able to reliably support 4k drives, etc. BIOS booting likely = will support an increasingly small subset of all possible booting methods a= s we go forward. The current crazy mix of different alternative firmwares m= akes it hard to know what will survive, but as we hit these limitations, it= will make it harder and harder to configure, deploy and manage these syste= ms.

The Linux on ZFS root pages, btw, recommend ha= ving two pools on two partitions on the disk. One that's a few GB that&= #39;s the bool that has the kernel in it, and the other, rest of the disk, = that's rpool for the root pool. If people want to continue to support B= IOS booting (or rather, booting using the CSM interfaces), then somebody is= going to need to step up to the plate and implement a similar option in bs= dinstall, bectl, freebsd-update, etc.

Warner
--00000000000036f5f2060e5f548d-- From nobody Sun Jan 7 19:01:18 2024 X-Original-To: freebsd-stable@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 4T7RPH05dmz55hN6; Sun, 7 Jan 2024 19:01:23 +0000 (UTC) (envelope-from SRS0=GM30=IR=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4T7RPG508bz4d6q; Sun, 7 Jan 2024 19:01:22 +0000 (UTC) (envelope-from SRS0=GM30=IR=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BC5BFD78B9; Sun, 7 Jan 2024 20:01:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1704654079; bh=IjzlT/4D0rQsJbQoss+iGDW7eZv4CBXPAhmlMBhqp/k=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=XvtKmAF4BBtFESkV+5T69EXxyvOGv6l/6X1g2w64P2+fjJ1fKgAZAv69YVgOCbSgW EvOZL1TpRSpFDV+YAwtFBYO1AAzkZbu7ZMU8NaV6agGQZwLvAU87pgpOEUK4V9xcyM ZwReKgC3x6xjtWH706cjI0GKdMnEYuGKnXat+2Ro= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9435DD7884; Sun, 7 Jan 2024 20:01:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1704654078; bh=IjzlT/4D0rQsJbQoss+iGDW7eZv4CBXPAhmlMBhqp/k=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=MILcixeIRkEgJL8yogua4Ct32xJMyEzdzeeaURyq+rP92vfGf3senCk4mBTnKhkg6 hBmu5jP8AIWNz4ewH6NB3sUwj/Gvy3tCZ2UFnHYDS47/y5ubRFM0v3bHmQniFXtRMH smusd1G+U+ysz4wknL+a8/ZFgEK9MGhd5Mn14UlA= Message-ID: Date: Sun, 7 Jan 2024 20:01:18 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US To: Warner Losh , lev@freebsd.org Cc: freebsd-fs , freebsd-stable References: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4T7RPG508bz4d6q X-Spamd-Bar: ---- 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:42000, ipnet:94.124.104.0/21, country:CZ] On 07/01/2024 19:34, Warner Losh wrote: > < 4294967296 sectors should be good. So these drives shouldn't see this > problem. the BIOS interfaces should have no trouble here. [...] > Yes. If the drives are > 2TB you lose. BIOS is not for you...  Unless > you make special partitions that are in the first 2TB of the drive and > only boot off of those. Also, if the drives are 4k, you likely lose, > though it's hit or miss. Those are the hard limits of the BIOS ABI. It is not always that simple math. As I wrote in my previous reply, my pool was unbootable in one machine but boots fine in the other. Both were Intel based amd64 with BIOS, not EFI. I think there are some buggy BIOSes where it cannot boot even on smaller pools than 2TB. (or maybe some improved BIOSes supporting larger boundaries than 2TB? I don't know in what exact position bootloader / kernel was on my 4TB pool) Kind regards Miroslav Lachman From nobody Sun Jan 7 20:49:24 2024 X-Original-To: freebsd-stable@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 4T7Tp31ngLz55wBc; Sun, 7 Jan 2024 20:49:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7Tp31JTcz4qyd; Sun, 7 Jan 2024 20:49:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704660571; h=from:from:reply-to: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=moJLxTRm4w6sk8CN21OufYz+qGwGUupMr1SNWmDFC1Q=; b=W8P3/dEzRcF4tth0VLGB3GbZeETlEEU8uMOdUKg6Eez4HvpljD3gTHN6VfRVoW5E9YZGzg GpF3QFz7Z35hEBzTiewXyAnOTAGoUAbuVzbFQhgbYsa1X7bBB3Ze5sv+wQsKgGfB151MlU 5PKH6m5FcIVnIO/qkstjGOkiWqAQA+YTp6jVIme+Ql9zFvk+YldrMP2uVHWDI8JrMmhHhu sgYkeIoqSSpoKhMFdIQDn76edAR5EMelbMlRFXTbCF2Sobj58MfNZPH63+TrHMazYOAehP lfUS2Bd8Iu2HJuErvPEJohrGfh/LMjJdMox7+dkktf+2bxeUFu3pY8xciFoATw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704660571; h=from:from:reply-to: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=moJLxTRm4w6sk8CN21OufYz+qGwGUupMr1SNWmDFC1Q=; b=L60jcZwsNHL1kjr1H1ARnsAm3L8JcFnIUhitK7FWGAjNkt4HpKXFO5m2N0IJT44ALgzFPL /vCIdLPZEeBrzKL4s+iT/QEovIOwBQ9vAxt1h68tDObj9I+MwEeuG/6Gh/M/uDw5neBoI7 QhHib7KO0Ph27Ce/EiiBMcYVqCGcDoggaj3DQO4hU4rDa7ICx1xo7lZPguY7z4/PGWY5d1 P+rcKAXj6VyM6TbLgeBaz6hhvjTPS0sEgh4vRaGQLBXZY+J0jFTvtml8+q8Q9ozOlbY97U xyz3Q+u7skCr9TyXqxwabBBzWnK606EAmc8YU3xD5q7LVffaMqYhiMy5s8Lrwg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704660571; a=rsa-sha256; cv=none; b=ddezyY86Sf3CjFNXmpd8gaaoPQJ1/MB8YBtEi8/o375BElPhFrD36+LBMpYHmjP/uvyxWd V0kPr2gZhhOADfTSlQxBLH168KjBmgehaDIdz68zONA2vo5B59pyMnzy1yTVPXb8EZHKJc pSvEJtQedG7vBwmg+SGuP7B4LLcgQjn/j7HPrs8+nRvzwW8s5cmrXz81IO69RgH9kQpPhh aAx0LgejwW9N/gGKTxBZ/OeeMzAgZaPYWXZWPxNwPslNyeRifZbK5Rgf7JbOC0fP0vLh7g SyexvL6x706W8SRljXas/RSMt+AlXhPh2ERb0cFXTSVLFYHOrgnRUNYgua26oQ== Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (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: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7Tp26ksKzZ7X; Sun, 7 Jan 2024 20:49:30 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.136.24] (83-84-181-95.cable.dynamic.v4.ziggo.nl [83.84.181.95]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 419AC1A2; Sun, 7 Jan 2024 23:49:25 +0300 (MSK) Message-ID: Date: Sun, 7 Jan 2024 21:49:24 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: lev@FreeBSD.org Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. To: Warner Losh Cc: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-fs , freebsd-stable References: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> Content-Language: en-US From: Lev Serebryakov Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07.01.2024 19:34, Warner Losh wrote: > I must have missed it. What were the diagnostics? zio_read error: 5 zio_read error: 5 zio_read error: 5 ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool zroot To be honest, I thinks there is something else. Because sequence of events were (sorry, too long, but I think, tht every detail matters here): (1) Update to 13.2 from 12.4. With installation of new gptzfsboot with gpart on both disks. It could place new /boot far away, but see (2) (2) Reboot, which completed, but showed that ada0 has problems (3) Replacement of ada0 by DC technicians, new disk is 512/4096, old disk is 512/512, pool has ashift=9 (4) Server refuses to boot from ada1 (ada0 is empty) with diagnostics (see above) (5) Linux rescue system, passing 2 devices to qemu with FreeBSD (because Linux shows that ZFS is on whole disk, not on partition!). (6) Re-creation of GPT on ada0, start of resilver (with sub-optimal ashift!). (7) Interruption of resilver with reboot, because it is painfully slow under qemu. (8) Wipe of ada0 (at this point resilver status of pool becomes crazy) to put live FreeBSD image to boot somehow. (9) Many tries to cancel resilver and boot from single-disk "historical" pool on ada1, no success. I've attributed it to the strange state of pool: one component, no mirrior, but "resilvering". (10) Boot from small UFS partition (which replaces swap partition). (11) Pool on ada1 (old, live, 512/512 disk) is still "Reslivering" without any additional components (with zero speed, of course). (12) Prepare partitions on ada0 again, creating new pool with ashift=12, send|receive. (13) Removing partition on ada1 (old one, ashift=9, still resilvering after many-many reboots with only one device in it). (14) Boot from fresh ada0 pool - same errors from gptzfsboot, fail, and gptzfsboot says about OLD pool (which should not be available as GPT on ada1 was wiped out!!!!) (15) Boot from UFS again. (16) Adding parition of ada1 as second component of new pool, resilvering successful. (17) Boot with gptzfsboot still fails! With brand-new ashift=12 pool! Now bootloader reports new pool name, but still fails to boot. You see, buildworld update could place /boot too far away. But there was one last successful boot between (1) and (3)! And state of pool on live disk ada1 was very strange: I can not cancel resilver no matter what I've tried till I zap GPT and start over. > If people want to continue to support BIOS booting (or rather, booting using the CSM interfaces), then somebody is going to need to step up to the plate and implement a similar option in bsdinstall, bectl, freebsd-update, etc. I can use UEFI boot without problems, but now I'm not sure, will it work for me now. -- // Lev Serebryakov From nobody Sun Jan 7 20:56:59 2024 X-Original-To: freebsd-stable@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 4T7Tyl0Wvlz55x4S; Sun, 7 Jan 2024 20:57:03 +0000 (UTC) (envelope-from lev@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7Tyk6hgXz4sYn; Sun, 7 Jan 2024 20:57:02 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704661022; h=from:from:reply-to: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=GovAzm586aX1tFxsxjyg7XMYUy6unepRRsd0F5nEXa0=; b=BAWcgtWO/FFCC4OsdS4rXuaVJl2gvLa6wjC+CDRNpN2JvJnf4cQdG6pMHb0E8pLgP5gt0x 36c/qo0YJa8FYJFeF495g6t/HZpWuSAmVZpvORmzFpnDlQ605fEvLayPugN7aFqNBNMT9q GgMhRmulzOo8NJ7rdsmTUu7iuvnKcRvfSDKxs0KImBznAzeGW/ZDsdjfkgoYLTEbtgTcgJ nkKnsJMclCtJkIj7lLh35zKg0YEF8NPPuNUa3r1xMqxQMrqtbTxy1V/nOWQMm4o4paqWgc Pbkiz+k6oQiqk56scLk/WY5an6J6rUPRJz06Gxli7432CThYkqUk1i/L/bGBcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704661022; h=from:from:reply-to: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=GovAzm586aX1tFxsxjyg7XMYUy6unepRRsd0F5nEXa0=; b=Y3Q/05BzYGfeZoI2etAA1fqCTmrzBQMKdmYIXvwL21nW/Y8RZNLaS2+zkP5EmNP2Hqu4RI JNpYc7YM4NPxv7aN4979DUfO1qaGkjt+CWoxXJOg2mxUkIHkX8qs1t7gqQQiFfkFeIi6+W 0iRlK2nEJ3K8YZzvwSQH0La5WWw2JNmMNzzx7L5GDV8gxXHkXbUZfNfNdlpsHg/lxkLYed ZYq3dPLJbclqDd3zfNV5ohaunmaeC4RVG7QDQONDlnJDJ3avOvO0vwKTRAhU4JJpM7G3QX +0LKJaxbJa7MZfstUpF1J/53S0O3OCUw7BoIH5FbwZroxnhqwmh12elujrb7Iw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704661022; a=rsa-sha256; cv=none; b=uj1taT38/WGPMkkSdf8E6afJdc/pRv+A8/wXntZYhSFop0jW0C97F702LvA3Yw6kRQsJO0 6rSlQCnmo+StxhOXwmTufg+RY7VqDPXFoBw9fUoY3iNBKX/aBeBIJCD3vFIZIJ6qSULHVK UKe+uOD/8ooxPRG7XrY+O3kB/ZjC9p0AxmZZT4UN5a5vbzlHnTGvDfYKUeYX/5L4yOxTX1 xxedGQ+vQpldQOawgXupoQSmWf6+1vBkm53RocHzivcE59jJ2hkNtAw7Mkgwmium/qeQKf DejQ+YA05nqA929v/iGs1LMZ+++psF32k3GULD95IZBTiF4EcWwt06AmLNfyRg== Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (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: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7Tyk526NzZVZ; Sun, 7 Jan 2024 20:57:02 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.136.24] (83-84-181-95.cable.dynamic.v4.ziggo.nl [83.84.181.95]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 95589332; Sun, 7 Jan 2024 23:56:59 +0300 (MSK) Message-ID: <2f91eeb7-430b-49e2-817b-5acd0f445fe9@FreeBSD.org> Date: Sun, 7 Jan 2024 21:56:59 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US From: Lev Serebryakov To: Warner Losh Cc: freebsd-fs , freebsd-stable Reply-To: lev@FreeBSD.org, lev@FreeBSD.org References: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07.01.2024 21:49, Lev Serebryakov wrote: > On 07.01.2024 19:34, Warner Losh wrote: > >> I must have missed it. What were the diagnostics? Oh, and two "nvlist inconsistency" before that vvvv > zio_read error: 5 > zio_read error: 5 > zio_read error: 5 > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zroot > > >  To be honest, I thinks there is something else. Because sequence of events were (sorry, too long, but I think, tht every detail matters here): > > (1) Update to 13.2 from 12.4. With installation of new gptzfsboot with gpart on both disks. It could place new /boot far away, but see (2) > (2) Reboot, which completed, but showed that ada0 has problems > (3) Replacement of ada0 by DC technicians, new disk is 512/4096, old disk is 512/512, pool has ashift=9 > (4) Server refuses to boot from ada1 (ada0 is empty) with diagnostics (see above) > (5) Linux rescue system, passing 2 devices to qemu with FreeBSD (because Linux shows that ZFS is on whole disk, not on partition!). > (6) Re-creation of GPT on ada0, start of resilver (with sub-optimal ashift!). > (7) Interruption of resilver with reboot, because it is painfully slow under qemu. > (8) Wipe of ada0 (at this point resilver status of pool becomes crazy) to put live FreeBSD image to boot somehow. > (9) Many tries to cancel resilver and boot from single-disk "historical" pool on ada1, no success. I've attributed it to the strange state of pool: one component, no mirrior, but "resilvering". > (10) Boot from small UFS partition (which replaces swap partition). > (11) Pool on ada1 (old, live, 512/512 disk) is still "Reslivering" without any additional components (with zero speed, of course). > (12) Prepare partitions on ada0 again, creating new pool with ashift=12, send|receive. > (13) Removing partition table on ada1 (with old pool, ashift=9, still resilvering after many-many reboots with only one device in it). And pleas note: this pool on ada1 (old, live disk) was NOT upgraded after 12-STABLE. It was old, 12-STABLE "level" pool with all new features disabled. -- // Lev Serebryakov From nobody Sun Jan 7 21:06:26 2024 X-Original-To: freebsd-stable@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 4T7V9r0cxzz55yC1 for ; Sun, 7 Jan 2024 21:06:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7V9q4pBmz43Dg for ; Sun, 7 Jan 2024 21:06:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a293f2280c7so126763066b.1 for ; Sun, 07 Jan 2024 13:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704661598; x=1705266398; 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=r40KQBPRA3q4Kx8Augm8TyuFOoZXmCoz+NYIaTV/oq8=; b=IjvvrIqAraXbiMl5TkgSsiewdSV0Whb61keKgb3cVfBjuwf3qzhy1vPlacux+pDWFt 3MAiKKIwNbAo7roCkiRtCKdAQtKJ3PBz9sg1ojyrcH+gVpbJfTRIhw+5FL04AyXkOfM2 H8gAsGAxGOqTAQa2nDwkR7C/nAgQ8EmLWxPtialnAS5iuLoN/InVP00JDxW34feP1iMg Ue5XPxAmC9F233TAvrl7knCe6McUu67K9uoBwUTFedJIl5A7RBjMuqtz8DNWOvyjfuDA I285oviGP+Nvjnf5B3w4r+xmgjWZgP4LePMd4mgv7Ow50ngxWtxzN/QmzT+eguM/o0Fo 2//Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704661598; x=1705266398; 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=r40KQBPRA3q4Kx8Augm8TyuFOoZXmCoz+NYIaTV/oq8=; b=XWoBKbrWQAwuJqi9T7o2YMJCkvIwHFdvI6CrhUJf8eY6t6UPm/hnAUTdMg10tMSW11 FbOoCf6ED5vrWWD1SNQY1Fwg9NZ9mMFfE3XKb3EEvI0AMxok/G9CtNV45UjRxBxtdtn6 DkKuo9PQmBO78TZwDUK2qtOYTwBjT9Drqww/WdAmy22Xl3sMNP6Mw9wKzlpCns2OGLlk PiU9JYuUYyA9S3hdWpxf3WUfwNcsyEza3h5LYhhwORxj8pvaDwHHcaw/rd+fImtHd/AW u1F6c7U9YZCxtvZoHtOG/p17NPnu5VvueODqWGJIv1iJFz6UWLwD8rah8i+6oMxZEWjd PcyA== X-Gm-Message-State: AOJu0YwIa1pnfZdcWnZQ9e46oGCP2y45AiXFZy/VLqbf8d1axrhH3dPc lsPXDjEXTYsM77aXcgk9xovrtXlvdmz2nyz4D9vEgVhY57kZEA== X-Google-Smtp-Source: AGHT+IFokWdN5h8upavvIYSj7qNcUk4QfxU2+Z0cR/bheYt68OSZCktpnmYeZyYss2dJtypP1Irr5HvXyNDdzTAtYlg= X-Received: by 2002:a17:906:310b:b0:a28:1916:6cc9 with SMTP id 11-20020a170906310b00b00a2819166cc9mr423605ejx.270.1704661597664; Sun, 07 Jan 2024 13:06:37 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Sun, 7 Jan 2024 14:06:26 -0700 Message-ID: Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. To: Miroslav Lachman <000.fbsd@quip.cz> Cc: lev@freebsd.org, freebsd-fs , freebsd-stable Content-Type: multipart/alternative; boundary="000000000000fdcd44060e61747d" X-Rspamd-Queue-Id: 4T7V9q4pBmz43Dg X-Spamd-Bar: ---- 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:2a00:1450::/32, country:US] --000000000000fdcd44060e61747d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 7, 2024 at 12:01=E2=80=AFPM Miroslav Lachman <000.fbsd@quip.cz>= wrote: > On 07/01/2024 19:34, Warner Losh wrote: > > > < 4294967296 sectors should be good. So these drives shouldn't see this > > problem. the BIOS interfaces should have no trouble here. > > [...] > > > Yes. If the drives are > 2TB you lose. BIOS is not for you... Unless > > you make special partitions that are in the first 2TB of the drive and > > only boot off of those. Also, if the drives are 4k, you likely lose, > > though it's hit or miss. Those are the hard limits of the BIOS ABI. > > It is not always that simple math. As I wrote in my previous reply, my > pool was unbootable in one machine but boots fine in the other. Both > were Intel based amd64 with BIOS, not EFI. I think there are some buggy > BIOSes where it cannot boot even on smaller pools than 2TB. (or maybe > some improved BIOSes supporting larger boundaries than 2TB? I don't know > in what exact position bootloader / kernel was on my 4TB pool) > OK. If the problem is that int13 has only 32-bits in the ABI, the math is that simple. The limit is 2^32 blocks, and there's no reliable provision for 4k sector sizes (there's some BIOSes that will do it, others that won't... it's a bit muddled looking at the problem reports, though we do try to support that). There's no BIOS64 implementation that extends the int13 interfaces to do wider block sizes that I've seen... It's just that it's so close it's easy to gravitate to a known issue... If other weird things are happening, then that means that we may have a typ= e problem that's truncating the logical block size (which the BIOS doesn't care about) to 32-bit (or maybe sometimes) which then leads to weird things happening. But... UEFI should suffer this same problem and we should hear about it a lot I'd think (though maybe how gptzfsboot is compiled might be the culprit, since that's the only thing that's confined to the gpt boot blocks that's not common binary code (we #include the implementation to make two different binary things....)). It shouldn't care that the copy of /boot/loader is past the 2TB logical limit, because the drives are smaller than 2TB and so none of their LBAs will be > 2^32 and should all work. If that's indeed the issue, then there's something weird about how we build it for gptzfsloader. The other thing it could be, though, is that if there's a resilvering, there's some subtle state that's confusing the simple reimplementation of ZFS reading that's in the boot loader. Though I'd expect to have heard about that before now. Especially since this would hit UEFI booting as well. Warner --000000000000fdcd44060e61747d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 7, 2024 at 12:01=E2=80=AF= PM Miroslav Lachman <000.fbsd@quip.c= z> wrote:
On 07/01/2024 19:34, Warner Losh wrote:

> <=C2=A04294967296 sectors should be good. So these drives shouldn&#= 39;t see this
> problem. the BIOS interfaces should have no trouble here.

[...]

> Yes. If the drives are > 2TB you lose. BIOS is not for you...=C2=A0= Unless
> you make special partitions that are in the first 2TB of the drive and=
> only boot off of those. Also, if the drives are 4k, you likely lose, <= br> > though it's hit or miss. Those are the hard limits of the BIOS ABI= .

It is not always that simple math. As I wrote in my previous reply, my
pool was unbootable in one machine but boots fine in the other. Both
were Intel based amd64 with BIOS, not EFI. I think there are some buggy BIOSes where it cannot boot even on smaller pools than 2TB. (or maybe
some improved BIOSes supporting larger boundaries than 2TB? I don't kno= w
in what exact position bootloader / kernel was on my 4TB pool)

OK. If the problem is that int13 has only 32-bits i= n the ABI, the math is that simple.
The limit is 2^32 blocks, and= there's no reliable provision for 4k sector sizes (there's
some BIOSes that will do it, others that won't... it's a bit mud= dled looking at the problem
reports, though we do try to support = that). There's no BIOS64 implementation that
extends the int1= 3 interfaces to do wider block sizes that I've seen... It's just th= at it's
so close it's easy to gravitate to a known issue.= ..

If other weird things are happening, then that = means that we may have a type
problem that's truncating the l= ogical block size (which the BIOS doesn't care
about) to 32-b= it (or maybe sometimes) which then leads to weird things happening.
But... UEFI should suffer this same problem and we should hear about it = a lot
I'd think (though maybe how gptzfsboot is compiled migh= t be the culprit, since
that's the only thing that's conf= ined to the gpt boot blocks that's not common
binary code (we= #include the implementation to make two different binary
things.= ...)). It shouldn't care that the copy of /boot/loader is past the 2TB<= /div>
logical limit, because the drives are smaller than 2TB and so non= e of their
LBAs will be > 2^32 and should all work. If that= 9;s indeed the issue, then there's
something weird about how = we build it for gptzfsloader.

The other thing it c= ould be, though, is that if there's a resilvering, there's some
subtle state that's confusing the simple reimplementation of ZFS= reading that's
in the boot loader. Though I'd expect to = have heard about that before now. Especially
since this would hit= UEFI booting as well.

Warner

=
--000000000000fdcd44060e61747d-- From nobody Sun Jan 7 21:15:14 2024 X-Original-To: freebsd-stable@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 4T7VMz1Lzqz560hg for ; Sun, 7 Jan 2024 21:15:27 +0000 (UTC) (envelope-from wlosh@bsdimp.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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7VMy4nckz45P7 for ; Sun, 7 Jan 2024 21:15:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a28d61ba65eso120249566b.3 for ; Sun, 07 Jan 2024 13:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704662125; x=1705266925; 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=vgHAAVGVnuMYvEQ3QnRnNsHbKlCKig/3HCPsAT5KGZU=; b=aKrEo8Hmc8oilm3o+C8F+KiCRmgtYyt9gzVQVXW470qBIJMbLKpjBLq/BagkBobQlD GFqC6wZKENMIbV53brGN2AIo7pzFMBqnnsDNlnu3dfElAGF7+cO5UqsgreOzh+WuM9sd UFxhFdzo57kL1xzgq7UcQwTXZoBnad6MsT+SkeEkOpCKTptZRxvLnxVKd4+dVPoBCzem QWgofQ0tOqC3e9SxO6gs5QXc38pet+IKcxVRiw2c9hQhNqwW8jmPR6rvY5tGLjPsxfjG kfDDpIGVPHTwdG2Ty8dZOX02JH8PUvroJkuXaYE5o7thDAGx8cED6tU97uKwzei5/Hzy 2qwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704662125; x=1705266925; 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=vgHAAVGVnuMYvEQ3QnRnNsHbKlCKig/3HCPsAT5KGZU=; b=ZoL7qafSW0R4P6/HccJSkIAvAmcX6cptzXG+y9P2PACL8KBb6VTvsrGMjU7Sra9xhH oz5WndyfSPXpfaNmLwajbkyRgLVeCgO1JlWS8RnaPLiW/Kzc4N2wWCLS1YDYR/+EKTk/ RaMHDvFzdABTJ8/fZBTipEEdqQfFS+BGJVL18QByP7PuFYORmYp2DJlgE9XTNA4hApST uZgjLrAyWtTAKNeKoWr1rxYztRdOBubjaQPCYfh+bd188VMyWdd9Teu5FfuBpHCy6+27 GoTxmFzqjsemVDqNP0STS/gkeJ0/17UTVdUUN7r7TqVnCmILL/8q48SQ8hwhWr1X+H0U UmWA== X-Gm-Message-State: AOJu0YypEfoZRWcyHQMyyGwbFKa11VDte6Waa3PBtcUTW6dMv8QMORen lApuAxBsadjKi7lEgG5JjE2ubbM5JpZdg2Bd59r2TMnlXlYPIyBfTDZSciE6pXU= X-Google-Smtp-Source: AGHT+IHFhioVO+WSOS73stbnwyNMxN77R5XrtFVLfzanDmMUJu9h6D/pAJZBbTJ6adefF93zun91Vs5Y+5oZZYYXOX4= X-Received: by 2002:a17:907:a05:b0:a28:dfe4:1d0b with SMTP id bb5-20020a1709070a0500b00a28dfe41d0bmr860061ejc.31.1704662125138; Sun, 07 Jan 2024 13:15:25 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> <2f91eeb7-430b-49e2-817b-5acd0f445fe9@FreeBSD.org> In-Reply-To: <2f91eeb7-430b-49e2-817b-5acd0f445fe9@FreeBSD.org> From: Warner Losh Date: Sun, 7 Jan 2024 14:15:14 -0700 Message-ID: Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. To: lev@freebsd.org Cc: freebsd-fs , freebsd-stable Content-Type: multipart/alternative; boundary="0000000000006e66a9060e619437" X-Rspamd-Queue-Id: 4T7VMy4nckz45P7 X-Spamd-Bar: ---- 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:2a00:1450::/32, country:US] --0000000000006e66a9060e619437 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 7, 2024 at 1:57=E2=80=AFPM Lev Serebryakov wr= ote: > On 07.01.2024 21:49, Lev Serebryakov wrote: > > > On 07.01.2024 19:34, Warner Losh wrote: > > > >> I must have missed it. What were the diagnostics? > > Oh, and two "nvlist inconsistency" before that vvvv > > > zio_read error: 5 > > zio_read error: 5 > > zio_read error: 5 > 5 is EIO which the loader uses internally for any error that the disk reports. I've not read through all the code involved here, but I think that means there might be read errors for real. Though the nvlist inconsistency might be an issue. So, if this is a mirror, then ada0 blank and ada1 with good data, in theory you should be fine. However, perhaps ZFS is finding that there's an error from ada1 for real. Does all of ada1 read with a simple dd? Not sure about the losing devices you described later on. > ZFS: i/o error - all block copies unavailable > > ZFS: can't read MOS of pool zroot > > > > > > To be honest, I thinks there is something else. Because sequence of > events were (sorry, too long, but I think, tht every detail matters here)= : > Yea. There's something that's failing, which zio_read is woefully under reporting for our diagnostic efforts. And/or something is getting confused by the blank disk and/or the partially resilvered disk. > (1) Update to 13.2 from 12.4. With installation of new gptzfsboot with > gpart on both disks. It could place new /boot far away, but see (2) > > (2) Reboot, which completed, but showed that ada0 has problems > > (3) Replacement of ada0 by DC technicians, new disk is 512/4096, old > disk is 512/512, pool has ashift=3D9 > > (4) Server refuses to boot from ada1 (ada0 is empty) with diagnostics > (see above) > > (5) Linux rescue system, passing 2 devices to qemu with FreeBSD (becaus= e > Linux shows that ZFS is on whole disk, not on partition!). > > (6) Re-creation of GPT on ada0, start of resilver (with sub-optimal > ashift!). > > (7) Interruption of resilver with reboot, because it is painfully slow > under qemu. > > (8) Wipe of ada0 (at this point resilver status of pool becomes crazy) > to put live FreeBSD image to boot somehow. > > (9) Many tries to cancel resilver and boot from single-disk "historical= " > pool on ada1, no success. I've attributed it to the strange state of pool= : > one component, no mirrior, but "resilvering". > > (10) Boot from small UFS partition (which replaces swap partition). > > (11) Pool on ada1 (old, live, 512/512 disk) is still "Reslivering" > without any additional components (with zero speed, of course). > > (12) Prepare partitions on ada0 again, creating new pool with ashift=3D= 12, > send|receive. > > (13) Removing partition table on ada1 (with old pool, ashift=3D9, still > resilvering after many-many reboots with only one device in it). > > And pleas note: this pool on ada1 (old, live disk) was NOT upgraded > after 12-STABLE. It was old, 12-STABLE "level" pool with all new features > disabled. > Yea, this isn't *THAT*OtHER* problem :). Warner > -- > // Lev Serebryakov > > --0000000000006e66a9060e619437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 7, 2024 at 1:57=E2=80=AFP= M Lev Serebryakov <lev@freebsd.org> wrote:
On = 07.01.2024 21:49, Lev Serebryakov wrote:

> On 07.01.2024 19:34, Warner Losh wrote:
>
>> I must have missed it. What were the diagnostics?

=C2=A0 Oh, and two "nvlist inconsistency" before that vvvv

> zio_read error: 5
> zio_read error: 5
> zio_read error: 5



So= , if this is a mirror, then ada0 blank and ada1 with good data, in theory
you should be fine. However, perhaps ZFS is finding that there'= ;s an error from
ada1 for real. Does all of ada1 read with a simp= le dd?

Not sure about the losing devices you descr= ibed later on.

> ZFS: i/o error - all block copies unavailable
> ZFS: can't read MOS of pool zroot
>
>
>=C2=A0 =C2=A0To be honest, I thinks there is something else. Because se= quence of events were (sorry, too long, but I think, tht every detail matte= rs here):

Yea. There's something th= at's failing, which zio_read is woefully under reporting for our diagno= stic efforts. And/or something is
getting confused by the blank d= isk and/or the partially resilvered disk.


> (1) Update to 13.2 from 12.4. With installation of new gptzfsboot with= gpart on both disks. It could place new /boot far away, but see (2)
> (2) Reboot, which completed, but showed that ada0 has problems
> (3) Replacement of ada0 by DC technicians, new disk is 512/4096, old d= isk is 512/512, pool has ashift=3D9
> (4) Server refuses to boot from ada1 (ada0 is empty) with diagnostics = (see above)
> (5) Linux rescue system, passing 2 devices to qemu with FreeBSD (becau= se Linux shows that ZFS is on whole disk, not on partition!).
> (6) Re-creation of GPT on ada0, start of resilver (with sub-optimal as= hift!).
> (7) Interruption of resilver with reboot, because it is painfully slow= under qemu.
> (8) Wipe of ada0 (at this point resilver status of pool becomes crazy)= to put live FreeBSD image to boot somehow.
> (9) Many tries to cancel resilver and boot from single-disk "hist= orical" pool on ada1, no success. I've attributed it to the strang= e state of pool: one component, no mirrior, but "resilvering". > (10) Boot from small UFS partition (which replaces swap partition). > (11) Pool on ada1 (old, live, 512/512 disk) is still "Reslivering= " without any additional components (with zero speed, of course).
> (12) Prepare partitions on ada0 again, creating new pool with ashift= =3D12, send|receive.
> (13) Removing partition table on ada1 (with old pool, ashift=3D9, stil= l resilvering after many-many reboots with only one device in it).

=C2=A0 And pleas note: this pool on ada1 (old, live disk) was NOT upgraded = after 12-STABLE. It was old, 12-STABLE "level" pool with all new = features disabled.

Yea, this isn't = *THAT*OtHER* problem :).=C2=A0

Warner
= =C2=A0
--
// Lev Serebryakov

--0000000000006e66a9060e619437-- From nobody Sun Jan 7 21:19:33 2024 X-Original-To: freebsd-stable@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 4T7VSm0qB4z561Gl; Sun, 7 Jan 2024 21:19:36 +0000 (UTC) (envelope-from lev@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7VSl6ttKz46hp; Sun, 7 Jan 2024 21:19:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704662376; h=from:from:reply-to: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=Tg/IoX2r7626nl2FGGM3y4zlJB3O1AF5MWoK1EcwkpU=; b=k/jEy2sDVd1RCMH84prpz8uR7fa9/dZ3R7cixAVMOL51ksrrOexHYw5Uk8cYyLvlnyR5aP Gjeeqi7/YhPapzj/y+A2JAE7FiYc6Q6cg8OJMWBuInKkd7QfpAG4dgtBcdEFkoFD7T6wMz OSakZFlumu6821IUObA61/TeeImRmAGVOrfTqlpLZFOb67bpHC3GZsuhIkmw+5q/ScZuJA TDRHvz2cOfQnxUxE2pMcJuTHOE48VgLFGc0I1hQpwv21AWaaUi9/xSBovkoGqR3n3YWiHt EBdxuKOhRqO8oM5AWl1ydLQIKB2cW86Y+5xuwNYV+e/mIzh/UPmaoHo47WTcuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704662376; h=from:from:reply-to: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=Tg/IoX2r7626nl2FGGM3y4zlJB3O1AF5MWoK1EcwkpU=; b=bFDOLEhKyIU5N/of/+7Tb4pNfVkXWyTabzh6LucyFXnYEc/6SeRIge4jfW68Q/+Jg+Dzru eiI2wslKGzKH3BtntFK+oakNZjDHFV/iNBvpagksDiXtX2Xxwm/3+NeAGb1u3xWa6aSrxB nQZlH1j36QdYtlIM+xVTbWD/O5RtFXigj0Xz66+VGUZOHFXMOq//S/L66o6VNLq1ZkzW7u p1GfJgIfCnma65nQZwlY8Ud97V+Qze7YiJ8u3v33Xp/nF/FTXiIuBJ0iyyEwTFFGwpX1eY 6FwNuUyC8UrJ8eVEdTYB4uR+1tq75avKQz4hv8gLCGn34jgRMXAW3xmynzsrGw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704662376; a=rsa-sha256; cv=none; b=T+pn7GkMuahbcvW2yRNY3NUlAjJrDo7sutAWo16ezTyy9jZ7dTAoUBp491IUig9BpxoiKV 6U5d58u4IfQnAUQSpVHYWfhs5yh0w9SYkW0oHDe3NMk2CyThAAcZ/RGS3/oEW/UxQMy6kt KCWD+Pb1L0lhVIvvGwgmTBU4AwCn7Bd6SkcZSwYyNn+xYScVfwpAsY6Q8Mv90bWGuTL/Kg EuwlZ3TIeR8qigbHO1cvDgffuhzqTGkkQdXdUFRVevb8wOMgG9aVcoclf+fuESJ89HnC+E pjwnKKBLPe08XaSqdmvhN/iCSU9nYeBnjr8fT4DTcZ+5/rpFQGxUa+CnrHbpPQ== Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (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: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7VSl5FyfzZfS; Sun, 7 Jan 2024 21:19:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.136.24] (83-84-181-95.cable.dynamic.v4.ziggo.nl [83.84.181.95]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id EC91F299; Mon, 8 Jan 2024 00:19:33 +0300 (MSK) Message-ID: <962b242d-546f-46ce-9eb2-9bd2a10f4608@FreeBSD.org> Date: Sun, 7 Jan 2024 22:19:33 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: lev@FreeBSD.org Subject: Re: FreeBSD 13.2-STABLE can not boot from damaged mirror AND pool stuck in "resilver" state even without new devices. Content-Language: en-US To: Warner Losh Cc: freebsd-fs , freebsd-stable References: <065f4f5c-f38b-45f4-b7e7-5248f871f7e6@FreeBSD.org> <2f91eeb7-430b-49e2-817b-5acd0f445fe9@FreeBSD.org> From: Lev Serebryakov Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07.01.2024 22:15, Warner Losh wrote: > So, if this is a mirror, then ada0 blank and ada1 with good data, in theory > you should be fine. However, perhaps ZFS is finding that there's an error from > ada1 for real. Does all of ada1 read with a simple dd? Yep, it is read with dd, I've checked it > Not sure about the losing devices you described later on. > > > ZFS: i/o error - all block copies unavailable > > ZFS: can't read MOS of pool zroot > > > > > >   To be honest, I thinks there is something else. Because sequence of events were (sorry, too long, but I think, tht every detail matters here): > > > Yea. There's something that's failing, which zio_read is woefully under reporting for our diagnostic efforts. And/or something is > getting confused by the blank disk and/or the partially resilvered disk. My theory, that something is confused when one disk is 512/4096 and other is 512/512. I want to check it on VM, but can not find VM that both (1) allows CMS boot and (2) allows to configure logical and physical sector of virtual HDD. bhyve could configure sector sizes, but doesn't support BIOS, and VBox and qemu-system can not emulate sector sizes (or I can not google proper configuration). -- // Lev Serebryakov