Big fun with Sys V Drivers
Stephen J. Friedl
friedl at vsi.UUCP
Tue Apr 26 14:51:06 AEST 1988
In article <353 at icus.UUCP>, lenny at icus.UUCP (Lenny Tropiano) writes:
> What about the secret "MAGIC MODE"? For those who don't know about
> this mode, it is something AT&T has for those who need a "shell" off
> a floppy /unix.
Thanks a lot, Lenny, that was my line :-(.
Enclosed is the first version of my standalone boot guide for the
3B2. I got a lot of requests so I decided to polish up for
"publication". We obviously disclaim any and all responsibility
for anything you have ever done or will ever do with this
information; this can be dangerous business so *please* be very
careful.
This is just an introductory document, and there is tremendous
room to grow here. I intend on writing some other docs about 3B2
wizardry: undocumented firmware-mode commands, writing your own
primary bootstrap (!), repartitioning from standalone mode, etc.
but for now this will do. When I get some time...
I don't know what the net.conventions are for printer attributes,
and I assume that some mailers have a hard time with backspaces,
formfeeds, and CR overprinting. To combat this, I told my WP's
printer driver to use the following:
<$b+> bold on
<$b-> bold off
<$u+> underline on
<$u-> underline off
Replace these with your favorite strings and you'll be all set.
There are no formfeeds or hyphenation in this document, and each
page is formatted to exactly 66 lines.
I actively solicit comments on the writing style. I rather
enjoy technical writing and want to improve myself (you know,
"programmers can't write and writers can't program"). Comments
on spelling, grammar, and other stylistic matters are strongly
encouraged.
I really hate to copyright net.postings, so I won't. You are
encouraged to give this doc to anybody you wish, but please do
so in the same spirit of friendly sharing that provided it to you.
Enjoy.
Steve
---
Steve Friedl V-Systems, Inc. Wizard of undocumented 3B goodies
friedl at vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
#------------------------- cut here --------------------------------
Running a Standalone Shell on a 3B2
Stephen J. Friedl
V-Systems, Inc.
April 25, 1988
<$b+>WARNING: the procedures described here<$b->
<$b+>require substantial knowledge of UNIX and<$b->
<$b+>entail a significant risk of causing loss of<$b->
<$b+>data. The obvious disclaimers apply here, so<$b->
<$b+>use at your own risk. Please be careful.<$b->
<$b+>Introduction<$b->
AT&T has developed some very simple, automated procedures
for doing just about everything required to administer a 3B2
computer. They do this with the help of detailed, step-by-step
manuals and some pretty decent sysadm menu software. The
difficulty is that there are some things that just can't be done
easily via the menus; fixing a dead machine is one of them.
This document is an introduction to operating your 3B from
a standalone /unix. Even with inoperable hard drives, it is
possible to insert the boot floppy (Essential Utilities Disk 1),
say some magic words, and receive a <$b+>#<$b-> prompt. At this point you
can do major surgery on the failing machine, often recovering a
drive previously thought to be lost.
Our style is informal and we'll use lots of examples to
illustrate the points at hand. We have been using standalone
shells for quite some time and have learned a great deal; we hope
to pass this information on to you. Please read this document
carefully before trying the methods described here, and if
possible have a wizard around when giving it a go. This can be
dangerous business: as has been said before, it is a time where
experience and informed courage count for much.
All of these notes were derived by looking at disks, picking
apart little programs, and generally by running into problems
we were bound and determined to solve. We are not a source code
licensee, and as such, we have made certain assumptions about
some of the pieces of this puzzle, those assumptions possibly
having limited correspondence with reality. Those with more
enlightenment are encouraged to fill us in on changes.
- 1 -
<$b+>Conventions<$b->
Throughout this document, sample usage sessions will be
shown indented, with user input in <$b+>bold<$b->. To make it easier
to distinguish between a multiuser UNIX shell and a standalone
one, we will show multiuser UNIX's root prompt as <$b+>##<$b-> and the
standalone prompt as <$b+>#<$b->.
<$b+>>>> Back up your boot disks <<<<$b->
This cannot be emphasized enough. Your boot floppies are
the key to your machine, and without them the machine is down.
Early in our experiences with standalone shells, our primary boot
floppies became corrupted early on a Saturday, and we had to wait
until Monday morning for AT&T to provide us a spare; it was as
embarrassing as it was frustrating. It is mandatory that you
have at least three copies of your boot disk before you begin
these procedures. While it is easy to have too few backups, it
is hardly possible to have too many.
The most efficient method for copying an entire floppy is
with the <$b+>dd<$b->(1) command. First, read a copy of the entire floppy
into a single file under /tmp. Be sure that room for the entire
filesystem -- 1435 blocks -- is available on the hard drive.
## <$b+>dd if=/dev/rdiskette of=/tmp/disk.copy bs=9b<$b->
158+0 records in
158+0 records out
This reads from the boot disk into the file <$b+>/tmp/disk.copy<$b->,
using the floppy's optimal blocksize. The command will take
somewhat over two minutes, and the input/output statistics shown
above are normal. Now, insert a formatted floppy into the drive
and do:
## <$b+>dd of=/dev/rdiskette if=/tmp/disk.copy bs=9b<$b->
158+0 records in
158+0 records out
Notice that the `<$b+>if<$b->' and `<$b+>of<$b->' options are the only changes,
signifying the reversal of copying direction. This second
command can be used repeatedly to make as many copies of the disk
as desired. Do remember to remove the /tmp/disk.copy file after
all copies have been made.
<$b+>Why do you want a standalone /unix?<$b->
The most compelling reason for a standalone shell is when
the primary drive has gone down and must be recovered. While
working from a standalone /unix is slow and tedious, it can often
save an entire hard disk with minimal data loss.
- 2 -
Case in point: a friend called in a panic. He had done
a dd(1) onto his hard drive improperly and had overwritten the
drive's partition tables, rendering it unbootable. He was able
to boot a standalone /unix from a floppy, manually initialize the
partition tables, and get his drive back with not a byte lost.
All it cost was a cross-country phone call and a half an hour of
time (plus a nice dinner next time he's in town).
We have also used this standalone shell to repair a corrupt
/etc/inittab, to fix /etc/passwd, to restore a /bin/login
that had been removed, and to install new bootstraps on the
hard drive. With a standalone boot disk in hand, a host of
possibilities presents itself.
<$b+>What is on your boot disk?<$b->
Before booting this floppy, take some time to explore
its contents, as the disk has a filesystem on it that can be
mounted and perused. To do this, insert <$b+>a copy<$b-> of the Essential
Utilities Floppy 1 (from now on, "the boot floppy") into the
drive <$b+>with a write-protect tab<$b->. Now,
## <$b+>mount /dev/dsk/c0d0s5 /install -r<$b->
Because this disk has a boot partition that resides on the
first cylinder, the more commonly used <$b+>/dev/diskette<$b-> (slice 6) is
replaced by <$b+>/dev/dsk/c0d0s5<$b-> (slice 5). The `<$b+>-r<$b->' flag asks that
the filesystem be mounted readonly.
The <$b+>/install<$b-> directory may now be visited like any other,
but remember that a floppy-based filesystem responds <$b+>much<$b-> slower
than one based on the hard drive. With this in mind, it is
helpful to insure that the current directory appears at the tail
end of the shell's search <$b+>$PATH<$b-> when exploring a floppy.
Because boot floppies vary from release to release, it would
be most helpful to simply get a listing of the contents of your
particular boot floppy. Do this by:
## <$b+>cd /install<$b->
## <$b+>ls -lRFab | pr | lp<$b->
This sends a formatted listing of the entire disk to the
printer; keep it handy.
The next step is to examine the particular installation
procedure used by this version of the boot floppy. Look in
<$b+>/install/etc/inittab<$b-> for the name of the program that does the
work, and on our disks (SVR2.0.4) the file is <$b+>/inst/etc/instf<$b->
(which is found in <$b+>/install/inst/etc/instf<$b-> if the floppy is
mounted on the hard drive). This installation script is fairly
verbose, and tracking down just what it is doing should be
- 3 -
straightforward and enlightening.
Once finished, the floppy must be unmounted:
## <$b+>cd /<$b->
## <$b+>umount /dev/dsk/c0d0s5<$b->
Never remove a mounted floppy filesystem without first
unmounting it, especially a boot disk. Doing this may leave the
filesystems's status flag in an "active" state and prevent the
boostrap from recognizing it. The umount operation insures that
the disk is properly updated before it is closed. When the green
drive light goes off, remove the floppy and return it to its
proper home.
<$b+>"Open Sesame"<$b->
To give standalone a try, first shut the machine down to
firmware mode. From multiuser UNIX, warn the users that the
machine will be unavailable, and run the following from the
system console:
## <$b+>cd /<$b->
## <$b+>/etc/shutdown -i5<$b->
This brings the machine into init state 5, which is firmware
mode. The shutdown program will verify your intentions, send
a notification to all logged-on users, and bring the machine to
firmware mode in one minute.
Assuming the machine is now in firmware mode, put a copy
of the boot disk into the drive. Note that some versions of the
operating system (Sys V Release 2, at least) require that the
boot floppy be write-enabled (i.e., no write-protect tab); it
is this requirement that mandates multiple backups of the boot
floppy. UNIX will be updating the disk while it runs -- the
superblock, access times, etc. -- and if the machine crashes at
the wrong time it simply will not boot again without an fsck. Be
careful.
Type in your firmware password and boot <$b+>/unix<$b-> from the
floppy drive (Option 0, named `<$b+>FD5<$b->') instead of the hard drive
(Option 1, named `<$b+>HD30<$b->' or `<$b+>HD72<$b->'). It can take several minutes
for UNIX to boot, but when it does, the familiar menu will be
displayed:
1) Full Restore
2) Partial Restore
3) Dual-Disk Upgrade
4) Release Upgrade
- 4 -
Selection? [1, 2, 3, 4, quit, help]
At this point, type the phrase
<$b+>magic mode<$b->
The system recognizes this special option and responds:
Poof!
Selection? [1, 2, 3, 4, quit, help, shell, copy]
Notice the new options? Now type <$b+>shell<$b->, then RETURN, and
you will be greeted with the familiar <$b+>#<$b-> prompt. You are now
running a standalone shell on the floppy.
A few reminders here: a floppy filesystem is not able to
hold much data, and many common utilities are unavailable. When
dealing with the standalone shell, one must learn alternatives
to these utilities. For example, <$b+>echo *<$b-> can replace <$b+>ls<$b->(1), and
<$b+>cat > file<$b-> can serve as a poor replacement to <$b+>ed<$b->(1). One must
become remarkably resourceful when working in an environment as
restricted as this. We will see later how we can enhance this
confined environment with additional tools.
<$b+>Standalone devices<$b->
The floppy's <$b+>/dev<$b-> directory contains a host of entries,
some of them referring to partitions on the hard drive. While a
particular partition may have several names, we generally use the
following devices to refer to the hard disk:
Partition What it is (on the hard disk)
----------- -----------------------------
/dev/idsk00 / filesystem
/dev/idsk01 swap area
/dev/idsk02 /usr filesystem
/dev/idsk06 the entire disk
/dev/idsk07 boot partition
/dev/idsk08 optional filesytem (/u or /usr2)
These also have names of the form <$b+>/dev/dsk/c1d0s0<$b->, but
we prefer using the shorter names because they tend to be
less confusing. In addition, each block device mentioned has
a corresponding character (raw) device entry of the form
<$b+>/dev/ridsk00<$b-> (note initial `<$b+>r<$b->'). Generally, we use the block
devices where a choice exists.
The cartridge tape drive is not available in standalone mode
because the floppy is not large enough to hold /unix with the CTC
drivers. Because of this, there are no device entries in /dev
that correspond to any tape drives. There are intermediate
- 5 -
solutions to this problem but they are beyond the scope of this
document and not usually necessary.
<$b+>Mounting the hard drive onto the floppy<$b->
To gain access to the primary hard drive, partitions of
interest are mounted onto directories on the floppy. The device
names are selected from the table in the previous section.
Before mounting a partition, we recommend running the
filesystem check <$b+>fsck<$b->(1m) first. The mount command will fail
if the the superblock is not in order -- this is often the case
after a crash. In addition, it gives a convenient verification
of the device status and the the filesystem's name and volume.
# <$b+>/etc/fsck /dev/idsk00<$b->
While some errors are to be expected while checking the
root partition, a total failure is a very serious error. Our
experience defines "total failure" as an indication by fsck
that it cannot find any possible traces of a filesystem. In
particular, "<$b+>CAN NOT READ: BLK 1<$b->" is one of the more ominous
messages we have seen.
It indicates either (A) the partition tables have been
destroyed, (B) there are hardware problems with the drive, or
(C) the boot floppy is bad. If the same message is printed from
different boot floppies, and it remains after checking the drive
cables, call AT&T for help. The message "<$b+>hard disk: Bad sanity<$b->
<$b+>word in VTOC on drive 0<$b->" is a virtual guarantee of corrupted
partition tables, and the procedures for their repair are
dangerous, intricate and beyond the scope of this manual; call
AT&T for help.
Once fsck grants the filesystem a clean bill of health, it
is ready to be mounted. Rather than take up space for a handful
of common commands, AT&T has rolled several of them into one:
<$b+>fsys<$b->. It is undocumented and appears to only be used on the boot
floppy.
Fsys takes a handful of options, not all of which are
interesting to us in standalone mode. Used in the install
scripts for a handful of filesystem-related duties, we will use
it simply as a replacement for <$b+>mount<$b->(1m) and <$b+>umount<$b->(1m). To
mount the hard disk's root filesystem onto the floppy's <$b+>/install<$b->
directory, do:
# <$b+>fsys -m /install /dev/idsk00<$b->
Fsys will complain on an error, and this brings us to a
serious bug in this program: if <$b+>either <$b->the mount directory <$b+>or<$b->
the partition's device name are invalid for any reason, the error
message will <$b+>always<$b-> point to the partition device name. This can
- 6 -
be, to put it lightly, "misleading".
Anecdote: we were running a standalone boot on a machine
whose main drive had just come back from the shop. We were
being very cautious, having already had an exceedingly unpleasant
experience with hardware failure on this customer's machine.
When trying to mount the hard drive onto the floppy, we did:
# <$b+>fsys -m /mnt /dev/idsk00<$b->
fsys: /dev/idsk00: no such file or directory
A hard-disk based UNIX on a 3B2 usually has a <$b+>/mnt<$b-> directory
used as a floppy mount point, but the floppy UNIX does not have
one (<$b+>/install<$b-> should be used instead). At this point, however,
we were not aware of the nature of our mistake.
Since the device name <$b+>/dev/idsk00<$b-> was indeed found in /dev,
the above error message led us to believe that the drivers could
not find the hardware and the drive itself was in very bad shape
(again). Ten panicky minutes later we realized that the error
message was wrong, and mounting onto /install instead of /mnt
worked as expected.
With the hard drive's root filesystem mounted on /install,
it is now fully part of the standard directory tree. While
the floppy has no editor or many of the helpful tools, the root
partition does, and these can be exploited. When beginning an
extended standalone session on the primary drive, we have found
it helpful to extend the shell's search path:
# <$b+>PATH=/install/bin:/install/etc:$PATH ; export PATH<$b->
Now the familiar <$b+>ls<$b->, <$b+>ed<$b->, (but not <$b+>vi<$b->) and many other
commands are available. Since they will be loaded from the hard
drive, execution is much faster.
As an example, assume that the root password has been
forgotten and the machine is basically closed. The solution
suggested by AT&T's documentation (in the <$u+>System Administration<$u->
<$u+>Utilities Guide<$u->) is to do a partial restore. The difficulty with
this approach is that many important system files -- /etc/passwd,
/etc/inittab, /etc/gettydefs, and others -- are overwritten in
the process. Even with a full backup, this can be an unpleasant
<$i+><$i->undertaking.
An alternate approach will use the standalone shell. The
general strategy is to mount the hard drive, edit the password
file, and boot multiuser UNIX. The full procedure is:
(boot standalone /unix)
# <$b+>fsck /dev/idsk00<$b->
# <$b+>fsys -m /install /dev/idsk00<$b->
# <$b+>/install/bin/ed /install/etc/passwd<$b->
(edit the file in the standard way)
- 7 -
<$b+>w<$b->
<$b+>q<$b->
# <$b+>fsys -u /dev/idsk00<$b->
At this point, the root drive is now unmounted and the
system may be rebooted. We are not sure of the best way to do
this, so we usually sync the disk and return to firmware with:
# <$b+>sync<$b->
# <$b+>sync<$b->
# <$b+>/etc/uadmin 2 2<$b->
Uadmin(1m) is documented in the manual (you must also
refer to the uadmin(2) manual page) -- the above does a normal
return to the monitor (i.e., firmware). <$b+>WARNING<$b->: uadmin(1m)
is available from full UNIX as well but is very dangerous. Use
it with extreme caution and only if you really know what uadmin
does.
<$b+>Making a standalone boot disk<$b->
<$b+>================== WARNING ==================<$b->
<$b+>Only do this on backup copies of the disks,<$b->
<$b+>NEVER to the main Essential Utilities Disk.<$b->
<$b+>================== WARNING ==================<$b->
The Essential Utilities Disk 1 contains many files needed
by the automatic restore/upgrade procedures, but for standalone
work, many are not needed. After working with these disk for
some time, we were able to narrow down what is helpful to have
on the disk and what is not. The following procedure (run from
multiuser mode, signified by the ## prompt) will convert an
Essential Utilities disk to a standalone boot disk.
(from hard disk UNIX)
## <$b+>fsck /dev/dsk/c0d0s5<$b->
## <$b+>mount /dev/dsk/c0d0s5 /install<$b->
## <$b+>cd /install/inst/bin<$b->
## <$b+>mv fsys pdinfo swap ttyset ../../bin<$b->
## <$b+>cd /install<$b->
## <$b+>/bin/rm -rf inst<$b->
## <$b+>cp /bin/ed /install/bin<$b->
## <$b+>cp /etc/fsdb /install/etc<$b->
## <$b+>cat > /install/inittab<$b->
<$b+>is:s:initdefault:<$b->
<$b+>sh:s:respawn:/bin/sh < /dev/console > /dev/console 2>&1<$b->
<$b+>^D<$b->
## <$b+>cd /<$b->
## <$b+>umount /dev/dsk/c0d0s5<$b->
- 8 -
While there may be other files on this floppy that are not
needed, we have operated on the principle of least customization.
It has been our experience that keeping the procedure simple
allows it to be done on-the-fly (say, at a customer site) and
minimizes the exploration required when a new operating system
disk is released.
In addition, it is not wise to pack the disk too tightly.
The editor requires adequate space under <$b+>/tmp<$b->, so an almost-full
disk precludes editing all but the smallest files; this applies
whether the file being edited resides on the hard drive or the
floppy.
Once this is done, the new disk will come up in standalone
mode without the need for <$b+>magic mode<$b->. In addition ed(1) and
fsdb(1m) are available. The other tools mentioned (<$b+>pdinfo<$b->, <$b+>swap<$b->,
<$b+>ttyset<$b->) are helpful but not required by the basic procedures.
Over time, the resourcefull standalone booter will likely
develop tools that help repair damaged UNIX systems; these can
often go onto these boot floppies. Remember to <$b+>strip<$b->(1) files
before putting them onto the disk, because the symbol table is
useless and wastes precious space.
It has been our experience that any version (SVR2, SVR3)
of boot disk can be used with any version of hard disk UNIX
without difficulty for doing simple operations such a performing
filesystem checks or editing /etc/passwd. For more complex
operations, such as repartitioning the hard drive or restoring
the bootstraps, higher version compatibility is required.
<$b+>Security Considerations<$b->
It should be apparent that knowledge of these standalone
methods is tremendously powerful. In addition to being able to
rescue a foundering machine, an unrestricted path to root has
been provided as well. While all the standard rules about
physical security of the computer apply here, an additional step
may be taken to thwart a would-be interloper.
The responsible system administrator of a machine in a
hostile environment will generally change the computer's firmware
password. This magic word is required before the monitor on
the 3B2 motherboard will boot from a floppy, and lack of this
password prevents a malicious user from simply pulling the power
plug to enter firmware mode.
In addition to changing the firmware password, the <$b+>floppy<$b->
<$b+>key<$b-> floppy should itself be secured. When the computer is
restarted with this disk in the drive, it will clear the
non-volatile RAM (NVRAM) and restore the default parameters.
Because the firmware password is included in these "default
- 9 -
parameters", this disk should be kept out of non-trusted hands.
<$b+>Conclusion<$b->
For those comfortable with its use, a standalone shell can
be a time/lifesaver and can obviate the need for many partial
and full restores. Those wishing to use the methods described
here are encouraged to explore them prior to their need. The
experience gained by a relaxed hour or two of investigation will
be more than repaid when the machine crashes and the procedures
are no longer "optional."
In addition, the layout of a standard boot disk varies
somewhat from release to release. While the general approach to
a standalone boot remains similar, some preliminary examination
may forestall unpleasant surprises when the machine conditions
are less hospitable.
We solicit bug reports, comments, and suggestions on this
document. Please direct them to:
V-Systems, Inc.
39 Brookhollow Drive
Santa Ana, CA 92705-5440
(714) 545-6442
Attn: Steve Friedl
Internet: friedl at vsi.com
AT&T Mail: attmail!vsi!friedl
Usenet: {backbones}!vsi.com!friedl
- 10 -
#------------------------- cut here ------------------------------------
More information about the Comp.sys.att
mailing list