Date: Thu, 28 Apr 2022 00:37:51 -0400 From: Zaphod Beeblebrox <zbeeble@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Larry Rosenman <ler@lerctr.org>, 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: <CACpH0Mc1pDptG9Ky=KSZNc5P7bVOkFtk=OoypGS6cMaZ-_n%2Bew@mail.gmail.com> In-Reply-To: <CANCZdfrJeqA9F%2BdZK%2Bqo7DJ=THhPhQR1usFmPSs7SNHO4Oefrg@mail.gmail.com> References: <2c2d774c-3677-c3b7-d099-71318743a434@zhegan.in> <20220427214502.f9ef1317f2911fb5247d1757@dec.sakura.ne.jp> <5914a66877e4799a405901b7c2c16505@lerctr.org> <CANCZdfrJeqA9F%2BdZK%2Bqo7DJ=THhPhQR1usFmPSs7SNHO4Oefrg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000c6694e05ddaf7d39 Content-Type: text/plain; charset="UTF-8" The point I want to reiterate, however, is this error is tossed out when my setup fails and the answer is a full powerdown of the motherboard --- after which the disks are adequately described. On Wed, Apr 27, 2022 at 9:26 AM Warner Losh <imp@bsdimp.com> wrote: > > > 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 > --000000000000c6694e05ddaf7d39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The point I want to reiterate, however, is this error is t= ossed out when my setup fails and the answer is a full powerdown of the mot= herboard --- after which the disks are adequately described.<br></div><br><= div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr= 27, 2022 at 9:26 AM Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@= bsdimp.com</a>> wrote:<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"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gm= ail_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" target=3D"_blank= ">ler@lerctr.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-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> </blockquote></div> --000000000000c6694e05ddaf7d39--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACpH0Mc1pDptG9Ky=KSZNc5P7bVOkFtk=OoypGS6cMaZ-_n%2Bew>