From nobody Fri Jul 19 04:49:13 2024 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WQHJd2LTjz5R7Gw for ; Fri, 19 Jul 2024 04:49:21 +0000 (UTC) (envelope-from zlei@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 4WQHJd1n80z4mYC; Fri, 19 Jul 2024 04:49:21 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721364561; 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=BR+HNjNkR1aoEP/NF8JdqBB+8YqnPwbyC8EmGGBfeqY=; b=HkcWB1pFOcooN8GZ94wOCn/coIWrFze4EbkkOJhOyoPRYG/whqyPF93mjv2/khMxwkw15z XE6yrjNvA4UQH+GZdpIB9UUmbodkyGJLagEwPa2fcc6yP9SwvA+UMZH9nI9MbS+qEGTuk9 X0izvGsjPy6vW0uu+6URn8yA/i+Hq2lNRZPrJBcl7eorf6mGsAAw0FJR8TakM2BjyD2kMb UtKtWvYB5gcT/DBb6OXlhutIfRMEY/XINsQglvqXIDgvHIB7vBk3AiDK4Osgk2mk4qcnZe dybnqY+sd/RPNmpuRjqKekzLhvAQp2ueLRZgv7JVky5WW44glRVKnl6/xQ+2Vg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721364561; a=rsa-sha256; cv=none; b=Z0cW0JLrNhd9KnA+z10m4hj+qzqWSiSbPAwjzTSW5vAM309PQEXxXI0/SERuqDUnDs8Hmn kdFOIlcqNJNGj4fZ0ggm1QWkHEa4qGlRGFxhDjrhZjIDCkjMSg/T48wDwiiR6c0bkA4uLz kPBePF7zxLlxGXLBYHa6oKUcDF0xowu85PUDHa9kfdOmd3MwGwI+MDNhUx1cAPowlZyGtm YPAC7hi4HiyjWDH0skuzOVmn029EOPlXQSM50n0Sv2gLzlSUr+/IugAw9wwZIJ0+sTZNSZ FqxKNP8omgdaV/gBpvsoqETd/EumBZ9hd0z9RfQAFJKjSNrKKh2tjrRfRl+ExA== 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=1721364561; 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=BR+HNjNkR1aoEP/NF8JdqBB+8YqnPwbyC8EmGGBfeqY=; b=x0/Wb/NOKJT0CjHPuVL91V2tF28rxEsYQskMzluy+nfqKW3xt+RJqyf7Cz+7nD2mF0N2m1 Oc99prLigtVJk0lnxTo51hT5XyQ4ERNcewc4mqkPxujGdk1O00l/VYDsviy/vXAwSQ2CtY KK+E7cMIHd/k/X6PPC2NbUlzLP61RL5M/XppxIhltFQlP3PuSo6/ekwSXVXAX4CFiwdt0f ZtigqCukNioNJ3FR8mBeVm8fL2NYkMisrlZ5ZOqrH8zQMRw7fq8FLKMTWvEc4R4hZCBkJh JiRRDPqDqZ/k+PzZkmopa0Uy/DvG443INlaMM1YJaOCKnRDEPCe5nIp2D8NkIg== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (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 4WQHJc1Th6z172k; Fri, 19 Jul 2024 04:49:19 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <9CCA0BFB-70D3-4E21-8BA7-3E9F35110E8D@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_84D08D30-9414-451B-ACA2-C530FE1DB7F8" 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 12:49:13 +0800 In-Reply-To: Cc: Gareth de Vaux , FreeBSD-STABLE Mailing List To: Warner Losh References: <01D917DB-7E47-46D7-AD22-AD09C4F89A96@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.8) --Apple-Mail=_84D08D30-9414-451B-ACA2-C530FE1DB7F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 19, 2024, at 10:19 AM, Warner Losh wrote: >=20 >=20 >=20 > On Thu, Jul 18, 2024, 7:10=E2=80=AFPM Zhenlei Huang > wrote: >=20 >=20 >> 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. >=20 > You're encouraged to upgrade to supported releases ;) >=20 >>=20 >> Does this mean that nextboot will not do its job? >=20 > I think the WARNING is a good hint and explain why it does not work = incase boot failure. >=20 > 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. >=20 > 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 > However, ZFS has special support via properties in the BE that lets = you do boot once and nextboot stuff. Yes and NO. Yes for 13.x, 14.x and CURRENT. nextboot(8) will consults zfsbootcfg(8) = to do the nextboot stuff if file system is ZFS. No for 12.x. neither nextboot(8) nor nextboot.sh will do that. And it = seems that loader(8) also do not get / set ZFS properties to enable / disable nextboot stuff. >=20 > But even better are boot environments. That's a more comple solution = that supports bootnext features and more. See bectl... >=20 > Warner=20 >=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? >=20 > That is implementation specific. Normally you can ignore the warning, = unless you have trouble booting > the kernel. >=20 >>=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? >=20 > I think normally you do not need that. >=20 > Best regards, > Zhenlei --Apple-Mail=_84D08D30-9414-451B-ACA2-C530FE1DB7F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 19, 2024, at 10:19 AM, Warner Losh <imp@bsdimp.com> = wrote:



On Thu, Jul 18, 2024, 7:10=E2=80=AFPM Zhenlei Huang = <zlei@freebsd.org> wrote:


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`.

However, ZFS has special support via properties in the BE = that lets you do boot once and nextboot = stuff.

Yes = and NO.

Yes for 13.x, 14.x and = CURRENT. nextboot(8) will consults = zfsbootcfg(8) to do the nextboot stuff if file = system
is ZFS.

No for 12.x.  neither nextboot(8) nor = nextboot.sh will do that. And it seems that loader(8) also do not get / = set
ZFS properties to enable / disable nextboot = stuff.


But even better are boot = environments. That's a more comple solution that supports bootnext = features and more. See bectl...

Warner 

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
<= /div>



= --Apple-Mail=_84D08D30-9414-451B-ACA2-C530FE1DB7F8--