Recent 5.4-p1 upgrade issue (lib/libc.so.5)

[Jon Passki]

--- Kris Kennaway <kris at 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/