Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 2026 17:53:00 +0100
From:      Martin Matuska <mm@FreeBSD.org>
To:        Warner Losh <imp@bsdimp.com>, Shawn Webb <shawn.webb@hardenedbsd.org>
Cc:        A FreeBSD User <freebsd@walstatt-de.de>, Charlie Li <vishwin@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, "<dev-commits-src-main@freebsd.org>" <dev-commits-src-main@freebsd.org>
Subject:   Re: git: 8a62a2a5659d - main - zfs: merge openzfs/zfs@f8e5af53e
Message-ID:  <1268de25-55c7-4dd8-995c-4521ef0f4c13@FreeBSD.org>
In-Reply-To: <CANCZdfrEppttf%2Btu%2BvpHKGd8ikSBpPJ=38cpE%2BsRzD1AjRpFhQ@mail.gmail.com>
References:  <69b561ff.39ea9.b797d91@gitrepo.freebsd.org> <2jb2vg6baofimu5xkxf62o5ogaq7fu5pk4o3vzhpegy446bppf@fzwtj6wtwk53> <CANCZdfpaKyzMDL0%2BMk3tSEeqsSU_C-OoWo1Dwwjg%2BG%2BrxiV2Eg@mail.gmail.com> <hqup3oiorbdgvtputen566fcajjoucurqpk7je6qchixat3i6c@zmfpxouvy7vs> <wryftbwxvsc3mhm6iglbx3ikzentaoewo3ldiw4knyqkckmhmo@hnmn3nosgawc> <becfc71c-2ea1-4a13-a3b1-3235f056badf@freebsd.org> <20260321090444.6f81da15@thor.sb211.local> <qeang5o4tlutdyxu2zfksbpljrrvf22eebf6r7b62umffzaymn@or5qwqnmbtbx> <CANCZdfq7YQuzgavRWm=DMKEvxQE9cYOFAEMpgk6faQwOL2tC2Q@mail.gmail.com> <5eaaokkdmmkcojky7362jvkandaard6eu26n77f5z5q7lqutu5@kywp5prvxozj> <CANCZdfrEppttf%2Btu%2BvpHKGd8ikSBpPJ=38cpE%2BsRzD1AjRpFhQ@mail.gmail.com>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
What has changed is bundled ZSTD.

Maybe providing a MBR boot loader without ZFS-ZSTD support?

Best regards,
mm

