From nobody Sun Sep 08 03:31:21 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 4X1b9N094Dz5VQRy for ; Sun, 08 Sep 2024 03:31:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 4X1b9M28Xxz4ty8 for ; Sun, 8 Sep 2024 03:31:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2d87196ec9fso2215077a91.1 for ; Sat, 07 Sep 2024 20:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725766293; x=1726371093; 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=F/5T/GNtAodssMWVN+rmJ2DzYvIu41e8vquKkOzdfAg=; b=Q886N7hkT1NA6VJSKWbSKOVrPlKQ8MI9caCg5eQpqLcZ8EtxDknBfKPPhzLvOGS/31 tme68Cic7O0/O+0ytw3HwoJI+sr/QU1QAgMa/6hpLN+80hzHpjeLzr5/lgE++WtaFIkO SsBNDAKCjKh4SgvkE4Xwqz8gsCxmBkD84/7A9oerbrNKU71+6ojsqyfOlFF9qHrmkp6F i+pppuoUX9Oi1KqklFGtax/oViCCE0DRUnKjgFStQazDFIIqN37LEDYIuAFOEGegJbm5 oxpMv2VwqiWshl+tRi+2qVCc/naCILEgp1gy4LvXx1+apdHux/OG+8YhnP2itrAWXF7v PC+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725766293; x=1726371093; 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=F/5T/GNtAodssMWVN+rmJ2DzYvIu41e8vquKkOzdfAg=; b=u9mvlb1PlD1RWMlsKTdkKdN7KLZESXfUrtRBbIvEu+fs+ewqjZAmr8cXcmSWxbu/rm ok/4sRF7R8xtGC3j48nRq6huo69ClsqnoWyDHv2DfXHTminVxnVr9eV5H72IQ3xs7eHg QzmZMFmWkWeSjYAXV/T0iKwWFwWJQsn/kIY3EMjNmbYnhGHHiCRSmC6JkjN2exroVtiA /4udIwQnQKVlvw6LBTXmf5NiN1110Tms8h3OqhlYLjOn9C8mIuMGYvATOa01a6sKyBxD voV9AEpAIn0yl+j2gvKQmOGRNSZ0dvCBA8xg8EnQKt94SVwdx5lvZNsJeXcnhcYl3s13 D/iQ== X-Forwarded-Encrypted: i=1; AJvYcCU2L+qDviyVueEwilkeN9q7IpYoBjl3kLwwD/3fzVDc7ioiwDkBfclN3iqc9heiIAfov23zwZUqzBIwnlLf0Js=@freebsd.org X-Gm-Message-State: AOJu0YxAPMvUpxLmHh1DiY0/nNQNucaekcRip/QdEcZolO2hBhmSWZ39 5goaOl7Spf1P+127tWiG2H43HziB2UM9LTWXham5+ook5DjTiKHHTKt6BILOcfq+u3JhrJnYymr E5WY7aBBaGX31VpQMH2gVv/zaEUL6eevHIYDc0EftK0HKknnV X-Google-Smtp-Source: AGHT+IFWiKQoTMwEGpHDYJZqBFJ+FxxHU6+ED1+o3KjD0MeH3Q0ShetnUpw6pqWeWsLhE88HE4V/sMkuKFBOEd+7juw= X-Received: by 2002:a17:90a:f48b:b0:2c1:9892:8fb with SMTP id 98e67ed59e1d1-2dad4de4c5bmr7225975a91.5.1725766293114; Sat, 07 Sep 2024 20:31:33 -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: <082B95C0-8D03-40E6-A5DD-EA8723FA9AF3.ref@yahoo.com> <082B95C0-8D03-40E6-A5DD-EA8723FA9AF3@yahoo.com> <20240908121601.2cb0dd605bf1669028c4b4ae@dec.sakura.ne.jp> In-Reply-To: <20240908121601.2cb0dd605bf1669028c4b4ae@dec.sakura.ne.jp> From: Warner Losh Date: Sat, 7 Sep 2024 21:31:21 -0600 Message-ID: Subject: Re: Loader needs to be updated message To: Tomoaki AOKI Cc: Mark Millard , void , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000ddf0bd06219346a4" 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: 4X1b9M28Xxz4ty8 --000000000000ddf0bd06219346a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 7, 2024, 9:16=E2=80=AFPM Tomoaki AOKI wrote: > On Sat, 7 Sep 2024 19:38:47 -0700 > Mark Millard wrote: > > > void wrote on > > Date: Sat, 07 Sep 2024 17:27:00 UTC : > > > > > On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote: > > > > > > >I'm more interested in what is there than just what is not > > > >there. May be show something analogous to: > > > > > > > ># gpart list | grep -E '(Name|type|efi|media)' > > > >1. Name: mmcsd1s1 > > > > efimedia: HD(1,MBR,00000000,0x8000,0x3b68000) > > > > rawtype: 12 > > > > type: fat32lba > > > >1. Name: mmcsd1 > > > >1. Name: da0p1 > > > > efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28,0x8200= 0) > > > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > > label: BPIM3efi > > > > type: efi > > > >2. Name: da0p2 > > > > efimedia: > HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82800,0x366000) > > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > > type: freebsd-swap > > > >3. Name: da0p3 > > > > efimedia: > HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x6861c800,0x732800) > > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > > type: freebsd-swap > > > >4. Name: da0p4 > > > > efimedia: > HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1c800,0x67c00000) > > > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > > > > type: freebsd-ufs > > > >1. Name: da0 > > > > > > > >I'll note that on various type of systems, the (effectively) > > > >ESP need not be specifically of "type: efi", possibly some > > > >fat variant instead also works. (Of course, EFI need not be > > > >the only alternative for various type of contexts.) > > > > > > > >I'll note the /boot/efi is normally just an empty directory > > > >that is possibly used as a mount point. > > > > > > > >In some (somewhat older) configurations /boot/msdos is > > > >similarly an empty directory and possibly used as the mount > > > >point instead. > > > > > > > >> After source building to latest stable in the usual way, same erro= r > message 'loader needs updating'. > > > > > > This is on the guest > > > > > > # gpart list | grep -E '(Name|type|efi|media)' > > > 1. Name: vtbd0p1 > > > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400) > > > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f > > > type: freebsd-boot > > > > As I understand it, that "type: freebsd-boot" means that one of > > the likes of: > > > > # ls -lodT /boot/gpt*boot* > > -r--r--r-- 1 root wheel uarch 62139 Apr 7 15:55:46 2024 /boot/gptboo= t > > -r-xr-xr-x 1 root wheel uarch 109568 Apr 7 15:55:46 2024 > /boot/gptboot.efi > > -r--r--r-- 1 root wheel uarch 176062 Apr 8 01:15:54 2024 > /boot/gptzfsboot > > > > is in use inside that freebsd-boot partition (vtbd0p1). But only > > one of those supports zfs. > > > > Fair warning that I never use any of those 3 --nor freebsd-boot > > partitions. Nor have I ever used Bhyve. Do not blindly believe what I > > report here. But hopefully it points in a useful direction to > > initially investigate. > > > > Looking at: > > > > "man 8 gptboot.efi" indicates that "gptboot.efi works only with UFS > > root file systems". > > > > "man 8 gptboot" indicates that "gptboot is used on BIOS-based > > computers to boot from a UFS partition on a GPT-partitioned disk". > > > > BUT "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based > > computers to boot from a filesystem in a ZFS pool". > > > > So the partitioning is not set up for supporting the combination of: > > EFI and ZFS-for-root-filesystem: if the gptzfsboot is used then it > > needs to be old style BIOS-and-ZFS for the context. > > > > So my expectation here is that the gptzfsboot content in use in > > vtbd0p1 (i.e. -i 1 vtbd0 in some commands) is out of date and needs > > to be updated. To my knowledge, there is no simple technique to look > > up the vintage present in -i 1 vtbd0 . > > > > I have no clue which of the following should be used for your context > > to be sure that the content ends up up to date: > > > > The Protective MBR variant: > > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 > > > > The variant for without the Protective MBR: > > # gpart bootcode -p /boot/gptzfsboot -i 1 vtbd0 > > > > Those commands are adjusted variations of what the man page's EXAMPLES > > section shows, but not using the 2 example's ada0 notation. > > > > > 2. Name: vtbd0p2 > > > efimedia: > HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x2000000) > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > type: freebsd-swap > > > 3. Name: vtbd0p3 > > > efimedia: > HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000) > > > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b > > > type: freebsd-zfs > > > 1. Name: vtbd0 > > > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > FYI: > boot1.efi works with ZFS. gptboot.efi is basically the one which > stripped ZFS-related codes from boot1.efi. > > And IIUC, boot1.efi shares most codes with loader.efi (except for its > own FS module wrapper as a consumer, implemented for UFS and ZFS). > > It would be deleted in the future (that is your plan, Warner?), > but currently still usable. > That's the plan. There's a number of advanced features it doesn't support and it doubles the effort for many things.. However it insulates one from loader.efi changes... which some people use..= . Warner --=20 > Tomoaki AOKI > --000000000000ddf0bd06219346a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Sep 7, 2024, 9:16=E2=80=AFPM Tomoaki AOKI <= junchoon@dec.sakura.ne.jp&= gt; wrote:
On Sat, 7 Sep 2024 19:38= :47 -0700
Mark Millard <marklmi@yahoo.com> wrote:

