demasi@paisano.UUCP (Michael C. De Masi) (04/16/88)
Hello again,
Being an administrator on several machines (various 3b's
running a few different versions of Sys V) I sometimes
find myself in the position of doing 'partial restores'
on my machines due to passwd files getting munged, inittabs
disappearing or someone forgetting their root password.
(generally user oriented problems)
A 'partial restore', which basically just replaces the
important system files with more or less vanilla versions
thereof usually works fine to get the machine to a more
or less workable state. This is usually followed by
replacing the clobbered system files with acceptable
backups, which also works fine. The only problem arises
with the fact that after a partial restore, one has to
reload every piece of software that conatins some sort
of a device driver. This also does the job, but is very
time consuming and a real drag with user's and developers
breathing down your back.
Now, I've been told that there is indeed a way to
reassociate a driver with a device short of re-installing
the whole package for the given device. This sounds correct
to me, since I don't think the 'partial restore' actually touches
the drivers in any way other than to somehow disconnect them
from the new /unix.
Anybody have any ideas?
---
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
2340 Dulles Corner Blvd. Herndon, Virginia 22071 Phone: 703-834-8123
UUCP: decuac!grebyn!paisano!demasi
"All things considered, I'd rather be in Philadelphia" - W C Fields
UNIX, Sys V and 3b are registered trademarks of AT&T.friedl@vsi.UUCP (Stephen J. Friedl) (04/16/88)
In article <406@paisano.UUCP>, Michael C. De Masi writes: > Being an administrator on several machines (various 3b's > running a few different versions of Sys V) I sometimes > find myself in the position of doing 'partial restores' > on my machines due to passwd files getting munged, inittabs > disappearing or someone forgetting their root password. > (generally user oriented problems) > > A 'partial restore', which basically just replaces the > important system files with more or less vanilla versions > thereof usually works fine to get the machine to a more > or less workable state. In many cases it is not necessary to do a standalone restore, as it trashes some pretty important files. There is a method to operate a standalone UNIX from the boot floppy by saying a few magic words. From there you can get a # prompt and do fsck, mount, etc. I use this all the time and almost never have to do a restore of any kind. It's wonderful. Michael's posting has prompted me to put down my thoughts on how to operate as a standalone shell. I'll send a copy to anybody who asks via email, and if I get enough requests I'll post it. NOTE: these are not automated procedures like the sysadm menus; you need a fair amount of Unix sysadm experience and you need to think fast on your feet. Beware... P.S. - this is for the 3B2 only... -- Steve Friedl V-Systems, Inc. "Yes, I'm jeff@unh's brother" friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
rwhite@nusdhub.UUCP (Robert C. White Jr.) (04/17/88)
in article <406@paisano.UUCP>, demasi@paisano.UUCP (Michael C. De Masi) says: > Now, I've been told that there is indeed a way to > reassociate a driver with a device short of re-installing > the whole package for the given device. This sounds correct > to me, since I don't think the 'partial restore' actually touches > the drivers in any way other than to somehow disconnect them > from the new /unix. Forgive me if I'm wrong, this is from memory.... This is somewhat what you need to do: [for 3b2(s) only] # This Will update all you kernel Drivers # This is not strictly necessary, but it can't hurt and # dosn't take much time [1 min or so] cd /boot mkboot -k KERNEL for AA in [!K]* do mkboot ${AA} done [This is the part I'm not shure about.... It may be done FOR YOU in step 4, if you try to complete the procedure without doing this step NO HARM will result. I havent had to do this whole thing, under SVR3 so I would NOT do this the first time. If you skip this step, and it dosn't work, you may restart from here. Either way, the results will be obvious when you get to step four... you may or may not have to:] EDIT your /etc/system to have an "INCLUDE" for every "new" driver. This will be done for you if you have restored the old /etc/system with the rest of your restore. Go to "firmware mode". This is where you have to be to do the next little little bit of magic. Going to firmware mode should be no mystery to you if you have been doing partal restores. Go to the next step when you have gotten to the "what program do you want to run" firmware prompt. THIS IS IT!!! The magic part!! Tell the firmware that you want to EXECUTE /etc/system. [yes, I know, /etc/system is NOT executable in any form, but the firmware will read it's contents and use the file to rebuld your /UNIX] You should first see a listing of all the modules the system will attempt to load. There will then be a [frighteningly!] long pause, and then you will get a four [or more] column load map of your kernel [name, text, data, <and I forget>]. All of this will be followed by the boot sequence you normally see when you load new drivers from diskette. I wouldn't suggest editing /etc/system with any regularity, but any of the other steps can be done safely on a stable system. The only real warning in all of this is that removing the SCSI entry from /etc/system and/or nukeing the edt will make the 600 unbootable until you do a _full_ restore. ALWAYS "cp /unix /oldunix" BEFORE DOING _ANY_ OF THIS ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 3B2 Security Hole cum System Saver.: If you loose the root password for a system you can recover it if you can log in as "sys" this is done via the "mv" command. This will probably reduce your "partial restore" efforts. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< << All the STREAM is but a page,<<|>> Robert C. White Jr. << << and we are merely layers, <<|>> nusdhub!rwhite nusdhub!usenet << << port owners and port payers, <<|>>>>>>>>"The Avitar of Chaos"<<<<<<<<<<<< << each an others audit fence, <<|>> Network tech, Gamer, Anti-christ, << << approaching the sum reel. <<|>> Voter, and General bad influence. << <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ## Disclaimer: You thought I was serious???...... Really???? ## ## Interogative: So... what _is_ your point? ;-) ## ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lynn@engr.uky.edu (H. Lynn Tilley) (04/18/88)
In article <406@paisano.UUCP> demasi@paisano.UUCP (Michael C. De Masi) writes: > [much text deleted.] > >Now, I've been told that there is indeed a way to >reassociate a driver with a device short of re-installing >the whole package for the given device. > I would be very interested in the answer to this problem and in addition maybe I could get some help on a problem we have around here. We have several 3b2/310s that we are using on an ethernet. Everything works great expect for on one machine. When this machine is rebooted it never recognizes that it has the ethernet drivers in place. The instant the machine returns to life it starts spewing "Network Down" messages. We have to go into the sysadmin menues, shutdown all network daemons and then reinstall the TCP/IP WIN software. Admittedly not a big task, but it is still a problem that I would like to clear up. We have tried to check to see that all the files have the correct permissions and that no important files are getting removed, etc. Any suggestions appreciated. Thanks in advance. -- | Henry L. Tilley UUCP: {cbosgd|uunet}!ukma!ukecc!lynn | University of Kentucky CSNET: lynn@engr.uky.edu V Engineering Computer Center BITNET: lynn%ukecc.uucp@ukma O voice: (606) 257-1752 ARPANET: lynn@a.ecc.engr.uky.edu
friedl@vsi.UUCP (Stephen J. Friedl) (04/20/88)
Hi folks,
I recently posted a note advertising a guide to running
a standalone shell off the boot floppy on a 3B2 and I got lots
of requests. I'll post it in a couple of days after I clean
it up and add a few more sections. Thanks for all the mail...
Steve
--
Steve Friedl V-Systems, Inc. Wizard of undocumented 3B stuff
friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedllenny@icus.UUCP (Lenny Tropiano) (04/22/88)
In article <571@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: |>Hi folks, |> |> I recently posted a note advertising a guide to running |>a standalone shell off the boot floppy on a 3B2 and I got lots |>of requests. I'll post it in a couple of days after I clean |>it up and add a few more sections. Thanks for all the mail... |> 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. Boot the foundation disk #1 (yes, the first disk) and get to the part that asks.. 1) Full Restore 2) Partial Restore 3) ... And at the prompt that is asking you to enter the particular option, type "magic mode<CR>" You will then get: Poof! And added to the prompt is .. Enter [ ... shell] You type "shell" and you get a "#", / being the floppy. Of course there isn't too many things on that floppy (enough to get yourself going) but you should mount your "HARD DISK" using the (fsys(1M) command). I don't remember the exact syntax, it's been a while... but I think it's: # fsys -m /dev/dsk/c1d0s0 Or something to that effect... and to unmount (don't forget this) use the "-u" option. But this will get you started anyhow. -Lenny -- US MAIL : Lenny Tropiano, ICUS Computer Group IIIII CCC U U SSS PO Box 1 I C U U S Islip Terrace, New York 11752 I C U U SS PHONE : (516) 968-8576 [H] (516) 582-5525 [W] I C U U S TELEX : 154232428 [ICUS] IIIII CCC UUU SSS AT&T MAIL: ...attmail!icus!lenny UUCP : ...{mtune, ihnp4, boulder, talcott, sbcs, bc-cis}!icus!lenny
friedl@vsi.UUCP (Stephen J. Friedl) (04/26/88)
In article <353@icus.UUCP>, lenny@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@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@vsi.com AT&T Mail: attmail!vsi!friedl Usenet: {backbones}!vsi.com!friedl - 10 - #------------------------- cut here ------------------------------------