Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Sep 2024 12:16:01 +0900
From:      Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
To:        Mark Millard <marklmi@yahoo.com>
Cc:        void <void@f-m.fm>, Current FreeBSD <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com>
Subject:   Re: Loader needs to be updated message
Message-ID:  <20240908121601.2cb0dd605bf1669028c4b4ae@dec.sakura.ne.jp>
In-Reply-To: <082B95C0-8D03-40E6-A5DD-EA8723FA9AF3@yahoo.com>
References:  <082B95C0-8D03-40E6-A5DD-EA8723FA9AF3.ref@yahoo.com> <082B95C0-8D03-40E6-A5DD-EA8723FA9AF3@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 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,0x82000)
> > > 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 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,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/gptboot
> -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
> 
> 
> ===
> 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.

-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240908121601.2cb0dd605bf1669028c4b4ae>