> void <void_at_f-m.fm> wrote on
> Date: Sat, 07 Sep 2024 17:27:00 UTC :
>
> > On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote:
> >
> > >I'm more interested in what is there than just what is no= t
> > >there. May be show something analogous to:
> > >
> > ># gpart list | grep -E '(Name|type|efi|media)'
> > >1. Name: mmcsd1s1
> > > efimedia: HD(1,MBR,00000000,0x8000,0x3b68000)
> > > rawtype: 12
> > > type: fat32lba
> > >1. Name: mmcsd1
> > >1. Name: da0p1
> > > efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28= ,0x82000)
> > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
> > > label: BPIM3efi
> > > type: efi
> > >2. Name: da0p2
> > > efimedia: HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82= 800,0x366000)
> > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-swap
> > >3. Name: da0p3
> > > efimedia: HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x68= 61c800,0x732800)
> > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-swap
> > >4. Name: da0p4
> > > efimedia: HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1= c800,0x67c00000)
> > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-ufs
> > >1. Name: da0
> > >
> > >I'll note that on various type of systems, the (effective= ly)
> > >ESP need not be specifically of "type: efi", possib= ly some
> > >fat variant instead also works. (Of course, EFI need not be > > >the only alternative for various type of contexts.)
> > >
> > >I'll note the /boot/efi is normally just an empty directo= ry
> > >that is possibly used as a mount point.
> > >
> > >In some (somewhat older) configurations /boot/msdos is
> > >similarly an empty directory and possibly used as the mount > > >point instead.
> > >
> > >> After source building to latest stable in the usual way,= same error message 'loader needs updating'.
> >
> > This is on the guest
> >
> > # gpart list | grep -E '(Name|type|efi|media)'
> > 1. Name: vtbd0p1
> > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x40= 0)
> > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
> > type: freebsd-boot
>
> As I understand it, that "type: freebsd-boot" means that one= of
> the likes of:
>
> # ls -lodT /boot/gpt*boot*
> -r--r--r--=C2=A0 1 root wheel uarch=C2=A0 62139 Apr=C2=A0 7 15:55:46 2= 024 /boot/gptboot
> -r-xr-xr-x=C2=A0 1 root wheel uarch 109568 Apr=C2=A0 7 15:55:46 2024 /= boot/gptboot.efi
> -r--r--r--=C2=A0 1 root wheel uarch 176062 Apr=C2=A0 8 01:15:54 2024 /= boot/gptzfsboot
>
> is in use inside that freebsd-boot partition (vtbd0p1). But only
> one of those supports zfs.
>
> Fair warning that I never use any of those 3 --nor freebsd-boot
> partitions. Nor have I ever used Bhyve. Do not blindly believe what I<= br> > report here. But hopefully it points in a useful direction to
> initially investigate.
>
> Looking at:
>
> "man 8 gptboot.efi" indicates that "gptboot.efi works o= nly with UFS
> root file systems".
>
> "man 8 gptboot" indicates that "gptboot is used on BIOS= -based
> computers to boot from a UFS partition on a GPT-partitioned disk"= .
>
> BUT "man 8 gptzfsboot" indicates "gptzfsboot is used on= BIOS-based
> computers to boot from a filesystem in a ZFS pool".
>
> So the partitioning is not set up for supporting the combination of: > EFI and ZFS-for-root-filesystem: if the gptzfsboot is used then it
> needs to be old style BIOS-and-ZFS for the context.
>
> So my expectation here is that the gptzfsboot content in use in
> vtbd0p1 (i.e. -i 1 vtbd0 in some commands) is out of date and needs > to be updated. To my knowledge, there is no simple technique to look > up the vintage present in -i 1 vtbd0 .
>
> I have no clue which of the following should be used for your context<= br> > to be sure that the content ends up up to date:
>
> The Protective MBR variant:
> # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0
>
> The variant for without the Protective MBR:
> # gpart bootcode -p /boot/gptzfsboot -i 1 vtbd0
>
> Those commands are adjusted variations of what the man page's EXAM= PLES
> section shows, but not using the 2 example's ada0 notation.
>
> > 2. Name: vtbd0p2
> > efimedia: HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x2= 000000)
> > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-swap
> > 3. Name: vtbd0p3
> > efimedia: HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800= ,0xdfff000)
> > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-zfs
> > 1. Name: vtbd0
>
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com

FYI:
boot1.efi works with ZFS. gptboot.efi is basically the one which
stripped ZFS-related codes from boot1.efi.

And IIUC, boot1.efi shares most codes with loader.efi (except for its
own FS module wrapper as a consumer, implemented for UFS and ZFS).

It would be deleted in the future (that is your plan, Warner?),
but currently still usable.
<= br>
That's the plan. There's a number of adv= anced features it doesn't support and it doubles the effort for many th= ings..

However it insula= tes one from loader.efi changes... which some people use...

Warner=C2=A0
<= br>
--
Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>
--000000000000ddf0bd06219346a4--