From nobody Sun Sep 8 03:16:01 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 4X1Zqf6XvRz5VN91 for ; Sun, 08 Sep 2024 03:16:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1Zqf2S5Hz4r9G for ; Sun, 8 Sep 2024 03:16:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4883G1Wa080155; Sun, 8 Sep 2024 12:16:02 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1725765363; bh=ME92OJIShjwd1tlk2/X3kR+Q1duYtr+YB/4xtmQoraE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=PuIdcX2cNGLumVwrz1WgZtj5Daf6nMjNTYJffzsYq8whs9BCSoirDsSa31Q3rWTJw vzhzxyh8tx1cTjvqYrj/ewcIEYJk/e382oJ3bWJiH67d/9kOqG6pnYUOmUNeizyBOd Q31puEsvISbd/gGiBdcYkPf27gQyIfvF0hbXf0Ko= Date: Sun, 8 Sep 2024 12:16:01 +0900 From: Tomoaki AOKI To: Mark Millard Cc: void , Current FreeBSD , Warner Losh 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> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4X1Zqf2S5Hz4r9G 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,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