Date: Mon, 23 May 2005 14:57:40 -0700 (PDT) From: Jon Passki <cykyc@yahoo.com> To: stable@freebsd.org Subject: Re: Recent 5.4-p1 upgrade issue (lib/libc.so.5) Message-ID: <20050523215740.89642.qmail@web50309.mail.yahoo.com> In-Reply-To: <20050523184430.GC96054@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Kris Kennaway <kris@obsecurity.org> wrote:
> On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote:
> > Here's what gets me: I was able to do a the supported upgrade
> > process in an unsupported manner (multiuser mode via ssh w/o a
> > shutdown inbetween, nor going into signle user mode) w/ no
> issues
> > on the build host. What occurs in that process (make
> buildworld;
> > make buildkernel; make installkernel; mergemaster -p; make
> > installworld; mergemaster) where libc can be replaced (assuming
> it
> > uses install(1), which is also linked against libc) without
> > failure, but using tar causes it to fail? Ideas?
>
> Look at how make installworld does the replacement safely.
Ah, makes sense now, but let me regurgitate:
According to src/Makefile.inc1, installword sets up INSTALLTMP with
some nifty files, along with the files previously in the obj tree
setup by phases such as bootstrap-tools. Since these are defined
later on in the path before the user's ${PATH}, one doesn't shoot
one's foot off when updating the binaries, correct?
In my circumstance, I don't have an obj tree on the dest. host, but
I do have /rescue. I could extract that on a first run and then
perform the later extractions with the updated tar (or just do it
all if /rescue/tar works anyway). Does this seem decent? Is there
a more elegant way?
Thanks for the heads up, Kris!
Jon
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050523215740.89642.qmail>