On 21. 3. 2026 16:30, Warner Losh wrote:
>
>
> On Sat, Mar 21, 2026 at 9:23 AM Shawn Webb 
> <shawn.webb@hardenedbsd.org> wrote:
>
>     On Sat, Mar 21, 2026 at 09:18:20AM -0600, Warner Losh wrote:
>     > On Sat, Mar 21, 2026, 9:08 AM Shawn Webb
>     <shawn.webb@hardenedbsd.org> wrote:
>     >
>     > > On Sat, Mar 21, 2026 at 09:04:17AM +0100, A FreeBSD User wrote:
>     > > > Am Tage des Herren Fri, 20 Mar 2026 23:27:20 -0400
>     > > > Charlie Li <vishwin@freebsd.org> schrieb:
>     > > >
>     > > > > Shawn Webb wrote:
>     > > > > > On Tue, Mar 17, 2026 at 04:52:16PM +0000, Shawn Webb wrote:
>     > > > > >> On Tue, Mar 17, 2026 at 10:44:59AM -0600, Warner Losh
>     wrote:
>     > > > > >>> On Tue, Mar 17, 2026 at 10:36 AM Shawn Webb <
>     > > shawn.webb@hardenedbsd.org>
>     > > > > >>> wrote:
>     > > > > >>>
>     > > > > >>>> Hey Martin,
>     > > > > >>>>
>     > > > > >>>> On Sat, Mar 14, 2026 at 01:26:23PM +0000, Martin
>     Matuska wrote:
>     > > > > >>>>> The branch main has been updated by mm:
>     > > > > >>>>>
>     > > > > >>>>> URL:
>     > > > > >>>>
>     > >
>     https://cgit.FreeBSD.org/src/commit/?id=8a62a2a5659d1839d8799b4274c04469d7f17c78
>     <https://cgit.FreeBSD.org/src/commit/?id=8a62a2a5659d1839d8799b4274c04469d7f17c78>;
>     > >
>     > > > > >>>>>
>     > > > > >>>>> commit 8a62a2a5659d1839d8799b4274c04469d7f17c78
>     > > > > >>>>> Merge: f91464171d61 f8e5af53e92f
>     > > > > >>>>> Author:     Martin Matuska <mm@FreeBSD.org>
>     > > > > >>>>> AuthorDate: 2026-03-14 12:14:56 +0000
>     > > > > >>>>> Commit:     Martin Matuska <mm@FreeBSD.org>
>     > > > > >>>>> CommitDate: 2026-03-14 12:14:56 +0000
>     > > > > >>>>>
>     > > > > >>>>> [snip for brevity]
>     > > > > >>>>>
>     > > > > >>>>>      Obtained from:  OpenZFS
>     > > > > >>>>>      OpenZFS commit:
>     f8e5af53e92fa7c03393fbd4922cb9c1d0c15920
>     > > > > >>>>
>     > > > > >>>> This commit seems to cause issues when building boot
>     loader
>     > > related
>     > > > > >>>> code:
>     > > > > >>>>
>     > > > > >>>> ==== BEGIN LOG ====
>     > > > > >>>> 114232 bytes available
>     > > > > >>>> btxld -v -f aout -e 0x200000 -o loader_simp -l
>     > > > > >>>>
>     /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btxldr/btxldr -b
>     > > > > >>>> /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx
>     > > loader_simp.bin
>     > > > > >>>> kernel: ver=1.02 size=690 load=9000 entry=9010
>     map=16M pgctl=0:58
>     > > > > >>>> client: fmt=elf size=5e2e8 text=57930 data=514c
>     bss=7470 entry=0
>     > > > > >>>> output: fmt=aout size=61000 text=1000 data=5f000
>     org=200000
>     > > entry=200000
>     > > > > >>>> ===> stand/i386/pxeldr (all)
>     > > > > >>>> -560 bytes available
>     > > > > >>>> *** Error code 1
>     > > > > >>>>
>     > > > > >>>
>     > > > > >>> What all do you have enabled? The defaults aren't even
>     close to
>     > > running out
>     > > > > >>> of space (though I've not looked at this).
>     > > > > >>
>     > > > > >> Hey Warner,
>     > > > > >>
>     > > > > >> Thanks for reaching out! I've uploaded `make
>     showconfig` here:
>     > > > > >> https://hardenedbsd.org/~shawn/2026-03-17_srcconf-r01.txt
>     > > > > >>
>     > > > > >> The following options are specific to HardenedBSD (in
>     no particular
>     > > > > >> order):
>     > > > > >>
>     > > > > >> 1. MK_HBSD_UPDATE
>     > > > > >> 2. MK_HBSDCONTROL
>     > > > > >> 3. MK_PIE
>     > > > > >> 4. MK_RELRO
>     > > > > >> 5. MK_SHLIBRANDOM
>     > > > > >> 6. MK_ZERO_REGS
>     > > > > >> 7. MK_SPECTREV1_FIX
>     > > > > >> 8. MK_SAFESTACK
>     > > > > >> 9. MK_RETPOLINE
>     > > > > >> 10. MK_LTOLIB
>     > > > > >> 11. MK_CFI
>     > > > > >
>     > > > > > MK_RETPOLINE was the culprit. Something about this ZFS
>     commit causes
>     > > > > > LLVM to emit more retpoline entries than before--too
>     many for a
>     > > little
>     > > > > > bootloader. That might be something to investigate
>     later, but only to
>     > > > > > satisfy a curious mind, not to actuall fix anything
>     (since nothing's
>     > > > > > actually broken.)
>     > > > > >
>     > > > > > Since it doesn't really make sense to apply speculative
>     execution
>     > > > > > mitigations to a bootloader, I disabled retpoline for a
>     components
>     > > > > > in stand/.
>     > > > > >
>     > > > > > Good to go.
>     > > > > >
>     > > > > Also just got bit by this, albeit during the lua loader,
>     since I have
>     > > > > WITH_RETPOLINE in my src.conf.
>     > > > >
>     > > >
>     > > > Hello,
>     > > >
>     > > > I do not have WITH_RETPOLINE in my /etc/src.conf, but since
>     I got this
>     > > mysterious error about
>     > > > not enough bytes left, I use WITHOUT_LOADER_PXEBOOT= YES
>     (due to issues
>     > > with WITH_BEARSSL=YES
>     > > > also used).
>     > > > Despite not using any WITH_RETPOLINE I also catch the error ...
>     > >
>     > > Something about this ZFS commit causes the boot laoder to be
>     too big.
>     > > I guess the first sign of trouble was with retpolines, but
>     there seem
>     > > to now be additional signs.
>     > >
>     > > What's the process for filing a bug report against OpenzFS for
>     > > something like this? (Not asking you directly, just a general
>     question
>     > > for the thread.)
>     > >
>     >
>     > That's a good question. We are rapidly aporoaching the day we
>     will have to
>     > freeze the set of zfs feature that we can boot with the BIOS
>     path. There's
>     > only so much space.
>     >
>     > Right now,  there's little to no bootloader testing, let alone
>     analysis
>     > done and that will need to change.
>
>     Another question might also be: is it worth the time and effort? Are
>     people really using a ZFS-enabled traditional MBR BIOS bootloader on
>     FreeBSD 16-CURRENT (or eventual 16.0-RELEASE)? From my rather naive
>     (and ignorant, since I don't know FreeBSD's userbase well), it seems
>     like folks use either loader.efi or u-boot (or both!)
>
>
> Nobody uses MBR BIOS bootloader. It's totally unsupported. They all 
> use the
> GPT one, which is used for all kinds of things, most recently several 
> light-weight
> VM systems that don't have UEFI. BIOS is what imposes the limit, not MBR.
>
> But there's a huge number of systems that are already in the field 
> that need
> to be upgradeable, but we will eventually need to draw a line in the 
> sand for
> that.
>
>     Not a question I can answer, of course, because everyone likely has a
>     different take on what "worth the time and effort" means to them. :-)
>
>
> Yea, the BIOS path is stubbornly hanging around.
>
> Warner
>
>     Thanks,
>
>     -- 
>     Shawn Webb
>     Cofounder / Security Engineer
>     HardenedBSD
>
>     Signal Username:  shawn_webb.74
>     Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
>     https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
>
[-- Attachment #2 --]
<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>What has changed is bundled ZSTD.</p>
    <p>Maybe providing a MBR boot loader without ZFS-ZSTD support?<br>
      <br>
      Best regards,<br>
      mm</p>
    <div class="moz-cite-prefix">On 21. 3. 2026 16:30, Warner Losh
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANCZdfrEppttf+tu+vpHKGd8ikSBpPJ=38cpE+sRzD1AjRpFhQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <br>
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr" class="gmail_attr">On Sat, Mar 21, 2026 at
            9:23 AM Shawn Webb &lt;<a
              href="mailto:shawn.webb@hardenedbsd.org"
              moz-do-not-send="true" class="moz-txt-link-freetext">shawn.webb@hardenedbsd.org</a>&gt;
            wrote:<br>
          </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
            Sat, Mar 21, 2026 at 09:18:20AM -0600, Warner Losh wrote:<br>
            &gt; On Sat, Mar 21, 2026, 9:08 AM Shawn Webb &lt;<a
              href="mailto:shawn.webb@hardenedbsd.org" target="_blank"
              moz-do-not-send="true" class="moz-txt-link-freetext">shawn.webb@hardenedbsd.org</a>&gt;
            wrote:<br>
            &gt; <br>
            &gt; &gt; On Sat, Mar 21, 2026 at 09:04:17AM +0100, A
            FreeBSD User wrote:<br>
            &gt; &gt; &gt; Am Tage des Herren Fri, 20 Mar 2026 23:27:20
            -0400<br>
            &gt; &gt; &gt; Charlie Li &lt;<a
              href="mailto:vishwin@freebsd.org" target="_blank"
              moz-do-not-send="true" class="moz-txt-link-freetext">vishwin@freebsd.org</a>&gt;
            schrieb:<br>
            &gt; &gt; &gt;<br>
            &gt; &gt; &gt; &gt; Shawn Webb wrote:<br>
            &gt; &gt; &gt; &gt; &gt; On Tue, Mar 17, 2026 at 04:52:16PM
            +0000, Shawn Webb wrote:<br>
            &gt; &gt; &gt; &gt; &gt;&gt; On Tue, Mar 17, 2026 at
            10:44:59AM -0600, Warner Losh wrote:<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt; On Tue, Mar 17, 2026 at
            10:36 AM Shawn Webb &lt;<br>
            &gt; &gt; <a href="mailto:shawn.webb@hardenedbsd.org"
              target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">shawn.webb@hardenedbsd.org</a>&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt; wrote:<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Hey Martin,<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; On Sat, Mar 14, 2026 at
            01:26:23PM +0000, Martin Matuska wrote:<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; The branch main has
            been updated by mm:<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; URL:<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;<br>
            &gt; &gt; <a
href="https://cgit.FreeBSD.org/src/commit/?id=8a62a2a5659d1839d8799b4274c04469d7f17c78"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://cgit.FreeBSD.org/src/commit/?id=8a62a2a5659d1839d8799b4274c04469d7f17c78</a><br>;
            &gt; &gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; commit
            8a62a2a5659d1839d8799b4274c04469d7f17c78<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; Merge: f91464171d61
            f8e5af53e92f<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; Author:     Martin
            Matuska <a class="moz-txt-link-rfc2396E" href="mailto:mm@FreeBSD.org">&lt;mm@FreeBSD.org&gt;</a><br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; AuthorDate:
            2026-03-14 12:14:56 +0000<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; Commit:     Martin
            Matuska <a class="moz-txt-link-rfc2396E" href="mailto:mm@FreeBSD.org">&lt;mm@FreeBSD.org&gt;</a><br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; CommitDate:
            2026-03-14 12:14:56 +0000<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; [snip for brevity]<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;      Obtained
            from:  OpenZFS<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;      OpenZFS
            commit: f8e5af53e92fa7c03393fbd4922cb9c1d0c15920<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; This commit seems to
            cause issues when building boot loader<br>
            &gt; &gt; related<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; code:<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; ==== BEGIN LOG ====<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; 114232 bytes available<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; btxld -v -f aout -e
            0x200000 -o loader_simp -l<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;
            /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btxldr/btxldr 
            -b<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;
            /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx<br>
            &gt; &gt; loader_simp.bin<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; kernel: ver=1.02
            size=690 load=9000 entry=9010 map=16M pgctl=0:58<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; client: fmt=elf
            size=5e2e8 text=57930 data=514c bss=7470 entry=0<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; output: fmt=aout
            size=61000 text=1000 data=5f000 org=200000<br>
            &gt; &gt; entry=200000<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; ===&gt;
            stand/i386/pxeldr (all)<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; -560 bytes available<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; *** Error code 1<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt; What all do you have
            enabled? The defaults aren't even close to<br>
            &gt; &gt; running out<br>
            &gt; &gt; &gt; &gt; &gt;&gt;&gt; of space (though I've not
            looked at this).<br>
            &gt; &gt; &gt; &gt; &gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt; Hey Warner,<br>
            &gt; &gt; &gt; &gt; &gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt; Thanks for reaching out! I've
            uploaded `make showconfig` here:<br>
            &gt; &gt; &gt; &gt; &gt;&gt; <a
href="https://hardenedbsd.org/~shawn/2026-03-17_srcconf-r01.txt"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">https://hardenedbsd.org/~shawn/2026-03-17_srcconf-r01.txt</a><br>;
            &gt; &gt; &gt; &gt; &gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt; The following options are
            specific to HardenedBSD (in no particular<br>
            &gt; &gt; &gt; &gt; &gt;&gt; order):<br>
            &gt; &gt; &gt; &gt; &gt;&gt;<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 1. MK_HBSD_UPDATE<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 2. MK_HBSDCONTROL<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 3. MK_PIE<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 4. MK_RELRO<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 5. MK_SHLIBRANDOM<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 6. MK_ZERO_REGS<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 7. MK_SPECTREV1_FIX<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 8. MK_SAFESTACK<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 9. MK_RETPOLINE<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 10. MK_LTOLIB<br>
            &gt; &gt; &gt; &gt; &gt;&gt; 11. MK_CFI<br>
            &gt; &gt; &gt; &gt; &gt;<br>
            &gt; &gt; &gt; &gt; &gt; MK_RETPOLINE was the culprit.
            Something about this ZFS commit causes<br>
            &gt; &gt; &gt; &gt; &gt; LLVM to emit more retpoline entries
            than before--too many for a<br>
            &gt; &gt; little<br>
            &gt; &gt; &gt; &gt; &gt; bootloader. That might be something
            to investigate later, but only to<br>
            &gt; &gt; &gt; &gt; &gt; satisfy a curious mind, not to
            actuall fix anything (since nothing's<br>
            &gt; &gt; &gt; &gt; &gt; actually broken.)<br>
            &gt; &gt; &gt; &gt; &gt;<br>
            &gt; &gt; &gt; &gt; &gt; Since it doesn't really make sense
            to apply speculative execution<br>
            &gt; &gt; &gt; &gt; &gt; mitigations to a bootloader, I
            disabled retpoline for a components<br>
            &gt; &gt; &gt; &gt; &gt; in stand/.<br>
            &gt; &gt; &gt; &gt; &gt;<br>
            &gt; &gt; &gt; &gt; &gt; Good to go.<br>
            &gt; &gt; &gt; &gt; &gt;<br>
            &gt; &gt; &gt; &gt; Also just got bit by this, albeit during
            the lua loader, since I have<br>
            &gt; &gt; &gt; &gt; WITH_RETPOLINE in my src.conf.<br>
            &gt; &gt; &gt; &gt;<br>
            &gt; &gt; &gt;<br>
            &gt; &gt; &gt; Hello,<br>
            &gt; &gt; &gt;<br>
            &gt; &gt; &gt; I do not have WITH_RETPOLINE in my
            /etc/src.conf, but since I got this<br>
            &gt; &gt; mysterious error about<br>
            &gt; &gt; &gt; not enough bytes left, I use
            WITHOUT_LOADER_PXEBOOT= YES (due to issues<br>
            &gt; &gt; with WITH_BEARSSL=YES<br>
            &gt; &gt; &gt; also used).<br>
            &gt; &gt; &gt; Despite not using any WITH_RETPOLINE I also
            catch the error ...<br>
            &gt; &gt;<br>
            &gt; &gt; Something about this ZFS commit causes the boot
            laoder to be too big.<br>
            &gt; &gt; I guess the first sign of trouble was with
            retpolines, but there seem<br>
            &gt; &gt; to now be additional signs.<br>
            &gt; &gt;<br>
            &gt; &gt; What's the process for filing a bug report against
            OpenzFS for<br>
            &gt; &gt; something like this? (Not asking you directly,
            just a general question<br>
            &gt; &gt; for the thread.)<br>
            &gt; &gt;<br>
            &gt; <br>
            &gt; That's a good question. We are rapidly aporoaching the
            day we will have to<br>
            &gt; freeze the set of zfs feature that we can boot with the
            BIOS path. There's<br>
            &gt; only so much space.<br>
            &gt; <br>
            &gt; Right now,  there's little to no bootloader testing,
            let alone analysis<br>
            &gt; done and that will need to change.<br>
            <br>
            Another question might also be: is it worth the time and
            effort? Are<br>
            people really using a ZFS-enabled traditional MBR BIOS
            bootloader on<br>
            FreeBSD 16-CURRENT (or eventual 16.0-RELEASE)? From my
            rather naive<br>
            (and ignorant, since I don't know FreeBSD's userbase well),
            it seems<br>
            like folks use either loader.efi or u-boot (or both!)<br>
          </blockquote>
          <div><br>
          </div>
          <div>Nobody uses MBR BIOS bootloader. It's totally
            unsupported. They all use the</div>
          <div>GPT one, which is used for all kinds of things, most
            recently several light-weight</div>
          <div>VM systems that don't have UEFI. BIOS is what imposes the
            limit, not MBR.</div>
          <div><br>
          </div>
          <div>But there's a huge number of systems that are already in
            the field that need</div>
          <div>to be upgradeable, but we will eventually need to draw a
            line in the sand for</div>
          <div>that.</div>
          <div> </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            Not a question I can answer, of course, because everyone
            likely has a<br>
            different take on what "worth the time and effort" means to
            them. :-)<br>
          </blockquote>
          <div><br>
          </div>
          <div>Yea, the BIOS path is stubbornly hanging around.</div>
          <div><br>
          </div>
          <div>Warner</div>
          <div> </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            Thanks,<br>
            <br>
            -- <br>
            Shawn Webb<br>
            Cofounder / Security Engineer<br>
            HardenedBSD<br>
            <br>
            Signal Username:  shawn_webb.74<br>
            Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50<br>
            <a
href="https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc</a><br>;
          </blockquote>
        </div>
      </div>
    </blockquote>
  </body>
</html>
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1268de25-55c7-4dd8-995c-4521ef0f4c13>