Date: Wed, 27 Apr 2022 07:25:29 -0600 From: Warner Losh <imp@bsdimp.com> To: Larry Rosenman <ler@lerctr.org> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, "Eugene M. Zheganin" <eugene@zhegan.in>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: FreeBSD boot from root pool larger than 1Tb/cannot read MOS/all block copies unavailable Message-ID: <CANCZdfrJeqA9F%2BdZK%2Bqo7DJ=THhPhQR1usFmPSs7SNHO4Oefrg@mail.gmail.com> In-Reply-To: <5914a66877e4799a405901b7c2c16505@lerctr.org> References: <2c2d774c-3677-c3b7-d099-71318743a434@zhegan.in> <20220427214502.f9ef1317f2911fb5247d1757@dec.sakura.ne.jp> <5914a66877e4799a405901b7c2c16505@lerctr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000e4bf0305dda2be2b Content-Type: text/plain; charset="UTF-8" On Wed, Apr 27, 2022 at 7:05 AM Larry Rosenman <ler@lerctr.org> wrote: > On 04/27/2022 7:45 am, Tomoaki AOKI wrote: > [snip] > > I've booting with around 1.5T or above (but under 2T) Root-on-ZFS > > installation via UEFI for years. > > > > Basically, UEFI requires GPT partitioning. So many of those would boot > > from larger than 1TB boot pool. > > > > As, IIRC, it is optional, some UEFI firmware would be able to boot from > > MBR-patritioned disk but there would be some risk that they have the > > same limitations as legacy BIOS in such situations. > > > > Note that possibly I'm just lucky enough not to be bitten. > > I've been booting UEFI from 10T pools for literally years, and I have a > HP server > with a 5T pool that IIRC boots GPT with BIOS, and a different Dell that > has a 6T > pool also GPT and UEFI. > Both bsdlabel and mbr have a 32-bit block count, which means for 512-byte blocks, the largest they can describe is 2TB. That's likely the root cause of this issue. The BIOS can't read beyond that limit on the disks. It's hit or miss what BIOSes do with 4k drives, though most of the later ones before uefi was well established coped well enough. This isn't to say that the old code in FreeBSD 12's boot loader didn't have other issues with LBAs > 32-bits for ZFS. And for MBR ZFS booting the update of the boot blocks is, at best, super weird. If you've not done that, you'll continue to have the older boot loader, even if the latest just works. I've never encountered this problem, so I can't offer better words of advice, though. All my ZFS booting started after I transitioned to UEFI booting. Warner --000000000000e4bf0305dda2be2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 27, 2022 at 7:05 AM Larry= Rosenman <<a href=3D"mailto:ler@lerctr.org">ler@lerctr.org</a>> wrot= e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04/27/2022= 7:45 am, Tomoaki AOKI wrote:<br> [snip]<br> > I've booting with around 1.5T or above (but under 2T) Root-on-ZFS<= br> > installation via UEFI for years.<br> > <br> > Basically, UEFI requires GPT partitioning. So many of those would boot= <br> > from larger than 1TB boot pool.<br> > <br> > As, IIRC, it is optional, some UEFI firmware would be able to boot fro= m<br> > MBR-patritioned disk but there would be some risk that they have the<b= r> > same limitations as legacy BIOS in such situations.<br> > <br> > Note that possibly I'm just lucky enough not to be bitten.<br> <br> I've been booting UEFI from 10T pools for literally years, and I have a= <br> HP server<br> with a 5T pool that IIRC boots GPT with BIOS, and a different Dell that <br= > has a 6T<br> pool also GPT and UEFI.<br></blockquote><div><br></div><div>Both bsdlabel a= nd mbr have a 32-bit block count, which means for 512-byte</div><div>blocks= , the largest they can describe is 2TB. That's likely the root cause</d= iv><div>of this issue. The BIOS can't read beyond that limit on the dis= ks. It's hit or</div><div>miss what BIOSes do with 4k drives, though mo= st of the later ones before</div><div>uefi was well established coped well = enough.</div><div><br></div><div>This isn't to say that the old code in= FreeBSD 12's boot loader didn't have</div><div>other issues with L= BAs > 32-bits for ZFS. And for MBR ZFS booting the</div><div>update of t= he boot blocks is, at best, super weird. If you've not done that,</div>= <div>you'll continue to have the older boot loader, even if the latest = just works.</div><div>I've never encountered this problem, so I can'= ;t offer better words of advice,</div><div>though. All my ZFS booting start= ed after I transitioned to UEFI booting.</div><div><br></div><div>Warner</d= iv></div></div> --000000000000e4bf0305dda2be2b--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrJeqA9F%2BdZK%2Bqo7DJ=THhPhQR1usFmPSs7SNHO4Oefrg>