From nobody Sat Dec 2 11:14:19 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sj6lZ2N12z532nX for ; Sat, 2 Dec 2023 11:14:50 +0000 (UTC) (envelope-from alex@alexburke.ca) Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) (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 4Sj6lZ04mxz4KSk for ; Sat, 2 Dec 2023 11:14:49 +0000 (UTC) (envelope-from alex@alexburke.ca) Authentication-Results: mx1.freebsd.org; none Date: Sat, 2 Dec 2023 12:14:19 +0100 (GMT+01:00) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexburke.ca; s=key1; t=1701515681; 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=xcogQCTIoeZYL1QXxBJ+dhFQ/hCFUeb2lrRaeZFucEE=; b=iOA+VEZUH9zos9zK1A6MSd9RK9zcPe4a0ehP4QrfloQh3bm1DM4D9+UxyyZ5cGrn0aX0je 2aUndsQur7xeLhxujMRIz9CilQ67mwVzDWIwq2YoTZ13qdou6MODF92F3WAExrMWoF1hKH 3SgpHf2LPOEXJ4rzanKe3c6s3wpH8lA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Alexander Burke To: Thomas Zander Cc: freebsd-stable@freebsd.org Message-ID: In-Reply-To: References: <20231201031737.DF0231B942@freefall.freebsd.org> Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: X-Migadu-Flow: FLOW_OUT 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:202172, ipnet:95.215.58.0/24, country:CH] X-Rspamd-Queue-Id: 4Sj6lZ04mxz4KSk Hello, `zpool scrub` will not catch this issue as the corruption did not happen on= disk. Solutions are being researched on the OpenZFS GitHub issue tracker regardin= g pools which may have already experienced the issue. Cheers, Alex ---------------------------------------- Dec 2, 2023 11:37:37 Thomas Zander : > On Fri, Dec 01, 2023 at 03:17:37AM +0000, FreeBSD Errata Notices wrote: >=20 >> Topic:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OpenZFS dat= a corruption >> ... >> I.=C2=A0=C2=A0 Background >> II.=C2=A0 Problem Description >> III. Impact >> IV.=C2=A0 Workaround >> V.=C2=A0=C2=A0 Solution >=20 > IMHO, what is missing between sections III and IV when the bug is about > persistency (file systems, data storage, file format conversion, ...) > is a subsection "Is there a way to find out which files are affected?" >=20 > For eaxmple, in the case of ZFS, it would be helpful to answer "Will > 'zpool scrub' find and / or repair affected files?" >=20 > There will be cases (this one? I don't know. Anyone?) in which the > answer is unfortunately "Nope, sorry.", but this would still be helpful > information, since it would save people from browsing the net for > hours, looking for an answer to that question. >=20 > Thanks for considering for future errata > Riggs From nobody Sun Dec 3 00:11:48 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SjS0C1vfyz53G53 for ; Sun, 3 Dec 2023 00:11:55 +0000 (UTC) (envelope-from mem@schmem.com) Received: from shell.qozzy.net (schorl.qozzy.net [209.104.225.37]) by mx1.freebsd.org (Postfix) with SMTP id 4SjS0B3jghz3PN2 for ; Sun, 3 Dec 2023 00:11:54 +0000 (UTC) (envelope-from mem@schmem.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of mem@schmem.com designates 209.104.225.37 as permitted sender) smtp.mailfrom=mem@schmem.com; dmarc=none Received: (qmail 8886 invoked by uid 101); 2 Dec 2023 19:11:48 -0500 From: "Mark E. Mallett" Date: Sat, 2 Dec 2023 19:11:48 -0500 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs Message-ID: References: <20231201031737.DF0231B942@freefall.freebsd.org> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.10 (2023-03-25) X-Spamd-Result: default: False [-0.24 / 15.00]; NEURAL_HAM_LONG(-0.97)[-0.967]; NEURAL_SPAM_SHORT(0.96)[0.958]; R_SPF_ALLOW(-0.20)[+ip4:209.104.225.32/27]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.07)[0.073]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[schmem.com]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:14265, ipnet:209.104.224.0/20, country:US] X-Rspamd-Queue-Id: 4SjS0B3jghz3PN2 X-Spamd-Bar: / Might I also ask (or say): I find some of the notice and actions confusing, at least in minor ways. I'm mainly only remarking since the subject has been opened. First, "Background" talks about FreeBSD 12 ZFS being based on Illumos ZFS, and 13 and on being based on OpenZFS. I kinda wish the notice would say why it tells me that, because the implication in the text is that both are affected. It would be nice if it said "both are affected" right out in the open. I realize it's implied. Second, it gives workaround of "vfs.zfs.dmu_offset_next_sync sysctl to 0" But on my 12.4 systems there is no such sysctl variable. Third, it says the binary upgrade will result in 12.4-RELEASE-p8. When I do the freebsd-update, the result according to uname is 12.4-RELEASE-p6. Thinking that perhaps I have to do it again, I am told No updates needed to update system to 12.4-RELEASE-p8 and yet uname -a still says 12.4-RELEASE-p6. Somebody might ask if I did a reboot, and yes. (and there's still no vfs.zfs.dum_offset variable) Like I said, all pretty minor except maybe the sysctl variable one. I'm mostly bothered because I'm overly literal and/or anal. I was starting from p1. I hadn't seen anything urging me to step up to a different patch level, hopefully I hadn't overlooked anything. -mm- (long time no post) From nobody Sun Dec 3 08:15:47 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sjfkj0MVVz52Wbm for ; Sun, 3 Dec 2023 08:15:57 +0000 (UTC) (envelope-from SRS0=BbIv=HO=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4Sjfkh074rz3NNV for ; Sun, 3 Dec 2023 08:15:55 +0000 (UTC) (envelope-from SRS0=BbIv=HO=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=fhdCwhrd; spf=pass (mx1.freebsd.org: domain of "SRS0=BbIv=HO=klop.ws=ronald-lists@realworks.nl" designates 87.255.56.188 as permitted sender) smtp.mailfrom="SRS0=BbIv=HO=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Received: from rwvirtual84.colo.realworks.nl (rwvirtual84.colo.realworks.nl [10.0.10.103]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4SjfkX2c1Jz3vB for ; Sun, 3 Dec 2023 09:15:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1701591348; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=X+TWuQI79K3cDmV1kT8+ZWRPeiJcbvglpw/B66HBdAs=; b=fhdCwhrdCSQqOfdThB8kM/pGlVnHyr6x5VJ0rn+NxxtrQOCyz4o96HvfYGuekk3i8UvTiZ HeTOmUJ344to8qoeBne/rMO+buDKj98/+d3Uonyrz16fZ5v8yL0M60I8so0dyRruhhWYOF 3DK24sd0oOZtlznvg7yYeUKURRlbivZ3pvPdg5dWjFPrVg8CDvPmJw+QsPsb6LjL8reOkf VFoGm64spJOw8kmQ1cfY1nauEc0EIF+O300Noc20PWJgfebzmoMUhFlYIi/ps1DDj5fM60 6No2W/VrUY9OrhqV+f4JfUf1T87MzMxqvH/UoMWd3yyjJtYEFm+bS4Kc1cYviw== Received: from rwvirtual84.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual84.colo.realworks.nl (Postfix) with ESMTP id 2A6D5C02B4 for ; Sun, 3 Dec 2023 09:15:47 +0100 (CET) Date: Sun, 3 Dec 2023 09:15:47 +0100 (CET) From: Ronald Klop To: freebsd-stable@freebsd.org Message-ID: <1033957706.15743.1701591347986@localhost> Subject: 14.1 in April? List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15742_2105090647.1701591347759" X-Mailer: Realworks (681.8) X-Originating-Host: from (84-105-120-103.cable.dynamic.v4.ziggo.nl [84.105.120.103]) by rwvirtual84 [10.0.10.103] with HTTP; Sun, 03 Dec 2023 09:15:47 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0 X-Spamd-Result: default: False [-2.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.995]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=BbIv=HO=klop.ws=ronald-lists@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_X_PRIO_THREE(0.00)[3]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=BbIv=HO=klop.ws=ronald-lists@realworks.nl]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Sjfkh074rz3NNV X-Spamd-Bar: -- ------=_Part_15742_2105090647.1701591347759 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, With all the improvements in 14-stable would it be nice to have a 14.1 release in 3 to 6 months containing e.g. the latest openzfs 2.2.X? I'm able to help if needed. Regards, Ronald. ------=_Part_15742_2105090647.1701591347759 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

With all the improvements in 14-stable would it be nice to have a 14.1 release in 3 to 6 months containing e.g. the latest openzfs 2.2.X?
I'm able to help if needed.

Regards,
Ronald.
  ------=_Part_15742_2105090647.1701591347759-- From nobody Sun Dec 3 09:52:18 2023 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 4Sjhsy4vc1z52ccl for ; Sun, 3 Dec 2023 09:52:22 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sjhsx4ttgz3Wgc for ; Sun, 3 Dec 2023 09:52:21 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 3B39qISI022589 for ; Sun, 3 Dec 2023 18:52:19 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 3 Dec 2023 18:52:18 +0900 From: Tomoaki AOKI To: stable@freebsd.org Subject: Re: EFI and zfs raid mirror partial fail (14.0 and RELENG_13) Message-Id: <20231203185218.b257e36a85147bea98e87f59@dec.sakura.ne.jp> In-Reply-To: References: <86d04457-5018-45f9-849f-eb20ed5cf380@twisted.org.uk> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [2.34 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_LONG(0.84)[0.842]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; R_SPF_NA(0.00)[no SPF record]; TO_DN_NONE(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4Sjhsx4ttgz3Wgc X-Spamd-Bar: ++ Resent. Not sure why, but this does not yet delivered. On Fri, 1 Dec 2023 22:57:12 -0700 Warner Losh wrote: > On Fri, Dec 1, 2023 at 10:34 PM Zaphod Beeblebrox wrote: > > > It can be more straightforward to update the gmirror, however. I've done > > this with UFS --- old boot, pair of UFS/GMIRROR usb sticks that then boot > > to a ZFS array that the BIOS couldn't see (so UFS only contained /boot and > > /rescue). It's easier to know that the boot is updated identically if > > gmirrored. Gmirror also has tools to verify, etc. > > > > Yes. More straight forward, not as safe. BIOS runs before FreeBSD, and > doesn't use gmirror at all, so it can't know if one copy is good or not. IT > has to assume that the copies are always good. If you are a single user, > then the convenience is likely worth it. It's going ot be fine and if you > have a power failure while updating, then you are going to be right there > to cope with whatever fallout by choosing the right device to boot from if > the primary is corrupted. Once you reboot FreeBSD, the gmirror will > resilver (usually) and life will be good. But you have to make absolutely > sure that the gmirror never degrades (which happens sometimes on crashes) > so that it always will update when you write a new loader. If the mirror is > degraded, it will boot the old loader if the degraded side is the primary > boot device for the BIOS. > > If you are deploying a redundant EFI booting system for lots of machines, > some of which are in the middle of nowhere without remote hands available, > then you can't rely on gmirror to always be right (because it can create > corrupted partitions while updating each copy that can pose problems when > you lose power. And there's the broken mirror problem that has to be > constantly monitored. At work, we cope with this by having lots of monitor > scripts for gmirror-based system and then take corrective actions when bad > things happen to a gmirror element. > > But for our multiple, redundant ESPes, we manually update them one at a > time because we can't take a chance on the gmirror being broken. If we have > a drive that's the primary boot fail read-only and we can't change the BIOS > boot order, then we RMA the box (though that's rare: we can usually move > the primary and arrange a different drive to be the backup booting device). > When you have tens of thousands of machines, even low failure rates can > cause big expenses... Though the broken mirror and the BIOS boots the wrong > disk that can't be fixed problem is way more common than having gmirror > break due to a crash during an upgrade (but the latter does happen). > > So yea, gmirror is convenient. But you have to watch it like a hawk to make > sure the mirror isn't broken before you do the update. And to make sure > that you can get hands on the system if an update breaks badly due to a > ill-timed power failure or system panic. > > Warner I now agree with it. Are these possible? 1. Admin decides disk/partition configuration on bsdinstall. 2. bsdinstall temporarily record the choices. 3. bsdinstall actually creates/modifies/deletes partitions as instructed at step 1. 4. Error out if something goes wrong. 5. If step4 went sane, bsdinstall generates script to update boot codes using information recorded at step2 such as... *If legacy boot is preferred, update boot code both in (p)mbr and freebsd-boot partition of admin's choice. *If UEFI boot is preferred, and if freebsd-default location is accepted, update loader.efi there. *If UEFI boot is preferred, and if UEFI-default location is forced, update loader.efi there as boot[arch].efi. If multiple types above are selected, update all selected. If admin specifies nothing to do by bsdinstall, and script to be generated does not already exists, generate skeleton (shebang and comments [including samples] only) is generated. Step 1, 3 and 4 should already be done by bsdinstall, but I'm uncertain about step 2. Doing above would allow installworld to call the script when loader.efi (if admin specifies, boot1.efi or something else for development) is rebuilt. The script should be aware of /boot/efi. The primary ESP would be there, but secondary and later ESPs should be mounted to other free (or temporary) mountpoint, updated and unmounted one by one. This way, updating primary first and copy whole contents to secondary and later is possible and can keep them in sync if some configuration files which bsdinstall doesn't care about exist. > > On Fri, Dec 1, 2023 at 7:46 PM Warner Losh wrote: > > > >> > >> > >> On Fri, Dec 1, 2023, 4:57 PM Pete French wrote: > >> > >>> > >>> On 01/12/2023 21:53, mike tancsa wrote: > >>> > Should have looked at open PRs. There is one from a while ago > >>> > > >>> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258987 > >>> > > >>> > > >>> > >>> Was thinking about this, and I was wondering if it would be possible to > >>> make the EFI partition a gmirror. So its across all discs, mounted only > >>> once, but would still boot from any of them. My understanding is geom > >>> has the label at the end, yes ? So the firmware would see the filesystem > >>> on a single partition quite happily ? > >>> > >> > >> I've done this. It works ok. But I don't run like this in production. If > >> I write a new file, that has so many writes to the different disks. If they > >> all go through then life is good (this is what gets us to OK). > >> > >> BUT, if there is a power failure or crash and only some of them make it > >> to disk, then you have a corrupt ESP and the BIOS may pick that ESP to boot > >> off of, booting corrupt data. > >> > >> Since this is infrequently updated, you can use a safe sequence to update > >> things one partition a time, then you might lose the file entirely, but it > >> will either be there and good. Or it will be gone. You can't get into a bad > >> situation. Either you boot old or new loader and can just quit from the > >> boot loader if it's the old one and it can't boot. Efi will try the next > >> one on the list. > >> > >> Here manual mirroring, if scripted, can be more reliable than gmirror. > >> > >> Warner > >> > >> -pete. -- Tomoaki AOKI From nobody Sun Dec 3 11:00:20 2023 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 4SjkNZ567xz52hT0 for ; Sun, 3 Dec 2023 11:00:30 +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 4SjkNY4tPgz3dgh for ; Sun, 3 Dec 2023 11:00:29 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=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 3B3B0N1k033759 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Sun, 3 Dec 2023 06:00:23 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:4c5f:5515:d7d4:294c] ([IPv6:2607:f3e0:0:4:4c5f:5515:d7d4:294c]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 3B3B0Jmf038874 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 3 Dec 2023 06:00:22 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <170e4c0b-5fbf-4b73-bdc1-b0905706fbaf@sentex.net> Date: Sun, 3 Dec 2023 06:00:20 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: EFI and zfs raid mirror partial fail (14.0 and RELENG_13) Content-Language: en-US To: Pete French , stable@freebsd.org References: <86d04457-5018-45f9-849f-eb20ed5cf380@twisted.org.uk> 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: <86d04457-5018-45f9-849f-eb20ed5cf380@twisted.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Spamd-Result: default: False [-3.33 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.935]; 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)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; MLMMJ_DEST(0.00)[stable@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[sentex.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SjkNY4tPgz3dgh X-Spamd-Bar: --- On 12/1/2023 6:57 PM, Pete French wrote: > > On 01/12/2023 21:53, mike tancsa wrote: >> Should have looked at open PRs. There is one from a while ago >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258987 >> >> > > Was thinking about this, and I was wondering if it would be possible > to make the EFI partition a gmirror. So its across all discs, mounted > only once, but would still boot from any of them. My understanding is > geom has the label at the end, yes ? So the firmware would see the > filesystem on a single partition quite happily ? > I view this issue in 2 parts-- a) the initial install and b) the maintenance going forward.  I think the a) part is more a clear cut bug than b).  b) I think is reasonable to be left up to the admin as part of the regular care and feeding of the server as to how they see fit.  But at install time,  especially with zfs, I think the (reasonable) assumption is all the necessary glue is done to make sure there is full redundancy on a boot mirror. If not, there should at least be a warning to tell the user that needs to be done. Personally, I would not like the gmirror part as that adds a bit of complexity I dont want. But it certainly would be nice for some users.  For now, I would vote against mounting the efi partition(s) by default as that breaks device redundancy and would like to see at least a warning from the installer that the efi parts are not yet setup on the other disks.     ---Mike From nobody Sun Dec 3 12:37:52 2023 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 4SjmY83Xbzz52pyq for ; Sun, 3 Dec 2023 12:38:04 +0000 (UTC) (envelope-from SRS0=2m6Z=HO=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 4SjmY762Vpz4LyH for ; Sun, 3 Dec 2023 12:38:03 +0000 (UTC) (envelope-from SRS0=2m6Z=HO=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 BD166D7895; Sun, 3 Dec 2023 13:37:53 +0100 (CET) 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 11E0BD7894; Sun, 3 Dec 2023 13:37:52 +0100 (CET) Message-ID: <57bac38c-e747-4c09-97b4-7f72b7c02a85@quip.cz> Date: Sun, 3 Dec 2023 13:37:52 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: EFI and zfs raid mirror partial fail (14.0 and RELENG_13) Content-Language: cs-Cestina To: mike tancsa , stable@freebsd.org References: <86d04457-5018-45f9-849f-eb20ed5cf380@twisted.org.uk> <170e4c0b-5fbf-4b73-bdc1-b0905706fbaf@sentex.net> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <170e4c0b-5fbf-4b73-bdc1-b0905706fbaf@sentex.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: 4SjmY762Vpz4LyH On 03/12/2023 12:00, mike tancsa wrote: > Personally, I would not like the gmirror part as that adds a bit of > complexity I dont want. But it certainly would be nice for some users. > For now, I would vote against mounting the efi partition(s) by default > as that breaks device redundancy and would like to see at least a > warning from the installer that the efi parts are not yet setup on the > other disks. Just my take on it... Installer should install EFI on all disks in the pool for redundancy and it would be nice to put entries in the fstab with noouto, a separate mountpoint in /mnt/ (or somewhere else?) would be nice for easier updates. And there should be some simple script to update EFI after a system upgrade on all EFI partitions defined in /etc/fstab. No magic guesswork, just use information stored by installer. Kind regards Miroslav Lachman From nobody Sun Dec 3 14:46:53 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SjqQH0ZJvz52xg1 for ; Sun, 3 Dec 2023 14:47:19 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (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 4SjqQG3SDsz4YnL for ; Sun, 3 Dec 2023 14:47:18 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2601:5cf:407e:55c1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 4F7AE2F969; Sun, 3 Dec 2023 09:47:04 -0500 (EST) Content-Type: text/plain; charset=utf-8 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs From: Paul Mather In-Reply-To: Date: Sun, 3 Dec 2023 09:46:53 -0500 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <72154019-C07D-4E34-8100-923DE013797D@gromit.dlib.vt.edu> References: <20231201031737.DF0231B942@freefall.freebsd.org> To: "Mark E. Mallett" X-Mailer: Apple Mail (2.3774.200.91.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:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Queue-Id: 4SjqQG3SDsz4YnL On 2 Dec 2023, at 7:11=E2=80=AFpm, Mark E. Mallett = wrote: > Might I also ask (or say): >=20 [[...]] > Third, it says the binary upgrade will result in 12.4-RELEASE-p8. = When > I do the freebsd-update, the result according to uname is > 12.4-RELEASE-p6. Thinking that perhaps I have to do it again, I am = told > No updates needed to update system to 12.4-RELEASE-p8 > and yet uname -a still says 12.4-RELEASE-p6. Somebody might ask if > I did a reboot, and yes. Sometimes a security advisory or errata notice affects only the userland = and doesn't cause the kernel version to be bumped. The "uname" output = you're seeing is only the kernel version. If you want to see both = kernel and userland versions you should use "freebsd-version". The "-k" = flag will show userland and "-u" the userland. I would imagine in your = case "freebsd-version -u" is 12.4-RELEASE-p8. Cheers, Paul. From nobody Sun Dec 3 16:09:56 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SjsFf0JPVz533Rk for ; Sun, 3 Dec 2023 16:09:58 +0000 (UTC) (envelope-from mem@schmem.com) Received: from shell.qozzy.net (schorl.qozzy.net [209.104.225.37]) by mx1.freebsd.org (Postfix) with SMTP id 4SjsFd1hM9z3C2Z for ; Sun, 3 Dec 2023 16:09:57 +0000 (UTC) (envelope-from mem@schmem.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of mem@schmem.com designates 209.104.225.37 as permitted sender) smtp.mailfrom=mem@schmem.com; dmarc=none Received: (qmail 10117 invoked by uid 101); 3 Dec 2023 11:09:56 -0500 From: "Mark E. Mallett" Date: Sun, 3 Dec 2023 11:09:56 -0500 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs Message-ID: References: <20231201031737.DF0231B942@freefall.freebsd.org> <72154019-C07D-4E34-8100-923DE013797D@gromit.dlib.vt.edu> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72154019-C07D-4E34-8100-923DE013797D@gromit.dlib.vt.edu> User-Agent: Mutt/2.2.10 (2023-03-25) X-Spamd-Result: default: False [-0.62 / 15.00]; NEURAL_HAM_LONG(-0.97)[-0.966]; NEURAL_SPAM_MEDIUM(0.80)[0.804]; R_SPF_ALLOW(-0.20)[+ip4:209.104.225.32/27:c]; NEURAL_HAM_SHORT(-0.15)[-0.155]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[schmem.com]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:14265, ipnet:209.104.224.0/20, country:US] X-Rspamd-Queue-Id: 4SjsFd1hM9z3C2Z X-Spamd-Bar: / On Sun, Dec 03, 2023 at 09:46:53AM -0500, Paul Mather wrote: > Sometimes a security advisory or errata notice affects only the > userland and doesn't cause the kernel version to be bumped. The "uname" > output you're seeing is only the kernel version. If you want to see > both kernel and userland versions you should use "freebsd-version". The > "-k" flag will show userland and "-u" the userland. I would imagine in > your case "freebsd-version -u" is 12.4-RELEASE-p8. Right you are. Thanks! -mm- From nobody Sun Dec 3 23:32:24 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sk34P3cdqz51mVd for ; Sun, 3 Dec 2023 23:32:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (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 4Sk34P1dKgz4LRj for ; Sun, 3 Dec 2023 23:32:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-50be3611794so1922430e87.0 for ; Sun, 03 Dec 2023 15:32:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701646355; x=1702251155; 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=pkyWM/q0vS5wkwgFEzRfh2RVRiacoSLGIBOeqWkuksU=; b=H4/v69fNgOBRtsVvg3LrQlJ+TUmvojPXKCQVXTBDd2ch6SA/QCItwyBN/cvB8scf7s gxhPGQ4TsMl1RAePGqnzV1EDEgBPdVnfogK5WspV636DXdWhAHrpQuV31kVzZXLO9Qm9 ybPTUOtj98/EsU6dkRPdcWJMSdf93ypzkAz4HYOQYSBToEclCOqEB58SgiTe1fM0R14v 1x1v4aH7EPxSbUuMCBtkOR5p3gW25iD5Hiv6pl8/87laDmJ4dLm9Mvt4ejaFmdV6Ichz /tlqlQyASruKqCUqUEqVl9cgcRbQHho+Bjpd1O65o6jEjwGZS9a6P1MaRXlELKpPU/so ZuRg== X-Gm-Message-State: AOJu0YyB6FytvK8vpyAm0sShshwMBv92QscpOqCzJPuF12sv3DNcbSso ApQcOg/+m2Pm3NGRcw4b9kQMX+EgaJFUk0tuU2xzk1Dj X-Google-Smtp-Source: AGHT+IGWl75xhk3DlCt5/p8w3WPzuvuoD0Ry4ecGo9Www1TimnO7YAa6b8wYL50ovZjK/zkhvs/A2SK0BbhHP+4/qsc= X-Received: by 2002:a05:6512:3704:b0:50b:f2fc:3a7e with SMTP id z4-20020a056512370400b0050bf2fc3a7emr397233lfr.65.1701646354709; Sun, 03 Dec 2023 15:32:34 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <20231201031737.DF0231B942@freefall.freebsd.org> In-Reply-To: From: Ed Maste Date: Sun, 3 Dec 2023 18:32:24 -0500 Message-ID: Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs To: mem@schmem.com Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" 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:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Sk34P1dKgz4LRj On Sat, 2 Dec 2023 at 19:11, Mark E. Mallett wrote:> > Second, it gives workaround of "vfs.zfs.dmu_offset_next_sync sysctl to 0" > But on my 12.4 systems there is no such sysctl variable. Oh, yes - the workaround is only applicable to 13.2 and later. For 12.4 there is no workaround. Note that it is much harder to encounter accidentally on 12.4, as 12.4 does not support copy_file_range(2). Applications that explicitly seek holes can encounter this issue (and it is reproducible on 12.4 via the test scripts) but it won't occur when using cp to copy on 12.4. From nobody Mon Dec 4 08:38:11 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SkHB30jQjz5367h for ; Mon, 4 Dec 2023 08:38:19 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SkHB20qjnz3Zyk for ; Mon, 4 Dec 2023 08:38:18 +0000 (UTC) (envelope-from pi@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:14f8:200:4::4 is neither permitted nor denied by domain of pi@freebsd.org) smtp.mailfrom=pi@freebsd.org; dmarc=none Received: from pi by fc.opsec.eu with local (Exim 4.97 (FreeBSD)) (envelope-from ) id 1rA4Sx-00000000Kwl-40In for freebsd-stable@freebsd.org; Mon, 04 Dec 2023 09:38:11 +0100 Date: Mon, 4 Dec 2023 09:38:11 +0100 From: Kurt Jaeger To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs Message-ID: References: <20231201031737.DF0231B942@freefall.freebsd.org> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-2.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.95)[-0.950]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; ARC_NA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[pi]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_NONE(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4SkHB20qjnz3Zyk X-Spamd-Bar: -- Hi! freebsd-update after the update to p1 reports kernel still at 14.0-RELEASE. I had thought that the ZFS fix is a kernel fix so that the kernel would also report -p1, but it does not. It might be because zfs is a kernel module, so the kernel itself was not really patched, but I might be wrong here. Is this how it is supposed to be ? -- pi@FreeBSD.org +49 171 3101372 Now what ? From nobody Mon Dec 4 09:18:35 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SkJ5072jNz537jZ for ; Mon, 4 Dec 2023 09:19:00 +0000 (UTC) (envelope-from alex@alexburke.ca) Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (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 4SkJ5041B6z3gP4 for ; Mon, 4 Dec 2023 09:19:00 +0000 (UTC) (envelope-from alex@alexburke.ca) Authentication-Results: mx1.freebsd.org; none Date: Mon, 4 Dec 2023 10:18:35 +0100 (GMT+01:00) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexburke.ca; s=key1; t=1701681532; 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=4iq1Ilcn7a9IsnHtkE3p5EHSv3DGUOB4X/hTCjc7qtk=; b=l+6aIaBJF0XEbDiGwDYRhCE0vvbZRpdMvKAaW+g//sr9DcJH9eLsjQFcj/uWAHTcK2m08V 5AthTatZcDvEnY9U7nRZ6agG9C6cO3YQ0bgUv+85WLor/Yw+kLsLH4fiDjSkTLCl+48SV6 ztKDMw3nCrJnSCekFvAhjxDnmLH672c= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Alexander Burke To: Kurt Jaeger Cc: freebsd-stable@freebsd.org Message-ID: <13227790-5861-44a5-927f-5de674be85f5@alexburke.ca> In-Reply-To: References: <20231201031737.DF0231B942@freefall.freebsd.org> Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: <13227790-5861-44a5-927f-5de674be85f5@alexburke.ca> X-Migadu-Flow: FLOW_OUT 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:202172, ipnet:91.218.175.0/24, country:CH] X-Rspamd-Queue-Id: 4SkJ5041B6z3gP4 Hi Kurt, For the GENERIC kernel that you are using unless you compiled your own, ZFS= is provided by way of a kernel module. While the base kernel itself has no= t changed the module was indeed updated. Cheers, Alex ---------------------------------------- Dec 4, 2023 09:38:28 Kurt Jaeger : > Hi! >=20 > freebsd-update after the update to p1 reports kernel still at 14.0-RELEAS= E. >=20 > I had thought that the ZFS fix is a kernel fix so that the kernel > would also report -p1, but it does not. It might be because > zfs is a kernel module, so the kernel itself was not really patched, > but I might be wrong here. >=20 > Is this how it is supposed to be ? >=20 > --=20 > pi@FreeBSD.org=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +49 171 31= 01372=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Now what ? From nobody Mon Dec 4 13:48:52 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SkQ4W3Ds0z53Npq for ; Mon, 4 Dec 2023 13:48:59 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4SkQ4V4G8Nz4gxj for ; Mon, 4 Dec 2023 13:48:58 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of freebsd-stable-local@be-well.ilk.org has no SPF policy when checking 23.30.133.173) smtp.mailfrom=freebsd-stable-local@be-well.ilk.org; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=ilk.org (policy=none) Received: from lowell-Ubuntu.lan (lowell-Ubuntu.lan [172.30.250.95]) by be-well.ilk.org (Postfix) with ESMTP id 6252335D63 for ; Mon, 4 Dec 2023 08:48:52 -0500 (EST) Received: by lowell-Ubuntu.lan (Postfix, from userid 1147) id 486AC10804D4; Mon, 4 Dec 2023 08:48:52 -0500 (EST) From: Lowell Gilbert To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs In-Reply-To: (Kurt Jaeger's message of "Mon, 4 Dec 2023 09:38:11 +0100") References: <20231201031737.DF0231B942@freefall.freebsd.org> Date: Mon, 04 Dec 2023 08:48:52 -0500 Message-ID: <445y1eaxiz.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [-0.60 / 15.00]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; NEURAL_HAM_LONG(-0.72)[-0.722]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; DMARC_POLICY_SOFTFAIL(0.10)[ilk.org : No valid SPF, No valid DKIM,none]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:7922, ipnet:23.30.0.0/15, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4SkQ4V4G8Nz4gxj X-Spamd-Bar: / Kurt Jaeger writes: > I had thought that the ZFS fix is a kernel fix so that the kernel > would also report -p1, but it does not. It might be because > zfs is a kernel module, so the kernel itself was not really patched, > but I might be wrong here. As far as I can see, that seems exactly right. From nobody Mon Dec 4 14:02:46 2023 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 4SkQNf00G1z53PFP for ; Mon, 4 Dec 2023 14:02:58 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SkQNc0w5Bz4kJK for ; Mon, 4 Dec 2023 14:02:55 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 3B4E2kxf010856 for ; Mon, 4 Dec 2023 23:02:47 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 4 Dec 2023 23:02:46 +0900 From: Tomoaki AOKI To: stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs Message-Id: <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> In-Reply-To: <445y1eaxiz.fsf@be-well.ilk.org> References: <20231201031737.DF0231B942@freefall.freebsd.org> <445y1eaxiz.fsf@be-well.ilk.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-0.69 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.996]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.19)[-0.190]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; R_DKIM_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SkQNc0w5Bz4kJK X-Spamd-Bar: / On Mon, 04 Dec 2023 08:48:52 -0500 Lowell Gilbert wrote: > Kurt Jaeger writes: > > > I had thought that the ZFS fix is a kernel fix so that the kernel > > would also report -p1, but it does not. It might be because > > zfs is a kernel module, so the kernel itself was not really patched, > > but I might be wrong here. > > As far as I can see, that seems exactly right. As this kind of confusion caused by mismatch of patchlevel between kernel and userland arises from time to time, now would be the time to switch to keep patchlevel in sync between kernel and userland. This would force both kernel and userland to be built using the same patchlevel, even if one of which is actually unchanged. But maybe helpful to avoid confusion like this. What was worse this time was that a non-in-kernel-but-in-tree module, zfs.ko, is updated but kernel itself is not updated. -- Tomoaki AOKI From nobody Mon Dec 4 15:06:03 2023 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 4SkRnZ2f8fz53RYl for ; Mon, 4 Dec 2023 15:06:10 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4SkRnY4Wbtz4ptp for ; Mon, 4 Dec 2023 15:06:09 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of freebsd-stable-local@be-well.ilk.org has no SPF policy when checking 23.30.133.173) smtp.mailfrom=freebsd-stable-local@be-well.ilk.org; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=ilk.org (policy=none) Received: from lowell-Ubuntu.lan (lowell-Ubuntu.lan [172.30.250.95]) by be-well.ilk.org (Postfix) with ESMTP id 660D8400C6 for ; Mon, 4 Dec 2023 10:06:03 -0500 (EST) Received: by lowell-Ubuntu.lan (Postfix, from userid 1147) id 502D51080478; Mon, 4 Dec 2023 10:06:03 -0500 (EST) From: Lowell Gilbert To: stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs In-Reply-To: <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> (Tomoaki AOKI's message of "Mon, 4 Dec 2023 23:02:46 +0900") References: <20231201031737.DF0231B942@freefall.freebsd.org> <445y1eaxiz.fsf@be-well.ilk.org> <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> Date: Mon, 04 Dec 2023 10:06:03 -0500 Message-ID: <448r6a2ejo.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [-0.67 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; NEURAL_SPAM_SHORT(0.79)[0.795]; NEURAL_HAM_LONG(-0.59)[-0.587]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; DMARC_POLICY_SOFTFAIL(0.10)[ilk.org : No valid SPF, No valid DKIM,none]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:7922, ipnet:23.30.0.0/15, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4SkRnY4Wbtz4ptp X-Spamd-Bar: / Tomoaki AOKI writes: > On Mon, 04 Dec 2023 08:48:52 -0500 > Lowell Gilbert wrote: > >> Kurt Jaeger writes: >> >> > I had thought that the ZFS fix is a kernel fix so that the kernel >> > would also report -p1, but it does not. It might be because >> > zfs is a kernel module, so the kernel itself was not really patched, >> > but I might be wrong here. >> >> As far as I can see, that seems exactly right. > > As this kind of confusion caused by mismatch of patchlevel between > kernel and userland arises from time to time, now would be the time to > switch to keep patchlevel in sync between kernel and userland. > > This would force both kernel and userland to be built using the same > patchlevel, even if one of which is actually unchanged. > But maybe helpful to avoid confusion like this. I doubt that no approach would keep *someone* from being surprised, *some* time. Whether such a change would make it less common? Maybe, but I am definitely the last person you should ask. Be well. Lowell From nobody Mon Dec 4 17:51:39 2023 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 4SkWSq2MFpz53c2W for ; Mon, 4 Dec 2023 17:51:55 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SkWSp6l2wz3M5x for ; Mon, 4 Dec 2023 17:51:54 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-54c9116d05fso2521361a12.3 for ; Mon, 04 Dec 2023 09:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701712311; x=1702317111; 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=sqk2zAW6+DTRgT335pPY3d1vHuVAU3TCHlfYOz57n6o=; b=gBgOxlMUqxdCGn+sRhbyjgf1dAsrlDQygkZdPfVMKgDsx6dQysj9O+uqxmolyvGixX 1pvap2iRg9RNImStnOh5acwxNoQJ4A/sql+8dVopVQ0+ZpKXfAZIvperd42jVnOhY9qV sLZC58347lsjuTHlSOJtde4k8JcYHFBfmAA98LqrOKeOA6iE4eX24u86VKviZO+IpkiK GSLW911Kbr0MXmbGYoGnQgxAOAY88ksZYhnhp2/We4BW4/qQomrgV/bDqTFc6UHPbzR+ T736B1z7e4dBi2KiijrLSoadjMooynkA1fUecnP+EmE8IGZwQpCMdRmgEzV6QRJhw3TX /3hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701712311; x=1702317111; 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=sqk2zAW6+DTRgT335pPY3d1vHuVAU3TCHlfYOz57n6o=; b=adu15QHC5cvoKnoXyYQbA3rx2tLhK6NuWyrz39A0cC4iKXvVC+aOn0QO5Sn7j/Em3O 1RyhLIbpjGbGHAj89Ti1/0whPkNDp0ehoYLjxK888vL2iilPqLJqMCTq6QAG5oQpyYtd UdvUqW2vjfPw2kMJL3XXapXBzByS0XVKUF+zoixAG1A/RYzpjKCIH68v002+8eRJqRKV 4XV9PMjHMUwNZvu5dzBgT3Kwvd2kQBq6vKXsir68cYzJURkWWHQinA2CKVUcW+CtLEQD /sYxJYa6jZYqBL6ow51WgvJ4KV+++O2GcvhSdk3RrUKq0hBM/RSkQELE2WMTyovRmdtW CfKA== X-Gm-Message-State: AOJu0YwYIriKYFYngvoDf2Oarzfyfq1G5ZayACQu/N1mtCMkydpuidKe d+JzvsWeg6/ET1rH4VXqnunOyCmZP2P8pkURYu1XoP4KC/s= X-Google-Smtp-Source: AGHT+IFIMCwBdDKyWi3+kwgwVsYQ8juOBvFUFpJ5EsHKbkig74OVbxBJsbvaQKNf9tnIfm3DTBSRWP3IMWnGNBDlu6c= X-Received: by 2002:a50:9fa1:0:b0:54c:5492:da1a with SMTP id c30-20020a509fa1000000b0054c5492da1amr1859609edf.50.1701712311137; Mon, 04 Dec 2023 09:51:51 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <20231201031737.DF0231B942@freefall.freebsd.org> <445y1eaxiz.fsf@be-well.ilk.org> <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> In-Reply-To: <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> From: Xin LI Date: Mon, 4 Dec 2023 09:51:39 -0800 Message-ID: Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs To: Tomoaki AOKI Cc: stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d0b9b4060bb2c5c8" 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: 4SkWSp6l2wz3M5x --000000000000d0b9b4060bb2c5c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 4, 2023 at 8:32=E2=80=AFAM Tomoaki AOKI wrote: > On Mon, 04 Dec 2023 08:48:52 -0500 > Lowell Gilbert wrote: > > > Kurt Jaeger writes: > > > > > I had thought that the ZFS fix is a kernel fix so that the kernel > > > would also report -p1, but it does not. It might be because > > > zfs is a kernel module, so the kernel itself was not really patched, > > > but I might be wrong here. > > > > As far as I can see, that seems exactly right. > > As this kind of confusion caused by mismatch of patchlevel between > kernel and userland arises from time to time, now would be the time to > switch to keep patchlevel in sync between kernel and userland. > > This would force both kernel and userland to be built using the same > patchlevel, even if one of which is actually unchanged. > But maybe helpful to avoid confusion like this. > > What was worse this time was that a non-in-kernel-but-in-tree module, > zfs.ko, is updated but kernel itself is not updated. Part of this is because freebsd-update generally wants to exclude cosmetic changes (like build timestamps, etc., which does not have an effect on runtime behavior) in binary patches, so in order to "fix" this we would need to change the update builder, at the expense of always delivering a kernel change regardless if there are any real changes to the binary. At the time when I owned the builder code, the consensus was that we are moving to a packaged base really soon (tm) and the builder is in "maintenance mode" so we didn't invest a lot in this front. Cheers, --000000000000d0b9b4060bb2c5c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2023 at 8:32=E2=80= =AFAM Tomoaki AOKI <junchoo= n@dec.sakura.ne.jp> wrote:
On Mon, 04 Dec 2023 08:48:52 -0500
Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> wrote:

> Kurt Jaeger <pi= @freebsd.org> writes:
>
> > I had thought that the ZFS fix is a kernel fix so that the kernel=
> > would also report -p1, but it does not. It might be because
> > zfs is a kernel module, so the kernel itself was not really patch= ed,
> > but I might be wrong here.
>
> As far as I can see, that seems exactly right.

As this kind of confusion caused by mismatch of patchlevel between
kernel and userland arises from time to time, now would be the time to
switch to keep patchlevel in sync between kernel and userland.

This would force both kernel and userland to be built using the same
patchlevel, even if one of which is actually unchanged.
But maybe helpful to avoid confusion like this.

What was worse this time was that a non-in-kernel-but-in-tree module,
zfs.ko, is updated but kernel itself is not updated.

<= /div>
Part of this is because freebsd-update generally wants to exclude cosmetic= changes (like build timestamps, etc., which does not have an effect on run= time behavior) in binary patches, so in order to "fix" this we wo= uld need to change the update builder, at the expense of always delivering = a kernel change regardless if there are any real changes to the binary.=C2= =A0 At the time when I owned the builder code, the consensus=C2=A0was that = we are moving to a packaged base really soon (tm) and the builder is in &qu= ot;maintenance mode" so we didn't invest a lot in this front.
Cheers,
--000000000000d0b9b4060bb2c5c8-- From nobody Mon Dec 4 18:00:17 2023 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 4SkWff283Zz52d45 for ; Mon, 4 Dec 2023 18:00:26 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SkWfd3T8Kz3NpB for ; Mon, 4 Dec 2023 18:00:25 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (096-033-195-197.res.spectrum.com [96.33.195.197]) by colo1.denninger.net (Postfix) with ESMTP id 723E32110DD for ; Mon, 4 Dec 2023 13:00:21 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 036EF298AAD for ; Mon, 4 Dec 2023 13:00:18 -0500 (EST) Message-ID: <02ab3650-3e42-4e92-a14f-559d9d3b0b13@denninger.net> Date: Mon, 4 Dec 2023 13:00:17 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs Content-Language: en-US To: stable@freebsd.org References: <20231201031737.DF0231B942@freefall.freebsd.org> <445y1eaxiz.fsf@be-well.ilk.org> <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> From: Karl Denninger In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020407070906030709080402" X-Spamd-Result: default: False [-5.78 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.890]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; XM_UA_NO_VERSION(0.01)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SkWfd3T8Kz3NpB X-Spamd-Bar: ----- This is a cryptographically signed message in MIME format. --------------ms020407070906030709080402 Content-Type: multipart/alternative; boundary="------------OPEkGwm264EgXFclFmeylaNj" --------------OPEkGwm264EgXFclFmeylaNj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/4/2023 12:51, Xin LI wrote: > > > On Mon, Dec 4, 2023 at 8:32 AM Tomoaki AOKI > wrote: > > On Mon, 04 Dec 2023 08:48:52 -0500 > Lowell Gilbert wrote: > > > Kurt Jaeger writes: > > > > > I had thought that the ZFS fix is a kernel fix so that the kernel > > > would also report -p1, but it does not. It might be because > > > zfs is a kernel module, so the kernel itself was not really > patched, > > > but I might be wrong here. > > > > As far as I can see, that seems exactly right. > > As this kind of confusion caused by mismatch of patchlevel between > kernel and userland arises from time to time, now would be the time to > switch to keep patchlevel in sync between kernel and userland. > > This would force both kernel and userland to be built using the same > patchlevel, even if one of which is actually unchanged. > But maybe helpful to avoid confusion like this. > > What was worse this time was that a non-in-kernel-but-in-tree module, > zfs.ko, is updated but kernel itself is not updated. > > > Part of this is because freebsd-update generally wants to exclude > cosmetic changes (like build timestamps, etc., which does not have an > effect on runtime behavior) in binary patches, so in order to "fix" > this we would need to change the update builder, at the expense of > always delivering a kernel change regardless if there are any real > changes to the binary.  At the time when I owned the builder code, the > consensus was that we are moving to a packaged base really soon (tm) > and the builder is in "maintenance mode" so we didn't invest a lot in > this front. > > Cheers, I would argue that if /kernel modules /are implicated in a patch then either (1) the kernel /version /has to come from a module (and thus be bumped if any of said modules are updated) or (2) the kernel /itself /has to be updated so its version can be patched. #1 is obviously a /lot/ less intrusive and perhaps the correct answer: /The "kernel revision" is incremented when *_either_* the kernel itself or any of its loadable modules are patched/updated, and the revision *_itself_* is in a loadable module and thus can be updated as a tiny little file instead of the entire kernel./ -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------OPEkGwm264EgXFclFmeylaNj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/4/2023 12:51, Xin LI wrote:


On Mon, Dec 4, 2023 at 8:32 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
On Mon, 04 Dec 2023 08:48:52 -0500
Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> wrote:

> Kurt Jaeger <pi@freebsd.org> writes:
>
> > I had thought that the ZFS fix is a kernel fix so that the kernel
> > would also report -p1, but it does not. It might be because
> > zfs is a kernel module, so the kernel itself was not really patched,
> > but I might be wrong here.
>
> As far as I can see, that seems exactly right.

As this kind of confusion caused by mismatch of patchlevel between
kernel and userland arises from time to time, now would be the time to
switch to keep patchlevel in sync between kernel and userland.

This would force both kernel and userland to be built using the same
patchlevel, even if one of which is actually unchanged.
But maybe helpful to avoid confusion like this.

What was worse this time was that a non-in-kernel-but-in-tree module,
zfs.ko, is updated but kernel itself is not updated.

Part of this is because freebsd-update generally wants to exclude cosmetic changes (like build timestamps, etc., which does not have an effect on runtime behavior) in binary patches, so in order to "fix" this we would need to change the update builder, at the expense of always delivering a kernel change regardless if there are any real changes to the binary.  At the time when I owned the builder code, the consensus was that we are moving to a packaged base really soon (tm) and the builder is in "maintenance mode" so we didn't invest a lot in this front.

Cheers,

I would argue that if kernel modules are implicated in a patch then either (1) the kernel version has to come from a module (and thus be bumped if any of said modules are updated) or (2) the kernel itself has to be updated so its version can be patched.

#1 is obviously a lot less intrusive and perhaps the correct answer: The "kernel revision" is incremented when either the kernel itself or any of its loadable modules are patched/updated, and the revision itself is in a loadable module and thus can be updated as a tiny little file instead of the entire kernel.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------OPEkGwm264EgXFclFmeylaNj-- --------------ms020407070906030709080402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzEyMDQxODAwMThaME8GCSqGSIb3DQEJBDFCBECEEF9J+6XfwC/tGrec e6FpoVtdShr+loOUAUfWifqFC6zXCKCK9jWOb+IClyCYbGImS3K38qdebM9AxI0s90stMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgAPlz9Xubntkh+p0ikR/A2F/l1BmCDJEWZxXxCK YqiPMM5frL9r+TfQi1haf9ACWOGkHa3kuIGZ8C25YGqijm7Btj2gcFljAkWupvxOCbYYTYEr djt5xRSwU3nr6pFvYTb11C4w122jIFbloyaStuKcSg9ZNNBD7WV1edk84P1ORVHhVHch77MA VgkdQ//9bVdQu0+t2Ds05QUvJLNke6fjYuDE1Tjpz9MxMIP2DZp3yAICLSclc9Nnc192+y+x ZHDC/erlU6jG3e6QzR9kAV5Cim+ZAcjkTbUv0rfzLhShHcEm6H7/otb2h2mu9EdN0fdgBccD TpU7RwmF8VPwHbcZ6KW96uS2/zEp6u4Zn7nKm/aZh5/sSd9M7NFGX3H8o/Cfrt51+t2zo1Jy G7dF9UBD9wm7p7Qd+tAbxOKqXAN1n+GW420tgmKl1CrV2SChub8AdiU3q0V9DRAdw8en1zZ+ 4kr69sGt+aqGcBAZD3ggJuTyaF5ipVMsaKJhRcQ6s9JIqQguQwrjy57XRIoMZbPdP2a0mw6N 8c6cUgSLNc7rp2m0I8At8RUFtoZ9w6RozAYXQa0MN/uszp5YfDAKOYebySsqDd23mWvwchip aRls3fCUjD+W67ugUReL6J5R+vRwCzbelp3GhGVGdKUIDO1pggmz59oUUaxe1bK4kNH5DwAA AAAAAA== --------------ms020407070906030709080402-- From nobody Mon Dec 4 18:59:44 2023 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 4SkXz94zGSz52h2L for ; Mon, 4 Dec 2023 18:59:49 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SkXz91G3Yz3VPM for ; Mon, 4 Dec 2023 18:59:49 +0000 (UTC) (envelope-from pi@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from pi by fc.opsec.eu with local (Exim 4.97 (FreeBSD)) (envelope-from ) id 1rAEAS-00000000MSL-0Jxf; Mon, 04 Dec 2023 19:59:44 +0100 Date: Mon, 4 Dec 2023 19:59:44 +0100 From: Kurt Jaeger To: Tomoaki AOKI Cc: stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs Message-ID: References: <20231201031737.DF0231B942@freefall.freebsd.org> <445y1eaxiz.fsf@be-well.ilk.org> <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> 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:12502, ipnet:2001:14f8::/32, country:DE] X-Rspamd-Queue-Id: 4SkXz91G3Yz3VPM Hi! > On Mon, 04 Dec 2023 08:48:52 -0500 > Lowell Gilbert wrote: > > > Kurt Jaeger writes: > > > > > I had thought that the ZFS fix is a kernel fix so that the kernel > > > would also report -p1, but it does not. It might be because > > > zfs is a kernel module, so the kernel itself was not really patched, > > > but I might be wrong here. > > > > As far as I can see, that seems exactly right. > > As this kind of confusion caused by mismatch of patchlevel between > kernel and userland arises from time to time, now would be the time to > switch to keep patchlevel in sync between kernel and userland. I'm fine with a little confusion if there's less churn during updates. > What was worse this time was that a non-in-kernel-but-in-tree module, > zfs.ko, is updated but kernel itself is not updated. It happens not very much, so it really does not matter. A note in the EN would be sufficient from my point of view. -- pi@FreeBSD.org +49 171 3101372 Now what ? From nobody Mon Dec 4 19:59:51 2023 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 4SkZJj3jJMz52ljx for ; Mon, 4 Dec 2023 20:00:05 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SkZJj0Bjqz3c1X for ; Mon, 4 Dec 2023 20:00:05 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-54c77e0832cso3212194a12.0 for ; Mon, 04 Dec 2023 12:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701720003; x=1702324803; 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=Ku8zh68lcxXowf5INjrFfcK0oSKST70IKvk1huhEdmM=; b=ULiaWwiLucXWBXKXJRa1+mfdOT5NBPEdqYePwV4iawWfn4Lbfrb7dNTfUwHUJ/Io3Y 1Zv7vhZGplI0IyvX0Or2d0FZOhRwWYoP1xWqMir3gswoBLUgMSweIuHacUWKlJXqx7M7 PRJ2dxC5aqIU0wZ6KWxgQQenjs7zdDrrsZZ4HHmtwSnnhcYndu2f9pmtcEy+fsO+GwvW 09v0Z+5M6jzXa6Ym26xWFkajMGJ6DFqH6mZPYMtR6U5eRJCHF67QJ2x70wGY8tOdD7qU jod8Cl4Q+8un2k5abW+npGziO+1aN6dzgTlj4kA+IDM0ccwd4vo8/x9Z8dHzFrCJ4Zb+ UJEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701720003; x=1702324803; 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=Ku8zh68lcxXowf5INjrFfcK0oSKST70IKvk1huhEdmM=; b=t+6g0XFafvTtSa3bP1CjjcVMaABWxOttHu0hDKHLhVIiOAxlZubY5mqqnsiq7LZd2u KdvPPTeHUQOP+Af15w2qZCdVKqIv63OlMNwryzCiNyywMHfnERCG8BXkqEvZgEXuqJ5B 0HeYqASj4ydR6nahiIdwLqGPxqESCZd1xW6Pg+zw3KJFnlvviEe3gzOU9sOejGhEJOSr mVHhyc8IM02LP4gZYNW+yrkGr3YZa3wn/QASeOlTH++VgWWbpPQeLpqZK7QXJ0pKYZES S4ZyBXL/hK7hquD0JUqepbZruQN0fHmQSKQ1jn33rA6M4MloPtUVzd6SwtWwND9EMFkD rNqA== X-Gm-Message-State: AOJu0YwWzypSpZuT1Clhp5clf3Hpmp4prV3vzWVDtmagpeAtRg0pXDjN vTgvxhxBJtDEiiXxR1XQsi0bVaSLbUCqAEdqOfnHJ3EJf+s= X-Google-Smtp-Source: AGHT+IGxIAi3Y/TemKJK/gNyX7OOP+ie+JCf21O+5fker+GdBCa+h312gB3v+SvoCr0u/i4UutUbJdxqeS24cyTx5bM= X-Received: by 2002:a50:8749:0:b0:54c:4837:93f5 with SMTP id 9-20020a508749000000b0054c483793f5mr2949894edv.60.1701720002838; Mon, 04 Dec 2023 12:00:02 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <20231201031737.DF0231B942@freefall.freebsd.org> <445y1eaxiz.fsf@be-well.ilk.org> <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> <02ab3650-3e42-4e92-a14f-559d9d3b0b13@denninger.net> In-Reply-To: <02ab3650-3e42-4e92-a14f-559d9d3b0b13@denninger.net> From: Xin LI Date: Mon, 4 Dec 2023 11:59:51 -0800 Message-ID: Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs To: Karl Denninger Cc: stable@freebsd.org Content-Type: multipart/alternative; boundary="00000000000046c6e4060bb49013" 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: 4SkZJj0Bjqz3c1X --00000000000046c6e4060bb49013 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 4, 2023 at 10:00=E2=80=AFAM Karl Denninger = wrote: > On 12/4/2023 12:51, Xin LI wrote: > > > > On Mon, Dec 4, 2023 at 8:32=E2=80=AFAM Tomoaki AOKI > wrote: > >> On Mon, 04 Dec 2023 08:48:52 -0500 >> Lowell Gilbert wrote: >> >> > Kurt Jaeger writes: >> > >> > > I had thought that the ZFS fix is a kernel fix so that the kernel >> > > would also report -p1, but it does not. It might be because >> > > zfs is a kernel module, so the kernel itself was not really patched, >> > > but I might be wrong here. >> > >> > As far as I can see, that seems exactly right. >> >> As this kind of confusion caused by mismatch of patchlevel between >> kernel and userland arises from time to time, now would be the time to >> switch to keep patchlevel in sync between kernel and userland. >> >> This would force both kernel and userland to be built using the same >> patchlevel, even if one of which is actually unchanged. >> But maybe helpful to avoid confusion like this. >> >> What was worse this time was that a non-in-kernel-but-in-tree module, >> zfs.ko, is updated but kernel itself is not updated. > > > Part of this is because freebsd-update generally wants to exclude cosmeti= c > changes (like build timestamps, etc., which does not have an effect on > runtime behavior) in binary patches, so in order to "fix" this we would > need to change the update builder, at the expense of always delivering a > kernel change regardless if there are any real changes to the binary. At > the time when I owned the builder code, the consensus was that we are > moving to a packaged base really soon (tm) and the builder is in > "maintenance mode" so we didn't invest a lot in this front. > > Cheers, > > I would argue that if *kernel modules *are implicated in a patch then > either (1) the kernel *version *has to come from a module (and thus be > bumped if any of said modules are updated) or (2) the kernel *itself *has > to be updated so its version can be patched. > > #1 is obviously a *lot* less intrusive and perhaps the correct answer: *T= he > "kernel revision" is incremented when either the kernel itself or any of > its loadable modules are patched/updated, and the revision itself is in a > loadable module and thus can be updated as a tiny little file instead of > the entire kernel.* > They are indeed incremented as part of the kernel patching process (this part is automated in freebsd-update builder actually), so freebsd-update builds would actually build -p1 kernels. However, when creating binary patches, freebsd-update would also examine the 'kernel' binary and note that only patchlevel were bumped and there is no change to the 'kernel' binary itself, which is considered cosmetic and ignore it when publishing the patches. This would be a lot easier to implement in a packaged world (where the package's patch level is bumped, while 'kernel' binary stays the same, and administrators examine the package's version instead of the kernel's version string). Cheers, --00000000000046c6e4060bb49013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2023 at 10:00=E2=80= =AFAM Karl Denninger <karl@denning= er.net> wrote:
=20 =20 =20
On 12/4/2023 12:51, Xin LI wrote:
=20


On Mon, Dec 4, 2023 at 8:32=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
On Mon, 04 Dec 2023 08:48:52 -0500
Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> wrote:

> Kurt Jaeger <pi@freebsd.org> writes:
>
> > I had thought that the ZFS fix is a kernel fix so that the kernel
> > would also report -p1, but it does not. It might be because
> > zfs is a kernel module, so the kernel itself was not really patched,
> > but I might be wrong here.
>
> As far as I can see, that seems exactly right.

As this kind of confusion caused by mismatch of patchlevel between
kernel and userland arises from time to time, now would be the time to
switch to keep patchlevel in sync between kernel and userland.

This would force both kernel and userland to be built using the same
patchlevel, even if one of which is actually unchanged.
But maybe helpful to avoid confusion like this.

What was worse this time was that a non-in-kernel-but-in-tree module,
zfs.ko, is updated but kernel itself is not updated.

Part of this is because freebsd-update generally wants to exclude cosmetic changes (like build timestamps, etc., which does not have an effect on runtime behavior) in binary patches, so in order to "fix" this we would need to change the update buil= der, at the expense of always delivering a kernel change regardless if there are any real changes to the binary.=C2=A0 At the time when I owned the builder code, the consensus=C2=A0was that we a= re moving to a packaged base really soon (tm) and the builder is in "maintenance mode" so we didn't invest a lo= t in this front.

Cheers,

I would argue that if kernel modules are implicated in a patch then either (1) the kernel version has to come from a module (and thus be bumped if any of said modules are updated) or (2) the kernel itself has to be updated so its version can be patched.

#1 is obviously a lot less intrusive and perhaps the correct answer: The "kernel revision" is incremented whe= n either the kernel itself or any of its loadable modules are patched/updated, and the revision itself is in a loadable module and thus can be updated as a tiny little file instead of the entire kernel.

They are indeed incremented as part= of the kernel patching process (this part is automated in freebsd-update b= uilder actually), so freebsd-update builds would actually build -p1 kernels= .=C2=A0 However, when creating binary patches, freebsd-update would also ex= amine the 'kernel' binary and note that only patchlevel were bumped= and there is no change to the 'kernel' binary itself, which is con= sidered cosmetic and ignore it when publishing the patches.

This wou= ld be a lot easier to implement in a packaged world (where the package'= s patch level is bumped, while 'kernel' binary stays the same, and = administrators examine the package's version instead of the kernel'= s version string).

Cheers,
--00000000000046c6e4060bb49013-- From nobody Thu Dec 7 00:56:48 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SlwpQ41WPz53HN4 for ; Thu, 7 Dec 2023 00:57:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SlwpP1Yqjz4Pvy for ; Thu, 7 Dec 2023 00:57:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=RCA53BH3; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701910619; bh=rxHaJ4Z0Ka5t187JPgCi3iiSzGFIra0U4OPI5ZYZbeU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=RCA53BH3CbwcLtlSPHdL+6bZvZhIkMb5rCL2HcoGPc9H20+GlHoN1fYBsLBHanYfehcmjZjuhKqFAazt0dkgTTggJ7VCdZiWTSVe2RqK4fu5X7iYDseNHneqVeabqg4BiD6Trkh0WTIqnShafIRnRKxH32wNFVIJhxwb5e5zbhW7hW+RYzsoUGEdt1MaaPw0pgVplTzzGzliPgTKpaJGal7iJY3+nBhYBHttpw54doJIlT8obxbcicXeeNFPij9+a9zDC/6DEiAQmry2IgINxazxj6ZRvJHQFJbXTPWYBlWj6L6nzAvGBhsbiNIfDZskaBrS++tAazZsedm4vn5crQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701910619; bh=cTRbpec+POh++YcTC+c1yhbgvVRW+6AtfHcjTPqn3QX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=gTvsBlToGqPxOtcY/L/0pkcW13TNfFUzSNTiALeslnRhWTXZJPeneEtCrkf0RmZ8zd/M1XPjD4M+Kh1m0BGdlGGtEUxUv9qyCorTKBLUlaFw+InmWk7hmycLX7hoVl4V/rS0CZduBnzFrTwQxAUWAmvkhSgJoWLzuhQK0lx5DAHXigx9MvMkV9UZ/diS3iPXGnCgLYkph0WQd0JLINSN+7pHZNYFYT5Ckq28Wwkz68kT6kcBg9O5bWsQoPdOeW1ziZuQcjMZZN/oXSPRMZ9i104w9icRjRRLVRc2DPnVnxnUF5d/nLFAuW5+Wq9rzWfQF5124QN+o677mNoylqIiHA== X-YMail-OSG: jr20dkgVM1l8xJgOCz718lV3.qJcHKSj3M8k_CtMvibjjmW2jDf2OekFRfNW54m teiDzhRuzC85qQ969pQdO.7V9HHXnDdLyGVwGfsQoyAiJ_qido6jk.C1pNXIZu2WcgiAqk2cJzO. cqlWUMoleEKJP43JYyJV_GlDvir2jPnKwW6o10pSaJWg9illPCPc5wLLiV8wL7pRB66j6.N0cUHP 9ZcInCMjrG3gC7Q5Y.0xQW_rqWyVLFQ7pwjtWIXP7AKq93Ch7qzyJQFvR.7NLSImXxdiUJaQvYO8 _OaFD5eL_MmbNdT7ob5L2AVNogL6n.6MJmEI61DIDpcZSPTzxnpi4c2YVBi2yaACPnTcqZbsugk4 8hr4b8kh9xYZoXvhW7RaYGg2IZW0eWFanv4JPpJ5IFDTgq7so476LuiL46_XZd.RdFwxRO1f0MKc W.d0hgg5H02jC5F2DbxXXhoC5ClLODCU.v4s2c.lj6cQ84ZFCzUjzFsmnYBOFv_aLdS3E_LBtvon 9UJU.mYmrd1uheWxQBe7SNnPoGAC4YXD5A5hUzqQm3xmXuthDhvg6x5nWcLcfXOD4kRNtJvN.Fhx 25RYDDiy3GvKBOk7W.ZKVu7PhSyuIcc2HSjpyK7twM24xB7F6wR2sC0Egajfc2IUw31bQkZURjMf uOFumBTpKLQGnRD_NiCmjQvoypbLv988Pn73XwSflHGxbhArLlN4FxYJzbhh1PGtLUKz3qYPxrXg zuL792_Zhug9tfJs6ZcbvXucRGeJ2Fls1S45Djewvy.ISO.vOIfMMnafGZte9K2cA4wpL70SCj6o M3gss48zVH3wkH8GugpmFsYz1ky4AK4DLvS1nRZ7yRm3a02S5rnlx9jJQErUH9xV6ULmczM6P5cy Cn7N90esq2dsPTA8Pqe4u3UtH.QtJPEcFoc30NUtR9ibqjnK0QlmZRkjxff9FQc5GyhnYUv0rlut sGjhFjti9IFWsQ8viJxntTYlRB5B45hrLvPHyuRLIpatS_IDPfkRg8A.rxTmn2bJaCpw8HCbDlTb QDyXzsYeIkCzWA._4.85GMOQ1DOQ6437ewckXyQhis1CjuTgi91xDF_GQPx21V_zeubpn2jT3xSU 89dydEb5lCdL3GJSgoYCTj1K5AchRJG0wrCWp6KMIUqIoQutNuqThGlLThOU67OyVTrDzLuej3vx mTHhPYioHewyBAE8oqDk_.37.KpmLHvZZzk1EGKj0qiwu5fOAuxiyFs82rH1VMIX_TAOAdxV1VTb paELHqTHKOggf0TpTdQZCuP30ZpLLdqIaoO_MAWQyli6NJ0eZ_UaZVjI8oZqsdJzAzj8L1g.Q5e0 UTIP2SpNt4ES97RyFWt.86S0WhP2WPXqUxjHXIBp4B0lNwgk.WiRhsf7JURfzdQV9UI6bh.D3gfT 0Sk3ffD.MY.qjW1K8duxFLgjEQgwhnKN3_RoROo.LzFjpH_f_JAUhicWVcd71RSMbiaxxZtZaMA5 OSS2aoneU_KW6NUcG0OsDoKSJ.AfRbts4Zrj4Be4lo4L5_rm.JWXnNFy.8z7bl8FlbEHVCi.Pgek MAQrkt5nd10X1zuLREEuTOhOYO9lFfQ5rzEjfLte_LsLPEQ1ncvQkQQUfUvzP8PdOsDP_lhQdEXO 5EVlV6losUUZ6RV5FRDvUdor95AN0XUD27v4KTBuA5TIM3luzlUgI3W4rcmOY.DLPevQx9XXfTR. FCLfjVJ9MDdA2lVg0BejB9fgCsyWO04f0qXCjoVZuxQtQsGwViSmjfLDGMZX1fOe8v3zHnuGLuoV HZ3y9RjmY0IRoXMK.5XvM55uPRMTaD_dM481y1UDxcRK6dFw080GQaD2knDsw1JtVeLjt0rQ2_jO 7mF3BLruJI0_zSQBT_S6kJ6FeIA_E.22PlS9FbMTYoG2evjkfoNThWsSl1STkV47Ao6GpPjxvezt tR_b85X_y7qSQ9.juLe0Q3Pg5otEtyB30yCfD8eKIiPvX7ppFPN3uQa6BN5tK7r4ciuNU5o.InM7 bfhI3sDjGB9DoQnC4JDl35yYWciRA45XPhR40BgCmBNNHsTGAAPpW9W8_Iq9cv3Pvffv5q8BCIuc .kSOqp11aYEs68VYOugkINQd5rqpewo8ET_vxDXkpdM4K3cTo6Tn70ucUlxLqSZd8bkMfHVLknLa TAkbxo7d9Fqs4ZD4qdRQbfP4HVKMjTAQbg652WdKU7r9arQHfjN3TPKDhPfOyDxyTH9gZ02.kh0G o6f1DPI2hOUOJd0.KjtUHQll4IiyGE.wdDsw67xhIsSKKBzTssZNWuXIabFQZHQ-- X-Sonic-MF: X-Sonic-ID: 09e42900-6975-4232-8e3d-cc74367e4491 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 Dec 2023 00:56:59 +0000 Received: by hermes--production-gq1-64499dfdcc-pz4mv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e5b23891c81ced7bb8a7ff280ddf90cd; Thu, 07 Dec 2023 00:56:59 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Is releng/13.2 deliberately missing: #15395 1ca531971 Zpool can start allocating from metaslab before TRIMs have completed Message-Id: <3D2D48B2-4C99-4E43-8BF2-AFA7957184D0@yahoo.com> Date: Wed, 6 Dec 2023 16:56:48 -0800 To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3774.200.91.1.1) References: <3D2D48B2-4C99-4E43-8BF2-AFA7957184D0.ref@yahoo.com> X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SlwpP1Yqjz4Pvy X-Spamd-Bar: --- zfs: merge openzfs/zfs@d99134be8 (zfs-2.1-release) into stable/13 included a metaslab vs. TRIM related merge: QUOTE OpenZFS release 2.1.14 Notable upstream pull request merges: #15395 1ca531971 Zpool can start allocating from metaslab before TRIMs = have completed END QUOTE that does not seem to have been commited into releng/13.2 . Was this = deliberate? By contrast, the other 2.1.14 notable upstream request merge commited = into stable/13: QUOTE #15571 77b0c6f04 dnode_is_dirty: check dnode and its data for dirtiness END QUOTE was also committed into releng/13.2 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 7 04:31:13 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sm1Yv23dYz53Yhc for ; Thu, 7 Dec 2023 04:31:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sm1Ys679kz3MXk for ; Thu, 7 Dec 2023 04:31:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sbJtE6BE; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701923487; bh=bqy9alElPtOLehJaAGfTGM393FoswTPIBgNyMJDVDqU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=sbJtE6BE+Cs33M3VN5HUCL+sa+yyCn9Cw8UVrl68BY1bPbL3Zi7ekoNWCQirwCYhoPgPT+HEGMmPi9+TBdPinBgmdyy5HTgt+sVqNuD38MSO0/9FoiLOSYMtmn20dSzb06O2C0RHsd/2V4A0qjhWiuvMK9LTWr+C9zOJyX4mp2LXJV1IkEICq7EZc/BNpBQ9fTVoR8r9QGYm9T/nYosejN1+VwM721YfM27/tlIJY+Yr3uYYgy4t8G7/P0jUoyc6CJWLW3sDJbK/tj4sRvZvEMsm1sN0HFTyaVnOyMUayXE/ZinJJ/AtHZ4HIUJHHizmOOwwLxPJo6lQpLHbBD032Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701923487; bh=h2v33qlk/8vHaRLno3Y1U5xVKpqDkIYdzLdglMaf6H1=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NTOOfrgbMHUb2djcP1e5rLucOEoiZ7ik6YkvI/Zx8R3cMhRvr7j+dzg2XdJL51YnU7fJ697UJtJ8VcEkW6FOC565uTU6QaLrxmg/2rHxlFHUDXXm6AqjLoc9PhXvL+3HFh6EcscPmKQ68GYvGUW6urnwncyD7U9RgYqtia3G1EpzhMUDTT74Xc71xnAmCafs1xCwoT+PbWEZ8Vt4jWWr8UWEAB1UW3KYTzrK/VUmsEK6Uwgs4CwGtLXvfMFsEe7/c4rMHoJg7Kh45JApDcnDVUv/4hIoBEDs9uzFkNhmIe0bwoBJuwTqCtUifPiCEeVbhZoEDzxA2QIOIDt7TydwaQ== X-YMail-OSG: Ty1C_xkVM1lOs0q6hy12BGcXju6FVFfwyYTzi2aVquxddWUJ2YrUXRWPxyKT1P8 ZctAE_71P_Y4MxmrZUYRMmd65X73iWYRuCL.xjnVdjKJ9l4mmB9uThmIBdLO5ZJXxlMsyLAEO7bY _r6JbAwj9qgqk1wYBp_SMMWTwO5GhFWab7HnGThrRx5qKA3ucR04jy5wx7XbbbgEWlQvBXqIYaeR 2JfjM7GaWxUujgDu0sm47_DQRwud.jf5UBo7vBH1B.sC_wX7zW8lplykGrGjryTrOn23M5m90nCj d.dxpGESngB3fEqOqyGasFUxxZSctuAKZFzf.RzGlE.OYM8YILoJrZ.QtHdcGG8z6hgrAhvXeUBl unjcwfZvS7ArqmsXbRTRwW3ZKCQMzVzfoyuA980eyh5kgbO0tI4jMyluhYCwgtS21Loeiw0N.42l CRNQb4Ej8kMAg7BDppelZwFhyWmY8Lrf8OQ5iopxRvQyOsRy9RStVZoIBCp5kojJ5WmBVNeIICa3 YDysEgWOeH2fmK7VOOJQ3Da77h2BQZNJ2Upe5MiyQ6P1goyZt1GRqvcOSAvZ0A5Uv3U2zP6iwZvX nxkacOh5uUQ.cw.xrX_IPf4.2UUDDkNLuPHDif5s67kdPXX6VJmuxdu.Ag.JNU0mibLewXzZBZ5E YM.taF4xwTL2424SKKFwe63Vjq.58W0RzLX0VUYsFoVJqjxpXSSERuKYYuIEbZbmiOmLz4PC93Bf Kv5oWsnvz5XX6.TYU_QJn4tizRuTM3UtLO0ilw7tTKyH143LcvJ96GyP2mfW5G0TfA0QtV8KFQVk _M0heEV5gyjxKXL_NLbMoP2fDYZjbNGCUMiOqqJ5NND8pc_EinmlEPISx1obzKCQlLbwR2O2Xu9a KLbtxFubwsd0n_KWL7Ndj1mQzL7lGSsYbpPVWxLhKL5MyWMiSuI7cFhsICA3YS2Gk6iQt9k3vU2l .Ek8_EtIFSiB.KvcEIDYtlmdVhloio68WWQfjdU_7kMzxqtq7MQmURcCy4GKoMXDofEZj_NcbpHM vZStVlbmNGWI1a7UPBeo6aR_6poPoRrap6dN9pRruHHFuhNG.27Fnd19_ldbu7Im.xOdGFYeZSyD 0QrkJ42hxfdODBlfUiCEnXy5zgvP0WsySg.9coidnot_N5ZJVKK4CQRT57sQdl1cE2Fye8_5TrSI eeZABRU25uupGKUATu63YQoLJGIGYpwkqDKxtvV2d3EOR7VdMTS9TBtV7b_biCR0gAI16jk9BV5B WmIv_zdB42aY1HafJB66i9pjZIkwgEc34Fo1GyuUSqP9BsFo8TuLZU4x0JxXlMNAXzuYRwpczkI3 sdWb4PliDd5huYB_GIZr8xK3Zii4jKAVX48e1OuEQlJnX7bsFD7ebne7RtaZBza22BHq7XRsWBi5 LpWtXczQfMNVXf1joA4eJfu2hawLqWKLDj7nKeJCFGTffu.QlS0irQYtHDhABC4G_6BfBnP8awe9 2N9H0PoMnT0Ga4kBLcL9f7xVkVAFmQBBAvqR6OAUneH3BgXejSE_vO3Zvy80OrnGW1hzXYG.VD9S qHkLP9WCi7J_gHpTBox2b._u6y0hLGHXPLXp1PtCXADm2DPIw86nAqf2XMPw3ziFIW397cqFnJlB RAn_wCACN5B3rIkYd0PXkNyHLhLXOgrwj8hC1M2g1lg_B.T2iMsNngS5Miu8W8eBXXOzOXTDRxDb JmAQ6TP1rZhPyXAGd2N5lRldtHZK6kr.z.BrDqk_AKPk4SWgmu.nNJK.MLm2UqPt2qsdOFX2.I3r TkMGvWg3ZBVXDSCtzZzoKJQPXUnNeqSG4QsmF2Pg5sJ78xtCD5q6rIrxrptMiJvAYnIiRkANeuYm ti4z54g2gDzqShPo7R4u1XKuSXJzqs8rCC5b8AyF8fvSpIG4NrLM3_C7gaX4pR.r24fyr4AeSNau e5eUrAdJtAD9TqdMe2mtKPf3HO3wg2WwUFr9g7_aNVNqNs.Pbh0v4BgEvVKIsGU0TgbLDBE5kHWr ex2reeNRXarLamqlo5dJ1ij2nPiguWb3NhV2R5mxUzSFQcmMVXWxqQWkYdPghjtxPO8zcTYVN9j1 mIo7MeOSRBqqJa87528l9nuUXUDpwP._GvqoAuwXizCPGA3mGLfR9BCbm2nUyz6uPuGhkiRnL3nq _tewRBnZeEa1vZ8LPxN2CI.hPAeVh60wFCHTKFBT0wQ8Rv8BndIM5.md7NXIAntQibwygYpjKKd9 r9jDbM.ug7sKzvaBINlXjUK1ApAzOBxeLGs_9coiIN_RXLPWU9foBo_tmCFGZajCZf4NicaWB7T0 iCyqLfA-- X-Sonic-MF: X-Sonic-ID: c1a297b4-c203-4fa9-aa27-5107d2b96bff Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 Dec 2023 04:31:27 +0000 Received: by hermes--production-gq1-64499dfdcc-m6m9b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1f8c2da4d6900a2db2a7a3cf6c36dfba; Thu, 07 Dec 2023 04:31:23 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports Message-Id: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D@yahoo.com> Date: Wed, 6 Dec 2023 20:31:13 -0800 Cc: dan@langille.org To: Warner Losh , Current FreeBSD , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3774.200.91.1.1) References: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D.ref@yahoo.com> X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Sm1Ys679kz3MXk X-Spamd-Bar: --- man arch reports: QUOTE Some machines support more than one FreeBSD ABI. Typically these = are 64-bit machines, where the =E2=80=9Cnative=E2=80=9D LP64 execution = environment is accompanied by the =E2=80=9Clegacy=E2=80=9D ILP32 environment, = which was the historical 32-bit predecessor for 64-bit evolution. Examples are: LP64 ILP32 counterpart amd64 i386 powerpc64 powerpc aarch64 armv6/armv7 aarch64 will support execution of armv6 or armv7 binaries if the = CPU implements AArch32 execution state, however older armv4 and armv5 binaries aren't supported. END QUOTE (I take "armv6 or armv7 binaries" as what was built targeting a FreeBSD architecture triple for one of those. FreeBSD keeps them distinct.) However, the armv6 part of that is wrong: The infrastructure supports only one 32-bit alternative for a given kernel, not a family of them at once . . . sys/kern/kern_mib.c : static const char * proc_machine_arch(struct proc *p) { if (p->p_sysent->sv_machine_arch !=3D NULL) return (p->p_sysent->sv_machine_arch(p)); #ifdef COMPAT_FREEBSD32 if (SV_PROC_FLAG(p, SV_ILP32)) return (MACHINE_ARCH32); #endif return (MACHINE_ARCH); } . . . static int sysctl_kern_supported_archs(SYSCTL_HANDLER_ARGS) { const char *supported_archs; supported_archs =3D #ifdef COMPAT_FREEBSD32 compat_freebsd_32bit ? MACHINE_ARCH " " MACHINE_ARCH32 : #endif MACHINE_ARCH; return (SYSCTL_OUT(req, supported_archs, strlen(supported_archs) = + 1)); } sys/arm64/include/param.h : #define MACHINE_ARCHES MACHINE_ARCH " " MACHINE_ARCH32 . . . #define MACHINE_ARCH32 "armv7" (There is no "armv6" alternative present.) But with something like: #define MACHINE_ARCH32 "armv7 armv6" MACHINE_ARCH32 is not interpreted as a list of alternatives, each supported. There is code that would have to be reworked to allow a list of alternatives to work. One can build a custom kernel with: #define MACHINE_ARCH32 "armv6" and then, having booted that kernel, then run armv6 on aarch64 --but, then, not armv7. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256132 is about this and has my messy notes as I explored and discovered that multiple 32-bit alternatives did not work. I see that I forgot various quote (") symbols. This note was prompted by: = https://lists.freebsd.org/archives/freebsd-hackers/2023-December/002728.ht= ml that mentions "the list of valid MACHINE_ARCH" that reminded me of this old issue. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 7 09:19:26 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sm7yS4lvdz53tdh; Thu, 7 Dec 2023 09:19:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sm7yS4G3Wz4S8X; Thu, 7 Dec 2023 09:19:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701940784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+7yN9OEkgGgFe0ohUOL4ljYavKJXghk+9c0DO9vPNUs=; b=dhj1pSd/w5FvDiI6/WyZtTUuMq9cTzwh0iz0cqgeWwYTemuFpiCP5uj+DWCZWZtZQQW+7r XGZv8H5QzDUejYYPpckjGW9ufsCp071Wo6w0NFccd6SfzR/6J6UuVob+ZTaYYp7lA2eFN2 Z+ZmmEOfPetI/GRjSeS+l6AqY0s9izZwYrZ/N3v80ImcSXak55gWR+A8Ueb/hEsOM+DYmm Ln+g6uiM+hD+Z+Q566Sl5K2VNK6rilnbhZh1UaoQ/0PRV3+ce+ptxCqQm7gBjoP11YFDXG hGmJ7N8r+wzd96X+aPcVnEfU4zZDFDxDsvq8WonbdKbEpbMoVBp57F2iKxJcxQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701940784; a=rsa-sha256; cv=none; b=e9aQIl7Ocxdz3g2y5grA/sHH4E0QuG/QiFa4085Jas+RXW5erPYbHtMo+azWcw+NWTf0Cz mdmG82AdaXTkx3sVYucO5IO2TZBlzu5hN8T272BEHI4fRr/KNZpBDqdmQ/8TkGuIvUaFAg gdexDkNjC4pVVSXNyi8oEkVE8+5p6I3xq6xm1WwS9hC1oRZnTfFFuiRelmnD0cI4iOx2KU qMXSD5ZV50+4mUz1guX0ecr17bJUHy8bMlQ43jj+lk703SPeJwYpgCx02ba4qc9gfttIvV OSJDYw9EPq6Wcy8WCbl8uIcVwUHukKaKEbad5/2tazkt+tjZiGON3FcvrVmg7A== 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=1701940784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+7yN9OEkgGgFe0ohUOL4ljYavKJXghk+9c0DO9vPNUs=; b=Xyt0LHNsyGGATdEDmLgZbxZE0DweD3iervXL8R/f/qwJV+IfOeY+vSXnxzkptxsF2TbU42 0uBavJEQgsYXq7GZHzVOo5xnRMKDeftYIo6Ars4HyLVJ3qmsdHoMUckKqJlH7jOOheLfoL /I5yOEY94tOuhfSQkMnXVVTQk3UqX5Ev/arzO1tXtkJb1l1Y3w/cbuwQP/MzLtL2Kq0rxX qSZ9CIFH4mPLB5GtbeZxfeC3cCDgX8JjJR75f4SoF+0gg7JRuP2WCBmDiarFLvNZqxbqB7 PbiF4U9pAmxDvLb1wzven/71kqzw0nzAFNxhBf8fUXA+o1b61SqvV1ljEL2TuQ== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Sm7yS2g78z3Nl; Thu, 7 Dec 2023 09:19:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4AAE1284BF; Thu, 7 Dec 2023 10:19:42 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_F15A5000-3925-42D9-80D8-80DB8FFAB5C2"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports From: Dimitry Andric In-Reply-To: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D@yahoo.com> Date: Thu, 7 Dec 2023 10:19:26 +0100 Cc: Warner Losh , Current FreeBSD , FreeBSD-STABLE Mailing List , dan@langille.org Message-Id: <2F5E2EA1-246A-4098-A964-3C8DEA2EF297@FreeBSD.org> References: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D.ref@yahoo.com> <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3731.700.6) --Apple-Mail=_F15A5000-3925-42D9-80D8-80DB8FFAB5C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 7 Dec 2023, at 05:31, Mark Millard wrote: >=20 > man arch reports: >=20 > QUOTE > Some machines support more than one FreeBSD ABI. Typically these = are > 64-bit machines, where the =E2=80=9Cnative=E2=80=9D LP64 execution = environment is > accompanied by the =E2=80=9Clegacy=E2=80=9D ILP32 environment, = which was the historical > 32-bit predecessor for 64-bit evolution. Examples are: >=20 > LP64 ILP32 counterpart > amd64 i386 > powerpc64 powerpc > aarch64 armv6/armv7 So, this might be replaced with "armv6^armv7" or "armv6 xor armv7", = then? -Dimitry --Apple-Mail=_F15A5000-3925-42D9-80D8-80DB8FFAB5C2 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----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZXGOHgAKCRCwXqMKLiCW o1ZvAJ9KH0xs8FDDxFxyfKCQBq8Uamj6sQCg/Zp6P2J3uIM8nNcRxurUuVQj7+8= =Sx35 -----END PGP SIGNATURE----- --Apple-Mail=_F15A5000-3925-42D9-80D8-80DB8FFAB5C2-- From nobody Thu Dec 7 10:33:08 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sm9bN03P0z540q9; Thu, 7 Dec 2023 10:33:20 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sm9bM2FCzz4b4f; Thu, 7 Dec 2023 10:33:19 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.17.1/8.17.1) with ESMTPS id 3B7AX9qh087594 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 7 Dec 2023 11:33:09 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.17.1/8.17.1/Submit) id 3B7AX8OI087593; Thu, 7 Dec 2023 11:33:08 +0100 (CET) (envelope-from fuz) Date: Thu, 7 Dec 2023 11:33:08 +0100 From: Robert Clausecker To: Mark Millard Cc: Warner Losh , Current FreeBSD , FreeBSD-STABLE Mailing List , dan@langille.org Subject: Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports Message-ID: References: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D.ref@yahoo.com> <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D@yahoo.com> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D@yahoo.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sm9bM2FCzz4b4f Hi; Am Wed, Dec 06, 2023 at 08:31:13PM -0800 schrieb Mark Millard: > man arch reports: > > QUOTE > Some machines support more than one FreeBSD ABI. Typically these are > 64-bit machines, where the “native” LP64 execution environment is > accompanied by the “legacy” ILP32 environment, which was the historical > 32-bit predecessor for 64-bit evolution. Examples are: > > LP64 ILP32 counterpart > amd64 i386 > powerpc64 powerpc > aarch64 armv6/armv7 > > aarch64 will support execution of armv6 or armv7 binaries if the CPU > implements AArch32 execution state, however older armv4 and armv5 > binaries aren't supported. > END QUOTE > > (I take "armv6 or armv7 binaries" as what was built targeting a FreeBSD > architecture triple for one of those. FreeBSD keeps them distinct.) > > However, the armv6 part of that is wrong: The infrastructure supports > only one 32-bit alternative for a given kernel, not a family of them at > once . . . See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256132 Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments From nobody Thu Dec 7 10:35:52 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sm9fV4qCYz540qZ for ; Thu, 7 Dec 2023 10:36:02 +0000 (UTC) (envelope-from SRS0=aNgP=HS=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4Sm9fS5pTXz4cv5 for ; Thu, 7 Dec 2023 10:36:00 +0000 (UTC) (envelope-from SRS0=aNgP=HS=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=lxDLqH6p; spf=pass (mx1.freebsd.org: domain of "SRS0=aNgP=HS=klop.ws=ronald-lists@realworks.nl" designates 87.255.56.188 as permitted sender) smtp.mailfrom="SRS0=aNgP=HS=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Received: from rwvirtual136.colo.realworks.nl (rwvirtual136.colo.realworks.nl [10.0.10.36]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4Sm9fK0VZTzhw for ; Thu, 7 Dec 2023 11:35:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1701945353; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: references:references; bh=VU5FqKEKvAxSen5kPgU0iEWKK+wyeiQm3GvZq5PFd4Q=; b=lxDLqH6pIgo36LuYu0+I9vmnn3hVKKJBy1hKaAqIxtLM+A6saOXo93nY//t6C2hj8EJcgl h5qEyFrIGnuomo08lHyjQu2myHkzbpfgu2jyR2uNQ6O17t6oA/Yrd02e+ovkKWux1Prnt2 RgMtYvHKnr0lAi4d0E6yjxWovpddYHAdhZXMfY/BmbvyoGG/THkqe/VQBy1bWUuouGn0hi LH+UnrFixYXnQswOzN/a12sw/FR06j9TPaWX2WQOYQPCm4SVY0kKJDNl5FqDFegs++BezD 134rNxwCnYDwa81GwTcPLCD+Izw01I30/fBRGK4xAJtKvihqRNEwcR0odDkWLw== Received: from rwvirtual136.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual136.colo.realworks.nl (Postfix) with ESMTP id E7695101572 for ; Thu, 7 Dec 2023 11:35:52 +0100 (CET) Date: Thu, 7 Dec 2023 11:35:52 +0100 (CET) From: Ronald Klop To: freebsd-stable@freebsd.org Message-ID: <464886240.91844.1701945352782@localhost> References: <65710262.29a57.67c10f38@rpi4> Subject: freebsd-update complains about changed files: /etc/ssl/certs/0179095f.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_91843_619229736.1701945352671" X-Mailer: Realworks (681.40) X-Originating-Host: from (84-105-120-103.cable.dynamic.v4.ziggo.nl [84.105.120.103]) by rwvirtual136 [10.0.10.36] with HTTP; Thu, 07 Dec 2023 11:35:52 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0 X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=aNgP=HS=klop.ws=ronald-lists@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL]; DKIM_TRACE(0.00)[klop.ws:+]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=aNgP=HS=klop.ws=ronald-lists@realworks.nl]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Sm9fS5pTXz4cv5 X-Spamd-Bar: --- ------=_Part_91843_619229736.1701945352671 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I have the problem from the forwarded mail below at several installs when I use freebsd-update. The interesting part is that /etc/ssl/certs/ contains files. Plain certctl rehash does not solve it. But "rm /etc/ssl/certs/*; certctl rehash" ends up with all files in /etc/ssl/certs becoming symlinks and the problem is gone. /etc/ssl/certs/002c0b4f.0 -> ../../../usr/share/certs/trusted/GlobalSign_Root_R46.pem Maybe I installed my jails in a wrong way so I got files instead of symlinks in /etc/ssl/certs. Anyway. What is supposed to be in /etc/ssl/certs? Files or symlinks? If somebody has a thought about this I'm interested. Otherwise it is just a data point in the mailinglist for somebody else with this problem to find a solution. NB: I also found older mention of this on the FreeBSD forums. https://forums.freebsd.org/threads/getting-the-latest-files-that-were-not-downloaded-during-upgrade.78973/ Regards, Ronald. Van: zzzzz@xxxxx.yy Datum: donderdag, 7 december 2023 00:23 Aan: root Onderwerp: rpi4 security updates > > Looking up update.FreeBSD.org mirrors... 3 mirrors found. > Fetching metadata signature for 13.2-RELEASE from update2.freebsd.org... done. > Fetching metadata index... done. > Inspecting system... done. > Preparing to download files... done. > The following files are affected by updates. No changes have > been downloaded, however, because the files have been modified > locally: > /etc/ssl/certs/0179095f.0 > /etc/ssl/certs/08063a00.0 > /etc/ssl/certs/0b9bc432.0 > /etc/ssl/certs/3e359ba6.0 > /etc/ssl/certs/5860aaa6.0 > /etc/ssl/certs/5931b5bc.0 > /etc/ssl/certs/5a7722fb.0 > /etc/ssl/certs/66445960.0 > /etc/ssl/certs/7a3adc42.0 > /etc/ssl/certs/7a780d93.0 > /etc/ssl/certs/8508e720.0 > /etc/ssl/certs/8f103249.0 > /etc/ssl/certs/90c5a3c8.0 > /etc/ssl/certs/9846683b.0 > /etc/ssl/certs/9ef4a08a.0 > /etc/ssl/certs/9f727ac7.0 > /etc/ssl/certs/d52c538d.0 > /etc/ssl/certs/ecccd8db.0 > /etc/ssl/certs/ed858448.0 > /etc/ssl/certs/fd64f3fc.0 > The following files will be updated as part of updating to > 13.2-RELEASE-p7: > /usr/share/certs/trusted/BJCA_Global_Root_CA1.pem > /usr/share/certs/trusted/BJCA_Global_Root_CA2.pem > /usr/share/certs/trusted/Certainly_Root_E1.pem > /usr/share/certs/trusted/Certainly_Root_R1.pem > /usr/share/certs/trusted/D-TRUST_BR_Root_CA_1_2020.pem > /usr/share/certs/trusted/D-TRUST_EV_Root_CA_1_2020.pem > /usr/share/certs/trusted/DigiCert_TLS_ECC_P384_Root_G5.pem > /usr/share/certs/trusted/DigiCert_TLS_RSA4096_Root_G5.pem > /usr/share/certs/trusted/E-Tugra_Global_Root_CA_ECC_v3.pem > /usr/share/certs/trusted/E-Tugra_Global_Root_CA_RSA_v3.pem > /usr/share/certs/trusted/HARICA_TLS_ECC_Root_CA_2021.pem > /usr/share/certs/trusted/HARICA_TLS_RSA_Root_CA_2021.pem > /usr/share/certs/trusted/HiPKI_Root_CA_-_G1.pem > /usr/share/certs/trusted/ISRG_Root_X2.pem > /usr/share/certs/trusted/Security_Communication_ECC_RootCA1.pem > /usr/share/certs/trusted/Security_Communication_RootCA3.pem > /usr/share/certs/trusted/Telia_Root_CA_v2.pem > /usr/share/certs/trusted/TunTrust_Root_CA.pem > /usr/share/certs/trusted/vTrus_ECC_Root_CA.pem > /usr/share/certs/trusted/vTrus_Root_CA.pem > > > ------=_Part_91843_619229736.1701945352671 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I have the problem from the forwarded mail below at several installs when I use freebsd-update.
The interesting part is that /etc/ssl/certs/ contains files.

Plain certctl rehash does not solve it.
But "rm /etc/ssl/certs/*; certctl rehash" ends up with all files in /etc/ssl/certs becoming symlinks and the problem is gone.
/etc/ssl/certs/002c0b4f.0 -> ../../../usr/share/certs/trusted/GlobalSign_Root_R46.pem

Maybe I installed my jails in a wrong way so I got files instead of symlinks in /etc/ssl/certs.

Anyway.
What is supposed to be in /etc/ssl/certs? Files or symlinks?

If somebody has a thought about this I'm interested.
Otherwise it is just a data point in the mailinglist for somebody else with this problem to find a solution.

NB: I also found older mention of this on the FreeBSD forums.
https://forums.freebsd.org/threads/getting-the-latest-files-that-were-not-downloaded-during-upgrade.78973/

Regards,
Ronald.

 

Van: zzzzz@xxxxx.yy
Datum: donderdag, 7 december 2023 00:23
Aan: root
Onderwerp: rpi4 security updates

Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 13.2-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
The following files are affected by updates. No changes have
been downloaded, however, because the files have been modified
locally:
/etc/ssl/certs/0179095f.0
/etc/ssl/certs/08063a00.0
/etc/ssl/certs/0b9bc432.0
/etc/ssl/certs/3e359ba6.0
/etc/ssl/certs/5860aaa6.0
/etc/ssl/certs/5931b5bc.0
/etc/ssl/certs/5a7722fb.0
/etc/ssl/certs/66445960.0
/etc/ssl/certs/7a3adc42.0
/etc/ssl/certs/7a780d93.0
/etc/ssl/certs/8508e720.0
/etc/ssl/certs/8f103249.0
/etc/ssl/certs/90c5a3c8.0
/etc/ssl/certs/9846683b.0
/etc/ssl/certs/9ef4a08a.0
/etc/ssl/certs/9f727ac7.0
/etc/ssl/certs/d52c538d.0
/etc/ssl/certs/ecccd8db.0
/etc/ssl/certs/ed858448.0
/etc/ssl/certs/fd64f3fc.0
The following files will be updated as part of updating to
13.2-RELEASE-p7:
/usr/share/certs/trusted/BJCA_Global_Root_CA1.pem
/usr/share/certs/trusted/BJCA_Global_Root_CA2.pem
/usr/share/certs/trusted/Certainly_Root_E1.pem
/usr/share/certs/trusted/Certainly_Root_R1.pem
/usr/share/certs/trusted/D-TRUST_BR_Root_CA_1_2020.pem
/usr/share/certs/trusted/D-TRUST_EV_Root_CA_1_2020.pem
/usr/share/certs/trusted/DigiCert_TLS_ECC_P384_Root_G5.pem
/usr/share/certs/trusted/DigiCert_TLS_RSA4096_Root_G5.pem
/usr/share/certs/trusted/E-Tugra_Global_Root_CA_ECC_v3.pem
/usr/share/certs/trusted/E-Tugra_Global_Root_CA_RSA_v3.pem
/usr/share/certs/trusted/HARICA_TLS_ECC_Root_CA_2021.pem
/usr/share/certs/trusted/HARICA_TLS_RSA_Root_CA_2021.pem
/usr/share/certs/trusted/HiPKI_Root_CA_-_G1.pem
/usr/share/certs/trusted/ISRG_Root_X2.pem
/usr/share/certs/trusted/Security_Communication_ECC_RootCA1.pem
/usr/share/certs/trusted/Security_Communication_RootCA3.pem
/usr/share/certs/trusted/Telia_Root_CA_v2.pem
/usr/share/certs/trusted/TunTrust_Root_CA.pem
/usr/share/certs/trusted/vTrus_ECC_Root_CA.pem
/usr/share/certs/trusted/vTrus_Root_CA.pem

  ------=_Part_91843_619229736.1701945352671-- From nobody Thu Dec 7 10:36:05 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sm9fr1w89z540Yr for ; Thu, 7 Dec 2023 10:36:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 4Sm9fq5Bvcz4dKK for ; Thu, 7 Dec 2023 10:36:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a1d93da3eb7so85631766b.0 for ; Thu, 07 Dec 2023 02:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1701945378; x=1702550178; 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=YRyu65Zu4HWwiLpjg4YtKBvk8ET3nb7Q0hBODLOoF5Y=; b=scOdVfKCdQJPYNILuLXq6WFNVxH7sW/FiLpaViukHu+ySzjwlizEiKT5kkZioJ7iOd Pmb1aD/SCEv/J3h3dsDW7pEaxIK702y5JYXkxYuuu1r0eCIsYpqPe/+0k5rqFvPETKyE CFmPH0ZKkaW7ude2V2IrKhwq4WK7pdvino+80U8OZHQTi+1korN4N8c5CdBQJpwl1aea 2VU5ANA6i7KfJX7p+o8aLOmdcsnwir5+xeTv5+sHaod54CqoixvnIZKcpF66FJysh3qz mdVSEAXienvOjwYMDVRbj3gaR5XT/HEsHlJpWAo+pePygphe3MlprXHMTO0/k7MAbnqy Jakg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701945378; x=1702550178; 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=YRyu65Zu4HWwiLpjg4YtKBvk8ET3nb7Q0hBODLOoF5Y=; b=c2iCEHDuAkm+Yt4PsHnTytN5B/lnlsuled2y4nFleZ/gqdm7qr4pjCPosfG6Mfikdl dHWCyseaOCZ2CHnHcs8PwLoYqCJ8iNzjxxh/2a8+17sRpeW8thSuNTguqO0lqrfxDuN2 ldQ7Vge6NUdnBl/rYgZp2c114nVSpHDgbDDhrm93ea5hLktGNtO3rR5/Fl1SDIYsp2Ac iAFt7HPUxja/bRASTxbmE3PH7JQV/BLFVs/VqXA++qbcNS3DsyMilaVrkfVtpTXKcEVt NfpYb8ZL97MdGru+y5fGctX2N/ROgPLCL4ef4Sz1F28SWSE5d3AdJQa3ufb+OshEGf6a ir1g== X-Gm-Message-State: AOJu0YwK55ugIp66lYzEsuM609sXKVHbQlGjwRlwUQyaPHJNR7urm01X kvoZ9MPYA1AXOp0/9h0JCO+BF5MVAMUdoSFddFAicg== X-Google-Smtp-Source: AGHT+IEahUuSnWviLUc7qIX+/hjxxo05qcFDJgGd4RVR0bMyL4PGtXWpGy8oJ7yPtwApoEkyfgJT+Uw+DG2DQuQmx8E= X-Received: by 2002:a17:906:5352:b0:a1d:1fb9:5e39 with SMTP id j18-20020a170906535200b00a1d1fb95e39mr1566562ejo.15.1701945377899; Thu, 07 Dec 2023 02:36:17 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D.ref@yahoo.com> <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D@yahoo.com> <2F5E2EA1-246A-4098-A964-3C8DEA2EF297@FreeBSD.org> In-Reply-To: <2F5E2EA1-246A-4098-A964-3C8DEA2EF297@FreeBSD.org> From: Warner Losh Date: Thu, 7 Dec 2023 03:36:05 -0700 Message-ID: Subject: Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports To: Dimitry Andric Cc: Mark Millard , Current FreeBSD , FreeBSD-STABLE Mailing List , Dan Langille Content-Type: multipart/alternative; boundary="000000000000ad589a060be909eb" 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-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sm9fq5Bvcz4dKK --000000000000ad589a060be909eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 7, 2023, 2:19 AM Dimitry Andric wrote: > On 7 Dec 2023, at 05:31, Mark Millard wrote: > > > > man arch reports: > > > > QUOTE > > Some machines support more than one FreeBSD ABI. Typically these a= re > > 64-bit machines, where the =E2=80=9Cnative=E2=80=9D LP64 execution = environment is > > accompanied by the =E2=80=9Clegacy=E2=80=9D ILP32 environment, whic= h was the > historical > > 32-bit predecessor for 64-bit evolution. Examples are: > > > > LP64 ILP32 counterpart > > amd64 i386 > > powerpc64 powerpc > > aarch64 armv6/armv7 > > So, this might be replaced with "armv6^armv7" or "armv6 xor armv7", then? > The binaries are basically the same. But you need one set of libraries or the other since the calling conversations differ. I think you'll need to enhance the current sysctl to be per jail. Or you could migrate away from armv6. It's days are numbered in main. Warner > -Dimitry > > --000000000000ad589a060be909eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 7, 2023, 2:19 AM Dimitry Andric <dim@freebsd.org> wrote:
On 7 Dec 2023, at 05:31, Mark Millard <marklmi@= yahoo.com> wrote:
>
> man arch reports:
>
> QUOTE
>=C2=A0 =C2=A0 =C2=A0Some machines support more than one FreeBSD ABI.=C2= =A0 Typically these are
>=C2=A0 =C2=A0 =C2=A064-bit machines, where the =E2=80=9Cnative=E2=80=9D= LP64 execution environment is
>=C2=A0 =C2=A0 =C2=A0accompanied by the =E2=80=9Clegacy=E2=80=9D ILP32 e= nvironment, which was the historical
>=C2=A0 =C2=A0 =C2=A032-bit predecessor for 64-bit evolution.=C2=A0 Exam= ples are:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LP64=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0ILP32 counterpart
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0amd64=C2=A0 =C2=A0 =C2=A0 =C2= =A0 i386
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0powerpc64=C2=A0 =C2=A0 powerpc=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aarch64=C2=A0 =C2=A0 =C2=A0 ar= mv6/armv7

So, this might be replaced with "armv6^armv7" or "armv6 xor = armv7", then?

=
The binaries are basically the same. But you need one set= of libraries or the other since the calling conversations differ. I think = you'll need to enhance the current sysctl to be per jail.

Or you could migrate away from armv6.= It's days are numbered in main.

Warner


-Dimitry

--000000000000ad589a060be909eb-- From nobody Thu Dec 7 10:46:35 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sm9v01L1vz541JT for ; Thu, 7 Dec 2023 10:46:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sm9tz60QPz3DMD for ; Thu, 7 Dec 2023 10:46:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701946008; bh=tJoS8yldyOObP/NxvaFESMrct9BZAwJTv6JjpYp7lgw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=B9LNuZUSi3boMkrZ4Mun0FZPVi8lcXrL2ozYygfDnpMc15WZuOrtaEmNJsTiGfrx+HV/ebQUuXvG+O0M1NiJeLfw4OJrdOoxYoJBgy52va81L/dfC46o8ozMRcO+X/dUPW5r5DsPI45K/zq6YHOdkwgrnNtcktCawE2HgrAxRIyHFnksUL8p5UOxF2UFUGBRv8banhFHMjUSSm8cvzDXtEnnyCz1Y4ZB13N5lyvqcemhjq2j3rEn2C51PmL1+d3FGqi2b+D0huDfRBU7YGh2QWm4aS2aRmWtFncS+REKTjZJw590uUZRqZDwwp1ygAUSsAs5VSR21lO3TO/2+gd0JQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701946008; bh=wvVV+doOqyBwbxUwgLY5YJ8kfwYYksR8XPpSDQk2Nt9=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e9H6+5Bf46QcNmsdLGkUjHmVnIEfpOf40s8fmhS0d0ULZcfH5Tlei/+87AakG0a1DpdSzh5cFhiCLgjO8WIfpj1aO/TbNiBdHPd/A3If0DHqSYoHrzcekUbmtO7mVIoEs/dECEE7cGUcYkWitt19fB5DTHF8bajQjOFHMstgyrNi+2MoRhHtIZPO9m+tCAJN677nn9TS0gjWDYfMSa67LgoF9ItaxgZV+RThdHKU6pdt1Cj+L7QoAwg0mR/FQu9uPMHI3VfRkSkwZDB1cyHb2jSGdRYGpJYCKrJINE4xUKk/M/WPrEdw6pw8Ei7n4Tzt0Hp6CQB+3XfOmWTpxE5QGg== X-YMail-OSG: X3GGa3cVM1kt_SblMETFHPprIBazfx1NsQXAiqKcr3vgPwDcSrkeCXkOjoE4m5u oidfHMzZgZk4Xx.cNOv9zYfKvcXubVe56Nr2j197.62yLld8wHQWYeNelrFkR9ZEjOTgsSRz84Hv a_yNxMAhShaeOHv_Vu8YnPeg1Cmcv0xywKWFfiGZZFuS4ssdH6nxNi2qXsM0s70bgnM5oWiasW_w WoRGE1CT3iHJ3li58k6oFWtAbxe1hKrdHtNj9WmDva0DY64aYDbd7RdaKPQ5S0WDLzGTr9UQ4Lwc EvMyhLdZLYWdjlyfUhs4hXvxF50XV6_SOeIl3T8JkQyp3Dl.Ra7y1chipU4G2DLVYIqOjqQwftZf 2T7EqW2Ncljv806wopyHxtpezRL_nr8Wz0a34qpplyIkX3It.Bz0zrcHLkj3ve7dGbbZfesw6K2j U0RpbxImWjqgoB9dDkXVl7BiSQsXId4bA1NLA62O2pRXw49TJOaD6Z7Fk76uE52WMZYeYdc5.E0d q5K2fZ97hIk4hLGuA2Ehy.k4nD9yZ4GaM7UkUVYxiSQx01D_7XOliejXRjRfRpvmLmwtw9Sgqbqm mDxYUBuOeVXjjHLW8erlCPULKdfXMSoqaZtC2Zq3FQMhp.lud0MZaV0JATL66Phfpz2APzLaRZn_ fxLopGXrJVvL7IP772Ax5eC1cka4Pugki3306vsS4pto3xQZdkxAnrAmmFJ1XI_M9ioiEU9mJI9z jy5Ik96_UHlRoOVMWgyeAauHrtW7gIF_lc5RbqVI3T.raXqUZeav1Orjm0psuda4kfNxvlvBdM.d HpuUiC9cX_rZA2E1muUsRnmp9X3wgtsR5JA13aWrnYc0xuFw_hbpW2hza.JMa.nOuEcznEfqmYe2 ar9Z1JaJL8f3CBELLjdNsOamPJq_0kkTycEVF0BjmrLancflusYTXEIf_z3k8DU8B8.STpqGNJiL HLEdmCIJuBVLzsP554PtCgBge22_cdsypTkp9QkORxoIRYHRpQnuqh9FLVjy1Az7z645vKW07zJP S86NWDc8G1xr9Y5KG0KG_YODXwWb85A9FuGETSRMXzTo_MTUrqnIQtQpIVae7OzJx1d6BJWwPLZq jbtvOU9gWRsMK4eFslh8oPh201D6pnEKZKtmcoOAx2OLBZZwXBTbeBJDh_DLC8e7OFpoSpPTmbBP xaOmBgJtqgx_JY69Gw3HtcaLxs.KHc89dalcEz25jkesGwedV6IG5D5.rBOj5nqRlAldYZn8Ay0v dSKCxqKR7lU.xTlnX8phR7ueQ6KygOfiJ8j48jrSEpAH_ARYvbE.ipsRBVUtJ2ML7.s04ilxKegb yO01SBfy2Pygp9P116d95DjCy3eLjKCu4CifnFZ6GMcRGXVuLG3aabBcSHsMGnCZQSBFyHZPfmck H0sc5GA.3glU6zulers8PbqXF4.qAUx.zozsCOok4GbMJTsJ0Wf2FlRA7KdwJDLOmUHKHWEhot.F JyBu2BeuoiVXHtcs95Xux2u8CebRMw_K2adlZkji6bQX33TIcvNn_guaPSUpU6efGDEDCSF0DfkZ 8paHV4Et1QsfORLR.jAqEzFGdhajrfTjB6GUG7dpU_iD._XzBcCH0XaXoMNkTvmDsUdUWMJOiaXJ m_2nmUI13V2vJAdKG5RL0izYjLZ2qHoFiFvOyIeSGR6pmcQBPK6LtrGbdcWpMgD.kmscn0YBM92o SWVxjn1JgAmhd9j927aNJvZYthb0yUiFCXe.oDyEAy8NCF2VJxilCnXnY.ageJ_kfxy1dYr7c4LE hBLjb2GH2Y6MdwE_Y38H1OkeOR6Mbezhhx8ZhR6nI3hu.Q2eQhMvw_dfyicNKY1xyNsCpob0QJwt 1ya0Wn5tfmgUteNk2TvF.UZyMA3IhJElrl.V74TtYUndTMbQhLuExVwBm48wEknOJxvuXnGoR23O G8P4TVGHqkSGc1J8rugH.eCQHZvNDrp9cZMNqalj1FUO0VktUPi1c118ol4mwOP4Dmzs15KccGHe 1383ORs5sMoaejh9YSSJSJC_JM5lMFwVmbd4NdKTIbk5FXVJCK2gb4RnhiOm32CKlAY0yzb9JGkL DbAzY.ZFL1smHvcEA9wMdHKS8XleOyunbDDg.uXJbqY36NClKNNxaRGcQD9rJskVxKxc80WmQZdy qwsomMPpqimeUX9rdJDvwXfKdzcspgioZqJxcGGzwd0y3rEg1GkF9B8HPTXwK54CmBq.R1stj4d7 eNKGH7j_hIZ7VGJnEd9OW_gNSK9nCLaolB.uyTepzuaYb0SWa2IzHcgUPM.mHIHW_Pryp5G.yLrJ hog-- X-Sonic-MF: X-Sonic-ID: c2b0902b-c7db-45eb-b2ee-c9a549c60f96 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 Dec 2023 10:46:48 +0000 Received: by hermes--production-gq1-64499dfdcc-pxg8l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 21ebad9e45431473a536abcc75eb83f5; Thu, 07 Dec 2023 10:46:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports From: Mark Millard In-Reply-To: <2F5E2EA1-246A-4098-A964-3C8DEA2EF297@FreeBSD.org> Date: Thu, 7 Dec 2023 02:46:35 -0800 Cc: Warner Losh , Current FreeBSD , FreeBSD-STABLE Mailing List , dan@langille.org, Mike Karels Content-Transfer-Encoding: quoted-printable Message-Id: <1B672854-4011-4F4D-BFBC-4C3ABF6FA4FB@yahoo.com> References: <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D.ref@yahoo.com> <3C33BBA5-A84D-4F46-B38E-B67F9FE0196D@yahoo.com> <2F5E2EA1-246A-4098-A964-3C8DEA2EF297@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sm9tz60QPz3DMD On Dec 7, 2023, at 01:19, Dimitry Andric wrote: > On 7 Dec 2023, at 05:31, Mark Millard wrote: >>=20 >> man arch reports: >>=20 >> QUOTE >> Some machines support more than one FreeBSD ABI. Typically these = are >> 64-bit machines, where the =E2=80=9Cnative=E2=80=9D LP64 execution = environment is >> accompanied by the =E2=80=9Clegacy=E2=80=9D ILP32 environment, = which was the historical >> 32-bit predecessor for 64-bit evolution. Examples are: >>=20 >> LP64 ILP32 counterpart >> amd64 i386 >> powerpc64 powerpc >> aarch64 armv6/armv7 >=20 > So, this might be replaced with "armv6^armv7" or "armv6 xor armv7", = then? Only for folks that build from source. For those folks, a footnote about updating MACHINE_ARCH32 in sys/arm64/include/param.h would be appropriate. It is not exactly obvious or commonly known. Hmm, thinking more about the old bugzilla information . . . I'll also note that my information predated lib32 on aarch64: just chroot/jail sorts of use back then, and I just tested chroot back then. I've never tested a lib32 context for armv6 on aarch64 for an adjusted MACHINE_ARCH32. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 7 11:54:23 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SmCP11t3zz545jn for ; Thu, 7 Dec 2023 11:54:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SmCP05tpYz3M79 for ; Thu, 7 Dec 2023 11:54:28 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.15.2) with ESMTP id 3B7BsOiB066722; Thu, 7 Dec 2023 11:54:24 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 3B7BsN7f066721; Thu, 7 Dec 2023 03:54:23 -0800 (PST) (envelope-from david) Date: Thu, 7 Dec 2023 03:54:23 -0800 From: David Wolfskill To: Ronald Klop Cc: freebsd-stable@freebsd.org Subject: Re: freebsd-update complains about changed files: /etc/ssl/certs/0179095f.0 Message-ID: Mail-Followup-To: David Wolfskill , Ronald Klop , freebsd-stable@freebsd.org References: <65710262.29a57.67c10f38@rpi4> <464886240.91844.1701945352782@localhost> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="btEwm4Z4mbfYGc94" Content-Disposition: inline In-Reply-To: <464886240.91844.1701945352782@localhost> 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:7018, ipnet:107.192.0.0/12, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SmCP05tpYz3M79 --btEwm4Z4mbfYGc94 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 07, 2023 at 11:35:52AM +0100, Ronald Klop wrote: > Hi, >=20 > I have the problem from the forwarded mail below at several installs when= I use freebsd-update. > The interesting part is that /etc/ssl/certs/ contains files. > ...=20 > Maybe I installed my jails in a wrong way so I got files instead of symli= nks in /etc/ssl/certs. >=20 > Anyway. > What is supposed to be in /etc/ssl/certs? Files or symlinks? > .... I have one (newer) laptop where I actually used FreeBSD install (for release 13.1),is now running 14.0-RELEASE-p2, and has been maintained strictly via freebsd-update and "pkg upgrade" (using the FreeBSD packages) (vs. my more usual source updates & custom-built packages, so it's about as close to a local "reference installation" as I'm likely to find). On it, /etc/ssl/certs/ only contains symlinks. I then checked a couple of my "development" machines (source-tracking stable & head daily); on them /etc/ssl/certs/ (also) only contains symlinks. FWIW. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org =E2=80=9CSo strong is the lure of power that men and women who had once see= med reasonable and responsible were suddenly willing to violate their oath to the Constitution out of political expediency and loyalty to Donald Trump.=E2=80=9D - Liz Cheney, 'Oath and Honor' See https://www.catwhisker.org/~david/publickey.gpg for my public key. --btEwm4Z4mbfYGc94 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZXGyb18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5QLGAP9WQAp6TcMiITrR2COy4/fkSrrmQhxlh3EA2sWNHy38GgEA3ezfxujZNhpn ozWsnJzvG8kld//tAWdkNK7+P4VY0AE= =mO6k -----END PGP SIGNATURE----- --btEwm4Z4mbfYGc94-- From nobody Fri Dec 8 12:16:50 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SmqrS53Jfz53t9q for ; Fri, 8 Dec 2023 12:16:56 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 4SmqrR5MfJz4LpW for ; Fri, 8 Dec 2023 12:16:55 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=qLABbgv0; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=s0NA9Oes; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.24 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B46D13200AC5 for ; Fri, 8 Dec 2023 07:16:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 08 Dec 2023 07:16:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm1; t=1702037813; x=1702124213; bh=XeQJUVbuboYRUUGpIPbiOWwZM fznZfx2ECopzrpk7dU=; b=qLABbgv07bcbjjfAsNZgpsLjV6tx/6qDumGYzvV2O v0xYjvct5i+4rW/uwrZaA7X8Vj6N8DIXoMBK3X4/jRl9597ZEA1Xp/D7e2u0kFY4 26MA/mhk+JQimy5mSDFeKJYfr7T8SKdOux1v8m1hrm3Xx8mkM/KzmzDA3+9iKo5v thZHjUf67z9t4/GXudUM25k+5nadunJIgzHP13BSFzJnDk9GOwYnNh0hUh/BanGx z5U8oMxdN2Ei4A4y0ay6dl7ypLrYOc1v0Zp3oZGdEXQPAmFXs5dhP0p0C5dgPzXj BjdHNlQ1YxVUCLNFZ3YDZIS2+HoSctpDVYEj7RAoX9XVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1702037813; x=1702124213; bh=XeQJUVbuboYRUUGpIPbiOWwZMfznZfx2ECo pzrpk7dU=; b=s0NA9OesD6aOL1RJbtD4FYpJihVQANVIJdYbgalj270jLyQrIxe Nb9KQtzZ5e2PKit6tbivm0ByMrT80fO3D9x1vQfo380lo0UStqg3le7zqSPNUlEb 7VgK50aVf1bsN54wzrSQ0wDdZb84Dc+Nm3TywZDbH8N0bSGmChW1xP/5pVkfVxd3 jbT0DehopFVNYAGFZirhoGdJIfXzSkTxXlKjihXMHf3cuSqoxXYzrjW/ZLNgePEj baX4PVGzAUFiZppHAV+oMW8a/PycKvV8gfk45/pxrhWA8BBPA2VxAXfVcGARx517 vYW09lKSSXP603RTLXiENx7gt5rhYdMV7mA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudekiedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 8 Dec 2023 07:16:52 -0500 (EST) Date: Fri, 8 Dec 2023 12:16:50 +0000 From: void To: freebsd-stable@freebsd.org Subject: some dirs don't get deleted with make-delete-old Message-ID: Mail-Followup-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.24:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SmqrR5MfJz4LpW X-Spamd-Bar: --- It seems some dirs don't get deleted with make delete-old: # yes | make delete-old [...] /usr/share/doc/atf rmdir: /usr/share/certs/blacklisted: Directory not empty /usr/share/atf [...] /usr/lib/debug/lib rmdir: /usr/lib/debug/boot: Directory not empty /usr/lib/debug/bin is this an error? context: source upgrade from stable/14-n265798 to stable/14-n265929 on arm64 -- From nobody Fri Dec 8 15:35:32 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SmwGy3rwGz52v66 for ; Fri, 8 Dec 2023 15:36:42 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SmwGx5Jfgz3CHK for ; Fri, 8 Dec 2023 15:36:41 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=2Z3SGapE; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1702049786; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sIlrFogs5cPhqI0QbLng9of752QDrMYI44FIyXyPYAc=; b=2Z3SGapE4/zA7g9iZiHQ2HPJvKeZaix+9YeY1cQ05nlIoKaQCtdbpGF4ssEUl3xx8nhhCs 9nS0pZoiJ8QP/5N5lgQSjjR9kEdtlP8d34EwJphEQt4NjWvj7onoNnO/cJliVCBuR4TThM aVXjEOTiusSHCg5BZqhJVUjlJW+fW7366NHtYy9Yx80NJz9YEaKrtqauKp+edP7xZX9TAj miIqR6VRdppDQA6C0KWc1Ea2+gVcKr6d3bddimAgz3EoICK5xbfRAm1GJtkR+TgSX2np0U 0hHONhLG0z2+i9xveRazI6Y9Bx0fECI5E8xzz6zUWYrVj1t4WqFUYG/6weJxBw== Date: Fri, 08 Dec 2023 16:35:32 +0100 From: Alexander Leidinger To: freebsd-stable@freebsd.org Subject: Re: some dirs don't get deleted with make-delete-old In-Reply-To: References: Message-ID: <77cde7607c6a0f918cfa183c7847cad5@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_322055d58449ca49c768c309b22cecfd"; micalg=pgp-sha256 X-Spamd-Result: default: False [-6.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; HAS_ATTACHMENT(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SmwGx5Jfgz3CHK X-Spamd-Bar: ------ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_322055d58449ca49c768c309b22cecfd Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2023-12-08 13:16, schrieb void: > It seems some dirs don't get deleted with make delete-old: > > # yes | make delete-old > > [...] > /usr/share/doc/atf > rmdir: /usr/share/certs/blacklisted: Directory not empty > /usr/share/atf > [...] > /usr/lib/debug/lib > rmdir: /usr/lib/debug/boot: Directory not empty > /usr/lib/debug/bin > > is this an error? No. It's a feature. :) Kidding... it depends: Either something old is not in the list to be deleted, or you have modified the content of those directories somehow (non standard options, debug options, testing of some patches, ...). Have a look inside those directories and look what is left there. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_322055d58449ca49c768c309b22cecfd Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmVzN9UACgkQEg2wmwP4 2IaeRBAApf7/SfVARZbKh2AaWF7vZjE82dI8oofZ2U7ucsDXwhkwUWLhHJx6vTUI z41uSDw4r5ddSIX7MGR0gx/RQr4ZFGjmZraHsP5P3GcZbX67Al+hDMMZEe8fvKeB bhEarubkq5uQ2xNKyXI20Ku3BHRSnFQzCdB52Jap4JNDUT4Xe9KFeCqI7BiRGDSR TmU26qImckiGy4ZLwFmXabOx2zkWGFuqIFlPH+oLsRiteBQLxGw5aiGnfQa0qaYL IVm3Dg6hahd8PQaU6e5jBdw9DyjuYGBg/vILzv/JnvBl9CM7Q2bir1/BQaLzimCv R3dlan8usIya/eWnmXKWr4usCkm0M1x7M9PhlbyEaWsvBe4N1wFAFRRbtNCy4uIO yZxFrNRGR5EGr8f8erSGdPvpk2OsE4XjW8pjt4QnZyGvWYPu7LLIHQTaASpfZIBr nDBHtGt0lElVAbkUQnZH2n0iJMK4EiQRzJg/P1OsGqjA6hOMvQV0eEB+K4b7EMnT p+M4LOpaEKa6zB2aAFyysObtpN7Rkya0R66e0/SVv6xQ16gsEXmzYCkXNxp8X5ZO UF0y4R902lFl38lOX2RGT9nhwAoRzywVfEf98ZmkpO+Bsbom1iMydm9I4h723OI0 KGEQ2rOAJbAKZVVv5vccJ2I04ERXpGcxMQyXgTp2OX2tpDRPYvk= =81T0 -----END PGP SIGNATURE----- --=_322055d58449ca49c768c309b22cecfd-- From nobody Fri Dec 8 16:33:29 2023 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 4SmxXr71qzz530Yy for ; Fri, 8 Dec 2023 16:33:48 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:13b:240c::25]) (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-384) client-digest SHA384) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SmxXq08BXz3KdX for ; Fri, 8 Dec 2023 16:33:46 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=K+BDrWoc; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 2a01:4f8:13b:240c::25 as permitted sender) smtp.mailfrom=herbert@gojira.at; dmarc=none Date: Fri, 08 Dec 2023 17:33:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1702053218; bh=tKRkQuK5ywvyS27ZYSeiHsGtwTX5ZnlJvG4c7Ks3R8M=; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; b=K+BDrWoch/N0mTixdRhLNKUaBfovA5hRnR5buyLpWfkEn+DXgqM4i9J/rdEFHHBIq cRZ4AKIoNxxAlUtAowM3KPJVswSOoZRo8ivk/lzJK457caMYRLO5zfQfYo/2kBKwmz zjK1OUp72wDp+o37ejfv+1FC2jfj6I24Mj2TWeNZrggF6UZ4bBJPt5vDtTkz/gT1Z+ pwFL7aY/pZnoHPaDHRyx2zDbgrCYGVNGDrLdVzPUZQB8HoSz28yEVeZ+YBOpPcUTky hDaESGhMxhXSzDQhTk4Wh3hwcfat4zXNdskjzgmP3V1seY69YtAvf+H89YUn8w9qKh 6NCYSMH0LrUlQ== Message-ID: <87cyvgbqna.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: stable@freebsd.org Subject: Re: some dirs don't get deleted with make-delete-old In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.1 Mule/6.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spamd-Result: default: False [-2.50 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:240c::25]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[stable@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; DKIM_TRACE(0.00)[gojira.at:+]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[gojira.at]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Queue-Id: 4SmxXq08BXz3KdX X-Spamd-Bar: -- On Fri, 08 Dec 2023 13:16:50 +0100, void wrote: > > It seems some dirs don't get deleted with make delete-old: > > # yes | make delete-old > > [...] > /usr/share/doc/atf > rmdir: /usr/share/certs/blacklisted: Directory not empty This directory should no longer exist. It was renamed to untrusted in June 2021 (commit 64e6e1e46363de5d4843cf0fc79406060ec44c03). > /usr/share/atf > [...] > /usr/lib/debug/lib > rmdir: /usr/lib/debug/boot: Directory not empty > /usr/lib/debug/bin > > is this an error? Do you use WITHOUT_DEBUG_FILES= in /etc/src.conf? I think the problem is: 1. etc/mtree/BSD.debug.dist The Makefile contains the following note: "# NOTE: BSD.debug.dist is unconditionally installed for developer ease-of-use." 2. make delete-old does not empty and delete /usr/lib/debug/boot/kernel and /usr/lib/debug/boot/modules. Both directories are excluded in tools/build/mk/OptionalObsoleteFiles.inc (lines 1336-1350). This code was commited in August 2017 by emaste (commit 63cd05d97a6d280e280538229040537d5ac75788). -- Herbert From nobody Sat Dec 9 15:24:17 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SnWyG381zz548jP; Sat, 9 Dec 2023 15:24:22 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 4SnWyF5XJSz3ZZ8; Sat, 9 Dec 2023 15:24:21 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=bHo7nvAe; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::329 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-40c26a45b2dso16858305e9.1; Sat, 09 Dec 2023 07:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702135460; x=1702740260; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=VjpYl0rXruhPMUWL9g3EqmViUC3GlUv9qVmiHuQKsMQ=; b=bHo7nvAeTq50aj3Ay9pt5dDeA0L7PB4h6P4Ia7SGUt6giFKFmgmxdiOseN845uvj6Z zKAbiMQC0yfSBhyNXo2VCSAY2ARi1M6qtcnm2F4dk+ee1yfHUd8088lw0a+gbBjnuQVN FF0XZVpk51T9iXxdv5fHqIEy6iv4IrtvE4+N6Nj5XvYw+II7/rO2R6EkvKO/e7LUwHDx re77hGKyQa+kUdXOa7pBNnv9KCpUlT1MUT5o9J9xJgS8n1hJJwCnuT5kdMxdJkpMA9bE mtRnWOQ02KZqpmEte9+/qMO5H/SnzWUVzD4HAsfM4Ve5GYn/XbS9JKsIm+1PUbFIqvtj EljA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702135460; x=1702740260; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VjpYl0rXruhPMUWL9g3EqmViUC3GlUv9qVmiHuQKsMQ=; b=UW39P/YRwhLEQp6jcPmCNQOoN1XRniKsEHGJWX8N/8nK+CJu0W1fO57q+qUUGMyNjq +sdJeZA6rqkyupWCRJH1ttgr14DbBVTSMUmq6B1YASIz8+dxLI5Hh6WvJx3Ivu0zGZWH 4C0heeJbYGjUw24lSNO4S7xIA2CnkTJYF0k0+WKvvWn3ELhZRxsSoB8S/YNNNNQYm/s5 y3g4mZhRQf7rYyAWB4X5YECAqs24SwsBnNAXXyRt9+me7HEiPEDqM1+4SiDvAzlw/GnJ DsYYjREIAWIXw+DsWuj7rk9qf830y01rBTAZVnO6i7wfxE7oZeCaHHlQE4KNpyjGI4nw 6SGQ== X-Gm-Message-State: AOJu0YwpG/Gljlmz59xd+4eBEjdtra3cruubyf5AiM1UkTcE9+INQXVC 0WMmUrnCvk/3GoTlvf8pA7AkfCBnt0oIRw== X-Google-Smtp-Source: AGHT+IH48y6VD2rDurRlRuGCno/tCMQSI6pT/pk1RleSyWkpmmwoPInv+1j0HKEhgp9Zmn2uLwTC5w== X-Received: by 2002:a05:600c:3b99:b0:40b:5e26:237b with SMTP id n25-20020a05600c3b9900b0040b5e26237bmr870354wms.44.1702135459559; Sat, 09 Dec 2023 07:24:19 -0800 (PST) Received: from [192.168.1.10] (host-2-100-164-166.as13285.net. [2.100.164.166]) by smtp.gmail.com with ESMTPSA id bd21-20020a05600c1f1500b0040c25abd724sm9228835wmb.9.2023.12.09.07.24.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Dec 2023 07:24:19 -0800 (PST) Message-ID: <839aef0f-f087-4cd5-bcfe-6342560a1c0d@gmail.com> Date: Sat, 9 Dec 2023 15:24:17 +0000 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: FreeBSD stable/13 end of life (was: FreeBSD 12.4 and stable/12 branch end-of-life) Content-Language: en-GB To: freebsd-security@freebsd.org References: <20231206220634.62F65176B5@freefall.freebsd.org> Cc: FreeBSD-STABLE From: Graham Perrin Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJimMMBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQLbHAQAJi998y42bEbq5HmABYovmAEtQj33YSUWyc9QRmAHpN8Er3lTKsgmZcVChB5Fu/d go2oYynDjlVpA7+wiSmg4AG78mOYbg/e19XMhrH0keDKqZXFkU+G7agR0mF09qvpQZ9MTJYZ 2u7FtytZK665UfipOdV8eGn2hFC/WynjUwEzKyryBgbbLAEbfOPeZNry4h2ZPWbtTvx/PE/V X3Vh2oGqYx69DCGz+0xEhy62ZKbkX5SL8LUf/1WViyCVzsHasFxmFxYPWIfBy8ayQ7xapz7M cSXSQyu4oDT4qh9eZiGP9/aAcZKHcV6t9y77JGhUJ/5O1sANKMa3YhgimE+Z86LHYa1IH774 PHj1nAXBwS+Cj/1l/NQoQcyjvOj8zuCsMJVaLMb6B46YsReP4+3yBLpyeBC//t6zWPbgAkWW VjROC0dXUAMTFpnA6NZe3UghG+Nc4fnCLGOhc2nyWFYHIaYV6Hv1ITFSem9DdeNnR1CFm1VM TJ7i7TuqYM+WZTkoUsTf4c46hS/ZNJZSCxh0s9yYr+BYk3XBbd+ElaZ1dJE6cuSVdw15+P2h DnprurxC4byl4YFkn+UAVvQsOgeq6aSHLOHX0weYu1OLoiPYsTdyGhne72+kDhEEdFD5aHdQ PFrbQIrqWLV0a04++0ZwGpNvXtgnWhDdAQJDwGsSSwbLzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmKYt7ACGwwFCQWjmoAACgkQt2dIb0oY1Av7qg//YjCZg8VXyMzXssgIQpROKKqh5V0UBSQl rM3tq4tWhyg0HVMugQj0Om+iNPsEEOGHkm6tyhHMzlKGpAc/l0iAM+8twIyg44Yo5+DcfFXr OMTbTw9T9jDsWOkOBksxy29iYhgpqpWdDBnhXvrJp/FNAiX8CfzrIOZeFPydDoEiKBEXAxfe a9o5J/JeVnZiUeoiFe7i68nZGsb4JxhPczNfqW12t0Ll5/ibjszg5BgjXiLao0KqbWNh4bS5 CVwH90Or+5qqWgzWPeBiuz+rN2QXE/V/fL44GEj1YKASCqmaiYRgjoRFubz1aq1wCXMXY3Iq d4525rscUgS7HBxbblnyTodUPaamN/2nSzcmE/Pkx8MApDSgZCIhs0RTAg+/AoX4HULV1rSE TQwMrBEQt84Tw5W5rHsvXKr4ZEsJUpbPLWYTISsp23nHR+vZtL/Ug+OWCmHC7X7D21xk/xVJ 4sA1RLJBKdCHtnyA4Unv/kNS1KVGxHnITVyw1a71QJADu4qsdtM5u6CyYUhqhM1oseWtV6j+ Qi8KC/G4C3AgZf06fe2fVl42z2grTabL4bC6FQXMwTX2dsm5NakWjUCmUL8uwsQE7ZA4zKxo EYI1YV9q1birpzncYRupr1qnMoggMUHWq0IBYshFQrEO8PeVUZBw7/GfAeh3argdw2Qu748T Cyw= In-Reply-To: <20231206220634.62F65176B5@freefall.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.908]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[grahamperrin]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::329:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-stable@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SnWyF5XJSz3ZZ8 X-Spamd-Bar: --- On 06/12/2023 22:06, FreeBSD Security Officer wrote: > ⋯ > > After December 31, the supported branches and releases, along with their > expected end-of-life dates, will be: > > +--------------------------------------------------------------------------+ > |   Branch    |   Release    |  Release Date     |      Estimated > EoL      | > +-------------+--------------+-------------------+-------------------------+ > | stable/14   | N/A          | N/A               | November 30, > 2028       | > +-------------+--------------+-------------------+-------------------------+ > | releng/14.0 | 14.0-RELEASE | November 20, 2023 | 14.1-RELEASE + 3 > months | > +-------------+--------------+-------------------+-------------------------+ > | stable/13   | N/A          | N/A               | January 31, > 2026        | > +-------------+--------------+-------------------+-------------------------+ > | releng/13.2 | 13.2-RELEASE | April 11, 2023    | 13.3-RELEASE + 3 > months | > +--------------------------------------------------------------------------+ > > Please refer to https://security.freebsd.org/ for an up-to-date list of > supported releases and the latest security advisories. > > The FreeBSD Security Team Hi Via the linked page, which redirects, the table of supported releases is incorrect. Please see comments 4—6. Kind regards Graham