Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: Clobbered C library warning
Keywords: Miscellaneous
Message-ID: <3263@brazos.Rice.edu>
Date: 17 Nov 89 17:36:47 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 29
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n194, Replies: v8n198
X-Sun-Spots-Digest: Volume 8, Issue 206, message 1 of 15

>Fortunately sh did work, so I was able to boot the machine single-user,

It has to, for obvious reasons (hard to run "/etc/rc.single" to mount
"/usr", on which the shared libraries reside, without it...).

>I found that one of the few working program was mv, and I used that to get
>the bad library file out of the way, and instantly everything was fine.

And now you know why "mv" is linked statically....  "tar" and "rcp" are
also linked statically, for the same reason.  (Unfortunately, this means
that "rcp" doesn't e.g. automatically start using the name server if you
pick up the "use the resolver" version of "libc.so" from "uunet"; perhaps
the statically-linked versions should be stuffed in "/sbin" - or,
S5R4-style, in "/usr/sbin" - with dynamically-linked versions in
"/usr/bin".)

>That was frighteningly close to having to reload from distribution tapes,
>though.

If you dump your "root" and "/usr" file systems on a sufficiently-regular
basis (I say "sufficiently regular" because you may not change "/usr" very
often, which would let you dump it only when it changes), you needn't
reload from a distribution tape; just bring up the mini-root and run
"restore" (which, as I remember, is on the mini-root, probably for this
very reason) to pull the individual damaged file from the dump tape.  The
4.3SBD miniroot has "restore" and "newfs"/"mkfs" on it, and I suspect this
dates back quite a bit, and was done precisely to let you fix up the root
file system (which extends to "/usr" for SunOS 4.x, at least) without
having to reload your system from scratch.