From nobody Fri Jul 19 01:10:05 2024 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WQBRm6Ypxz5Qm8s for ; Fri, 19 Jul 2024 01:10:12 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WQBRm62srz4SDM; Fri, 19 Jul 2024 01:10:12 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721351412; 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=2oAD/HWKFDfA1fM+OmQ4OEJQQxlFZMNSgl82ux2TUAE=; b=akhRZrVC5mv9QIk9F/3E2rsCkC9KWky44YN91iAmfwcikNylejVK3Py60CKqh8ETwl1soH 884ov4cS5Tdnx3L6bPrAO9pi3soQdtrmwhwEesIxdBXIPJ9v3aGEPDUUS0N2mplPpZp7AJ YJHHk1sKXCK7YdWt8hVd3UsiNUnjETW7029+bILfsTwUAehf+iF9+hkQDvYpPPiNF4I2+c oC8qFyuqAyODBsUMUHjkpIcVjWQUYJMY42A5mYPNw+ahCfCSh337rh1KBkcas3hAMlsPhE VppgqBg6/aMRQE5vWDsnLxv9EDZsPiPGjdUGEXg034fDSiqT0ScJ4lNWQif6zA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721351412; a=rsa-sha256; cv=none; b=iYE3W8av3nPxuq8Utz5CCcR7oNnSNKKPQRjJKDNF/RqNMkhszDUjBqdKS2EjUSOp+/ZPgo 4s/d9+hStRGdYXm2TLnd+9OtkL3aYUDHbdFdC2fInGMclzfc7VgesR2Rvd3+TRNS/1f0f0 f3rL9GHskSurb8GmSKyXJsz8YDsC7HfO0wl4+Hfuf+sqaOgUKK7CXcQ5Hv0bbO5+Zi+wWc cMDu2EPZT4Hd7oOW25LDR2wJQ0f3ITaugqyXv2sSN9NoSISWun3AR9EK4M3PQFDNHsh2TB wlfZp8L0KsGN133ge1rgHh8ALjy/ycJT1U7/bNq2+zUxMptmRDM4i/cKj1VJ8Q== 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=1721351412; 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=2oAD/HWKFDfA1fM+OmQ4OEJQQxlFZMNSgl82ux2TUAE=; b=DZlrLWAEnCV1v/dHSG7hqBThtlg9udhNPVICTyq3Cudr83ZbN06KLS1MVWZGC5NEknpwqs Dsfaie/Y18QhLXVeZih/gURssHhYQ/Nn5gGKaRrRRJZH+GmKEbJMfTvN84XZfKHWxWHlYO GreZVLoTEcQZlyc4ecvnO8PTrN0ibJPv3DvtHs4oLllBBBlpr6O5pIxJk6/RqnvIErveyL xapD6D8fUp/5rujJ69150eRBplOiqeFGYgdtsNVNznT8pZV3+1nD4/8CuIVwbNGHcJlqih 9jfvAsM6ZYIlXnrhrkv48Qw6bE6eau/m/Z5A/wj855DpS5JwdPfE3pmdErG1LQ== Received: from smtpclient.apple (unknown [IPv6:2001:19f0:6001:9db:98f0:9fe0:3545:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WQBRl6jBZz12xh; Fri, 19 Jul 2024 01:10:11 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <01D917DB-7E47-46D7-AD22-AD09C4F89A96@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_071E00C1-5AEE-4D1D-80DC-867748BDB8A2" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: nextboot warns it won't reset Date: Fri, 19 Jul 2024 09:10:05 +0800 In-Reply-To: Cc: freebsd-stable@freebsd.org To: Gareth de Vaux References: X-Mailer: Apple Mail (2.3696.120.41.1.8) --Apple-Mail=_071E00C1-5AEE-4D1D-80DC-867748BDB8A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 19, 2024, at 4:45 AM, Gareth de Vaux = wrote: >=20 > Hi all, nextboot warns as follows: >=20 > # nextboot -k testkernel > WARNING: loader(8) has only R/O support for ZFS > nextboot.conf will NOT be reset in case of kernel boot failure >=20 >=20 > This's on a ZFS zroot 12.4-STABLE system. You're encouraged to upgrade to supported releases ;) >=20 > Does this mean that nextboot will not do its job? I think the WARNING is a good hint and explain why it does not work = incase boot failure. The implementation of load desired kernel is write loader parameters to = /boot/nexboot.conf , to indicate the loader(8) do its job, that is loading the desired kernel on next = boot. Well it is a oneshot boot so the loader will try to disable these parameters by writing = `nextboot_enable=3DNO` to /boot/nexboot.conf. That is the magic. Apparently if loader(8) does not support write to = filesystem, in this case the ZFS,=20 it will fail to write /boot/nexboot.conf in case kernel boot failure. = Thus subsequent boot the loader(8) would still try to boot from the oneshot `testkernel`. >=20 > I see a blog mentioning that nextboot will write metadata to the ZFS = pool label, > in which case maybe the warning is no longer applicable? That is implementation specific. Normally you can ignore the warning, = unless you have trouble booting the kernel. >=20 >=20 > Also I suspect I should rather run "nextboot -D" to revert the = situation. > Is this equivalent to removing /boot/nextboot.conf and/or this = metadata in the > ZFS pool label? I think normally you do not need that. Best regards, Zhenlei --Apple-Mail=_071E00C1-5AEE-4D1D-80DC-867748BDB8A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 19, 2024, at 4:45 AM, Gareth de Vaux <stable@lordcow.org> = wrote:

Hi all, nextboot warns as follows:

# nextboot -k testkernel
WARNING: loader(8) has = only R/O support for ZFS
nextboot.conf will NOT be reset = in case of kernel boot failure


This's on a ZFS zroot 12.4-STABLE system.

You're = encouraged to upgrade to supported releases ;)


Does this mean that nextboot will not do its = job?

I think the WARNING is a good hint and explain why = it does not work incase boot failure.

The implementation of load desired kernel is write = loader parameters to /boot/nexboot.conf , to indicate
the = loader(8) do its job, that is loading the desired kernel on next boot. = Well it is a oneshot boot
so the loader will try to disable = these parameters by writing `nextboot_enable=3DNO` to  /boot/nexboot.conf.

That is the magic. Apparently if = loader(8) does not support write to filesystem, in this case the = ZFS, 
it will fail to write /boot/nexboot.conf in case kernel boot failure. Thus = subsequent boot the loader(8) would
still= try to boot from the oneshot `testkernel`.


I see a blog mentioning that nextboot will = write metadata to the ZFS pool label,
in which case maybe = the warning is no longer applicable?

That = is implementation specific. Normally you can ignore the warning, unless = you have trouble booting
the kernel.



Also I suspect I should rather = run "nextboot -D" to revert the situation.
Is this = equivalent to removing /boot/nextboot.conf and/or this metadata in = the
ZFS pool label?

I = think normally you do not need that.

Best regards,
Zhenlei


= --Apple-Mail=_071E00C1-5AEE-4D1D-80DC-867748BDB8A2--