From nobody Mon Apr 15 00:11:07 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 4VHndj5N6qz5HM8k for ; Mon, 15 Apr 2024 00:11:21 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 4VHndj2pZTz46qY for ; Mon, 15 Apr 2024 00:11:21 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-61acfd3fd3fso3938737b3.1 for ; Sun, 14 Apr 2024 17:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1713139880; x=1713744680; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yGV3vfwdcZsRbNBWdLa9IXLhBoz/DID/xRf1tMZ48+Y=; b=JOSn29Vz4fVmO9vKNKG7L1UUqrFM2j63Tnm+X+UqMZRqihrtyFycsHRU4XoG/rRUAc 7a5J+8AUy5IlXSoo9hAz6iK/+zvbMH2waVIjm9SFyCreOXeKPnvSf86r+fUcVWoTgJwA JM5FPNuSHiFi1MRiZ/GwzNsuq2GAhpni+xmI4PhKJ/Up8LpOnGbxronBge4TnQYJAKEn JXPcOEhLH52MUgT7Dhdgq0aDS410U9GLv/6/nzEAfMxguRj03cLeSOJ8xtmjcEGXUGCW JRQ0jtcH1x+twmOeJwwviETYRaEoQtUmx9lm6Nx0Avu6UogQiuWin8cDuuCmt2WgmScB wpWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713139880; x=1713744680; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yGV3vfwdcZsRbNBWdLa9IXLhBoz/DID/xRf1tMZ48+Y=; b=Ni2xokkgJmxg1es0arYizSMaJ/yLCkG8SdiQGE7DU0S5KE5WrjA7z2XvNUdg1p1ltE Pa+WdqEeeDfwyfhEyaH3fCPGVmw19DQkbjh7JVpW40uBttAMX19KBDymtvVdPC9FZsWl B4a9spFV2zjfdh/1iMhk6WijCJgv1FlJy0KmWKmVrRJvpfwTVzV/VCv1myxb3qv83SpZ agDhu7VVfr7b/2/Pc2uFDzwTeFgoOr3Vz9geyJbQ17AsEn0731ZUNhv+jdkKZD/NeWbK rKUGS/7oPZtIrLAoz4X6EO5WcKaLC9nEnB353C49UHvS79OKw+fwPA9zndPBQMoOoNbu aY9g== X-Gm-Message-State: AOJu0YyYAxw+XJpMPNHA9qv0BMsSZc8sDBHIk8ycn37uLJGjjTMDHOvt HMqPeZinDIG9MO4P1PNc6M5+THhvGWBbGwWGV8EcM3/CCwdjnSIMsCXr4pEeL61MBKbv7lmybO8 = X-Google-Smtp-Source: AGHT+IErZuPI9Jqqn9kgRCg0X+evPXFUdusAC0gkdnLK4p+Oxz5d5eUCG0rasSz43DP3PCMFueIguQ== X-Received: by 2002:a81:7189:0:b0:60a:6ad0:6c72 with SMTP id m131-20020a817189000000b0060a6ad06c72mr8034401ywc.36.1713139879818; Sun, 14 Apr 2024 17:11:19 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id f63-20020a81a842000000b006187ad29fe8sm1409316ywh.61.2024.04.14.17.11.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Apr 2024 17:11:19 -0700 (PDT) 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: X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: What's happening to Sender: headers? From: Bakul Shah In-Reply-To: Date: Sun, 14 Apr 2024 17:11:07 -0700 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7338D9DD-E075-4382-9769-8188FDC639EB@iitbombay.org> References: To: Andrew Reilly X-Mailer: Apple Mail (2.3774.500.171.1.1) 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] X-Rspamd-Queue-Id: 4VHndj2pZTz46qY > On Apr 14, 2024, at 3:33=E2=80=AFPM, Andrew Reilly = wrote: >=20 >=20 > Over the weekend I got around to investigating, and discovered that = the errant messages don=E2=80=99t _have_ a Sender: header. There=E2=80=99= s a Return-Path: header that captures the envelope-from, but I haven=E2=80= =99t figured out how to make sieve check that yet: it doesn=E2=80=99t = seem to like it. Sieve documentation is spectacularly inconclusive, but = I suspect that the envelope extension might do what I want, but that=E2=80= =99s not really my question. >=20 > Does anyone know why the Sender: header, which used to be so reliable = that I had thought it an intrinsic part of the SMTP/MTA ecosystem, has = gone away, or is at least not ubiquitous? The Sender: field is optional. I don't know why FreeBSD stopped using it = but I filter on List-Id: (which is used by pretty much every mailing = list), which seems more appropriate.= From nobody Mon Apr 15 00:21: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 4VHnsk48DHz5HMkr for ; Mon, 15 Apr 2024 00:21:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 4VHnsk0hbYz4C8b for ; Mon, 15 Apr 2024 00:21:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2d82713f473so44978271fa.3 for ; Sun, 14 Apr 2024 17:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1713140501; x=1713745301; 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=N/dhJUv1a7uUoczFlI0jLqnS8vSSGAlnOISYjDGGR+k=; b=gHkVnQh6MswuDdFemxmQSR6Xv2ohruUhT/Ek8DdL2FWd1QoYXmyMyy4peFFWphSsXw 0L/NAP/wvV0KwpTlQmp4vAvjenew6x12OGMShPd92TrUzqU9DBA4Wx82W7NASd+4WHJe /beaxLjiOok4p8SUzJBbVMsVNeKsCg3mn1IfkISiLumvyCo3QqGDzEfWAkUSjLbFieBs hhNpE1r3Kbekzb8eOBFN/E1VC4vJ+CJnM1MNOFj5ECSHvFazhIGJpp7M7nrp2MkVPF6g 4cL8xSgLzWPMjGDBnNqqeY3KicH4ipLMTz2B2LTzJ2+zNmkph5i8rkHeUnImQHivkSIe we0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713140501; x=1713745301; 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=N/dhJUv1a7uUoczFlI0jLqnS8vSSGAlnOISYjDGGR+k=; b=hQK55QyVBO7Viq8Pk49P+yRTrLgeYFdnaol1+UM9FXAGTnIw3JItJLF5ZR2uFiGDQT +kY7m/4M+I8ci/ZtBtt81uByV8N/6LDrTvtQ1CILGl2lsrPziJ2n3jE85CyOAQiASH3r etV2n+WskYyOl7EsNcdePjfa3BHKp/zX2qev1/+xaMrCt4mMmJjUJIp4BKu+hoqedZg/ HjHZPKjpPL0ARrM8Gr6wt52V3omOIM9L5JnscZAkrAlB8uH1tRw45KWnjwLzzHoxT6gT NYSWEnn6glPapXmzMzmOgSW9H0qVvtu2/4zSHX/qtdj+9qqO4NaiYmaPK4edFGpFhho+ I/Og== X-Forwarded-Encrypted: i=1; AJvYcCVDsWGznbtyiC+JkSbLLP3MoOqTM5OLgTlNijF21ebwd6fUBZRLVMyJ4/TG4pd9q96HRPECCWJiXxjh03RG29WEiHAcXvjLzsHe0w== X-Gm-Message-State: AOJu0YyBe8Q7mJIW6+CW0DeaUHtsK/Vve7h0cV0tqgDvgHJHCRCEsm3O 8pDrfHXsDsot38UtfzrEJsAACEXdKMvbN7MU3kD49m5Y7Y4hk8Vx/L0hEGfHZPG7xE4HcDl37o1 0xZGcfkgBN8rYfVP3kLEE1xsVKg32YxddQm2exA== X-Google-Smtp-Source: AGHT+IFOb0RLc3RuK1zJniwN1kzZP9WNabfF2XTPkYTWC3+p1TAPsykTCLKzkaT4dYTMkTCJ/rbWLX/A5xo2rARAqWo= X-Received: by 2002:a2e:3209:0:b0:2d6:8e88:5a8b with SMTP id y9-20020a2e3209000000b002d68e885a8bmr6527708ljy.32.1713140500561; Sun, 14 Apr 2024 17:21:40 -0700 (PDT) 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: X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <7338D9DD-E075-4382-9769-8188FDC639EB@iitbombay.org> In-Reply-To: <7338D9DD-E075-4382-9769-8188FDC639EB@iitbombay.org> From: Warner Losh Date: Sun, 14 Apr 2024 18:21:27 -0600 Message-ID: Subject: Re: What's happening to Sender: headers? To: Bakul Shah Cc: Andrew Reilly , FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="000000000000fca6900616179a70" 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] X-Rspamd-Queue-Id: 4VHnsk0hbYz4C8b --000000000000fca6900616179a70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2024, 6:11=E2=80=AFPM Bakul Shah wrot= e: > > > > On Apr 14, 2024, at 3:33=E2=80=AFPM, Andrew Reilly > wrote: > > > > > > Over the weekend I got around to investigating, and discovered that the > errant messages don=E2=80=99t _have_ a Sender: header. There=E2=80=99s a= Return-Path: > header that captures the envelope-from, but I haven=E2=80=99t figured out= how to > make sieve check that yet: it doesn=E2=80=99t seem to like it. Sieve doc= umentation > is spectacularly inconclusive, but I suspect that the envelope extension > might do what I want, but that=E2=80=99s not really my question. > > > > Does anyone know why the Sender: header, which used to be so reliable > that I had thought it an intrinsic part of the SMTP/MTA ecosystem, has go= ne > away, or is at least not ubiquitous? > > The Sender: field is optional. I don't know why FreeBSD stopped using it > but I filter on List-Id: (which is used by pretty much every mailing list= ), > which seems more appropriate. > Bapt is going to restore it Monday. It's useful for vacation(1) still apparently. Warner > --000000000000fca6900616179a70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 14, 2024, 6:11=E2=80=AFPM Bakul Shah <<= a href=3D"mailto:bakul@iitbombay.org">bakul@iitbombay.org> wrote:


> On Apr 14, 2024, at 3:33=E2=80=AFPM, Andrew Reilly <areilly@big= pond.net.au> wrote:
>
>
> Over the weekend I got around to investigating, and discovered that th= e errant messages don=E2=80=99t _have_ a Sender: header.=C2=A0 There=E2=80= =99s a Return-Path: header that captures the envelope-from, but I haven=E2= =80=99t figured out how to make sieve check that yet: it doesn=E2=80=99t se= em to like it.=C2=A0 Sieve documentation is spectacularly inconclusive, but= I suspect that the envelope extension might do what I want, but that=E2=80= =99s not really my question.
>
> Does anyone know why the Sender: header, which used to be so reliable = that I had thought it an intrinsic part of the SMTP/MTA ecosystem, has gone= away, or is at least not ubiquitous?

The Sender: field is optional. I don't know why FreeBSD stopped using i= t but I filter on List-Id: (which is used by pretty much every mailing list= ), which seems more appropriate.

Bapt is going to restore it Monday. It'= s useful for vacation(1) still apparently.=C2=A0
Warner=C2=A0
--000000000000fca6900616179a70-- From nobody Tue Apr 16 01:50:29 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 4VJRnj3Yssz5HWcH for ; Tue, 16 Apr 2024 01:50:33 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (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 "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJRnh3yC9z4CLw for ; Tue, 16 Apr 2024 01:50:32 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuta.io header.s=s1 header.b=XaIotSOP; dmarc=pass (policy=quarantine) header.from=tuta.io; spf=pass (mx1.freebsd.org: domain of henrichhartzer@tuta.io designates 81.3.6.162 as permitted sender) smtp.mailfrom=henrichhartzer@tuta.io Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 10022FBFAA9 for ; Tue, 16 Apr 2024 01:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1713232229; s=s1; d=tuta.io; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=TyUTW8m7A5ZelbxPLLfsoTCIKPLVzTZdTgLinoaknCA=; b=XaIotSOPWRoJ4WrReZyzPSv3sk/wsieBjALM3WqkpuNKEolyvO0ESCtALQMuRP8m ApTwZkVjmRXRLrhZD7XMJTjOZDJNqmAQsNHAkglwNP7uyc6cLxHmtRNaV08ycSlY46l S/H2QN5k4eBXq+gUF23yLRTjbIgOSvlrHKEKmvniDHg+F0Fqv8rkdKBfq5bD19QzIcO 3XN+P3NdxFELZyuJ7V8Eqj6GYaLadVgHcZmDlOSDf+c2IPPNILf+EjyauuhO71Oj2+c TLuOPtQV4sZBjZyv/CRjPIwNOQjgoimOYrr8ZuQm81pEuNn9mal5ImLU35Ow2BmMzYp mPu6DrXCGA== Date: Tue, 16 Apr 2024 03:50:29 +0200 (CEST) From: henrichhartzer@tuta.io To: Freebsd Stable Message-ID: In-Reply-To: References: Subject: zroot on 14.0-RELEASE quickly becomes unreadable by the boot loader 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.08 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[tuta.io,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tuta.io:s=s1]; RWL_MAILSPIKE_VERYGOOD(-0.20)[81.3.6.162:from]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[tuta.io:+] X-Rspamd-Queue-Id: 4VJRnh3yC9z4CLw Hi everyone, I had previous thread titled: Can't find bootable partition I also have a forum thread for this, but it's slow going as my account is not yet verified and each post requires approval: https://forums.freebsd.org/threads/14-0-stopped-booting-mysteriously-zfs-mirror.93101/ Here's what I had to do to produce a non-booting system: Details: 14.0-RELEASE x86_64 2x 16TB harddrives ZFS mirror installed with GPT UEFI. "Automatic" ZFS install. 8GB RAM Hardware has ECC and passed memtest. Fully updated with freebsd-update. Intel S1260 Atom (non-speculative execution processor) After writing over 1TB of random data to the filesystem and pressing the reset button on the server, (a regular reboot might've been sufficient as well, but not sure) it booted but the boot loader had "zio_read error: 5" errors plastering over top of the menu. It still booted, nonetheless. After that successful boot, I rebooted and the boot loader failed quickly, dumping me into a UEFI shell. I've had at least two similar failures like this already. I don't suspect a full 1TB written is required to cause it. BIOS boot, from a previous install, also did not appear to work. I also don't suspcet that patches, or lack of patches, influences the issue. It's *possible* that somehow hardware is to blame, but while running the server has had no instability or odd behaviors. I've done make kernel and make world without incident. I've rsynced several TB without issue as well. Whenever this happens, I can zpool import zroot from the installer and zpool shows no errors. And smartctl shows no errors (this is the third pair of drives I've had this happen with). I've yet to have a zpool scrub come back with errors. Has anyone else had any issues like this? It's very perplexing and concerning. Thank you! -Henrich From nobody Tue Apr 16 21:53:49 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 4VJyV64pLFz5H8kr for ; Tue, 16 Apr 2024 21:53:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJyV63nzMz4djk for ; Tue, 16 Apr 2024 21:53:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713304430; a=rsa-sha256; cv=none; b=V8cpe6OwSvfHcl4OcovoyrG5ATYvEgFLBke1xKC1QSNmVnnVVGl0CFpbSqeFHNVHnJa5SE v509iIYamyGtriTR8c5At05LZ+807qG2fWq2hPHOYY/vLvjEUdjN6fKdxAEgf+VKvvwWpP fHE16q3xGagFu5v3hBlAOy9g+RxkkRNrJL7EURtI413sgRLWNgS0scUMbnHKtmOKnimjpy hccDS/mMZvno/uLt6FItg7VMm2zljrLHHeIr/Ijp1kC2FqAXRhCzQ3GtGTGF4GSNje8Fhj Via7kedHW4Zi03hcHFPE2PveL0jr6JKdk7s54kFmXAECwoFIp0k82xFYwH56Aw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713304430; 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=cSYuGhd4rh1FQvqfk+QbSgO7y4W7WbeTS4Bnjcj8Pj4=; b=A0AHU44MQkWgak8wwVUZyKWYSNKREb3R475cgcKdagG7YTY54Rgm0zjR9SWbxHChXBnrIL nnS67MIBC3oszTWhm5bMMJhOs05A+GPwm/2N3tgyK5gY8PJ70jl7wGK8yZ3C7Ht2sZkphn 0i8XGzvMBQvmTpMQj7qVHUqHdFV3ZHDpkTu3XMqqo8/fFocCJowidg8FkY7iQY4rX101Km mpDs0fCF9Ll4wMeN9ig4ZvRMNkgjmRkA5mpk0FIVwN9lQ/BzooErj+FWN2Dsh6bD7+X+Uo qEACb0FvphulUle2ldVgYKN6lm4ZKfHyXGcM2cN5/RFUv4qHjvVZFZu2MPOSbw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VJyV63NMFz10sw for ; Tue, 16 Apr 2024 21:53:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43GLroux071976 for ; Tue, 16 Apr 2024 21:53:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43GLroV3071970 for stable@FreeBSD.org; Tue, 16 Apr 2024 21:53:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 278099] outdated version of zstd(1) is kept in the base Date: Tue, 16 Apr 2024 21:53:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: needs-patch, performance, regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: delphij@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278099 --- Comment #6 from Xin LI --- (In reply to Alexander Motin from comment #3) For future reference in case someone wanted to give this a shot, the concer= ns at OpenZFS[1] was that different versions of zstd may [2] generate different output for the same data. When compressed ARC is disabled (enabled by default), ARC would only have a copy of uncompressed data, but the MAC was calculated against compressed data, so arc_hdr_authenticate() would see a mismatch because it's now using a newer version of zstd to compress the data (for performance reasons, because re-compression is faster than reading the data back from disk). [1] https://github.com/openzfs/zfs/pull/11367#pullrequestreview-559645117 further explained in https://github.com/openzfs/zfs/pull/11367#issuecomment-753517958 [2] https://github.com/facebook/zstd/issues/999#issuecomment-359538229 --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Apr 16 22:08:18 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 4VJypq6QcQz5HBQ8 for ; Tue, 16 Apr 2024 22:08:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJypq1sJ0z4hhj for ; Tue, 16 Apr 2024 22:08:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713305299; a=rsa-sha256; cv=none; b=ZiE6w9B9ZRv/UyAbUtzZFu7ji6vs5yW5No0oi+y5xpdFZy6MEqEYW7PmGwptPzas3tslKx o7lyH4hX2LVXMTf8xqJaoSzMas43qeNnNiGIaPml/sPTwaDaLY6zb1l6y3R79yZiv9pv5T pq8Jt+vGNM8zgjHpCvoYL0HpAr3nPZB0j6/o9+Q6YO6+ves1XUI4AmJ9ho/lR6cpbwZ73r iPQQhRLyIaOKn8H+udKihEpTkPtJZWeXmYVAQvWgtJmwXzMVADF8auOxUnWQeYcRZwa63D S0jbAgHLCCRz/SjpcoWZ3OyDC/rxOrGrwmkd8Afe7RTJ2ZIvvuqu1Zsfun/UBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713305299; 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=6yY/R2k16/jn6bB4guc4gZc0BDlRCoZJJW+smbn8Efs=; b=LrX6meaGMrgb7jY1R4N0NtuGQ8GGBFr0soJxxOlPJxfGnNjhPIvFP5ubE1cknzGtIjdWRS Bo7W52thzBZil3HORzZQvr3jFUr/i8jLj7tNQfwNpJZTy3L5XUzrnB3pjzm49mQBFTLX9C Pj/j7+QtGcx0QbJ/tJamgya5Wq8Wjji3Iqym68opsdPx4QJlOk2bCyN+RHZ/cI1RIufl48 +1phMb+WHD1+0NTzHY/+Fqe1gDnDHDo2Vc6qbNse8Z017xJN1RAcEyza+ywfsVzYgSMtYL YkbZKsDVCQ/vzKN2VyPrDTxeCm56RPAsg3G1MmcS7PKpRJF9UCEPSJndUICwwg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VJypq1D3bz10PN for ; Tue, 16 Apr 2024 22:08:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43GM8JNV048843 for ; Tue, 16 Apr 2024 22:08:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43GM8JET048842 for stable@FreeBSD.org; Tue, 16 Apr 2024 22:08:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 278099] outdated version of zstd(1) is kept in the base Date: Tue, 16 Apr 2024 22:08:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: needs-patch, performance, regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: alex-freebsd-bugs@alexburke.ca X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278099 alex-freebsd-bugs@alexburke.ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alex-freebsd-bugs@alexburke | |.ca --- Comment #7 from alex-freebsd-bugs@alexburke.ca --- (In reply to Dag-Erling Sm=C3=B8rgrav from comment #4) > =E2=80=9Cpronity=E2=80=9D is not a word I think it's a perfectly cromulent word, and at any rate if Shakespeare cou= ld make up his own words then so can Marek. --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Apr 16 23:09:09 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 4VK09237Zwz5HHQr for ; Tue, 16 Apr 2024 23:09:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VK0920G8yz4spK for ; Tue, 16 Apr 2024 23:09:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713308950; a=rsa-sha256; cv=none; b=vjNr5iS5yaEz1nQXmZYhdybImgDr6e4nUz2lUrYxeEkpVaGzqXRkz38f/chdjG1CU6oNqC hCXipQekqy9StAHTpLyf53ANQhj5wSHg1b2zYYys8oL1IdejN5YrnTMSD+B2RLNN5HXggQ GfT3Oop8y5OiIY5WLtydLRdbZRF7t1XL6SBfiDHT3tg5+9ldul5C/M+9akYZ+klIVuk7JE kzmHgI8YzycGEfh9zwUeirhLq2PVOFqkW+B9szpfqez/fV0LcOlfr3Hsox4esjdFkdyLqq n+e//28IiNgMx4hT8gLU03e1s8jHtZDx//L/ayZOYx/DfCX7RCXFr9YDtKipHw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713308950; 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=3b+/5PuaugCcw5YNOf6yjmg4zfmYkJWqPKp/djpqe/M=; b=cK+aV6BPudoY+fS9PLB99K3nxb06okZALjuSM4AoVGdXBiBHOvj7UW0khp56bzQ+0qUuxi MBX3hoSqWUy2MvZZLrO30x5IYqEbz78voKYTLsfVYKTt6NgD/Q1dS9xCIe8t8sGkYIV4eU 4finKqDh6xj6L9/S56LdQj1QBXfmfJiRsU4PS71wsYDXEpqcBtNeNuqNF3DZhiqBTY7ULo kPz6EyRPKxipmY4N6w8w/PbOhXjnqEDi+y29LEoR8Vp2PysNcRh8+jpfz1vwkjFGWtGL/o ANjrrYXCbYTBlySbrreKBSRuqj0iygVBLF2OxwO3/BJcEV0uahEprMzwOzRyrQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VK0916syfz12S8 for ; Tue, 16 Apr 2024 23:09:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43GN99e8002732 for ; Tue, 16 Apr 2024 23:09:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43GN999O002731 for stable@FreeBSD.org; Tue, 16 Apr 2024 23:09:09 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 278099] outdated version of zstd(1) is kept in the base Date: Tue, 16 Apr 2024 23:09:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: needs-patch, performance, regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: portmaster@bsdforge.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278099 --- Comment #8 from Chris Hutchinson --- pronity: noun Proneness; propensity. It *is* a word. It's been in use since 1913. If you happen to have a copy of the Websters dictionary with a print/publishing date of 1913. You'll find it there. Do Note; it will need to be an American-English dictionary. Sorry. I couldn't resist. :) --Chris --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Wed Apr 17 17:03: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 4VKS0d0YMGz5HFH7 for ; Wed, 17 Apr 2024 17:03:29 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "gilb.zs64.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VKS0c0QVkz3xCY for ; Wed, 17 Apr 2024 17:03:27 +0000 (UTC) (envelope-from stb@lassitu.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 212.12.50.234 as permitted sender) smtp.mailfrom=stb@lassitu.de Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 6DA255A2C50; Wed, 17 Apr 2024 17:03:19 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_AD28BFE7-F609-4FCE-BBAA-2427B268C91B"; protocol="application/pgp-signature"; micalg=pgp-sha512 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: zroot on 14.0-RELEASE quickly becomes unreadable by the boot loader From: Stefan Bethke In-Reply-To: Date: Wed, 17 Apr 2024 19:03:18 +0200 Cc: Freebsd Stable Message-Id: <11A8BB6B-ADCD-4A59-8956-C9E8BC9BB6EF@lassitu.de> References: To: henrichhartzer@tuta.io X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.79 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; ONCE_RECEIVED(0.10)[]; FREEFALL_USER(0.00)[stb]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:13135, ipnet:212.12.48.0/21, country:DE]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[lassitu.de]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4VKS0c0QVkz3xCY --Apple-Mail=_AD28BFE7-F609-4FCE-BBAA-2427B268C91B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 16.04.2024 um 03:50 schrieb henrichhartzer@tuta.io: > I also have a forum thread for this, but it's slow going as my account = is not yet verified and each post requires approval: = https://forums.freebsd.org/threads/14-0-stopped-booting-mysteriously-zfs-m= irror.93101/ >=20 > 2x 16TB harddrives Some BIOSes (and maybe UEFI too) might have issues accessing blocks = beyond a certain number. Try creating a pool just for the OS that is = small-ish (1 TB max) and see if you can still reproduce the issue. Stefan --=20 Stefan Bethke Fon +49 175 3288861 --Apple-Mail=_AD28BFE7-F609-4FCE-BBAA-2427B268C91B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAmYgANYACgkQD885WK4W 4sEBaAf8CwILIXRaZaChgldU0hKFGn3KffHpOon9wBIrj82xwKkPhjeFmzQEcEdl C8MM0JACzLEuHz6k0OubqfPHrS042nS74IHFMVjgjePQieCUIdayGx9BKytJxMBV opjd1YCyrwjNBymuSsuPNU/3V9g6pIGne0txMiroRQdOLDDzmGLTcEWWTDio21SP oH4wXAooJMRAg84KMKC4Gzidh4Eag3dG1wcxcqkYSka7YYBK/lxfZ1BWbufzmlgZ madkh12eKjN8hm63IOQS+qu3XupGq/NeLiXwARXe32NPPHSRZAcU0YzNVLaNnxYd NChRsI7Du5fofnfb9Hqt0HfwycEONQ== =H4vx -----END PGP SIGNATURE----- --Apple-Mail=_AD28BFE7-F609-4FCE-BBAA-2427B268C91B-- From nobody Thu Apr 18 13:37: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 4VKzNz4Bjdz5GsyG for ; Thu, 18 Apr 2024 13:37:55 +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 4VKzNy59M2z4Kv5 for ; Thu, 18 Apr 2024 13:37:54 +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 43IDbmBP006465 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) for ; Thu, 18 Apr 2024 09:37:48 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e] ([IPv6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 43IDbhkM095043 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 18 Apr 2024 09:37:47 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <82761f2b-475f-43ab-b045-95c60c330db7@sentex.net> Date: Thu, 18 Apr 2024 09:37:43 -0400 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-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: zfs boot error on mirrored drive 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.86 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.25 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.860]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received]; XM_UA_NO_VERSION(0.01)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[mike]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; MIME_TRACE(0.00)[0:+]; 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)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sentex.net]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4VKzNy59M2z4Kv5 I have a strange bootup issue on a test box that I just updated from 11, to 12 and now RELENG13. Its a simple mirror. But if I boot up with ada0, I get an error and cannot boot further. Where as if I boot up with ada1, I get some errors and then proceeds to boot normally. For one thing, I dont get where zbackup1 is coming from. The pool I boot from is zroot ?!? Where would that reference be stored ? I think ada0 was part of another pool long ago (zbackup1). Here is the error when booting from disk 0 BIOS drive C: is disk0 BIOS drive D: is disk1 zio_read error: 5 zio_read error: 5 ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool zbackup1 ZFS: can't find pool by guid Can't find /boot/zfsloader Can't find /boot/loader Can't find /boot/kernel/kernel FreeBSD/x86 boot Default: /boot/kernel/kernel boot: Here are the messages when booting from disk 1 Loading /boot/d| disk1 zio_read error: 5 zio_read error: 5 ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool zbackup1 BIOS 615kB/3363840kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 and it continues on from there and boots After I did the zpool upgrade zroot, I did gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1   pool: zroot  state: ONLINE   scan: resilvered 195G in 01:04:31 with 0 errors on Mon May 25 16:08:21 2020 config:         NAME        STATE     READ WRITE CKSUM         zroot       ONLINE       0     0     0           mirror-0  ONLINE       0     0     0             ada0p3  ONLINE       0     0     0             ada1p3  ONLINE       0     0     0 errors: No known data errors Whats odd is that zbackup1 is not the name of the pool.  Where is that coming from ?  The pool I boot from is zroot on this box Loading /boot/defaults/loader.conf Loading /boot/loader.conf.local Loading /boot/d| disk1 zio_read error: 5 zio_read error: 5 ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool zbackup1 BIOS 615kB/3363840kB available memory 1(nanobsd2)# gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 3907029127 first: 40 entries: 128 scheme: GPT Providers: 1. Name: ada0p1    Mediasize: 524288 (512K)    Sectorsize: 512    Stripesize: 0    Stripeoffset: 20480    Mode: r0w0e0    efimedia: HD(1,GPT,55d32563-9eba-11ea-87ad-0007430611a8,0x28,0x400)    rawuuid: 55d32563-9eba-11ea-87ad-0007430611a8    rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f    label: (null)    length: 524288    offset: 20480    type: freebsd-boot    index: 1    end: 1063    start: 40 2. Name: ada0p2    Mediasize: 21474836480 (20G)    Sectorsize: 512    Stripesize: 0    Stripeoffset: 1048576    Mode: r1w1e0    efimedia: HD(2,GPT,55d3938d-9eba-11ea-87ad-0007430611a8,0x800,0x2800000)    rawuuid: 55d3938d-9eba-11ea-87ad-0007430611a8    rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b    label: (null)    length: 21474836480    offset: 1048576    type: freebsd-swap    index: 2    end: 41945087    start: 2048 3. Name: ada0p3    Mediasize: 1978922958848 (1.8T)    Sectorsize: 512    Stripesize: 0    Stripeoffset: 21475885056    Mode: r1w1e1    efimedia: HD(3,GPT,563d7775-9eba-11ea-87ad-0007430611a8,0x2800800,0xe6608000)    rawuuid: 563d7775-9eba-11ea-87ad-0007430611a8    rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b    label: (null)    length: 1978922958848    offset: 21475885056    type: freebsd-zfs    index: 3    end: 3907028991    start: 41945088 Consumers: 1. Name: ada0    Mediasize: 2000398934016 (1.8T)    Sectorsize: 512    Mode: r2w2e3 0(nanobsd2)# gpart list ada1 Geom name: ada1 modified: false state: OK fwheads: 16 fwsectors: 63 last: 3907029134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada1p1    Mediasize: 524288 (512K)    Sectorsize: 512    Stripesize: 0    Stripeoffset: 20480    Mode: r0w0e0    efimedia: HD(1,GPT,25a0d50e-4207-11e6-8ebd-003048d6ef12,0x28,0x400)    rawuuid: 25a0d50e-4207-11e6-8ebd-003048d6ef12    rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f    label: gptboot1    length: 524288    offset: 20480    type: freebsd-boot    index: 1    end: 1063    start: 40 2. Name: ada1p2    Mediasize: 21474836480 (20G)    Sectorsize: 512    Stripesize: 0    Stripeoffset: 1048576    Mode: r1w1e0    efimedia: HD(2,GPT,25b0e143-4207-11e6-8ebd-003048d6ef12,0x800,0x2800000)    rawuuid: 25b0e143-4207-11e6-8ebd-003048d6ef12    rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b    label: swap1    length: 21474836480    offset: 1048576    type: freebsd-swap    index: 2    end: 41945087    start: 2048 3. Name: ada1p3    Mediasize: 1978922958848 (1.8T)    Sectorsize: 512    Stripesize: 0    Stripeoffset: 21475885056    Mode: r1w1e1    efimedia: HD(3,GPT,25c584a8-4207-11e6-8ebd-003048d6ef12,0x2800800,0xe6608000)    rawuuid: 25c584a8-4207-11e6-8ebd-003048d6ef12    rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b    label: zfs1    length: 1978922958848    offset: 21475885056    type: freebsd-zfs    index: 3    end: 3907028991    start: 41945088 Consumers: 1. Name: ada1    Mediasize: 2000398934016 (1.8T)    Sectorsize: 512    Mode: r2w2e3 It looks like if I do just a 0(nanobsd2)# zpool import    pool: zbackup1      id: 5819795054093255811   state: UNAVAIL status: The pool was last accessed by another system.  action: The pool cannot be imported due to damaged devices or data.    see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY  config:         zbackup1                  UNAVAIL  insufficient replicas           raidz2-2                UNAVAIL  insufficient replicas             da5                   UNAVAIL  cannot open             mfisyspd8             UNAVAIL  cannot open             mfisyspd7             UNAVAIL  cannot open             mfisyspd6             UNAVAIL  cannot open             ada0                  UNAVAIL  cannot open             17460231907795801757  UNAVAIL  cannot open 0(nanobsd2)# it thinks ada0 is/was part of an old pool.  How do I get rid of that reference ?     ---Mike From nobody Thu Apr 18 14:04:57 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 4VL00H5sd8z5GwJ7 for ; Thu, 18 Apr 2024 14:05:03 +0000 (UTC) (envelope-from SRS0=kxRp=LX=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 4VL00H4wBMz4R9Y for ; Thu, 18 Apr 2024 14:05:03 +0000 (UTC) (envelope-from SRS0=kxRp=LX=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 78A75D7889; Thu, 18 Apr 2024 16:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1713449101; bh=qMge3VTrsI/AX9ol3acZ8XD9NAYCj0DDEqdnnHlJR18=; h=Date:Subject:To:References:From:In-Reply-To; b=BBXEd2t0199XFqlZAd+nPSDlY5xBm+nPP8TPm9rD0d9S/AhupZKBVzr3fyWatAjaI 3JTXKrAt0eED0uGQ4Mo8LxzxS3yIltm8hX/2vt4Hzar9qgjhk2jdcJtrHo+iJQYCpj 3uCmFCGsTfxC9JutgM0saRwWlR12y98vjY6dkqUM= 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 8F1B6D788C; Thu, 18 Apr 2024 16:04:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1713449097; bh=qMge3VTrsI/AX9ol3acZ8XD9NAYCj0DDEqdnnHlJR18=; h=Date:Subject:To:References:From:In-Reply-To; b=p3t2Dbkb+Kd+ntVzGQEUl6dDIt2RRFuKAZM3bOes6U897/K389wSA6jmWW6m3t2vL C9QKsV1xMFN1udPQw5WC5ji9iJYeuZB6x3OwfEUuXPGZEcJxxCsee437h23NPjhi/g LPSblEMMt9ZamJzJHUvh0DIvSeUXiaCPW+mDThT4= Message-ID: Date: Thu, 18 Apr 2024 16:04:57 +0200 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: zfs boot error on mirrored drive To: mike tancsa , FreeBSD-STABLE Mailing List References: <82761f2b-475f-43ab-b045-95c60c330db7@sentex.net> Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <82761f2b-475f-43ab-b045-95c60c330db7@sentex.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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] X-Rspamd-Queue-Id: 4VL00H4wBMz4R9Y On 18/04/2024 15:37, mike tancsa wrote: > I have a strange bootup issue on a test box that I just updated from 11, > to 12 and now RELENG13. > > Its a simple mirror. But if I boot up with ada0, I get an error and > cannot boot further. Where as if I boot up with ada1, I get some errors > and then proceeds to boot normally. > > For one thing, I dont get where zbackup1 is coming from. The pool I boot > from is zroot ?!? Where would that reference be stored ? I think ada0 > was part of another pool long ago (zbackup1). [...] > It looks like if I do just a > > 0(nanobsd2)# zpool import >    pool: zbackup1 >      id: 5819795054093255811 >   state: UNAVAIL > status: The pool was last accessed by another system. >  action: The pool cannot be imported due to damaged devices or data. >    see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY >  config: > >         zbackup1                  UNAVAIL  insufficient replicas >           raidz2-2                UNAVAIL  insufficient replicas >             da5                   UNAVAIL  cannot open >             mfisyspd8             UNAVAIL  cannot open >             mfisyspd7             UNAVAIL  cannot open >             mfisyspd6             UNAVAIL  cannot open >             ada0                  UNAVAIL  cannot open >             17460231907795801757  UNAVAIL  cannot open > 0(nanobsd2)# > > it thinks ada0 is/was part of an old pool.  How do I get rid of that > reference ? I am not a ZFS expert but can this be stored in a /etc/zfs/zpool.cache? (or in a different path, I remember zpool.cache was stored somewhere else in older versions of FreeBSD, maybe /boot/zfs/zpool.cache) You can try to delete zpool.cache (just rename so you can move it back), import and export should re-create it. Kind regards Miroslav Lachman From nobody Thu Apr 18 14:09: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 4VL05B2rwXz5GwRM for ; Thu, 18 Apr 2024 14:09:18 +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 4VL05B2MtHz4TQy for ; Thu, 18 Apr 2024 14:09:18 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; none 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 43IE9IwS012732 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Thu, 18 Apr 2024 10:09:18 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e] ([IPv6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 43IE9F3W098221 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Apr 2024 10:09:17 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <0c069bca-b512-457b-8934-66b859f449db@sentex.net> Date: Thu, 18 Apr 2024 10:09:16 -0400 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: zfs boot error on mirrored drive To: Miroslav Lachman <000.fbsd@quip.cz>, FreeBSD-STABLE Mailing List References: <82761f2b-475f-43ab-b045-95c60c330db7@sentex.net> Content-Language: en-US From: mike tancsa 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== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.86 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:11647, ipnet:2607:f3e0::/32, country:CA] X-Rspamd-Queue-Id: 4VL05B2MtHz4TQy On 4/18/2024 10:04 AM, Miroslav Lachman wrote: > I am not a ZFS expert but can this be stored in a > /etc/zfs/zpool.cache? (or in a different path, I remember zpool.cache > was stored somewhere else in older versions of FreeBSD, maybe > /boot/zfs/zpool.cache) > You can try to delete zpool.cache (just rename so you can move it > back), import and export should re-create it. > I dont have one in /etc just in /boot/zfs.  Doing a strings on that file, I dont see reference to zbackup1 however, just the real pool, zroot. So strange. I am guessing its stored somewhere specifically on the individual drives? # strings /boot/zfs/zpool.cache zroot version name zroot state pool_guid hostid hostname nanobsd2.sentex.ca com.delphix:has_per_vdev_zaps vdev_children vdev_tree type root guid children type mirror guid metaslab_array metaslab_shift ashift asize is_log create_txg com.delphix:vdev_zap_top children type disk guid path /dev/ada0p3 phys_path id1,enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00/p3 whole_disk create_txg com.delphix:vdev_zap_leaf type disk guid path /dev/ada1p3 phys_path id1,enc@n3061686369656d30/type@0/slot@2/elmdesc@Slot_01/p3 whole_disk create_txg com.delphix:vdev_zap_leaf features_for_read com.delphix:hole_birth com.delphix:embedded_data From nobody Thu Apr 18 14:21: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 4VL0M02RZdz5GxhJ for ; Thu, 18 Apr 2024 14:21:16 +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 4VL0Lz0vWqz4XwL for ; Thu, 18 Apr 2024 14:21:15 +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 43IELFM6014075 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Thu, 18 Apr 2024 10:21:15 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e] ([IPv6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 43IELEAJ099626 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Apr 2024 10:21:14 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: Date: Thu, 18 Apr 2024 10:21:14 -0400 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: zfs boot error on mirrored drive From: mike tancsa To: FreeBSD-STABLE Mailing List References: <82761f2b-475f-43ab-b045-95c60c330db7@sentex.net> <0c069bca-b512-457b-8934-66b859f449db@sentex.net> Content-Language: en-US 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== In-Reply-To: <0c069bca-b512-457b-8934-66b859f449db@sentex.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.39 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; FREEFALL_USER(0.00)[mike]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sentex.net]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4VL0Lz0vWqz4XwL On 4/18/2024 10:09 AM, mike tancsa wrote: > On 4/18/2024 10:04 AM, Miroslav Lachman wrote: >> I am not a ZFS expert but can this be stored in a >> /etc/zfs/zpool.cache? (or in a different path, I remember zpool.cache >> was stored somewhere else in older versions of FreeBSD, maybe >> /boot/zfs/zpool.cache) >> You can try to delete zpool.cache (just rename so you can move it >> back), import and export should re-create it. >> > I dont have one in /etc just in /boot/zfs.  Doing a strings on that > file, I dont see reference to zbackup1 however, just the real pool, > zroot. So strange. I am guessing its stored somewhere specifically on > the individual drives? > OK a little further.  Looking at the output of zdb -l /dev/ada0 I see LABEL 1 has the old info where as zdb -l /dev/ada1 only shows the active pool zroot. So I guess the question is how do I get rid of LABEL 1 on ada0. I guess I could offline the disk, do a full zpool-labelclear on /dev/ada0 and then "replace" ada0p3 with ada0p3.  But I wonder if there is a more surgical way to do it ?  zdb -l /dev/ada0 failed to unpack label 0 ------------------------------------ LABEL 1 ------------------------------------     version: 5000     name: 'zbackup1'     state: 0     txg: 37258100     pool_guid: 5819795054093255811     hostid: 2940363587     hostname: 'otherhost.sentex.ca'     top_guid: 15407571356201067876     guid: 7177971506633653196     hole_array[0]: 1     vdev_children: 3     vdev_tree:         type: 'raidz'         id: 2         guid: 15407571356201067876         nparity: 2         metaslab_array: 115         metaslab_shift: 36         ashift: 9         asize: 12002364751872         is_log: 0         create_txg: 263935         children[0]:             type: 'disk'             id: 0             guid: 9271219886945262566             path: '/dev/da5'             phys_path: '/dev/diskid/DISK-%20%20%20%20%20WD-WCC1P1023355'             whole_disk: 1             DTL: 618             create_txg: 263935         children[1]:             type: 'disk'             id: 1             guid: 8131984913529158308             path: '/dev/mfisyspd8'             phys_path: '/dev/diskid/DISK-%20%20%20%20%20WD-WMAWP0126093'             whole_disk: 1             DTL: 617             create_txg: 263935         children[2]:             type: 'disk'             id: 2             guid: 10328589068509663454             path: '/dev/mfisyspd7'             phys_path: '/dev/diskid/DISK-%20%20%20%20%20WD-WMAWP0079293'             whole_disk: 1             DTL: 616             create_txg: 263935         children[3]:             type: 'disk'             id: 3             guid: 3414086086163178196             path: '/dev/mfisyspd6'             phys_path: '/dev/diskid/DISK-%20%20%20%20%20WD-WMAUR0331605'             whole_disk: 1             DTL: 615             create_txg: 263935         children[4]:             type: 'disk'             id: 4             guid: 7177971506633653196             path: '/dev/mfisyspd9'             phys_path: '/dev/diskid/DISK-%20%20%20%20%20WD-WMAUR0387259'             whole_disk: 1             DTL: 614             create_txg: 263935         children[5]:             type: 'disk'             id: 5             guid: 17460231907795801757             path: '/dev/da8p1'             whole_disk: 1             not_present: 1             DTL: 262356             create_txg: 263935     features_for_read:         com.delphix:hole_birth         com.delphix:embedded_data     labels = 1 ------------------------------------ LABEL 2 ------------------------------------     version: 5000     name: 'zroot'     state: 0     txg: 61126347     pool_guid: 13987985424735542345     errata: 0     hostname: ''     top_guid: 17259639802746798684     guid: 18413289395104510392     vdev_children: 1     vdev_tree:         type: 'mirror'         id: 0         guid: 17259639802746798684         metaslab_array: 34         metaslab_shift: 34         ashift: 12         asize: 1978918240256         is_log: 0         create_txg: 4         children[0]:             type: 'disk'             id: 0             guid: 18413289395104510392             path: '/dev/ada0p3'             phys_path: 'id1,enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00/p3'             whole_disk: 1             DTL: 110             create_txg: 4         children[1]:             type: 'disk'             id: 1             guid: 9245256067651064428             path: '/dev/ada1p3'             phys_path: 'id1,enc@n3061686369656d30/type@0/slot@2/elmdesc@Slot_01/p3'             whole_disk: 1             DTL: 4403             create_txg: 4     features_for_read:         com.delphix:hole_birth         com.delphix:embedded_data     labels = 2 3 From nobody Thu Apr 18 15:12:22 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 4VL1Tz621Vz5H3BT for ; Thu, 18 Apr 2024 15:12:23 +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 4VL1Tz31Vqz4km9 for ; Thu, 18 Apr 2024 15:12:23 +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 43IFCNrM022233 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Thu, 18 Apr 2024 11:12:23 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e] ([IPv6:2607:f3e0:0:4:48c2:ffd8:e147:2c2e]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 43IFCMxl005119 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Apr 2024 11:12:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <77e01882-58c6-4100-81b4-7f387cc94196@sentex.net> Date: Thu, 18 Apr 2024 11:12:22 -0400 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: zfs boot error on mirrored drive (solved) From: mike tancsa To: FreeBSD-STABLE Mailing List References: <82761f2b-475f-43ab-b045-95c60c330db7@sentex.net> Content-Language: en-US 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== In-Reply-To: <82761f2b-475f-43ab-b045-95c60c330db7@sentex.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; FREEFALL_USER(0.00)[mike]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sentex.net]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4VL1Tz31Vqz4km9 On 4/18/2024 9:37 AM, mike tancsa wrote: > I have a strange bootup issue on a test box that I just updated from > 11, to 12 and now RELENG13. > > Its a simple mirror. But if I boot up with ada0, I get an error and > cannot boot further. Where as if I boot up with ada1, I get some > errors and then proceeds to boot normally. > > For one thing, I dont get where zbackup1 is coming from. The pool I > boot from is zroot ?!? Where would that reference be stored ? I think > ada0 was part of another pool long ago (zbackup1). > OK problem solved.  Reboot works on either drive and no errors or warnings at the start. # dd if=/dev/zero of=/dev/ada0p1 bs=1 status=progress # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 and zdb looks good. # zdb -l /dev/ada0 failed to unpack label 0 failed to unpack label 1 ------------------------------------ LABEL 2 ------------------------------------     version: 5000     name: 'zroot'     state: 0     txg: 61127964     pool_guid: 9708037437097115416     errata: 0     hostname: 'nanobsd2.sentex.ca'     top_guid: 17259639802746798684     guid: 18413289395104510392     vdev_children: 1     vdev_tree:         type: 'mirror'         id: 0         guid: 17259639802746798684         metaslab_array: 34         metaslab_shift: 34         ashift: 12         asize: 1978918240256         is_log: 0         create_txg: 4         children[0]:             type: 'disk'             id: 0             guid: 18413289395104510392             path: '/dev/ada0p3'             phys_path: 'id1,enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00/p3'             whole_disk: 1             DTL: 110             create_txg: 4         children[1]:             type: 'disk'             id: 1             guid: 9245256067651064428             path: '/dev/ada1p3'             phys_path: 'id1,enc@n3061686369656d30/type@0/slot@2/elmdesc@Slot_01/p3'             whole_disk: 1             DTL: 4403             create_txg: 4     features_for_read:         com.delphix:hole_birth         com.delphix:embedded_data     labels = 2 3 0(nanobsd2)# zpool import no pools available to import 0(nanobsd2)# > > Here is the error when booting from disk 0 > > BIOS drive C: is disk0 > BIOS drive D: is disk1 > zio_read error: 5 > zio_read error: 5 > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zbackup1 > ZFS: can't find pool by guid > > Can't find /boot/zfsloader > > Can't find /boot/loader > > Can't find /boot/kernel/kernel > > FreeBSD/x86 boot > Default: /boot/kernel/kernel > boot: > > > Here are the messages when booting from disk 1 > > Loading /boot/d| disk1 > zio_read error: 5 > zio_read error: 5 > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zbackup1 > BIOS 615kB/3363840kB available memory > > FreeBSD/x86 bootstrap loader, Revision 1.1 > > and it continues on from there and boots > > After I did the zpool upgrade zroot, I did > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1 > > >   pool: zroot >  state: ONLINE >   scan: resilvered 195G in 01:04:31 with 0 errors on Mon May 25 > 16:08:21 2020 > config: > >         NAME        STATE     READ WRITE CKSUM >         zroot       ONLINE       0     0     0 >           mirror-0  ONLINE       0     0     0 >             ada0p3  ONLINE       0     0     0 >             ada1p3  ONLINE       0     0     0 > > errors: No known data errors > > Whats odd is that zbackup1 is not the name of the pool.  Where is that > coming from ?  The pool I boot from is zroot on this box > > Loading /boot/defaults/loader.conf Loading /boot/loader.conf.local > Loading /boot/d| disk1 > zio_read error: 5 > zio_read error: 5 > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zbackup1 > BIOS 615kB/3363840kB available memory > > 1(nanobsd2)# gpart list ada0 > Geom name: ada0 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 > last: 3907029127 > first: 40 > entries: 128 > scheme: GPT > Providers: > 1. Name: ada0p1 >    Mediasize: 524288 (512K) >    Sectorsize: 512 >    Stripesize: 0 >    Stripeoffset: 20480 >    Mode: r0w0e0 >    efimedia: HD(1,GPT,55d32563-9eba-11ea-87ad-0007430611a8,0x28,0x400) >    rawuuid: 55d32563-9eba-11ea-87ad-0007430611a8 >    rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f >    label: (null) >    length: 524288 >    offset: 20480 >    type: freebsd-boot >    index: 1 >    end: 1063 >    start: 40 > 2. Name: ada0p2 >    Mediasize: 21474836480 (20G) >    Sectorsize: 512 >    Stripesize: 0 >    Stripeoffset: 1048576 >    Mode: r1w1e0 >    efimedia: > HD(2,GPT,55d3938d-9eba-11ea-87ad-0007430611a8,0x800,0x2800000) >    rawuuid: 55d3938d-9eba-11ea-87ad-0007430611a8 >    rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b >    label: (null) >    length: 21474836480 >    offset: 1048576 >    type: freebsd-swap >    index: 2 >    end: 41945087 >    start: 2048 > 3. Name: ada0p3 >    Mediasize: 1978922958848 (1.8T) >    Sectorsize: 512 >    Stripesize: 0 >    Stripeoffset: 21475885056 >    Mode: r1w1e1 >    efimedia: > HD(3,GPT,563d7775-9eba-11ea-87ad-0007430611a8,0x2800800,0xe6608000) >    rawuuid: 563d7775-9eba-11ea-87ad-0007430611a8 >    rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b >    label: (null) >    length: 1978922958848 >    offset: 21475885056 >    type: freebsd-zfs >    index: 3 >    end: 3907028991 >    start: 41945088 > Consumers: > 1. Name: ada0 >    Mediasize: 2000398934016 (1.8T) >    Sectorsize: 512 >    Mode: r2w2e3 > > 0(nanobsd2)# gpart list ada1 > Geom name: ada1 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 > last: 3907029134 > first: 34 > entries: 128 > scheme: GPT > Providers: > 1. Name: ada1p1 >    Mediasize: 524288 (512K) >    Sectorsize: 512 >    Stripesize: 0 >    Stripeoffset: 20480 >    Mode: r0w0e0 >    efimedia: HD(1,GPT,25a0d50e-4207-11e6-8ebd-003048d6ef12,0x28,0x400) >    rawuuid: 25a0d50e-4207-11e6-8ebd-003048d6ef12 >    rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f >    label: gptboot1 >    length: 524288 >    offset: 20480 >    type: freebsd-boot >    index: 1 >    end: 1063 >    start: 40 > 2. Name: ada1p2 >    Mediasize: 21474836480 (20G) >    Sectorsize: 512 >    Stripesize: 0 >    Stripeoffset: 1048576 >    Mode: r1w1e0 >    efimedia: > HD(2,GPT,25b0e143-4207-11e6-8ebd-003048d6ef12,0x800,0x2800000) >    rawuuid: 25b0e143-4207-11e6-8ebd-003048d6ef12 >    rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b >    label: swap1 >    length: 21474836480 >    offset: 1048576 >    type: freebsd-swap >    index: 2 >    end: 41945087 >    start: 2048 > 3. Name: ada1p3 >    Mediasize: 1978922958848 (1.8T) >    Sectorsize: 512 >    Stripesize: 0 >    Stripeoffset: 21475885056 >    Mode: r1w1e1 >    efimedia: > HD(3,GPT,25c584a8-4207-11e6-8ebd-003048d6ef12,0x2800800,0xe6608000) >    rawuuid: 25c584a8-4207-11e6-8ebd-003048d6ef12 >    rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b >    label: zfs1 >    length: 1978922958848 >    offset: 21475885056 >    type: freebsd-zfs >    index: 3 >    end: 3907028991 >    start: 41945088 > Consumers: > 1. Name: ada1 >    Mediasize: 2000398934016 (1.8T) >    Sectorsize: 512 >    Mode: r2w2e3 > > > It looks like if I do just a > > 0(nanobsd2)# zpool import >    pool: zbackup1 >      id: 5819795054093255811 >   state: UNAVAIL > status: The pool was last accessed by another system. >  action: The pool cannot be imported due to damaged devices or data. >    see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY >  config: > >         zbackup1                  UNAVAIL  insufficient replicas >           raidz2-2                UNAVAIL  insufficient replicas >             da5                   UNAVAIL  cannot open >             mfisyspd8             UNAVAIL  cannot open >             mfisyspd7             UNAVAIL  cannot open >             mfisyspd6             UNAVAIL  cannot open >             ada0                  UNAVAIL  cannot open >             17460231907795801757  UNAVAIL  cannot open > 0(nanobsd2)# > > it thinks ada0 is/was part of an old pool.  How do I get rid of that > reference ? > >     ---Mike > From nobody Fri Apr 19 13:39:51 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 4VLbNx2xjYz5H4xn for ; Fri, 19 Apr 2024 13:40:01 +0000 (UTC) (envelope-from gerrit.kuehn@aei.mpg.de) Received: from umail2.aei.mpg.de (umail2.aei.mpg.de [194.94.224.8]) (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 4VLbNw3NkDz49jm for ; Fri, 19 Apr 2024 13:40:00 +0000 (UTC) (envelope-from gerrit.kuehn@aei.mpg.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gerrit.kuehn@aei.mpg.de designates 194.94.224.8 as permitted sender) smtp.mailfrom=gerrit.kuehn@aei.mpg.de Received: from arc.aei.uni-hannover.de (ahgate1.aei.uni-hannover.de [130.75.117.49]) by umail2.aei.mpg.de (Postfix) with ESMTPS id DEE02200E671 for ; Fri, 19 Apr 2024 15:39:57 +0200 (CEST) Date: Fri, 19 Apr 2024 15:39:51 +0200 From: Gerrit =?UTF-8?B?S8O8aG4=?= To: freebsd-stable@freebsd.org Subject: possible regression handling packet fragmentation in 14.0 with tftp/pxe Message-ID: <20240419153951.5a23ce5f@arc.aei.uni-hannover.de> Organization: MPG X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1) 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/J_HhMHjp0FHYYB.x_9v55wV"; protocol="application/pkcs7-signature"; micalg=SHA384 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.79 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.99)[-0.991]; R_SPF_ALLOW(-0.20)[+ip4:194.94.224.8]; RWL_MAILSPIKE_VERYGOOD(-0.20)[194.94.224.8:from]; RCVD_IN_DNSWL_MED(-0.20)[194.94.224.8:from]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; ASN(0.00)[asn:680, ipnet:194.94.0.0/15, country:DE]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_ALL(0.00)[]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[mpg.de]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4VLbNw3NkDz49jm --Sig_/J_HhMHjp0FHYYB.x_9v55wV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I have found something that looks like a regression to me (but it may also be a bugfix, and I was just relying on the bug earlier :-). Anyway, I don't fully understand what is going on, maybe someone here has more insight than I do. I have various router appliances based on FreeBSD. They act as NAT-routers, dns/dhcp-servers and vpn-servers (using tinc in switch mode as vpn solution). I use these in different incarnations for many years now (since 8.something afaicr), the systems work fine up to 13.3. With 14.0 I hit a strange issue: Some of my LANs that FreeBSD is acting as NAT-gateway for (using pf for nat, including scrubbing) contain diskless machines that need to boot off a NFS-server that is located outside the LAN. To make this possible, The router and the NFS-server run a tinc-connection. On the router, tinc's virtual TAP-interface is bridged with the physical interface of the LAN: --- bridge0: flags=3D1008843 metric 0 mtu 1500 options=3D0 ether 58:9c:fc:10:ff:ed id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=3D143 ifmaxaddr 0 port 7 priority 128 path cost 2000000 member: ix3 flags=3D143 ifmaxaddr 0 port 4 priority 128 path cost 2000 groups: bridge nd6 options=3D9 --- The remote server runs both nfsd for the diskless root and tftpd for PXE-booting. This was working fine up to 13.3. However, with the router under 14.0, the first step of the tftp-part (delivering pxelinux.0 from the syslinux package) fails and ends up in timeouts. For the following: 192.168.130.3 is the diskless client trying to boot (Linux) 192.168.130.253 is the server for nfsroot and tftp (FreeBSD) 192.168.130.254 is the router and dhcp-server (FreeBSD 13.3/14.0) The tftpd-server logs the follwoing events for this in /var/log/xferlog when the client tries to boot via pxe: --- Apr 19 11:37:40 192.168.130.253 tftpd[49562]: Filename: 'pxelinux.0' Apr 19 11:37:40 192.168.130.253 tftpd[49562]: Mode: 'octet' Apr 19 11:37:40 192.168.130.253 tftpd[49564]: Filename: 'pxelinux.0' Apr 19 11:37:40 192.168.130.253 tftpd[49564]: Mode: 'octet' Apr 19 11:37:40 192.168.130.253 tftpd[49564]: 192.168.130.3: read request for //pxelinux.0: success Apr 19 11:37:45 192.168.130.253 tftpd[49564]: receive_packet: timeout Apr 19 11:37:45 192.168.130.253 tftpd[49564]: Timeout #0 on ACK 1 Apr 19 11:37:50 192.168.130.253 tftpd[49564]: receive_packet: timeout Apr 19 11:37:50 192.168.130.253 tftpd[49564]: Timeout #1 on ACK 1 Apr 19 11:37:55 192.168.130.253 tftpd[49564]: receive_packet: timeout Apr 19 11:37:55 192.168.130.253 tftpd[49564]: Timeout #2 on ACK 1 Apr 19 11:38:00 192.168.130.253 tftpd[49564]: receive_packet: timeout Apr 19 11:38:00 192.168.130.253 tftpd[49564]: Timeout #3 on ACK 1 Apr 19 11:38:05 192.168.130.253 tftpd[49564]: receive_packet: timeout Apr 19 11:38:05 192.168.130.253 tftpd[49564]: Timeout #4 on ACK 1 Apr 19 11:38:10 192.168.130.253 tftpd[49564]: receive_packet: timeout Apr 19 11:38:10 192.168.130.253 tftpd[49564]: Timeout #5 send ACK 1 giving up --- A tcpdump for the MAC of the pxe client taken on the physical interface of the router looks like this: --- 11:37:36.843770 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:25:90:69:bf:ae, length 548 11:37:36.844639 IP 192.168.130.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 357 11:37:40.853302 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:25:90:69:bf:ae, length 548 11:37:40.855024 IP 192.168.130.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 357 11:37:40.855653 ARP, Request who-has 192.168.130.253 tell 192.168.130.3, length 46 11:37:40.856543 ARP, Reply 192.168.130.253 is-at 00:bd:df:ce:fa:03, length 28 11:37:40.856584 IP 192.168.130.3.2070 > 192.168.130.253.69: TFTP, length 27, RRQ "pxelinux.0" octet tsize 0 11:37:40.860701 IP 192.168.130.253.38476 > 192.168.130.3.2070: UDP, length 14 11:37:40.860737 IP 192.168.130.3.2070 > 192.168.130.253.38476: UDP, length 17 11:37:40.860908 IP 192.168.130.3.2071 > 192.168.130.253.69: TFTP, length 32, RRQ "pxelinux.0" octet blksize 1456 11:37:40.891419 IP 192.168.130.253.31448 > 192.168.130.3.2071: UDP, length 15 11:37:40.891455 IP 192.168.130.3.2071 > 192.168.130.253.31448: UDP, length 4 11:37:40.910020 IP 192.168.130.253.31448 > 192.168.130.3.2071: UDP, length 1460 11:37:40.910037 IP 192.168.130.253 > 192.168.130.3: ip-proto-17 11:37:45.910310 IP 192.168.130.253.31448 > 192.168.130.3.2071: UDP, length 1460 11:37:45.910327 IP 192.168.130.253 > 192.168.130.3: ip-proto-17 11:37:50.915422 IP 192.168.130.253.31448 > 192.168.130.3.2071: UDP, length 1460 11:37:50.915439 IP 192.168.130.253 > 192.168.130.3: ip-proto-17 11:37:55.919340 IP 192.168.130.253.31448 > 192.168.130.3.2071: UDP, length 1460 11:37:55.919359 IP 192.168.130.253 > 192.168.130.3: ip-proto-17 11:38:00.934017 IP 192.168.130.253.31448 > 192.168.130.3.2071: UDP, length 1460 11:38:00.934033 IP 192.168.130.253 > 192.168.130.3: ip-proto-17 11:38:05.943631 IP 192.168.130.253.31448 > 192.168.130.3.2071: UDP, length 1460 11:38:05.943651 IP 192.168.130.253 > 192.168.130.3: ip-proto-17 --- It looks like there are tftp packages transmitted that are somehow never picked up by the client. As 13.3 was running fine in this place, I compared the tcpdump output to what is happening there: --- 13:34:34.112855 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:90:69:bf:ae (oui Unknown), length 548 13:34:36.145073 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:90:69:bf:ae (oui Unknown), length 548 13:34:40.154596 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:90:69:bf:ae (oui Unknown), length 548 13:34:40.155930 ARP, Request who-has 192.168.130.253 tell 192.168.130.3, length 46 13:34:40.156176 ARP, Reply 192.168.130.253 is-at 00:bd:7b:2d:f7:05 (oui Unknown), length 28 13:34:40.156239 IP 192.168.130.3.2070 > 192.168.130.253.tftp: 27 RRQ "pxelinux.0" octet tsize 0 13:34:40.159338 IP 192.168.130.253.16697 > 192.168.130.3.2070: UDP, length 14 13:34:40.159406 IP 192.168.130.3.2070 > 192.168.130.253.16697: UDP, length 17 13:34:40.159574 IP 192.168.130.3.2071 > 192.168.130.253.tftp: 32 RRQ "pxelinux.0" octet blksize 1456 13:34:40.162327 IP 192.168.130.253.33393 > 192.168.130.3.2071: UDP, length 15 13:34:40.162388 IP 192.168.130.3.2071 > 192.168.130.253.33393: UDP, length 4 13:34:40.162708 IP 192.168.130.253.33393 > 192.168.130.3.2071: UDP, bad length 1460 > 1392 13:34:40.162758 IP 192.168.130.253 > 192.168.130.3: udp 13:34:40.162837 IP 192.168.130.3.2071 > 192.168.130.253.33393: UDP, length 4 13:34:40.163089 IP 192.168.130.253.33393 > 192.168.130.3.2071: UDP, bad length 1460 > 1392 13:34:40.163124 IP 192.168.130.253 > 192.168.130.3: udp 13:34:40.163670 IP 192.168.130.3.2071 > 192.168.130.253.33393: UDP, length 4 13:34:40.163920 IP 192.168.130.253.33393 > 192.168.130.3.2071: UDP, bad length 1460 > 1392 13:34:40.163956 IP 192.168.130.253 > 192.168.130.3: udp 13:34:40.164515 IP 192.168.130.3.2071 > 192.168.130.253.33393: UDP, length 4 13:34:40.164765 IP 192.168.130.253.33393 > 192.168.130.3.2071: UDP, bad length 1460 > 1392 [...] --- Although this reports "bad length" all the time (whatever this means), it works and transfers bootloader, initramfs, kernel etc. for diskless Linux machines in the LAN. But this suspiciously looked like MTU problems. The VPN only offers an MTU of 1425 by default, while tftp appears to use 1460. After some searching and reading I found that the original tftp default was 512 byte packets, and the client obviously requests larger packets for speed reasons explicitely with the "blksize 1456" command. Unfortunately, I found no way to configure the PXE firmware to use smaller packets. However, adding the "-o" option to FreeBSD's tftpd could disable all extra options and forced both the server and the client to user smaller packets. TFTP and PXE-booting were working fine again after that change. On the other hand, this feels like a workaround. What is the actual problem here, and why did the very same setup "just work" up to FreeBSD 13.3 on the router? The setup of pf.conf is quite minimal, the packet normalization part is just --- set block-policy return set optimization aggressive scrub in all --- Is this some kind of regression or rather the fix of a bug I was relying upon earlier? Any hints and insight would be greatly appreciated. cu Gerrit --Sig_/J_HhMHjp0FHYYB.x_9v55wV Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgIFADCABgkqhkiG9w0B BwEAAKCCF/QwggQyMIIDGqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNV BAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1Nh bGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEg Q2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAxMDAwMDAwWhcNMjgxMjMxMjM1 OTU5WjB7MQswCQYDVQQGEwJHQjEbMBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHDAdTYWxmb3JkMRowGAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEh MB8GA1UEAwwYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvkCd9G7h6naHHE1FRI6+RsiDBp3BKv4YH47kAvrz q11QihYxC5oG0MVwIs1JLVRjzLZuaEYLU+rLTCTAvHJO6vEVrvRUmhIKw3qyM2Di 2olV8yJY897cz++DhqKMlE+faPKYkEaEJ8d2v+PMNSyLXgdkZYLASLCokflhn3Yg UKiRx2a163hiA1bwihoT6jGjHqCZ/Tj29icyWG8H9Wu4+xQrr7eqzNZjX3OM2gWZ qDioyxd4NlGs6Z70eDqNzw/ZQuKYDKsvnw4B3u+fmUnxLd+sdE0bmLVHxeUp0fmQ GMdinL6DxyZ7Poolx8DdneY1aBAgnY/Y3tLDhJwNXugvyQIDAQABo4HAMIG9MB0G A1UdDgQWBBSgEQojPpbxB+zirynvgqV/0DCktDAOBgNVHQ8BAf8EBAMCAQYwDwYD VR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDA2oDSgMoYwaHR0cDov L2NybC5jb21vZG8ubmV0L0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAIVvwC8Jvo/6T61nvGRIDOT8TF9gBYzKa2vBRJaAR26Obu XewCD2DWjVAYTyZOAePmsKXuv7x0VEG//fwSuMdPWvSJYAV/YLcFSvP28cK/xLl0 hrYtfWvM0vNG3S/G4GrDwzQDLH2W3VrCDqcKmcEFi6sML/NcOs9sN1UJh95TQGxY 7/y2q2VuBPYb3DzgWhXGntnxWUgwIWUDbOzpIXPsmwOh4DetoBUYj/q6As6nLKkQ EyzU5QgmqyKXYPiQXnTUoppTvfKpaOCibsLXbLGjD56/62jnVvKu8uMrODoJgbVr hde+Le0/GreyY+L1YiyC1GoAQVDxOYOflek2lphuMIIFgTCCBGmgAwIBAgIQOXJE Ovkit1HX02wQ3TE1lTANBgkqhkiG9w0BAQwFADB7MQswCQYDVQQGEwJHQjEbMBkG A1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHDAdTYWxmb3JkMRowGAYD VQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UEAwwYQUFBIENlcnRpZmljYXRl IFNlcnZpY2VzMB4XDTE5MDMxMjAwMDAwMFoXDTI4MTIzMTIzNTk1OVowgYgxCzAJ BgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkg Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sIs9CsVw127c0n00ytUINh4qog TQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnGvDoZtF+mvX2do2NCtnbyqTsr kfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQIjy8/hPwhxR79uQfjtTkUcYR Z0YIUcuGFFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfbIWax1Jt4A8BQOujM8Ny8nkz+ rwWWNR9XWrf/zvk9tyy29lTdyOcSOk2uTIq3XJq0tyA9yn8iNK5+O2hmAUTnAU5G U5szYPeUvlM3kHND8zLDU+/bqv50TmnHa4xgk97Exwzf4TKuzJM7UXiVZ4vuPVb+ DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNVicQNwZNUMBkTrNN9N6frXTps NVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5D9kCnusSTJV882sFqV4Wg8y4 Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJWBp/kjbmUZIO8yZ9HE0XvMns QybQv0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ5lhCLkMaTLTwJUdZ+gQek9Qm RkpQgbLevni3/GcV4clXhB4PY9bpYrrWX1Uu6lzGKAgEJTm4Diup8kyXHAc/DVL1 7e8vgg8CAwEAAaOB8jCB7zAfBgNVHSMEGDAWgBSgEQojPpbxB+zirynvgqV/0DCk tDAdBgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rIDZsswDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2Vy dmljZXMuY3JsMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IBAQAYh1HcdCE9nIrgJ7cz 0C7M7PDmy14R3iJvm3WOnnL+5Nb+qh+cli3vA0p+rvSNb3I8QzvAP+u431yqqcau 8vzY7qN7Q/aGNnwU4M309z/+3ri0ivCRlv79Q2R+/czSAaF9ffgZGclCKxO/WIu6 pKJmBHaIkU4MiRTOok3JMrO66BQavHHxW/BBC5gACiIDEOUMsfnNkjcZ7Tvx5Dq2 +UUTJnWvu6rvP3t3O9LEApE9GQDTF1w52z97GA1FzZOFli9d31kWTz9RvdVFGD/t So7oBmF0Ixa1DVBzJ0RHfxBdiSprhTEUxOipakyAvGp4z7h/jnZymQyd/teRCBah o1+VMIIG5jCCBM6gAwIBAgIQMQJw1DW+mySa+FbQ4eKFSTANBgkqhkiG9w0BAQwF ADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAs BgNVBAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MjAwMjE4MDAwMDAwWhcNMzMwNTAxMjM1OTU5WjBGMQswCQYDVQQGEwJOTDEZMBcG A1UEChMQR0VBTlQgVmVyZW5pZ2luZzEcMBoGA1UEAxMTR0VBTlQgUGVyc29uYWwg Q0EgNDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALNK4iJeJ1vpBFsU BDUyIBSutNIxQMbNUMAeoUTKr55KYX8tkN5imzNqLaRCypYBPP9wED2AaO6e8njk bjzJwLgPqDBkW9sG3kmi3GW6cF4Hwr5ysZqve/5EJDhV+9OhfTu/4dMnoR4Q41Hc jMk9MzLOADAQ0awBZ/29r0d49AUmIKELNeqEqmnTN6fndL7x/2K0TLToZLxqS7sy /Jvi0wEFr0CfdjcAsioh7KaD+Jizyb1aRKQzJ6Q20VEHX7UqWc1SkzTkbz6xj0S5 ydBBFQh0fNiy+qM/deVpK4HgmPSJrrpQZ+LlbHfWabmwoDPxF71QZVYiqrrAoUrG RJ+47iLBiIg8miIYS7Hd2ppvAUt24CugMXUjETjQ+oYh09fNi5n/AvoER8UBvTHL xt+blL0bvL+2z2YiUWk+2Qtn+dD+JU5Z2y71qV7+cr+4YXjvGzF5bYsi8HiwflTb 4Php3y+k1twKtchdcq2QGc0eDG6Y01nRHUiyr8/PtMAsLHEPNZ2wzsA7fb8mftHi V20ZFmYqknJ8AIOfwdTVA+E62JayOJ+sxadqcmFDorsz/mrPwGZ8+txr4xSuvVjg 0dlv0yuA+1YpBDIYNfL4bkX+IcZ1mTstL4Xw0f4N2iW3bBmnPnYmoYxMM8gflCiT gss73nBvG2f7v1PD7BDGYNO4iD4vAgMBAAGjggGLMIIBhzAfBgNVHSMEGDAWgBRT eb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUaQChxyFY+ODFGyCwCt2nUb8T 2eQwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYw FAYIKwYBBQUHAwIGCCsGAQUFBwMEMDgGA1UdIAQxMC8wLQYEVR0gADAlMCMGCCsG AQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzBQBgNVHR8ESTBHMEWgQ6BB hj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNh dGlvbkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNo dHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5j cnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEMBQADggIBAAoFTnsNjx8TOQD9b+xixsPt7Req4wHMeNw/R5dddEPgQAQA YJZKz5BEv1cjGbH7nbPH3AxrxhN6OVH40p6OLIo9MXSrrfMzGs7/P+FTCjwgNxFE tLQ1KC9NboA3asJcl7mIs3l8h9iAgEH1zLUvq2s+5n++NQmbzudDsTFDMapY3kX1 TwyUCTRzmItqcbsYIyg2MeIXWfRtqPqC5R4bufmpzA5BPINLX340Sp/CNQ9QZqw3 VkfyHWwTo+vO9Gm2L6srNamJT6Lb+TeXZvl8UPL5a72O/pH0GgGHjt6z9QzPARna RKshVWviNK6ST4WmZHllu3CJg0BXqx1vWyswawgvNeWt1qxITacYe9mSWTbNR2Cf tvTUwerruDSY2jMaZPoNqbjUpuG/blYwWzzvVerBUhviAahPXJF/9V48ybWPBq6q KOEokW+s3B4ad5sY96KlovEijaIQDip1HO0SD+rLNYaiBcr9MV2aK+DfbZ8w9BaN CQyFEYwzxIKOVk3bYvzHRk5ihUDascmbk/bkiNl74c/KfuKQmJImaqWoWZR6jBcX cPV0WUIKz/nILTpFhGojZEQW77by3aezAi9jrEIUBHRG1LwzPbJc2V3SOzYyaJFQ atzuKZbN1Q9s9y/2x1QXtKwREY8jNgvx0iIfOK35gKgYJJcyDql4XfuEc2nVMIIH SzCCBTOgAwIBAgIRAMCEqCZW/bEp9AgcdlGEWuEwDQYJKoZIhvcNAQEMBQAwRjEL MAkGA1UEBhMCTkwxGTAXBgNVBAoTEEdFQU5UIFZlcmVuaWdpbmcxHDAaBgNVBAMT E0dFQU5UIFBlcnNvbmFsIENBIDQwHhcNMjMwODE1MDAwMDAwWhcNMjYwODE0MjM1 OTU5WjCB0zEOMAwGA1UEERMFODA1MzkxRzBFBgNVBAoMPk1heC1QbGFuY2stR2Vz ZWxsc2NoYWZ0IHp1ciBGw7ZyZGVydW5nIGRlciBXaXNzZW5zY2hhZnRlbiBlLlYu MRswGQYDVQQJDBJIb2ZnYXJ0ZW5zdHJhw59lIDgxDzANBgNVBAgTBkJheWVybjEL MAkGA1UEBhMCREUxFTATBgNVBAMTDEdlcnJpdCBLdWVobjEmMCQGCSqGSIb3DQEJ ARYXZ2Vycml0Lmt1ZWhuQGFlaS5tcGcuZGUwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQCg7n7fRC0hIeomyBYF0RZ0L/jKjURwqPL3vBN+HvDxzp+Wcn0a Voeia3LPeXvf18d7BeIQ2SVFXWnWzVpVKzv7VUg4OD424GmcQrFXkChSvOc/rLaA FmNIaKWgYwUOAqmDh3t9JzQTVj6FrAeJwzXmnv42msNUfnhA2dRllOCmilLUqm/5 nOgrImuiA3R1S0CcljAmEr5PnUmKJaanbaq74Jb54gf622cRyWwylMJijMGboDYw uaGynrLgfo+rWbXc2TASO6pjSQDKAAfXO/NzLgp+BmneN1II9alVUAJRUpFDkgx9 peM+qUJryLtO+veOKElsOe2S4qvk0PaE/MVAcIJiThdY7qde8Q9FyOJsDN5kiX4g fsKmtF7EdB71Uc8N78L62r7/7Y5WL8gRxXCN8BsmLXSiCylvtIYsbJMDhK6C+37w 9Cg1A8AWeksg1TmCcvolEJy3+bfPx7NlmEfRdkdzuVb1KxfB0z4SbhSwOAR1WYVg mEAQuj1l9k7suUtdUY4ZeMnRLVPtmQh+bxcJPaRllpHSTYbYVQlSNXkP0al2/J8d jJHhulOsCX8oYfyQ9a33jHsKUf632Lpg8446ym19UrNPh9pntXRXVhhkw+/tPE8G BxH81BCvvSUhVu0Nckx8zOWiI1+6Z5t71udnXOEv9lJFvqDlY71lkiu+jQIDAQAB o4IBpDCCAaAwHwYDVR0jBBgwFoAUaQChxyFY+ODFGyCwCt2nUb8T2eQwHQYDVR0O BBYEFOsacOXMtCWA1hWcY7A/tb8e/tTSMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjA/BgNVHSAEODA2 MDQGCysGAQQBsjEBAgJPMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5j b20vQ1BTMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9HRUFOVC5jcmwuc2VjdGln by5jb20vR0VBTlRQZXJzb25hbENBNC5jcmwweAYIKwYBBQUHAQEEbDBqMD0GCCsG AQUFBzAChjFodHRwOi8vR0VBTlQuY3J0LnNlY3RpZ28uY29tL0dFQU5UUGVyc29u YWxDQTQuY3J0MCkGCCsGAQUFBzABhh1odHRwOi8vR0VBTlQub2NzcC5zZWN0aWdv LmNvbTAiBgNVHREEGzAZgRdnZXJyaXQua3VlaG5AYWVpLm1wZy5kZTANBgkqhkiG 9w0BAQwFAAOCAgEAbUB7zWvNZ98vh3u7hzpnbA1K4U9bga1YkpVbOgv7/UY5RiZP Rk06O18f5TnRSWiiF3XImBG1uVjbcwVKIemliCQRQzVVt2JXOJVT1EafDDe9DK5o QaXGHY7NAT1lPLEwtgv8hxBBvthMaMa6lpibT/IUi83jHPZUgsGajCgPXd05Bh/L jCzWDOmHuwFdjRAMQs1VsPYx+OVcRvS1jmw0bT6o5/nruRwF5brxUK39Mftj3sIN b+UvVkXdAGw5iQWFwllGpwBgo3iESa1R72qkBMWph8D6Jbg795WBgjMULCPTiZkq eOif9sW1/37AoutSh7VMh7WMrEW9QURVWYR1hYjS0/TMo8aXfPOLtLYoSg/R6i+j eXqREsJQxMAl0e/JJej1TAFCsWg0r6Dg4mYq636plAr6pu7pJATNVPT0HrsBMYWu PV2WRH8Obs+n1xe4ftGxE4yDWiL56lnp6tnfVR8qinEqpGBfj7BAwEcO/Na9b+oK tDEmWHzupKkdmoOWktURY+Q/5RVWoiozNujYljc9iaK3agqBbJ5ZzRyrCKOPLnw4 9b8koO03WkXPqlm59nxAOdJE6ZQ2aQ8ev6ji+UlGnlIvgk70MsRukY2shpAiowb6 bKjKyK3QGNnT4zmL6ixSRmnYhC95U923Yf+hy+6jqS1Ec6kgpREYG53Qv5IxggMs MIIDKAIBATBbMEYxCzAJBgNVBAYTAk5MMRkwFwYDVQQKExBHRUFOVCBWZXJlbmln aW5nMRwwGgYDVQQDExNHRUFOVCBQZXJzb25hbCBDQSA0AhEAwISoJlb9sSn0CBx2 UYRa4TANBglghkgBZQMEAgIFAKCBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0yNDA0MTkxMzM5NTFaMCgGCSqGSIb3DQEJDzEbMBkw CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMD8GCSqGSIb3DQEJBDEyBDAZeXMKbrEM elQuLIU5VEhKdo0/srKmyDDdxRY8ywqUvlmNuLbwjDHnnV+Ca0Vf1pAwDQYJKoZI hvcNAQEBBQAEggIAT2qfHpQLedG12kzwDqp/68q9me7hdDUiR+54cFaOEt5V0j32 DvyHVXjfjqyRcBCCjHQb6CuLfKKPEzVruM5MQinRe45Lcnd0esIPPZmNkwzt+D2p Fk8UKetSIOHdG6uCODW9n6II09JWnEHcVPMPsui0lWLBGv3yEFgO6hsx+8zoKOYj RuNpt+c0nv05ttO97L5ywP5jDshBZ0BycsYn78IQxIRxIzue32+pXJiWeL289YAG xcMXlp3RcCrJBUARzZ/ThNqDehfVf07eIn91q14DvxEzc5IL6sRf3m60YSDXkwox 6KgaNLt49gLqwJ/rjVm1GECZrcQdfLFVnQ3orXzHv03+lVd2/NVZlBKFyWvnnaZP Th8mxXXEJHSlaBWhv048bMs5hQhOcx+k0RRqGWadNtjW0HefShwuoQO4MPwGllD6 FNpfbGJKrta9Borr2HuuNhMJX8t4hWuRCxTrc7g1XGGJz5ssY6mILjA+ycp4TSz8 3O2VJqrX2z1Ff/DapV/lb8FU30JtZCqGNDwakr4SzIHAqwZI4oqSpBe3av1Knuf0 mj0r5mHxU0pqgQendeoeBgxx01GXahoXDi9zy0tm/gUS8/sBSaGDf7rczpWGcm0y Z1XmUBuN7iZYqd1Gvh/qtwlV9g+1J9KL1IzfoMFNnNBQbPixXzA1Ibep1eIAAAAA AAA= --Sig_/J_HhMHjp0FHYYB.x_9v55wV-- From nobody Fri Apr 19 15:48: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 4VLfDf6c84z5HGmW for ; Fri, 19 Apr 2024 15:48:02 +0000 (UTC) (envelope-from des@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 4VLfDf64Xtz4WVY; Fri, 19 Apr 2024 15:48:02 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713541682; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WBJapBlmvoiObSCdtEf6GwRmKMb3Hcw6UtNJ+XR4FC0=; b=H8GR0p0aIWvwMZks0vThh7gN/Se3I4AKEHMQLWt1J0K1s8PVu2S3feCoGxX6cBMVIvMren T7va+G2fK2owGURtO0uQ+EoXfE/IAqeGlWh1+dNaNyjkCkhlhEZTxcHIFWMS5S52YDlL7f QUc4QBgzM1u4xiOfc/nLT4mVogMfMja8/wGwUIOrnOnJzY+rAvpCMv4/ndEb1ADUB/bXk5 ASdMoGV5GG7Z5Ismzesc97DEL+nvqnQtxKAzOTO3mhRGjzQiBG+dgHOOmaZhy4X7vinpiR z5pXR7glmOvlt2BP9avBAhUhsN20mn0NhEIyFrGch3ekFs/KDv2EU0TIH2gTXQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713541682; a=rsa-sha256; cv=none; b=aiTp+yZvzYO+v1KlJ+9wr7/XZO4M5+c8g8AmF3+9kjKyaElwFXUEU3aAJipS+rLJojhNcJ UkYsVp0UNEVNwmZ/OInLHMdA6/NCzxBy9XLmSxgK1Rdaw47aGndIpJiMovEg1GKiExtkvs DK2WlMDUGUDOnhMcnoGhnKvhyl+PUnWHBkO8PlMru48ztg3exsh8cATLVJ87Wjiii6EqMw Vao/9zISjs0bVY2USLfXc9QVMXIBUAlln6FVPu1hM+3LpmMWRoZuh8Q4DjgW1t7OLhni3v 6FdRGFvj5P7/DpcdWBtr6+DK2MWyYQtGPjL55KRfxoUBwrONETvwfQANfHBDEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713541682; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WBJapBlmvoiObSCdtEf6GwRmKMb3Hcw6UtNJ+XR4FC0=; b=O2lIF0U/cqbBeJSaPGM1OxTAYuTq86QOnz7S0xmNdjTSuAKIQ18wZJ2eccWrO4NBus1UwL WgNWZoyzMAZ6jcT96lkyXs+2Aqn8pnfjhqcx6dWTRd9dBceeLsdCH+P7X+9PVw45TqbOD6 uWNIAZKqKjKbiqUh+Jhao96NwsWR13IaTBbuzhAd7n4Ax/QVlIEZDItppdvk3+6nXivPmV aMFplNlA0EXnyycuFKp8+D8Pbvb2MSQzJZIUwXGGcd/zPI+1foq8fG1B/WiQPU2AeONZLG eMwZUI52tNlNuk4DR8rnkp44yvUc6avlGmu1GY9+NI6Ji0K6EHp1t4ARhwlkkw== Received: from ltc.des.dev (163.23.65.37.rev.sfr.net [37.65.23.163]) (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: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VLfDf4sMdzd7V; Fri, 19 Apr 2024 15:48:02 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 7249A1E5A9; Fri, 19 Apr 2024 17:48:01 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gerrit =?utf-8?Q?K=C3=BChn?= Cc: freebsd-stable@freebsd.org Subject: Re: possible regression handling packet fragmentation in 14.0 with tftp/pxe In-Reply-To: <20240419153951.5a23ce5f@arc.aei.uni-hannover.de> ("Gerrit =?utf-8?Q?K=C3=BChn=22's?= message of "Fri, 19 Apr 2024 15:39:51 +0200") References: <20240419153951.5a23ce5f@arc.aei.uni-hannover.de> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 19 Apr 2024 17:48:01 +0200 Message-ID: <86y1999wwe.fsf@ltc.des.dev> 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: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gerrit K=C3=BChn writes: > For the following: > 192.168.130.3 is the diskless client trying to boot (Linux) > 192.168.130.253 is the server for nfsroot and tftp (FreeBSD) > 192.168.130.254 is the router and dhcp-server (FreeBSD 13.3/14.0) > [...] > But this suspiciously looked like MTU problems. The VPN only offers an MTU > of 1425 by default, while tftp appears to use 1460. After some > searching and reading I found that the original tftp default was 512 byte > packets, and the client obviously requests larger packets for speed > reasons explicitely with the "blksize 1456" command. Unfortunately, I fou= nd > no way to configure the PXE firmware to use smaller packets. > However, adding the "-o" option to FreeBSD's tftpd could disable all extra > options and forced both the server and the client to user smaller packets. > TFTP and PXE-booting were working fine again after that change. Since you control the routers and endpoints, I would suggest running tcpdump at various points to see what is the tunnel and pf are doing to the UDP packets. They are presumably getting fragmented at some point, and hopefully reassembled somewhere else. Meanwhile you can also set the net.inet.udp.maxdgram sysctl to 1425 on the NFS server, as tftpd will cap the blocksize to that value. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org