Hello, I performed an unsupported way of installing and am soliciting what I could do next time to prevent installation blues. I'm not expecting assistance from the Project, just some love :) I have a build host that created what I needed for the host being upgraded. Once it's more polished, I'll be happy to share my steps, but relatively it went well. When I attempted to update /lib/libc.so.5, though, I hit a bump. I `chflags noschg /lib/libc.so.5` and then used tar to extract the exact file. tar was able to unlink the file, and then choked. After some unrelated errors, I was in single user mode using /rescue to save my rear end, which worked well enough. Doing `ldd /sbin/tar` hinted why it probably choked, since tar is dynamically linked to /lib/libc.so.5. 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? TIA, Jon PGP Fingerprint: 1BB0 A946 927B 93C3 ED6A 0466 6692 6C2C 84BE 4122 "Should any political party attempt to abolish social security, unemployment insurance, and eliminate labor laws and farm programs, you would not hear of that party again in our political history. There is a tiny splinter group, of course, that believes you can do these things. Among them are [...] a few other Texas oil millionaires, and an occasional politician or business man from other areas. Their number is negligible and they are stupid." [1] -- Dwight D. Eisenhower, Former President of the USA (Republican), Nov. 8, 1954 [1] http://www.eisenhowermemorial.org/presidential-papers/first-term/documents/1147.cfm __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote:> Hello, > > I performed an unsupported way of installing and am soliciting what > I could do next time to prevent installation blues. I'm not > expecting assistance from the Project, just some love :) > > I have a build host that created what I needed for the host being > upgraded. Once it's more polished, I'll be happy to share my > steps, but relatively it went well. When I attempted to update > /lib/libc.so.5, though, I hit a bump. > > I `chflags noschg /lib/libc.so.5` and then used tar to extract the > exact file. tar was able to unlink the file, and then choked. > After some unrelated errors, I was in single user mode using > /rescue to save my rear end, which worked well enough. Doing `ldd > /sbin/tar` hinted why it probably choked, since tar is dynamically > linked to /lib/libc.so.5. > > 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. Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050523/f3e97084/attachment.bin
Sorry for coming late to the thread -- catching up on mailing list traffic :) On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote:> I `chflags noschg /lib/libc.so.5` and then used tar to extract the > exact file. tar was able to unlink the file, and then choked. > After some unrelated errors, I was in single user mode using > /rescue to save my rear end, which worked well enough. Doing `ldd > /sbin/tar` hinted why it probably choked, since tar is dynamically > linked to /lib/libc.so.5.You didn't mention it so I'll ask, did you give the -U flag to tar? If not, it didn't actually unlink libc.so.5, but instead started overwriting it. This likely caused tar to bomb (probably with a SIGSEGV or other bad condition), as the shared library in memory is backed by the pages on disk. Executables are locked to prevent this from happening (ETXTBSY), however shared libraries are not. Overwriting one will almost certainly cause running processes to die and other Bad Things to happen. tar -U unlinks the file first and creates a new one, which seems to be what you want. Of course if you did specify that and just didn't mention it, then the problem is something else entirely -- and shouldn't have happened AFAIK :) Craig