kdo@lucid.com (Ken Olum) (11/12/89)
Here's a impressive way to lose that's probably worth knowing about in advance: I attempted to install a new version of libc.so... by copying it from another machine on our network. In the middle of the copy, my machine crashed. When it came back up again, all the programs tried to map in the partially-copied lib file, got memory-errors and aborted. A few programs worked, but csh was not one of them, so I couldn't log in. Fortunately sh did work, so I was able to boot the machine single-user, but then ls, cat, cp, more, and almost every other useful program was broken. Eventually I realized that I could get a list of possible programs by type "echo /usr/bin/*", and then I tried them one by one until 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. That was frighteningly close to having to reload from distribution tapes, though. The only way to fix this problem is to psych out that this is what is wrong and find a program to fix it. Ken Olum Lucid, Inc.
root@sherwood.prime.com (Operator) (11/14/89)
The warning about changing the shared 'C' library from Ken Olum is right
on target. We have run into his problem a bunch of times when attempting
to switch 'C' libs. Here are a couple of things I have learned:
1) NEVER use cp - it is dynamically linked and always gets mangled;
2) You MAY be able to get away with using install - it just uses reads
and writes, so the chances of overwriting some executing routine are
small. You can try this if your needs demand it, but I wouldn't bet the
farm on it.
3) The following are statically linked, so they always work. You can use
them to avoid c/trashing your system when you are playing with the
dynamic 'C' library:
tar - use this to move the library or to restore a good version from
tape, etc;
mv - use this to overwrite the version you want to replace.
sh - you can shutdown to single-user mode, use mv or tar to replace
the library, and then <cntl-D> back up to multi-usr mode.
cd - to get around.
To find out if a particular program is statically or dynamically linked,
use the ldd(1) command (not, however, that SUN in their infinite wisdom
made this dynamically linked, so ldd won't work if your 'C' lib is already
trashed).
Mark Hickey Computervision Division
O/S Development Prime Computer, Inc.
Bedford, MA 01730
UUCP : {decvax|linus|sun}!cvbnet!mhickey
Internet: mhickey@cvbnet.prime.comguy@uunet.uu.net (Guy Harris) (11/18/89)
>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.