From nobody Fri Jul 19 02:19:12 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 4WQCzf4gBHz5QtC9 for ; Fri, 19 Jul 2024 02:19:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 4WQCzd4ThNz4YHg for ; Fri, 19 Jul 2024 02:19:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5c669a0b5d1so791767eaf.3 for ; Thu, 18 Jul 2024 19:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721355564; x=1721960364; 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=HnXk6+VUbVJDgzVoMDRxwT3i0Gf54fkEdx6LY55RDAs=; b=P8Tk30dYljSM6fplQoFQ0t3DdGrml5nchcobsJ9GnNcluqZd8l/NwRwc9hV6lfIlPE rHpQYN1LyNZcAjqjmmuK4Y2EbdfUT7aHcBW3Bi93zB5tjaCC13PNFlP2C+ZmOiUzws0D EyjVOZBcm07vMwh1C05rVfpaP9Ato+cF3mPWM1IZzDA1Qyw7jP0ua/B7Mnn7WT4udq3r gnOtJ+UdwpPmwjo/RlOM7SA9I8ELhDsIAHR5zteg0TbkPzgb9SYkA3b6ccCbNiP3Qymf Y9gDigKdNA7+a35aTeZQk5TYkk4ldaZofux6TMK9FCdlZLGrA5BJfxMvS9H26/PIx20I APPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721355564; x=1721960364; 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=HnXk6+VUbVJDgzVoMDRxwT3i0Gf54fkEdx6LY55RDAs=; b=TzyGWQByCJ5ncscxKcCa5J9CqZHxg58wDuZ88OiVarEpln1OUthmpJ2igE+zDnxGN6 b/52e9Ib7ZTE9iqYID2vDP7gtREpaVz7qb7Svm2FVsZeyhHzxJc2CTm0NMi9T82rQYlM CehBVAMgwHbdIvG5dRbbOmAfsAOVPP+17mIPYLk5HD7DHZg0N/NHkZKM8ld7nO8IJEGP 7LmP/NyVBbzMtebXTNgk91pUdvHi1RlscRlAu+4YVsO4LHp23zKy1cSAkRxuyBABz4aK Xy/gKddrBuwFriSJuT680FaxlLNrVCvf7u7AQKz1RZJyzBQOKYPOZktv5J6PjFgKsbCP zgyg== X-Forwarded-Encrypted: i=1; AJvYcCXap5XxdYS7TR4jd+T1Pn+A1dNM6l5Je3cbM20ydva78TtZemOFsEtSiQEnqKstVr7uV2wrj5MxPsz7hCKX7o2kQ2R7aZ42ucKDvw== X-Gm-Message-State: AOJu0YwKouhOM05rw/RFW4eMKaop7sGAqp7vSMHlKvknbDsMSBaGw/uv LG+axkxD1W6ut1jzEKcNACHmRlccdYIaJev8t8KEHVIvvlWw0zfenBh7uSs1mZCkXM5n7OPqdKy DCWpsC57H04ib7sTSB7sBcrrMjBlvC5UYtdnf1V5Tziy1+4we X-Google-Smtp-Source: AGHT+IGsx89iV4gfdUq5S6u1sH1SZ1B1D/2pzWniX3pbfkB++GDmOK0ourd1qO8i7xoJIEAAd3Ddo0ylotAlxOTUWak= X-Received: by 2002:a05:6359:5a8f:b0:1aa:a01a:23da with SMTP id e5c5f4694b2df-1aca9f9c8aemr330161255d.27.1721355564236; Thu, 18 Jul 2024 19:19:24 -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> In-Reply-To: <01D917DB-7E47-46D7-AD22-AD09C4F89A96@FreeBSD.org> From: Warner Losh Date: Thu, 18 Jul 2024 20:19:12 -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="000000000000f06acc061d905292" 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: 4WQCzd4ThNz4YHg --000000000000f06acc061d905292 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 18, 2024, 7:10=E2=80=AFPM Zhenlei Huang wrot= e: > > > 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 incas= e > 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_e= nable=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. 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 i= n > the > ZFS pool label? > > > I think normally you do not need that. > > Best regards, > Zhenlei > > > --000000000000f06acc061d905292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 18, 2024, 7:10=E2=80=AFPM Zhenlei Huang &l= t;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 failur= e.

The implementation of load desired kernel is wr= ite loader parameters to /boot/nexboot.conf , to indicate
the loa= der(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=C2=A0<= span style=3D"color:rgb(0,0,0)">parameters by writing `nextboot_enable=3DNO` to =C2=A0/boot/nexboot.conf.

Tha= t is the magic. Apparently if loader(8) does not support write to filesyste= m, in this case the ZFS,=C2=A0
it will fail to write=C2=A0/b= oot/nexboot.conf in case kernel boot failure. Thus subsequent boot the load= er(8) would
still try to = boot from the oneshot `testkernel`.

However, ZFS has sp= ecial support via properties in the BE that lets you do boot once and nextb= oot stuff.

But even bett= er are boot environments. That's a more comple solution that supports b= ootnext features and more. See bectl...

Warner=C2=A0

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

That is impleme= ntation specific. Normally you can ignore the warning, unless you have trou= ble booting
the kernel.

<= div>

Also I suspect I should rather run "nextboot -D" to r= evert 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


--000000000000f06acc061d905292--