From nobody Fri Jul 19 04:58:58 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 4WQHX02k7qz5QtW3 for ; Fri, 19 Jul 2024 04:59:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 4WQHWz69cCz4pjr for ; Fri, 19 Jul 2024 04:59:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-78c84837564so1062570a12.3 for ; Thu, 18 Jul 2024 21:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721365151; x=1721969951; 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=D0SjkXrpQHZgQROzpQwXqfXPLpjdRTwbllzvBbECvMs=; b=Bu+QXNMPBBbwhoBdSqzWfY9EM/4jcQ9+vJutKr+UjtBx60zCA3P7KywJylDFW8p5di qZ6V+GQObuELnRYg5A0bNxkNwrNNWea3qWbDH0o9/avFxmWsWtJd+2lcFhRTWzz5Xeu6 COsvwxpSY/maQdtukOhRPrcSoz7k4cVIiXe+7QBUOlfGaMSXXGsH5c6XISSc98mM2OR5 dU/cgeGHu/+ZmMTKwa77VhGf1t6KyYD3lzoCxi7Pc0UIGqYt2FN7uaUvfVrJykC/e32l u4fgPaXggSp0gfvNDbcajEQPGhIPJK65JHWr2VTpUjeLdosqfSmmOKbMLS6L/xC1z7w2 lt2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721365151; x=1721969951; 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=D0SjkXrpQHZgQROzpQwXqfXPLpjdRTwbllzvBbECvMs=; b=NrJSQckVnJtMSreT1QxyqY5qOqeAOe/YWUePVB+Bvzpm3VzqCjf0mbAjJPRzk/FJEW 5bLzyjc487woC5PQDg5zQ6FkUEqVCHI6zXPLB9l3ju+Ht4ZfYw825b3u1sMVmAQwhBHq GJv6uaPmwhi+E8FUMjxMsp9qhFittCED2lT60xMC2BN8F3IW2zhsxResLaf32XXX2QLK NN10Jc0b/mz8vKzysFaJSzHgJHt87VkCZohbO1qAA98fBM8M9tjfMqhrKdK+DlTAKgLm 9P6oKNTpWp84u0YU5ppxAirMC+hr9QgoDfg2CDzR5mhrBNbqUnm48+Bj5oCRIw5YuQb9 TUxA== X-Forwarded-Encrypted: i=1; AJvYcCVbNmLwyHFjlcbXrGxLrsUvu7F0Sh6I+9OlFRnGfMKDEZugD6oS9dbiETBjbKOhYsXWci9k6nV39sHyxK7N0YQeOezbMalr1chZHg== X-Gm-Message-State: AOJu0Yy3Yyqk6R6+XgHlBCkOBezVAw/ge2hAeq666yu0GDVPy+Ro0eCQ 6MeNt4cbBNDoP2p3N1zXvGv3EELL1lVmEPrIWK5H1503/lVHMrLbyOB0aYwvDg1VPA9uX00TyeV teBD1aji/cKpoNktEqqYg9RqlIJP6J84b0g6FYR9b0OmrPDJlttU= X-Google-Smtp-Source: AGHT+IHVQGB+D9woyxUPCya6D4kfrLpY2NKm00xAMlIKn+H0Tn9+5J/ZyW1U1NCTt2pEBqpWv2ofgUZBafq7xfP9gW4= X-Received: by 2002:a05:6a20:43a9:b0:1c3:fcbb:5670 with SMTP id adf61e73a8af0-1c3fddcd3c1mr8395552637.48.1721365150523; Thu, 18 Jul 2024 21:59:10 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: <01D917DB-7E47-46D7-AD22-AD09C4F89A96@FreeBSD.org> <9CCA0BFB-70D3-4E21-8BA7-3E9F35110E8D@FreeBSD.org> In-Reply-To: <9CCA0BFB-70D3-4E21-8BA7-3E9F35110E8D@FreeBSD.org> From: Warner Losh Date: Thu, 18 Jul 2024 22:58:58 -0600 Message-ID: Subject: Re: nextboot warns it won't reset To: Zhenlei Huang Cc: Gareth de Vaux , FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="000000000000537e8f061d928e19" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WQHWz69cCz4pjr --000000000000537e8f061d928e19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 18, 2024 at 10:49=E2=80=AFPM Zhenlei Huang w= rote: > > > On Jul 19, 2024, at 10:19 AM, Warner Losh wrote: > > > > On Thu, Jul 18, 2024, 7:10=E2=80=AFPM Zhenlei Huang wr= ote: > >> >> >> On Jul 19, 2024, at 4:45 AM, Gareth de Vaux 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 d= o > boot once and nextboot stuff. > > > Yes and NO. > > Yes for 13.x, 14.x and CURRENT. nextboot(8) will consults zfsbootcfg(8) t= o > 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. > I missed that detail and understand your comments about running a supported release. It does indeed not work on 12. Warner > 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 >> > > > > --000000000000537e8f061d928e19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 18, 2024 at 10:49=E2=80= =AFPM Zhenlei Huang <zlei@freebsd.or= g> wrote:


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

<= div>


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


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

Hi all, nextboot warns a= s follows:

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


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

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


Doe= s this mean that nextboot will not do its job?
=

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

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

That is the magic. Appare= ntly if loader(8) does not support write to filesystem, in this case the ZF= S,=C2=A0
it will fail to write=C2=A0/bo= ot/nexboot.conf in case kernel boot failure. Thus subsequent boot the loade= r(8) would
still try to boot from the oneshot `testk= ernel`.
=
However, ZFS has special support via properties= in the BE that lets you do boot once and nextboot stuff.
=

Yes and NO.

Yes f= or 13.x, 14.x and CURRENT.=C2=A0nextboot(8= ) will=C2=A0consults zfsbootcfg(8)<= /span>=C2=A0to do the nextboot stuff if fi= le system
is ZFS.<= /div>

No for 12.x. =C2=A0neither nextboot(8) nor nextboo= t.sh will do that. And it seems that loader(8) also do not get / set
<= div>ZFS properties to enable / disable nextboot stuff.

I missed that detail and understand your comm= ents about running a supported release. It does indeed not work on 12.
<= /div>

Warner
But ev= en better are boot environments. That's a more comple solution that sup= ports bootnext features and more. See bectl...

<= /div>
Warner=C2=A0

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

That is implem= entation specific. Normally you can ignore the warning, unless you have tro= uble 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.

<= /div>
Best regards,
Zhenlei



--000000000000537e8f061d928e19--