Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Mar 2022 07:26:50 -0400
From:      Karl Denninger <karl@denninger.net>
To:        Warner Losh <imp@bsdimp.com>
Cc:        FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   Re: Hybrid partition tables -- can gpart make them?
Message-ID:  <14170134-a925-1f24-6138-eb57ce881752@denninger.net>
In-Reply-To: <CANCZdfqheEm4ypt2Va=2JRVSbHF1D%2BRFyYjGnPp8eay8WGaW3Q@mail.gmail.com>
References:  <68449cab-c5d7-47ff-99e1-d0e6963374d0@denninger.net> <CANCZdfqheEm4ypt2Va=2JRVSbHF1D%2BRFyYjGnPp8eay8WGaW3Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.

--------------ms000407000004030404060808
Content-Type: multipart/alternative;
 boundary="------------gzBL93ra00EIDAG6rgmuBuF2"

--------------gzBL93ra00EIDAG6rgmuBuF2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 3/18/2022 00:19, Warner Losh wrote:
>
>
> On Thu, Mar 17, 2022 at 7:20 AM Karl Denninger <karl@denninger.net> wrote:
>
>     First, the "why" -- I wish to have *two* OS partitions, a data
>     partition and a config partition under NanoBSD on a Pi3 or 4. 
>     Both boot using EFI and the "3", at least, appears to refuse to do
>     so off a GPT-labeled disk.  This means I need *five* slices and
>     MBR can only do 4.
>
>     I attempted to have one slice be "Freebsd" with the two OS
>     partitions inside it, which would work *except* it doesn't because
>     I can't set "bootme" on those; the EFI loader always finds the
>     first usable UFS partition and boots it.  I need to be able to
>     toggle that to boot the *second* partition.
>
>     I've replaced boot1.efi (quite some time ago) with loader_lua.efi
>     in the EFI partition.  This works, but there does not appear to be
>     a way to tell it that I want it to default to something other than
>     the first bootable partition it finds
>
>
> It follows the EFI Boot Manager protocol, but the RPi doesn't give a 
> good way to persist that data.
>
> If you could get GPT working, you could use gptboot.efi, which allows 
> you to set which GPT partition to boot. We use that at Netflix for 
> this exact scenario.
>
> More, see below...
>
>     The intent is to enable the capability to upgrade the OS without
>     having to wipe/reload the card the unit boots from, then set the
>     other partition as the  "next boot." This works quite nicely with
>     nanoBSD generally for MBR-bootable devices (and I use it with the
>     pcEngines boards), but doesn't on the Pi due to requiring the EFI
>     partition which means I run out of slots, never mind that the
>     loader will still find andn boot the first one.
>
> So, we read in \efi\freebsd\loader.efi off the ESP by default. We use 
> it to set boot environment variable (not UEFI ones, though there's a 
> UEFI override for this filename)
>
> This lets you set currdev to be the device that you wish to boot off 
> of in there. This will load all the /boot files off that partition (at 
> least all the lua scripts, config, etc). I've tested this, but wound 
> up using the GPT method for selecting partitions because that's 
> operationally better for the purpose that I'd needed this for.
>
> This won't help with the gpart creation question, nor with the mkimage 
> issue. The RPi requires the MBR partitioning to find things. GPT goes 
> hand in hand with MBR, since we put a 'protective mbr' on the disk in 
> addition to the GPT tables. That's part of the GPT spec. mkimage could 
> be hacked to create this hybrid, where you'd have one FAT slice in the 
> MBR world, and you could have the full layout you want with GPT. 
> However, that's kinda weird, and I don't know how our code would cope 
> with that (I've never tried it, though I have discussed it 
> theoretically with benno when he was trying to have a unified gpt/iso 
> boot loader in BIOS land)....
>
> Warner

I found a solution that works.

The EFI lua loader, if placed on the EFI partition directly, will load 
/and use /a config file on the MSDOS partition at 
EFI/FreeBSD/loader.env, and in there you can stick the directive 
"rootdev=......" (such as "disk0s2a" or "disk0s2b")

Now the disk layout can be:

MBR
    EFI
    Freebsd
       freebsd-ufs (system 1)
       freebsd-ufs (system 2)
       config (for nanobsd, overlay for the MD areas
       data (miscellaneous things)

You can then update the second system partition while it is running, 
validate that the load was good (e.g. cryptographic sum verify if you 
want, fsck of the new system boot partition is clean, that the 
/etc/fstab entry for root is adjusted in the "new" area as appropriate, 
etc) and then change rootdev only on success.  This is basically the 
same process that NanoBSD uses for MBR disks in setting the active 
primary partition which works as intended on MBR devices and it works on 
the Pi3 and 4 which boot from EFI.

What I thought I was going to have to do was have a fifth partition in 
front of the two system ones that had *only* the /boot/lua and 
/boot/defaults/loader.conf files, because otherwise if you are updating 
the first partition and it fails you're boned since that's where the 
directive is to change the rootdev.  But since the loader will obey the 
directive on the EFI partition that has proved to be unnecessary.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------gzBL93ra00EIDAG6rgmuBuF2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 3/18/2022 00:19, Warner Losh wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANCZdfqheEm4ypt2Va=2JRVSbHF1D+RFyYjGnPp8eay8WGaW3Q@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">
          <div dir="ltr" class="gmail_attr">On Thu, Mar 17, 2022 at 7:20
            AM Karl Denninger &lt;<a href="mailto:karl@denninger.net"
              moz-do-not-send="true" class="moz-txt-link-freetext">karl@denninger.net</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">
            <div>
              <p>First, the "why" -- I wish to have *two* OS partitions,
                a data partition and a config partition under NanoBSD on
                a Pi3 or 4.  Both boot using EFI and the "3", at least,
                appears to refuse to do so off a GPT-labeled disk.  This
                means I need *five* slices and MBR can only do 4.</p>
              <p>I attempted to have one slice be "Freebsd" with the two
                OS partitions inside it, which would work *except* it
                doesn't because I can't set "bootme" on those; the EFI
                loader always finds the first usable UFS partition and
                boots it.  I need to be able to toggle that to boot the
                *second* partition.<br>
              </p>
              <p>I've replaced boot1.efi (quite some time ago) with
                loader_lua.efi in the EFI partition.  This works, but
                there does not appear to be a way to tell it that I want
                it to default to something other than the first bootable
                partition it finds</p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>It follows the EFI Boot Manager protocol, but the RPi
            doesn't give a good way to persist that data.</div>
          <div><br>
          </div>
          <div>If you could get GPT working, you could use gptboot.efi,
            which allows you to set which GPT partition to boot. We use
            that at Netflix for this exact scenario.</div>
          <div><br>
          </div>
          <div>More, see below... </div>
          <div><br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>
              <p>The intent is to enable the capability to upgrade the
                OS without having to wipe/reload the card the unit boots
                from, then set the other partition as the  "next boot." 
                This works quite nicely with nanoBSD generally for
                MBR-bootable devices (and I use it with the pcEngines
                boards), but doesn't on the Pi due to requiring the EFI
                partition which means I run out of slots, never mind
                that the loader will still find andn boot the first one.</p>
            </div>
          </blockquote>
          <div>So, we read in \efi\freebsd\loader.efi off the ESP by
            default. We use it to set boot environment variable (not
            UEFI ones, though there's a UEFI override for this filename)<br>
          </div>
          <div><br>
          </div>
          <div>This lets you set currdev to be the device that you wish
            to boot off of in there. This will load all the /boot files
            off that partition (at least all the lua scripts, config,
            etc). I've tested this, but wound up using the GPT method
            for selecting partitions because that's operationally better
            for the purpose that I'd needed this for.</div>
          <div><br>
          </div>
          <div>This won't help with the gpart creation question, nor
            with the mkimage issue. The RPi requires the MBR
            partitioning to find things. GPT goes hand in hand with MBR,
            since we put a 'protective mbr' on the disk in addition to
            the GPT tables. That's part of the GPT spec. mkimage could
            be hacked to create this hybrid, where you'd have one FAT
            slice in the MBR world, and you could have the full layout
            you want with GPT. However, that's kinda weird, and I don't
            know how our code would cope with that (I've never tried it,
            though I have discussed it theoretically with benno when he
            was trying to have a unified gpt/iso boot loader in BIOS
            land)....<br>
          </div>
          <div><br>
          </div>
          <div>Warner<br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>I found a solution that works.</p>
    <p>The EFI lua loader, if placed on the EFI partition directly, will
      load <i>and use </i>a config file on the MSDOS partition at
      EFI/FreeBSD/loader.env, and in there you can stick the directive
      "rootdev=......" (such as "disk0s2a" or "disk0s2b")<br>
    </p>
    <p>Now the disk layout can be:</p>
    <p>MBR<br>
         EFI<br>
         Freebsd<br>
            freebsd-ufs (system 1)<br>
            freebsd-ufs (system 2)<br>
            config (for nanobsd, overlay for the MD areas<br>
            data (miscellaneous things)</p>
    <p>You can then update the second system partition while it is
      running, validate that the load was good (e.g. cryptographic sum
      verify if you want, fsck of the new system boot partition is
      clean, that the /etc/fstab entry for root is adjusted in the "new"
      area as appropriate, etc) and then change rootdev only on
      success.  This is basically the same process that NanoBSD uses for
      MBR disks in setting the active primary partition which works as
      intended on MBR devices and it works on the Pi3 and 4 which boot
      from EFI.</p>
    <p>What I thought I was going to have to do was have a fifth
      partition in front of the two system ones that had *only* the
      /boot/lua and /boot/defaults/loader.conf files, because otherwise
      if you are updating the first partition and it fails you're boned
      since that's where the directive is to change the rootdev.  But
      since the loader will obey the directive on the EFI partition that
      has proved to be unnecessary.<br>
    </p>
    <div class="moz-signature">-- <br>
      Karl Denninger<br>
      <a href="mailto:karl@denninger.net" class="moz-txt-link-freetext">karl@denninger.net</a><br>
      <i>The Market Ticker</i><br>
      <font size="-2"><i>[S/MIME encrypted email preferred]</i></font></div>
  </body>
</html>

--------------gzBL93ra00EIDAG6rgmuBuF2--

--------------ms000407000004030404060808
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO
62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp
ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD
QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx
MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw
ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A
16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg
96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg
y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs
YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg
6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX
SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM
cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN
5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l
CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg
CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v
b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF
oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG
SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O
BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC
GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE
BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh
IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ
zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN
AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR
dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu
2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X
lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK
FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q
IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA
1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL
shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ
qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE
QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMzE4MTEyNjUw
WjBPBgkqhkiG9w0BCQQxQgRA0vo5NQ2KVZUmAPvJ6cRS1L+tFJMvNoMggAkz0vxyk/7iYCJO
2y8UxMWS0gpc0WES/GM+H6PUNWrMp2hUi1MD8DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl
AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg
gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz
dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0
ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF
AASCAgB0cwMpEPJpm67Vc0eeGEJ+fDcYyn4zmw9XtPHIAxoLVjFAHbf5vJ+ASorHdcVNZEdp
1lZHL1onxOElJ3QH5LE+7SbJaL9R6awV/Ld10+d7Iig0ShAauMbRoRm/PyHOPmjiU05B73u0
DZrpcDv2iXKDAvQ+NxL1fvPv0HGqfFCz0lgnJWhJRiBA1inJbsJ4xfTDbmFEJ+rWagu5rLW9
VjgMrP3onFCdjdXwPA1qNyI+lDHDEOFgybG/Q2p6/sFA+YwvEPRJB4Q3fUjwBSJ3+ebH1hxr
ieketYlOJfoqyDosZQV+7tdz4DyvO2UqiWBe82h0E+Tivr52VPvdUNiECCTD31+obm9N4Q+f
0q8fQgAJEWYWOseHSU3a9koP0C7bgGIO1+EIxU8Imde5YGrl0/s1HnMzDNSfkU8C/YxpEDE0
D/YZ4IQGlgcNtK7gbZTx5vY5sEuddZpZKa/3Ftsu9J2BAbFpCatRKXAg56tk6xFrdIrHKBK7
vrMo7LOe0l4czKb5UVoM8WU24T9+SGZ9Ix4iNu+givhioX754En8iLbUEj2GbFBK4Fg46CD5
Kh47+0vsBEbEhjrqlyviyfS2SqL9iaQSi3rQX7nTSvOvHM1na2+Rp0CMRjbgB0dvy6EILKqS
xCEGRJcMxd0IbBQXX4zj2B4l8u3RKIUO0iWgx70hIQAAAAAAAA==
--------------ms000407000004030404060808--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14170134-a925-1f24-6138-eb57ce881752>