We consider the possible solutions in two stages:
1. What proactive steps to take to ensure that you can
recover from the problem.
2. How to recover from the problem, preferably having
taken some or all of these proactive steps.
----------------------------------------------------------------
1. Taking proactive steps to recover from a lost libc.so.1
----------------------------------------------------------------
To ensure that you can recover from a lost libc.so.1, follow
the steps below:
A. Make a backup copy of the file in a reliable, secure location
in the root filesystem. Make sure that the file has perms/modes
of 555 bin:bin.
NOTE:
If your backup copy of libc.so.1 does not have the correct
perms/modes, then recovery from a lost libc.so.1 in the future
may still be difficult or impossible.
B. Make an emergency boot/root floppy set for the system, using
the supported emergency floppy creation procedure furnished
in the "mkdev fd" utility; verify this floppy set after
creation by booting with them, mounting the root filesystem,
and checking for the existence and proper functionality of
basic utilities such as mv, cp, ln, cpio, and so on.
The "mkdev fd" procedure automatically places /usr/lib/libc.so.1
on the root floppy, as this is necessary for full functionality
of the root floppy.
NOTE:
Even if you had already made a boot/root floppy set after
you installed the operating system, it is strongly recommended
that you create a new floppy set after installing any software
that replaces /usr/lib/libc.so.1. Some prominent instances
include the following SLSs:
OSS601A (on OpenServer 5.0.2 or 5.0.4)
OSS600A (on OpenServer 5.0.5 + RS505A)
RS505A (on OpenServer 5.0.5)
OSS603A (on OpenServer 5.0.0)
C. Download and install the Technical Library Supplement TLS704.
This TLS contains a small set of crucial shell utilities that
are statically linked and function independently of
/usr/lib/libc.so.1. It also includes the versions of the
libc.so.1 file supplied with each SCO OpenServer 5 release
(5.0.0, 5.0.2, 5.0.4, 5.0.5), along with the replaced versions
of this file supplied with each of the SLSs in B above.
See Technical Article 110353, "TLS704 - Statically linked utilities and versions
of libc.so.1 for OpenServer 5" for more information.
NOTE:
The statically linked binaries contained in TLS704 are
already furnished by OpenServer Release 5.0.5. However, it may
still be valuable to install TLS704 on a 5.0.5 system because of
the different versions of libc.so.1 supplied by TLS704.
-----------------------------------------
2. Recovering from a lost libc.so.1
-----------------------------------------
The method of recovery depends upon the current state of the
system, specifically, whether the system is still running or it
has been shut down and a reboot attempted.
In what follows below, it is assumed that you have installed
TLS704 as instructed above, or have OpenServer 5.0.5, which
already has the binaries to be used below. The binaries are
assumed to be in the /sbin directory.
What to do if the system has _not_ been shut down yet:
-----------------------------------------------------------
A. Make a note of the following pathname:
/opt/K/SCO/Unix/<version>/usr/lib/libc.so.1
where <version> is the version number of the Unix component on
your OpenServer 5 system. Below is a table of Unix component
versions for the OpenServer 5 releases, to be used in all
subsequent steps:
OpenServer Release Unix version number
------------------ -------------------
5.0.5 5.0.5Eb
5.0.4 5.0.4Eb
5.0.2 5.0.2Dp
5.0.0 5.0.0Cl
This is the full pathname for the libc.so.1 file on your
OpenServer 5 system.
It is likely that either this pathname is missing, the file
has incorrect perms/modes, or the symbolic link to it is missing;
usr/lib/libc.so.1 should exist as a symlink to the pathname
given above. At this stage, however, the commands usually
required to find out what is amiss are disabled.
The simplest way to proceed, therefore, is to replace the
library file and test the system operation. If commands still
cannot be run, it is possible that the symlink is broken, and
it can then be re-created. If, after this, commands still
cannot be run, it is likely that the perms/modes of the replaced
libc.so.1 are incorrect, or there is some other problem. In this
case, rebooting the system from floppy still offers a viable
opportunity for recovery.
B. Copy the saved libc.so.1 to the pathname given in A above:
/sbin/cp <save dir>/libc.so.1
/opt/K/SCO/Unix/<version>/usr/lib/libc.so.1
where <save dir> is the secure location of the saved copy of
libc.so.1, or the appropriate version of libc.so.1 furnished
by TLS704.
If this message is displayed:
cp: unable to create file libc.so.1: Text file busy
it is likely that the pathname and the /usr/lib/libc.so.1 symlink
exist, but that the file is either corrupted or the perms/modes
are incorrect. In this case, move the pathname:
/sbin/mv /opt/K/SCO/Unix/<version>/usr/lib/libc.so.1 /tmp/libc.so.old
and attempt the above cp operation again.
If shell commands do not function normally at this stage,
proceed to step C. Otherwise, the problem is resolved.
C. Restore the symbolic link with /usr/lib/libc.so.1:
/sbin/ln -s /opt/K/SCO/Unix/<version>/usr/lib/libc.so.1 /usr/lib/libc.so.1
If this error message is displayed:
ln: cannot create /usr/lib/libc.so.1: File already exists
then it is likely that /usr/lib/libc.so.1 exists as a regular file
(but as a corrupted shared library), but not as a symlink. In this
case, move the file as in B above:
/sbin/mv /usr/lib/libc.so.1 /tmp/libc.so.old
and then try to create the symlink once again.
D. Test normal operation by verifying both pathnames:
ls -l /usr/lib/libc.so.1
ls -l /opt/K/SCO/Unix/<version>/usr/lib/libc.so.1
It should be clear that /usr/lib/libc.so.1 exists as a symlink to
the /opt/K/SCO... pathname. All other shell commands should now
function normally. If not, shut down the machine (it may be
necessary to power down prematurely, if the normal shutdown sequence
does not complete) and proceed to the procedure below, "What to do
if the system has already been shut down."
E. Correct the permissions and modes of libc.so.1 if necessary:
chmod 555 /usr/lib/libc.so.1
chown bin:bin /usr/lib/libc.so.1
If shell commands do not function normally at this stage, or if
you had not taken the proactive steps as described above which are
required to perform the steps in this section, proceed to the steps
that immediately follow.
What to do if the system has already been shut down:
---------------------------------------------------------
A. Boot the system from the emergency boot/root floppy set and
bring the system to a shell prompt.
B. Run fsck on the root filesystem:
fsck -ofull /dev/hd0root
C. Mount the root filesystem on the primary hard disk:
mount /dev/hd0root /mnt
D. Copy the /usr/lib/libc.so.1 file from the root diskette:
cd /mnt/opt/K/SCO/Unix/<version>/usr/lib
cp /usr/lib/libc.so.1 .
where <version> is the Unix component version of your system as
above; we repeat that table of information here for clarity:
OpenServer Release Unix version number
------------------ -------------------
5.0.5 5.0.5Eb
5.0.4 5.0.4Eb
5.0.2 5.0.2Dp
5.0.0 5.0.0Cl
E. Check the existence of the symbolic link with
/mnt/usr/lib/libc.so.1:
ls -l /mnt/usr/lib/libc.so.1
and re-create the symlink if necessary:
ln -s /opt/K/SCO/Unix/<version>/usr/lib/libc.so.1 /mnt/usr/lib/libc.so.1
F. Correct the permissions and modes of libc.so.1 if necessary:
chmod 555 /mnt/usr/lib/libc.so.1
chown bin:bin /mnt/usr/lib/libc.so.1
G. Unmount the hard disk root filesystem, reboot the system
normally, and test the system operation.
H. Download and install TLS704 on your system to ease the recovery,
should a similar situation arise again.
What to do if none of the proactive steps outlined above have
been taken
--------------------------------------------------------------
If you have not created a proper set of emergency boot/root
floppies, you can still follow the above procedure for recovery,
if you have the original installation media (N0 floppy plus OS
CD-ROM).
NOTE:
The main shortcoming of using the installation media is
that the version of libc.so.1 supplied in the installation
environment may not match the OS configuration on the hard disk.
Recovery is still likely, but as soon as the system is able to
boot normally, the correct version of libc.so.1 should be obtained
from the appropriate patch or other software.
A. Boot the system from the N0 diskette, and enter "tools" at the
"Boot:" prompt.
B. Configure the primary media device as instructed by the
installation sequence. Insert the CD-ROM when prompted.
C. Choose the "Execute a shell..." option.
D. Follow the procedure above under "What to do if the system
has already been shut down", starting from step B.
E. Create a set of emergency boot/root floppies for general
purpose recovery for the future.
F. Download and install TLS704 on your system to ease recovery,
should a similar situation arise again.
SEE ALSO:
Technical Article 110077, "What is addressed by SLS OSS601A, the Year 2000
Supplement for SCO OpenServer 5.0.2 and 5.0.4?"
Technical Article 110091, "Special notes and recommendations before installing
OSS601A, the Year 2000 Supplement for SCO OpenServer 5.0.2
and 5.0.4."
Technical Article 110334, "After unloading OSS601A, shell commands fail on
my 5.0.2 system with "Killed"."
Technical Article 105032, "My system panics with "PANIC: exit cannot exec
/etc/init (PID 1) status 9."
|