From nobody Mon Jul 1 08:40:15 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WCKHb2LWcz5Psc1 for ; Mon, 01 Jul 2024 08:40:27 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WCKHb1rqqz52sV for ; Mon, 1 Jul 2024 08:40:27 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1719823227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SbmUNSXl9TKLVvk0n6+iRdYYpptn/IfZ7/sz1928i+0=; b=VJRXAR3ICJw9bdQhr2VDp3iedvslkxWp71+PV9+41K/EHWHIJyIpVALQ2tzPDRl9Fhc5LN CrbaPo9r78K43LM8v62TFtF1s/dBhHkm7l3dWA3L+beEVUn9Z9lbT1JnGwvMp2xdroH2mj hFuIvde9ps9koi7wqKClyXRFZWtyuzh+ve1+T0GwOnMEc7IZoGq8lr53Ix6F5iN2c6wpKc dZmswjVXJ1L8jkc6BVFaM39F0rQBWBE7suEDHAURw1f20i/QwI6QmWUrvysoJT9guVG1pk kxYtNkTrBO4UcIgC4xK1WlphC+FBMykRA9961kkbgjqpaq7Z6rfeHTQaongw6Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1719823227; a=rsa-sha256; cv=none; b=jZHGyx/XqzSO3l8RTUc59yrQWBm3ffpEG6fcykrTO3oPssEKzk/caysw/ME1jccz7Kp5Mj 4dycXy3hBUWdqdYDIlAdF2iC886xqoOAc1QInJ+SBgV9EFzORjxqH3Z/H3FNekahfsm7z2 9avmI5N+NzUI2vt5EHd28/UNW8dFFGTnXP3dQyUoPf0rIN/3e67FCx3rqJsCwn+RUUHPrj L1lxL6wWR16XnSLtEBCilzk+FJtdAZNLJdfe23VZ8RXrZQ0+p5rUzjF+YdAxjXb4LH6qEA efbJXmhFWkk0L3PDT35AHuIVq9GIVyFbHjTozyX9K4wpfuwQ013O+8Sh486fIQ== 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=1719823227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SbmUNSXl9TKLVvk0n6+iRdYYpptn/IfZ7/sz1928i+0=; b=waFINE5z5r3jYEiMLCfwnSV2oV54J0XWxn86hYnCGF20M6jkfdLRMASP6n4lceZCLBrhNV OLEXIrRYl8W6IB6dIZCyyNXZaFDCxTQjvxjrwzMmu/zKXWjeNKUoma8FPceavYvZhhsSHv XBETOUJv7LsC8kLIG8Zyb7SuWFOUxLpDPjCd+YOs1YjL4llKXMF0Zr+dWfK0YMG4/0qlxf b2UiXUJPlbPWej4ZamYVwHA4yomWIXr+Gf4b5tYPyprCqnPAadc77rUap09YqIf/Kvyikg 97V39v7eKOQqjgNRgwgdQOb3eS3VT51zkkexiOcfLXPhGAX6IzBc4t+O6T0cAA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WCKHb1GKPzGd4 for ; Mon, 1 Jul 2024 08:40:27 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-159-181-184.range86-159.btcentralplus.com [86.159.181.184]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 7675CB954 for ; Mon, 1 Jul 2024 09:40:26 +0100 (BST) From: David Chisnall Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Please can we do something about programmatic interfaces to ZFS? Message-Id: <8C7859E3-A72E-4852-AF43-DFD0ABA5D270@FreeBSD.org> Date: Mon, 1 Jul 2024 09:40:15 +0100 To: FreeBSD Current X-Mailer: Apple Mail (2.3774.600.62) Hi, Since updating to 15-CURRENT, I have been unable to get some existing = code that used libzfs_core to take snapshots. There are a lot of = reasons that this could have broken and it=E2=80=99s hard to track it = down: - We ship both libnv and libnvpair. These define the same data = structure but with different APIs and are incompatible. I believe libnv = can create the serialised data structures that the ZFS ioctls expect. - We don=E2=80=99t install headers for libnvpair or libzfs_core (or = libzfs) and so any code using these has to either depend on things in = the src tree (which depend on OpenSolaris headers that are incompatible = with FreeBSD ones, so must be in separate compilation units) or provide = its own definitions, which may get out of sync with the libraries. - We don=E2=80=99t provide any documentation of the underlying ZFS = ioctls (and there is some code that suggests that these vary between = platforms), and so the *only* API for interacting with ZFS is = libzfs_core. - The APIs in libzfs_core are also poorly documented. This makes it incredibly difficult to interact with ZFS via anything = other than the `zfs` command-line tool. When things break, I have no = idea which of these layers caused the breakage. David From nobody Mon Jul 1 22:36:35 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WCgrb5j9Tz5QL6c for ; Mon, 01 Jul 2024 22:36:47 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WCgrZ5stsz4DKR for ; Mon, 1 Jul 2024 22:36:46 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=CiWya5gO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::534 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-74840cb804dso986198a12.2 for ; Mon, 01 Jul 2024 15:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719873405; x=1720478205; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZWlSKihytbhJ6GQYRSdmVHKHFYDPaWKs3yanBz9jL2c=; b=CiWya5gO06rgZLIJJ0ITdAJZD+Bf5xoa1hO65DOuGYIC2y9PnNJAt9hFtSsOsCvwE+ qUX/C37fE2GUzw7aHiaRgxHiOLxYJ6nfDeNfo0ai5zh1Vv6srOGbe02+dSSZkLbMW2vn Ypyx0Cki8qdTwwzVk8+RhrRgiVZmYfMSghApKlHoRCUKNz53FpBfpZsl48GkiydrA00K gfxKj5BuPWLfvIahguwBKIBFwyqGfUd6NqflRlpmMVeJGQshNaQFKvX/edvB4Q0B99sK JCy1FCXUYlebC+sJkX64BmYLHHZxlIKVpXErlbQQUTUCtaAuPuOiJGF9DzVj681ACHOS Fsrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719873405; x=1720478205; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZWlSKihytbhJ6GQYRSdmVHKHFYDPaWKs3yanBz9jL2c=; b=j8eVq6LMOQ/pA4ujDAgqHSL3QjRu2SJwFu1WnQHYEaHdKIGkIVRRFlZi6mVJvsQlEa fJbdtH+7Cz2YgT9lDRVY1l8zdt4/ZWPGl+kN5PJkU56bXN9JvUyx0TpN833j0FZr8ToZ RSBw5YPh+yeqGNKvUaHT/y3GEM5jweCnDTDJm00TmUf2kSb7WdyI+3DtSilesROWW3iH NDFL54wzr7ZNYfD9cpuSjYiqh4gB9/8fLi6zfSteT2ECCB42Tm1Rqxw5ovtS6r/0bXJs eYeF0zcB/MBw95YWNrSNBR58rNA/+9n4LD9WBuCeY2xvsta25vLJ/vP1YNw2dHbb0M0o 4rEg== X-Gm-Message-State: AOJu0Yz26fJ5s4I0ylWSIJfD96UeRhpO0LRD5AVreR2et0uFeqYxDd8/ 5H6pJrFJaLkslXFgyt7Vl8mGZ+fmrUyORT3Lu7zoC0yqL7oSmWmGXpNlDV4MZNdpj+ZkhcnI7F7 BklCUwxm5waDeq4xcaWgZdH60Xw== X-Google-Smtp-Source: AGHT+IHsnjN7xxchUH2sHHwxpOfR+++OcB6rBpV4Afue0FgSAt/lM6Y89KLzxTdHDa4wIy+++XQIxQ4mhAX+ZyVD5z8= X-Received: by 2002:a17:90a:aa02:b0:2c3:cc6:636e with SMTP id 98e67ed59e1d1-2c93d6d7335mr5478345a91.2.1719873405167; Mon, 01 Jul 2024 15:36:45 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202406301523.45UFNLnX009631@gndrsh.dnsmgr.net> In-Reply-To: <202406301523.45UFNLnX009631@gndrsh.dnsmgr.net> From: Rick Macklem Date: Mon, 1 Jul 2024 15:36:35 -0700 Message-ID: Subject: Re: Booting in bhyve always sets currdev to ZFS To: "Rodney W. Grimes" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- 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.995]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::534:from] X-Rspamd-Queue-Id: 4WCgrZ5stsz4DKR On Sun, Jun 30, 2024 at 8:23=E2=80=AFAM Rodney W. Grimes wrote: > > > On Fri, Jun 28, 2024 at 6:26?PM Rick Macklem w= rote: > > > > > > Hi, > > > > > > I've installed FreeBSD current in a bhvye instance. Everything > > > went ok, with UFS as a root partition. > > > Then I created a zpool in another partition... > > > - Now, every time I boot it I have to > > > OK set currdev=3Ddisk0s1a: > > > to get it to boot. > > > > > > What is the trick to keep ZFS from messing up the boot variables? > > I've been poking around, but haven't learned much. > > I think it is userboot (although there are so many boot programs in /bo= ot, > > I am not 100% sure?) that sets currdev=3Dzfs:example: since it sees the= re is ZFS > > in a partition on the drive. It is not the boot partition and doesn't h= ave > > any boot stuff in it. > > > > When I look at userboot, it appears that it always sets userboot_zfs_fo= und > > to 1 whenever userboot_zfs_probe() is called, given that there is a ZFS > > partition with a pool on it. This makes extract_currdev get set to the > > ZFS stuff, > > assuming I am reading the code correctly. > > What I do not understand is why I have not seen this before? > > (Was the a change to building it with USERBOOT_ZFS_SUPPORT done?) > > > > It seems that userboot_zfs_probe() should check for boot files on the v= olume > > and not just that a pool exists on the partition, maybe? > > > > Anyhow, manually setting currdev=3Ddisk0s1a: gets around the problem. > > You should be able to set that in your ufs partition /boot/loader.conf > file and at least then your not having to drop to the OK prompt and > manually entering this. Doesn't help, because it is not reading files from the boot ufs file system= . (I could copy all the boot stuff over into the ZFS file system, but that ki= nda defeats the purpose of having UFS as the boot fs.) For example, it always fails with: ERROR: cannot open /boot/lua/loader.lua: no such file or directory. When I look in stand/efi/loader/main.c, there is a function that checks for boot files called sanity_check_currdev(). However, userboot does not have a similar function and just seems to assume that the ZFS partition in the bootable one, if it finds one. --> I am wondering if sanity_check_currdev() shoud be added to userboot to handle this case? rick > > There is much magic in boot code that bites, and not just in FreeBSD. > Often assumptions are made that "this" boot code, and "this" OS are > the only things on the disk(s). > > The fact that Linux uses a "apple-zfs" uuid, and FreeBSD a "FreeBSD-zfs" > drove me nuts for 2 days until I found this little tid bit. > > Zpool import doesnt care, but the boot code does! > > > -- > Rod Grimes rgrimes@freebs= d.org From nobody Tue Jul 2 12:54:15 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WD2tV5Fgzz5QNQf for ; Tue, 02 Jul 2024 12:54:42 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4WD2tT1lBmz4sC5 for ; Tue, 2 Jul 2024 12:54:41 +0000 (UTC) (envelope-from janm@transactionware.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of janm@transactionware.com designates 203.14.245.7 as permitted sender) smtp.mailfrom=janm@transactionware.com Received: (qmail 93139 invoked by uid 907); 2 Jul 2024 12:54:32 -0000 Received: from i59F7FFBA.versanet.de (HELO smtpclient.apple) (89.247.255.186) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Tue, 02 Jul 2024 22:54:32 +1000 Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Booting in bhyve always sets currdev to ZFS From: Jan Martin Mikkelsen In-Reply-To: Date: Tue, 2 Jul 2024 14:54:15 +0200 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <4988117B-1511-43DA-8B78-1BC007C037F2@transactionware.com> References: To: Rick Macklem X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+ip4:203.14.245.0/24]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[transactionware.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; TO_DN_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4WD2tT1lBmz4sC5 On 29. Jun 2024, at 03:26, Rick Macklem wrote: >=20 > Hi, >=20 > I've installed FreeBSD current in a bhvye instance. Everything > went ok, with UFS as a root partition. > Then I created a zpool in another partition... > - Now, every time I boot it I have to > OK set currdev=3Ddisk0s1a: > to get it to boot. >=20 > What is the trick to keep ZFS from messing up the boot variables? I remember having this problem a few years ago. I see I have in an old = startup file, =E2=80=98-e =E2=80=9Crootdev=3Ddisk0=E2=80=9D=E2=80=99 to = set a loader environment variable. I also recall needing different Bhyve = firmware, and I used gptboot. Some of these things might have been for = different reasons. Other details are fuzzy. Regards, Jan M.= From nobody Tue Jul 2 14:30:18 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WD5144Yf3z5QZxc for ; Tue, 02 Jul 2024 14:30:32 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WD5133y4Sz576x for ; Tue, 2 Jul 2024 14:30:31 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gndrsh.dnsmgr.net; spf=pass (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net designates 65.75.216.6 as permitted sender) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 462EUIKK017612; Tue, 2 Jul 2024 07:30:18 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 462EUI7s017611; Tue, 2 Jul 2024 07:30:18 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202407021430.462EUI7s017611@gndrsh.dnsmgr.net> Subject: Re: Booting in bhyve always sets currdev to ZFS In-Reply-To: To: Rick Macklem Date: Tue, 2 Jul 2024 07:30:18 -0700 (PDT) CC: "Rodney W. Grimes" , FreeBSD CURRENT X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.77 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[gndrsh.dnsmgr.net,none]; R_SPF_ALLOW(-0.20)[+ip4:65.75.216.0/23]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4WD5133y4Sz576x > On Sun, Jun 30, 2024 at 8:23?AM Rodney W. Grimes > wrote: > > > > > On Fri, Jun 28, 2024 at 6:26?PM Rick Macklem wrote: > > > > > > > > Hi, > > > > > > > > I've installed FreeBSD current in a bhvye instance. Everything > > > > went ok, with UFS as a root partition. > > > > Then I created a zpool in another partition... > > > > - Now, every time I boot it I have to > > > > OK set currdev=disk0s1a: > > > > to get it to boot. > > > > > > > > What is the trick to keep ZFS from messing up the boot variables? > > > I've been poking around, but haven't learned much. > > > I think it is userboot (although there are so many boot programs in /boot, > > > I am not 100% sure?) that sets currdev=zfs:example: since it sees there is ZFS > > > in a partition on the drive. It is not the boot partition and doesn't have > > > any boot stuff in it. > > > > > > When I look at userboot, it appears that it always sets userboot_zfs_found > > > to 1 whenever userboot_zfs_probe() is called, given that there is a ZFS > > > partition with a pool on it. This makes extract_currdev get set to the > > > ZFS stuff, > > > assuming I am reading the code correctly. > > > What I do not understand is why I have not seen this before? > > > (Was the a change to building it with USERBOOT_ZFS_SUPPORT done?) > > > > > > It seems that userboot_zfs_probe() should check for boot files on the volume > > > and not just that a pool exists on the partition, maybe? > > > > > > Anyhow, manually setting currdev=disk0s1a: gets around the problem. > > > > You should be able to set that in your ufs partition /boot/loader.conf > > file and at least then your not having to drop to the OK prompt and > > manually entering this. > Doesn't help, because it is not reading files from the boot ufs file system. > (I could copy all the boot stuff over into the ZFS file system, but that kinda > defeats the purpose of having UFS as the boot fs.) It had to of loaded userboot from the ufs, right? What type of disk is this? gpt or mbr? Can you show the output of gpart show and gpart list? > > For example, it always fails with: > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > When I look in stand/efi/loader/main.c, there is a function that checks > for boot files called sanity_check_currdev(). However, userboot does not > have a similar function and just seems to assume that the ZFS partition > in the bootable one, if it finds one. That sounds like a wrong assumption by the code. > --> I am wondering if sanity_check_currdev() shoud be added to userboot > to handle this case? Warner?? > rick > > > > > There is much magic in boot code that bites, and not just in FreeBSD. > > Often assumptions are made that "this" boot code, and "this" OS are > > the only things on the disk(s). > > > > The fact that Linux uses a "apple-zfs" uuid, and FreeBSD a "FreeBSD-zfs" > > drove me nuts for 2 days until I found this little tid bit. > > > > Zpool import doesnt care, but the boot code does! > > > > -- > > Rod Grimes rgrimes@freebsd.org -- Rod Grimes rgrimes@freebsd.org From nobody Wed Jul 3 23:31:20 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WDwys5z74z5QZCK for ; Wed, 03 Jul 2024 23:31:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WDwys1Gkbz563n for ; Wed, 3 Jul 2024 23:31:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=gEVWCkaN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-6e7b121be30so11321a12.1 for ; Wed, 03 Jul 2024 16:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720049492; x=1720654292; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l8UE2EgcfqqPVXD+R4ruGzA3Kfy38QtiCd8m4Q8wPbU=; b=gEVWCkaNc7ZcxuiBQGbukR1aSN0cqifph61L5VlCRNq93/xAg2HatNg8L+XIsj8KWW qmBqfuRFDoId3yeXf6oB5FRhGew24JJ4E6FkW9YxYGr2QlR7QQlQwLQNcc2dLRMQTGDX 1cHHfS+VmyF9MZSqMSbvqdAa3pD7y9wVFgqfXP39XfjMHh8l07gHZLlUBjXR3u3I4wbi C9lgPqzdD+zhg0jAmmW/pv/iui3p7NKt+qvCPpYGzt7iPhlfFqMaSEySViYbtPoRPHff YwpK0XtPOqYYQF+Q8NSDWu2SNMcdZBn/l9umFgBr0JBnZQHl6IA8VZuIqlU9VFeAWHbb PkpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720049492; x=1720654292; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l8UE2EgcfqqPVXD+R4ruGzA3Kfy38QtiCd8m4Q8wPbU=; b=HDkFUs6YKi64j76yOWM/hs8oG+DFqr4DLPWQ0C5wRKrITWc9/gF/zdogu4PV4eM6DR wOR5jn4YdTPi5rslvbCNOMidSF+4WYYr+NF8WhcEi9MsSYQP4H2+X/fwVD0ltCe8xiJw JRh2EEXM0jufZUU04z5de61FezIC7WA+HVKu9BY2KZcjCvjhVqc+JAtiFsfoT5k8GiKg LuvF1l6rfZsp7hddXBCLR6EUrdbwQw5TWe5agtu7gA4hTqF5e+UqnOEhRwdF77yKxGKK ZBZx8JSjbPgR2zMe2/nhPhzlykAQaipC1x2oFII+1oXIn+gzhyzT5NItz873zvkjbAZa z3Dw== X-Gm-Message-State: AOJu0Yxhte0gt+jEa/xo4sr+rPUxnrksRzaRtomy0TKwZe31TUgOzT3R wkaBU1ECuLWPa70zB2qndXOnzzVSPeTHqJvIvVDVTtJ/dPlcPKCFNulDkE5SY0s47NBPspKQvsv 9vqwJwHWXZnLT/XJB11LZlfWE8hNgwH4= X-Google-Smtp-Source: AGHT+IFVLB+e/krc9HEnpfPHcMBgPPtyYTqwmtdTC8auyaA2oHp4a/aNs3T2j6T5aNpSNczbBlX9PwG5IhEUu4ianfQ= X-Received: by 2002:a05:6a21:3286:b0:1be:c97f:2445 with SMTP id adf61e73a8af0-1bef6101ca6mr14274230637.22.1720049491469; Wed, 03 Jul 2024 16:31:31 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202407021430.462EUI7s017611@gndrsh.dnsmgr.net> In-Reply-To: <202407021430.462EUI7s017611@gndrsh.dnsmgr.net> From: Rick Macklem Date: Wed, 3 Jul 2024 16:31:20 -0700 Message-ID: Subject: Re: Booting in bhyve always sets currdev to ZFS To: "Rodney W. Grimes" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.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)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::531:from] X-Rspamd-Queue-Id: 4WDwys1Gkbz563n On Tue, Jul 2, 2024 at 7:30=E2=80=AFAM Rodney W. Grimes wrote: > > > On Sun, Jun 30, 2024 at 8:23?AM Rodney W. Grimes > > wrote: > > > > > > > On Fri, Jun 28, 2024 at 6:26?PM Rick Macklem wrote: > > > > > > > > > > Hi, > > > > > > > > > > I've installed FreeBSD current in a bhvye instance. Everything > > > > > went ok, with UFS as a root partition. > > > > > Then I created a zpool in another partition... > > > > > - Now, every time I boot it I have to > > > > > OK set currdev=3Ddisk0s1a: > > > > > to get it to boot. > > > > > > > > > > What is the trick to keep ZFS from messing up the boot variables? > > > > I've been poking around, but haven't learned much. > > > > I think it is userboot (although there are so many boot programs in= /boot, > > > > I am not 100% sure?) that sets currdev=3Dzfs:example: since it sees= there is ZFS > > > > in a partition on the drive. It is not the boot partition and doesn= 't have > > > > any boot stuff in it. > > > > > > > > When I look at userboot, it appears that it always sets userboot_zf= s_found > > > > to 1 whenever userboot_zfs_probe() is called, given that there is a= ZFS > > > > partition with a pool on it. This makes extract_currdev get set to = the > > > > ZFS stuff, > > > > assuming I am reading the code correctly. > > > > What I do not understand is why I have not seen this before? > > > > (Was the a change to building it with USERBOOT_ZFS_SUPPORT done?) > > > > > > > > It seems that userboot_zfs_probe() should check for boot files on t= he volume > > > > and not just that a pool exists on the partition, maybe? > > > > > > > > Anyhow, manually setting currdev=3Ddisk0s1a: gets around the proble= m. > > > > > > You should be able to set that in your ufs partition /boot/loader.con= f > > > file and at least then your not having to drop to the OK prompt and > > > manually entering this. > > Doesn't help, because it is not reading files from the boot ufs file sy= stem. > > (I could copy all the boot stuff over into the ZFS file system, but tha= t kinda > > defeats the purpose of having UFS as the boot fs.) > > It had to of loaded userboot from the ufs, right? I assume it is reading some boot file from UFS. Way back when I thought a primary boot was read from 8K at the begining of the partition, but that's how out of date I on this. -> Put another way, I don't know if "userboot" is the one I am seeing try to use the ZFS partition. > > What type of disk is this? gpt or mbr? It's old MBR. Although I'll assume bhyve knows other stuff, most of my old hardware only does MBR and not EFI, so I'll still in the MBR habit. > > Can you show the output of gpart show and gpart list? root@nfsv4-foo:~ # gpart show =3D> 63 67108801 vtbd0 MBR (32G) 63 1 - free - (512B) 64 67108800 1 freebsd [active] (32G) =3D> 0 67108800 vtbd0s1 BSD (32G) 0 33554432 1 freebsd-ufs (16G) 33554432 12582912 2 freebsd-swap (6.0G) 46137344 20971456 4 freebsd-zfs (10G) root@nfsv4-foo:~ # gpart list Geom name: vtbd0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 67108863 first: 63 entries: 4 scheme: MBR Providers: 1. Name: vtbd0s1 Mediasize: 34359705600 (32G) Sectorsize: 512 Stripesize: 32768 Stripeoffset: 0 Mode: r3w3e5 efimedia: HD(1,MBR,0x90909090,0x40,0x3ffffc0) attrib: active rawtype: 165 length: 34359705600 offset: 32768 type: freebsd index: 1 end: 67108863 start: 64 Consumers: 1. Name: vtbd0 Mediasize: 34359738368 (32G) Sectorsize: 512 Stripesize: 32768 Stripeoffset: 0 Mode: r3w3e8 Geom name: vtbd0s1 modified: false state: OK fwheads: 255 fwsectors: 63 last: 67108799 first: 0 entries: 8 scheme: BSD Providers: 1. Name: vtbd0s1a Mediasize: 17179869184 (16G) Sectorsize: 512 Stripesize: 32768 Stripeoffset: 0 Mode: r1w1e1 rawtype: 7 length: 17179869184 offset: 0 type: freebsd-ufs index: 1 end: 33554431 start: 0 2. Name: vtbd0s1b Mediasize: 6442450944 (6.0G) Sectorsize: 512 Stripesize: 32768 Stripeoffset: 0 Mode: r1w1e0 rawtype: 1 length: 6442450944 offset: 17179869184 type: freebsd-swap index: 2 end: 46137343 start: 33554432 3. Name: vtbd0s1d Mediasize: 10737385472 (10G) Sectorsize: 512 Stripesize: 32768 Stripeoffset: 0 Mode: r1w1e1 rawtype: 27 length: 10737385472 offset: 23622320128 type: freebsd-zfs index: 4 end: 67108799 start: 46137344 Consumers: 1. Name: vtbd0s1 Mediasize: 34359705600 (32G) Sectorsize: 512 Stripesize: 32768 Stripeoffset: 0 Mode: r3w3e5 > > > > > For example, it always fails with: > > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > When I look in stand/efi/loader/main.c, there is a function that checks > > for boot files called sanity_check_currdev(). However, userboot does no= t > > have a similar function and just seems to assume that the ZFS partition > > in the bootable one, if it finds one. > > That sounds like a wrong assumption by the code. > > > --> I am wondering if sanity_check_currdev() shoud be added to userboot > > to handle this case? > > Warner?? > > > rick > > > > > > > > There is much magic in boot code that bites, and not just in FreeBSD. > > > Often assumptions are made that "this" boot code, and "this" OS are > > > the only things on the disk(s). > > > > > > The fact that Linux uses a "apple-zfs" uuid, and FreeBSD a "FreeBSD-z= fs" > > > drove me nuts for 2 days until I found this little tid bit. > > > > > > Zpool import doesnt care, but the boot code does! > > > > > > -- > > > Rod Grimes rgrimes@fr= eebsd.org > -- > Rod Grimes rgrimes@freebs= d.org From nobody Sun Jul 7 03:42:48 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WGtPk5V5Kz5Q9f3 for ; Sun, 07 Jul 2024 03:43:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WGtPj0QPrz4nGr for ; Sun, 7 Jul 2024 03:43:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LePHU0Wo; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1720323782; bh=SKWB+uTwWjPpYZvauQVYSONC8HOVeScpqeeqWkG8+3A=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=LePHU0Wog03dR2RANqzqFOp2IxRtAiiIavjss9E4EKV4WAAncIy6hwi10mKBkGUDKQ7GsxV7SaZVGkVwpt5luvtQPERQbkKyJU5M7dGWahFegyk/IN6Xg+0/oK+IbPnO1G3KQEnW9d+FMqSDYtRsma6PsLMxMG4Mu8eIDNl73NWzpcP6kqraTCeXUQDHLQpczujMM6ob4D6dK6EQ2JE1UOwQPeSXd2KJtuJnPJnUTXjY1h8z8XsAOtRlaIwVVV5gddZ10bm7irTlARcYBESwfECrc74ZjM/gwU0jpZLAxLSG3QWUDYWmmhpFTuYvx+E3P3/uIn3mux46YtWbUHTrJw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1720323782; bh=IsVOijDGOWsrB6Tg1OxZIjPbPBmpYIozNSNo+PGHeRd=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=l3HcKvacZAL9z1GRoaDKeHaWbKsdPtcgCcHaD7TfVDvH4egD9Dw7wiYkpwQ1PVREP8mc+r8htkxMcM+MvKZnJTYyN4It8NTAEPv3ZYIX+E7yjIoihWR4FBIaNkhgzWl5eMxFfwTOz92VEou9ZBp8QDBX0/25nG0pXR36kDnRT+d+p5Kyzi2sLj8+K/OThGANkPPNeyig/JEhspe77Ivrz3eWlz6l5wTno/fPgsX6F7N5oxSNs4iVe1roFjk3QejyPMD6RtbOaFi/oDZH1KaXRV79ns1gLZ0FluLIALh0tV9Gw/p6wo0br4BbxyhjP+LFFd5YNVxcISeAR8xtqOkR7Q== X-YMail-OSG: j74keGQVM1nlT3YRPGhdKUh98.G3Rt8HU_Ed5EpU0S.eUzClcw5POpbjIcAQfMH 1YmwGzb0hY6sdEaXBTf92jl8Sq7TSB3Pu0Iv6yPUUXYKRQNLuI2ztOqyCJJ2ETf1UrwLPPkLAQ5I XJ3wq.2rT4EYj7xktqKH1AgioG9lzpejDUBDwXWs7rkA.9Lv.wfws7Y2LHiGVdJk_48l5DJOOh3z WtGiust2kR4k7grUdbIJvlMx9CfhiAu9f1MIfGN_Dlf5gCWNhhtAlmEamkHrmBXNeVXblUqwU40o aGsK3sDosQIAKivlMUDSnIckify5xE3rEcty1Y7fxjBORcRCtRY5bUqBRekslicH7lVzcUjyv3w2 uYwAcXhMcLPh8nTpQkJ_kdOw1i7jbBWncwa2kCezeSU57cnG396n7_cbucZUQ.9qxVZkYEc1n61M BQDKYVYumFy5Ec.vmh6sKtGiF06JxStQlzpl3KvRm6qa9f_LElvcTBGM5fyaLU8wCu4zA2L5YXQS XF.nw63BG_42uEYHfX3gx7euXMqNYTJXK2qVZo7ALPOpCW_F8T8hN3hXRdkmpDlS76_C.zKJ2nSU D7.xW8rXIPxs24z95Eex.vVnvH5lRbwDd0CFBcIoQBL9xhajPmAmm73bcqdowILchJeJgjqApnb9 168ld1FmpZjG5hSRIEif18XqAioqBbezqwUIPP7q.lIMcFF79yxzUG0_ebafKQY0QtAlEPWnmi1W SpDJISjRXnj.btBxfMz5qdo6rTUmG2SMcE2uxxxstGfM8EK6sRh8uUXAig4bhlMc_hjQKYr.B9Z0 y9k59bGuM7hnY84aD7WQsW1ZgiaZFEgi7yjyykmb.Si8I9dmU6RGotkSFuOi8mnsW8KKqKWzy_E9 c.C_SqZVJq7TKQxmL7cPw36EG4f_6PKch0T2ZOBLyJbLSlRUfpZKzl_20xRA0CoucT.apt7uoR5r _UaHiK0PN6FBTQ8e2KTmd1qaR9O9DdoOkhs2LqrC_8QDrJtBIUxBD1e_N.1NpjNQMsZWuXJby2AF blNZv6pZ86fxeBBDWljq1WpmjpzHs6jOBvTZ0ELk3KZqX3D46nnFuv5rO6fcYhPTkgdGfT0vHeup dreySdAe2eYrtS90chhnF4XAwtBlYCj8l3YHdau_HSXKZ1r3aA_pt5OtsxyYnquJe5qZoM0qhWP3 egXT82XHW9RAqu24USdnCEv2CS.TjnHgPiyDXeu6s0dal1jgswm2lmaa79j2ETAqLl2tlod2kHL1 VPf4r8xnUcHiRJAQtIUBGDmoR0UZ8aWiazTYP_CsTMnw3flEZh__y0QInpqZlg61aGio8fP3uSPW 6nm_rtexkZJBbbHg7aAzivPyHBTMIx3TVUGJfjOV04G_zjic9OKjblsx3eVzqDu854xnvgryk7iE BK6mmDBpRCyDWLQ4qChUR4bnOnN8hVvrOiZs1Emdj0y2wDVTblVSwe3AiGsA.fJRhNoRsmWVfcEA MGPexXzz9Zm1N2av6_FzjwLksSzrwShR5Nu.M.ySKNB11ydVQPImabsc8uhE7fPXSvgSq0dx.AvV tUF8YpI9_4hxskZrB6pdCp5a4ZcNy0AWo57ez0FGKfWE2AuCVHOxRlOKoFDPhW75giHIYdwkLdU4 UlgEu2DsTSehfVx3SvCw._I1rwEUIP.okS.b1kCM.g2lfReRPd9Cr1uEUTcgWvfxU4uXIY3rHRxy reNSLGMzLeV4uPADX.9VKpsnBfxq5soiq4.jKtgdI9cPpowh9JqJw_8Bo12kYxzKORnzsSM7LK3R VYfiPXsTy4sCmj72Ri8dQ7yiNsd9onwMXDp_qTN.tY17P0oz1dzLYt6jtH3Y5R9LZJOy8kk_fdN3 WqPhonCiLOC0hiI5GKDlKnP4PZf1idoBMCxkWvIKmWZpxs34B9w2NSgVo1bZJVNzTENyU0GZu6SJ 1n3JS_YzJPQQoDRhWeXcECYlsHTBm7qh6AQX9j8PS61aItXNdRdjVlah9s7WscNaGgTGOMfKlcc1 wIuxv8eIDZSqZj9QHirfiGKO4Y7a.2aCn0BXMnSSKfmOc7flBjibaCr.FtXRtVOVAVltpKwFtlp1 Fv0KYpE0HezKPMQsdNR6cnk.FZnKNcWXdwLCPjgggsPvzrlhy74HXPIs2f2C7NRrVRFazRHuI0Wb qlLVU9GCgL6ePi_NRWd5p0CRZZsd2ffmCdn9kAaBgJ4FRkrC43N38eh7tayhl7SfrEBDBKH_6uhX qQGe4el9Qsvp_mL4MbbbjPOJOYr9O3KqIHH9VxUpayIvsEZh4iTtd_8SwSUnJCBadEHTvcw8nHyc - X-Sonic-MF: X-Sonic-ID: 104829cc-e9b8-4825-8ac1-5011ce5ddb6e Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Jul 2024 03:43:02 +0000 Received: by hermes--production-gq1-5b4c49485c-4758j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9cd428122dae61b6c979c3a3078b09ac; Sun, 07 Jul 2024 03:42:59 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: A better alternative to having builds of main-armv7-default fully disabled and last-built be months out of date Message-Id: <91287D15-F0A9-4425-A265-B07418B8714D@yahoo.com> Date: Sat, 6 Jul 2024 20:42:48 -0700 To: Philip Paeps , FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD X-Mailer: Apple Mail (2.3774.600.62) References: <91287D15-F0A9-4425-A265-B07418B8714D.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from] X-Rspamd-Queue-Id: 4WGtPj0QPrz4nGr main's armv7 packages that are distributed are getting to be months behind because of the build hangups preventing the builds on ampere2. The hangups happen just-after graphics/graphviz installation during the activity in a builder where that build depends on graphics/graphviz . I expect that the armv7 "bulk -a" builds on ampere2 would complete if the Makefile for graphics/graphviz had: BROKEN_armv7=3D leads to ampere2 build hangups for builds that depended = on graphics/graphviz A related subset of the packages would not be built at all. But that is better for security and such than the official packages that are available being systematically months out of date, at least in my view. I suggest trying the chnage and enabling main-armv7-default builds to see if they complete overall. I'll note that there is a hostorical example of a graphics/giflib build failure that lead to 3481 ports not being built, including graphics/graphviz . But the "bulk -a" completed and 24176 packages built and were distributed. graphics/graphviz having BROKEN_armv7 should generaelly build more packages than that when graphics/giflib builds okay. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jul 7 10:04:14 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WH2sg4084z5Qn11; Sun, 07 Jul 2024 10:04:23 +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 4WH2sg1NpYz4M4l; Sun, 7 Jul 2024 10:04:23 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.18.1/8.18.1) with ESMTPS id 467A4E7S029467 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 7 Jul 2024 12:04:14 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.18.1/8.18.1/Submit) id 467A4EFg029466; Sun, 7 Jul 2024 12:04:14 +0200 (CEST) (envelope-from fuz) Date: Sun, 7 Jul 2024 12:04:14 +0200 From: Robert Clausecker To: Mark Millard Cc: Philip Paeps , FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD Subject: Re: A better alternative to having builds of main-armv7-default fully disabled and last-built be months out of date Message-ID: References: <91287D15-F0A9-4425-A265-B07418B8714D.ref@yahoo.com> <91287D15-F0A9-4425-A265-B07418B8714D@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91287D15-F0A9-4425-A265-B07418B8714D@yahoo.com> 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:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Queue-Id: 4WH2sg1NpYz4M4l Greetings, Am Sat, Jul 06, 2024 at 08:42:48PM -0700 schrieb Mark Millard: > main's armv7 packages that are distributed are getting to be months > behind because of the build hangups preventing the builds on ampere2. As a stop-gap measure, you can use my package set. http://fuz.su/pkg/ I'm currently preparing 2024Q3 builds. These will be ready in about a week or two. If there are known users of this package set, I can see that I rebuild it more often. Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments