Re: To people upgrading from before r363679

The problem identified in Warner's email was fixed in r364030, so an
easy solution is updating from r363678 or earlier directly to r364030
or later.

Best,
Conrad

On Mon, Aug 10, 2020 at 3:20 AM Dennis Clarke <dclarke_at_blastwave.org> wrote:
>
> On 8/5/20 9:19 PM, Warner Losh wrote:
> > If you are upgrading across r363679, you may have installworld fail, as
> > documented in UPDATING.
> >
> > I have a fix (that requires a trip through buildworld) that's under review
> > at https://reviews.freebsd.org/D25967 . The changes are likely good, but
> > comments likely need updating.
> >
> > The short version is that we purposely use old libraries to install the
> > system. We created a symbolic link to a bunch of binaries on the system and
> > once installworld installs one of them, we get the error. The workaround
> > works because we copy libc.so before doing the installworld, so now we're
> > running with a new libc.so with new binaries, which works. My fix always
> > copies and never symlinks. The symbolic link stuff is too fragile.
> >
> > With it, I've done one system, but I'd appreciate reports (on the code
> > review if possible, to me in email if not) of people who have success
> > upgrading with this. If you've already run installworld and hit the
> > undefined symbol, it's too late for you to help me test (since re-running
> > is the same as hitting to test is the same as the workaround and so it will
> > work even if my workaround is busted).
> >
> > Some history: This was introduced about 2 years ago. Prior to that, we
> > always copied binaries for the install.
>
> This will fix the situation :
>
> triton$
> triton$ cat /usr/src/my.patch
> ...