esch(8) esch(8)
NAME
esch - validate and repair file systems from the A/UX
StartupShell
SYNOPSIS
esch [-b] [-ccluster-number] [-f] [-v]
DESCRIPTION
esch attempts to ensure that a minimal A/UX file system ex-
ists for a multiuser boot. When possible, it corrects bad
blocks, repairs file system inconsistencies, and replaces
corrupt or missing files. esch is intended to be run when
there is reason to suspect that the A/UX file systems have
been damaged.
Flag options to esch are
-b Bypasses bad block checking functions.
-c cluster-number
Allows the user to specify the autorecovery cluster
number.
-f Does not perform fsck (see fsck(1M)).
-v Reports any corrective measures taken.
esch must be run in the A/UX Startup environment before the
A/UX system is booted. When the system is powered on or
A/UX is rebooted, and the boot dialog is canceled by the
user, the A/UX Startup shell (see StartupShell(8)) prompt
appears and the esch command line may be entered.
Within the A/UX StartupShell, esch may be set to run au-
tomatically with each boot process by assigning the desired
esch command line to the StartupShell variable autorecovery.
A hard disk may be divided into partitions. Each partition
contains one file system (see fs(4)). Information on all
the partitions on a disk is kept in the disk partition map
(see dpme(4)) for that disk. One of the fields in a dpme is
the cluster number. This is used to identify the group of
partitions esch should use.
esch requires that all partitions reside on one disk. esch
reads the cluster number from nvram (see nvram(7)) and lo-
cates all the partitions in that cluster. A cluster must
contain a root partition, a swap partition, and at least one
autorecovery partition. A cluster may also contain a parti-
tion known to esch as the usr partition. There may be mul-
tiple autorecovery partitions in a cluster.
April, 1990 1
esch(8) esch(8)
Autorecovery file systems contain copies of files that are
necessary for a minimal multiuser A/UX system. If new ver-
sions of commands, programs, or files are installed on the
system, the autorecovery file systems should be updated us-
ing eu(1M) or escher(1M).
esch will check each file system for bad blocks. This is
done by verifying that each block can be read. If possible,
any blocks that cannot be read will be spared by the
hardware or replaced with alternate blocks (see altblk(4))
by the software. If neither of these is successful, the
block number is added to a list of blocks that is passed to
fsck. fsck will add these blocks to a file associated with
inode one; this has the effect of removing the blocks from
the file system. Checking for bad blocks is a time-
consuming process. This phase of autorecovery may be omit-
ted using the -b flag option. It is advisable to occasion-
ally run esch without the -b flag option to be sure any bad
blocks have been dealt with in the appropriate manner.
esch will then run fsck on each file system. This invoca-
tion of fsck uses the -y flag option. All questionable
files will be removed from the file system. If fsck should
fail or if the superblock is unreadable, a mkfs (see
mkfs(1M)) will be performed on the file system.
After the file systems have been checked for consistency,
esch will enter the file check merge phase. The configura-
tion master list (see cml(4)) is a list of files required
for a multiuser A/UX system. This file gives rules about
the attributes of each required file. The file check merge
phase of esch will check each file in the cml for conformity
to the specified file attributes (size, version, check sum,
permissions, and so forth). If a file does not conform to
these rules, esch will attempt to replace it with a copy
from an autorecovery file system. If the file in question
is found on an autorecovery file system, it must conform to
the cml rules or it will not be placed on the root or usr
file system.
FILES
/etc/eschatology/init2files
SEE ALSO
escher(1M), eu(1M), eupdate(1M), fsck(1M), mkfs(1M),
altblk(4), cml(4), dpme(4), fs(4), autorecovery(8), Startup-
Shell(8).
``System Startup and Shutdown'' in A/UX Local System Ad-
ministration.
2 April, 1990
WARNINGS
esch must never be interrupted! Do not power off the system
or push the reset button while esch is running. If esch is
interrupted, major file system damage may result or entire
file systems may be destroyed.
esch will attempt to replace files on two file systems only.
These are the root file system and a file system that is in-
tended to be mounted on /usr. Any other file systems will
be ignored by esch.
The superblock of a file system contains information
describing the file system. If esch is unable to read the
superblock of a file system, or if the superblock has a bad
magic number, the file system is not usable and an mkfs will
be performed on the file system. Everything on the file
system will be removed! All user files will be gone and
cannot be restored, since the only files esch restores will
be those listed in the cml.
If a file system should become full while esch is copying a
replacement file to it, esch will attempt to free up space
by deleting files from /lost+found, /tmp, /usr/lost+found,
or /usr/tmp (depending upon whether the file system is root
or usr). Subdirectories and their contents will also be re-
moved from these directories. If the directories have been
emptied and there is still no room to copy required files,
esch will terminate with an error.
April, 1990 3