All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
@(#)2.t 6.5 (Berkeley) 5/7/91
.bp .nr H1 2 .nr H2 0 .bp
2. BOOTSTRAP PROCEDURE .R
Note: The \*(4B release contains only Tahoe filesystems and executable
images.
The procedures in this section cannot be used on the VAX
with the \*(4B distribution tape supplied by Berkeley.
However, it is possible to make a boot tape that can be used in this way
by extracting the sources in the distribution tape on a VAX, compiling,
and making a tape using the procedures described in Appendix A.
This section explains the bootstrap procedure that can be used
to get the kernel supplied with this distribution running on your machine.
If you are not currently running 4.2BSD or 4.3BSD you will
have to do a full bootstrap using a 4.3BSD tape;
to install the \*(4B release, the new sources must then be loaded
and compiled.
Chapter 3 describes how to upgrade an existing 4.2BSD or 4.3BSD system.
programs.
An understanding of the operations used in a full bootstrap
is very helpful in performing an upgrade as well.
In either case, it is highly desirable to read and understand
the remainder of this document before proceeding.
Converting pre-4.2BSD Systems
The file system format was changed between 3BSD and 4.0BSD, and again between 4.1BSD and 4.2BSD. At a minimum you will have to dump any old file systems, and then restore them onto the \*(4B file system. Sites running 3BSD or 32/V may be able to modify the restore program to understand the old 512 byte block file system, but this has never been tried. The dump format used in 4.0BSD and 4.1BSD is backward-compatible with that used in \*(4B (which is unchanged from 4.2BSD). That is, the \*(4B restore program understands how to read 4.0BSD and 4.1BSD dump tapes, although \*(4B dump tapes cannot be restored under 4.0BSD or 4.1BSD. It is also desirable to make a convenient copy of system configuration files for use as guides when setting up the new system; the list of files to save from 4.2BSD systems in chapter 3 may be used as a guideline.
The first step is to dump your file systems with dump\|(8). For the utmost of safety this should be done to magtape. However, if you enjoy gambling with your life (or you have a VERY friendly user community) and you have enough disk space, you can try converting your file systems while copying to a new disk partition by piping the output of dump directly into restore after bringing up \*(4B. If you select the latter tack, a version of the 4.1BSD dump program that runs under \*(4B is provided in /etc/dump.4.1. Beware that file systems created under \*(4B can use about 5-10% more disk space for file system related information than under 4.1BSD. Thus, before dumping each file system it is a good idea to remove any files that may be easily regenerated. Since all programs should be recompiled under the new system, your best bet is to remove any object files. File systems with at least 10% free space on them should restore into an equivalently sized \*(4B file system without problem. Booting from tape
The tape bootstrap procedure used to create a working system involves the following major steps:
Certain of these steps are dependent on your hardware configuration. Formatting the disk pack used for the root file system may require using the DEC standard formatting programs. Also, if you are bootstrapping the system on an 11/750, no console cassette is created.
Bootstrapping an 8600 is a bit more difficult than bootstrapping the other machines. The procedures for loading the toggle program and reading the tape bootstrap monitor described in Appendix B must be used if you do not have access to a console RL02 pack with a UNIX bootstrap. Such a pack may be made on an 8600 already running UNIX, or on another \*(4B system with an RL02 drive using the procedures in 4.1.1. One may be required to enter the toggle program more than once. After the bootstrap monitor is loaded, device addresses will be the same as if the machine were an 11/780. UNIBUS and MASSBUS adaptors are numbered from zero across both SBIA's (if present).
The following sections describe the above steps in detail. In these sections references to disk drives are of the form xx(n,m) and references to files on tape drives are of the form yy(n,m) where xx and yy are names described in section 1.4 and n and m are the unit and offset numbers described in section 1.4. Commands you are expected to type are shown in italics, while that information printed by the system is shown emboldened. Throughout the installation steps the reboot switch on a 780 or 730 should be set to off; on an 8600 or 750 set the power-on action to halt. (In normal operation a 780 or 730 will have the reboot switch on and an 8600 or 750 will have the power-on action set to reboot/restart.)
If you encounter problems while following the instructions in this part of the document, refer to Appendix C for help in troubleshooting. Step 1: formatting the disk
All disks used with \*(4B should be formatted to insure the proper handling of physically corrupted disk sectors. If you have DEC disk drives, you should use the standard DEC formatter to format your disks. If not, the format program included in the distribution, or a vendor supplied formatting program, may be used to format disks. The format program is capable of formatting any of the following supported distribution devices:
| EMULEX MASSBUS: AMPEX Capricorn, 9300, CDC 9766, 9775, |
| FUJITSU 330M, 2351 Eagle |
| EMULEX SC-21V, SC-31 AMPEX 9300, Capricorn, CDC 9730, 9766, |
| UNIBUS: FUJITSU 160M, 330M |
| EMULEX SC-31 UNIBUS: FUJITSU 2351 Eagle |
If you have run a pre-4.1BSD version of UNIX on the packs you are planning to use for bootstrapping it is likely that the bad sector information on the packs has been destroyed, since it was accessible as normal data in the last several tracks of the disk. You should therefore run the formatter again to make sure the information is valid.
On an 11/750, to use a disk pack as a bootstrap device, sectors 0 through 15, the disk sectors in the file ``/boot'' (the program that loads the system image), and the file system indices that lead to this file must not have any errors. On an 8600, 11/780, or 11/730, the ``boot'' program is loaded from the console medium and includes device drivers for the ``hp'' and ``up'' disks that do ECC correction and bad sector forwarding; consequently, on these machines the system may be bootstrapped on these disks even if the disk is not error free in critical locations. In general, if the first 15884 sectors of your disk are clean you are safe; if not you can take your chances.
To load the format program, insert the distribution TU58 cassette or RX01 floppy disk in the appropriate console device (on the 11/730 use cassette 0) and do the following steps.
If you have an 8600 start the bootstrap monitor using the procedure described in Appendix B. Then give the command: .RT =\|format
If you have an 11/780 give the commands: .RT >>>\|HALT >>>\|UNJAM >>>\|INIT >>>\|LOAD FORMAT >>>\|START 2
If you have an 11/750 give the commands: >>>\|I >>>\|B DDA0 =\|format
If you have an 11/730 give the commands: >>>\|H >>>\|I >>>\|L DD0:FORMAT >>>\|S 2
The format program should now be running and awaiting your input: Disk format/check utility Enable debugging (1=bse, 2=ecc, 3=bse+ecc)?
If you made a mistake loading the program off the TU58 cassette or using the bootstrap monitor loaded for the 8600 the ``='' prompt should reappear and you can retype the program name. If something else happened, you may have a bad distribution cassette or floppy, or your hardware may be broken; refer to Appendix C for help in troubleshooting. If you are unable to load programs off the distributed medium, consult Appendix B for an alternate (more painful) approach.
Format will create sector headers and verify the integrity of each sector formatted. Remember format runs only on the up and hp drives listed above. Format will prompt for the information required as shown below. Questions with default answers appear with the default in parentheses at the prompt; a carriage return will take the default. If you err in answering questions, ``Delete'' erases the last character typed, and ``^U'' erases the current input line. Enable debugging (0=none, 1=bse, 2=ecc, 3=bse+ecc)? 0 Device to format? xx(0,0) ...(the old bad sector table is read; ignore any errors that occur here)... Formatting drive xx0 on adaptor 0: verify (yes/no)? yes Device data: #cylinders=842, #tracks=20, #sectors=48 Starting cylinder (0): (hit RETURN to accept the defaults) Starting track (0): Ending cylinder (841): Ending track (19): Available test patterns are: 1 - (f00f) RH750 worst case 2 - (ec6d) media worst case 3 - (a5a5) alternating 1's and 0's 4 - (ffff) Severe burnin (up to 48 passes) Pattern (one of the above, other to restart)? 2 Maximum number of bit errors to allow for soft ECC (3): Start formatting...make sure the drive is online ...(soft ecc's and other errors are reported as they occur)... ...(if 4 write check errors were found, the program terminates like this)... Errors: Bad sector: 0 Write check: 4 Hard ECC: 0 Other hard: 0 Marked bad: 0 Skipped: 0 Total of 4 hard errors revectored. Writing bad sector table at block 524256 ...(524256 is the block # of the first block in the bad sector table)... Done Once the root device has been formatted, format will prompt for another disk to format. Halt the machine by typing ``control-P'' and ``H'' (the ``H'' is necessary only on the 780 and 8600, but does not hurt on the other machines). Enable debugging (1=bse, 2=ecc, 3=bse+ecc)?^P >>>\|H
It may be necessary to format other drives before constructing file systems on them; this can be done at a later time with the steps just performed. Format can also be used in an extended test mode (pattern 4) that uses numerous test patterns in up to 48 passes to detect as many disk surface errors as possible; this test may be run for many hours, depending on the CPU and controller. On an 11/780, this can be sped up significantly by setting the clock fast. It may be run for some number of passes, then either terminated or continued according to the errors found to that point. Step 2: copying the mini-root file system
The second step is to run a simple program, copy, which copies a small root file system into the second partition of the disk. This file system will serve as the base for creating the actual root file system to be restored. The version of the operating system maintained on the ``mini-root'' file system understands that it should not swap on top of itself, thereby allowing double use of the disk partition. Copy is loaded just as the format program was loaded; for example, on an 8600 or 8200, one must enter the toggle and the bootstrap monitor as described in Appendix B and then:
| (copy mini root file system) |
| =\|copy |
| From: yy(y,1) (unit y, second tape file) |
| To: xx(x,1) (mini root is on drive x; second partition) |
| Copy completed: 205 records copied |
| From: |
| (copy mini root file system) |
| >>>\|LOAD COPY |
| >>>\|START 2 |
| From: yy(y,1) (unit y, second tape file) |
| To: xx(x,1) (mini root is on drive x; second partition) |
| Copy completed: 205 records copied |
| From: |
| (copy mini root file system) |
| >>>\|B DDA0 |
| =\|copy |
| From: yy(y,1) (unit y, second tape file) |
| To: xx(x,1) (mini root is on drive x; second partition) |
| Copy completed: 205 records copied |
| From: |
| (copy mini root file system) |
| >>>\|L DD0:COPY |
| >>>\|S 2 |
| From: yy(y,1) (unit y, second tape file) |
| To: xx(x,1) (mini root is on drive x; second partition) |
| Copy completed: 205 records copied |
| From: |
You now have the minimal set of tools necessary to create a root file system and restore the file system contents from tape. To access this file system load the bootstrap program and boot the version of unix that has been placed in the ``mini-root'': (follow the procedure in Appendix B to load the bootstrap monitor)
| (load bootstrap program) |
| =\|boot |
| Boot |
| : xx(x,1)vmunix (bring in vmunix off mini root) |
| (load bootstrap program) |
| >>>\|BOOT ANY |
| Boot |
| : xx(x,1)vmunix (bring in vmunix off mini root) |
| (load bootstrap program) |
| >>>\|B DDA0 |
| =\|boot |
| Boot |
| : xx(x,1)vmunix (bring in vmunix off mini root) |
| (load bootstrap program) |
| >>>\|L DD0:BOOT |
| >>>\|D RB 3 |
| >>>\|S 2 |
| Boot |
| : xx(x,1)vmunix (bring in vmunix off mini root) |
The standalone boot program should then read the system from the mini root file system you just created, and the system should boot: 271944+78848+92812 start 0x12e8 4.3 BSD UNIX #1: Wed Apr 9 23:33:59 PST 1988 karels@monet.berkeley.edu:/usr/src/sys/GENERIC real mem = xxx avail mem = yyy ... information about available devices ... root device? .R
The first three numbers are printed out by the bootstrap programs and are the sizes of different parts of the system (text, initialized and uninitialized data). The system also allocates several system data structures after it starts running. The sizes of these structures are based on the amount of available memory and the maximum count of active users expected, as declared in a system configuration description. This will be discussed later.
UNIX itself then runs for the first time and begins by printing out a banner identifying the release and version of the system that is in use and the date that it was compiled.
Next the mem messages give the amount of real (physical) memory and the memory available to user programs in bytes. For example, if your machine has 16 megabytes of memory, xxx will be 16777216.
The messages that come out next show what devices were found on the current processor. These messages are described in autoconf\|(4). The distributed system may not have found all the communications devices you have (dh's, dz's, etc.), or all the mass storage peripherals you have especially if you have more than two of anything. You will correct this soon, when you create a description of your machine from which to configure UNIX. The messages printed at boot here contain much of the information that will be used in creating the configuration. In a correctly configured system most of the information present in the configuration description is printed out at boot time as the system verifies that each device is present.
The \*(lqroot device?\*(rq prompt was printed by the system and is now asking you for the name of the root file system to use. This happens because the distribution system is a generic system. It can be bootstrapped on any VAX cpu and with its root device and paging area on any available disk drive. You should respond to the root device question with xx0*. This response supplies two pieces of information: first, xx0 shows that the disk it is running on is drive 0 of type xx, secondly the \*(lq*\*(rq shows that the system is running \*(lqatop\*(rq the paging area. The latter is most important, otherwise the system will attempt to page on top of itself and chaos will ensue. You will later build a system tailored to your configuration that will not ask this question when it is bootstrapped. root device? xx0* WARNING: preposterous time in file system -- CHECK AND RESET THE DATE! erase ^?, kill ^U, intr ^C #
The \*(lqerase ...\*(rq message is part of /.profile that was executed by the root shell when it started. This message is present to remind you that the line character erase, line erase, and interrupt characters are set to be what is standard on DEC systems; this insures that things are consistent with the DEC console interface characters. Step 4: restoring the root file system
UNIX is now running, and the `UNIX Programmer's manual' applies. The `#' is the prompt from the shell, and lets you know that you are the super-user, whose login name is \*(lqroot\*(rq. To complete installation of the bootstrap system two steps remain. First, the root file system must be created, and second a boot floppy or cassette must be constructed.
To create the root file system the shell script \*(lqxtr\*(rq should be run as follows: # disk=xx0 type=tt tape=yy xtr where xx0 is the name of the disk on which the root file system is to be restored (unit 0), tt is the type of drive on which the root file system is to be restored (see the table below), and yy is the name of the tape drive on which the distribution tape is mounted.
If the root file system is to reside on a disk other than unit 0 (as the information printed out during autoconfiguration shows), you will have to create the necessary special files in /dev and use the appropriate value. For example, if the root should be placed on hp1, you must create /dev/rhp1a and /dev/hp1a using the MAKEDEV script in /dev as follows: # cd /dev; MAKEDEV hp1 The following table lists the various drive types.
| Drive Type Drive Type |
| DEC RM03 type=rm03 DEC RM05 type=rm05 |
| DEC RM80 type=rm80 DEC RP06 type=rp06 |
| DEC RP07 type=rp07 DEC RK07 type=rk07 |
| DEC RA80 type=ra80 DEC RA60 type=ra60 |
| DEC RA81 type=ra81 DEC R80 type=rb80 |
| DEC RA70 type=ra70 DEC RA82 type=ra82 |
| DEC RD53 type=rd53 DEC RD54 type=rd54 |
| CDC 9766 type=9766 CDC 9775 type=9775 |
| AMPEX 300M type=9300 AMPEX 330M type=capricorn |
| FUJITSU 160M type=fuji160 FUJITSU 330M type=capricorn |
| FUJITSU 404M type=eagle |
If the machine is an 8600, 8200, 11/780 or 11/730, a boot floppy,
cassette, or console RL02 should be constructed according to the
instructions in chapter 4. For 11/750's, bootstrapping is performed by
using a boot prom and special code located in sectors 0-15 of the
root file system. The
disklabel program installs the needed code.
XXX needs thought:
Locate the disk name and type from the table in step 7, then
run the following command:
# disklabel -rw ${disk}0 $type "optional_pack_name"
On an 11/780 with old-style (MS780C) interleaved memory, or other
configurations that
require alteration of the standard boot files, this step may
be left for later.
Step 6: rebooting the completed root file system
With the above work completed, all that is left is to reboot: #\|sync (synchronize file system state) #\|^P (halt machine) >>>\|HALT (for 11/780's) >>>\|UNJAM (for 8600's or 11/780's only) >>>\|I (initialize processor state) >>>\|B xxS (on an 11/750, use B/2; see below for 8200) ...(boot program is eventually loaded)... Boot : xx(x,0)vmunix (vmunix brought in off root) 271944+78848+92812 start 0x12e8 4.3 BSD UNIX #1: Wed Apr 9 23:33:59 PST 1988 karels@monet.berkeley.edu:/usr/src/sys/GENERIC real mem = xxx avail mem = yyy ... information about available devices ... root on xx0 WARNING: preposterous time in file system -- CHECK AND RESET THE DATE! erase ^?, kill ^U, intr ^C #
On an 8200, or if the root device selected by the kernel is not correct, it is necessary to boot using the option to ask for the root device. On the 8200, use B/R5:800 followed by @ANYBOO.CMD; on the 11/750, use B/3; on the other processors, use BOOT ANY. At the prompt from the bootstrap, use the same device specification above: xx(x,0)vmunix. Then, to the question ``root device?,'' respond with xx0. See section 6.1 and appendix C if the system does not reboot properly.
The system is now running single user on the installed root file system. The next section tells how to complete the installation of distributed software on the /usr file system. Step 7: placing labels on the disks
First set up shell variables, so that the commands we give will work regardless of the disk you have. You might wish to review the disk configuration information in section 4.3 before continuing; the partitions used below are those most appropriate in size. Find the disk you have in the following table and execute the commands in the right hand portion of the table:
| DEC RM03 # disk=hp; name=hp0g; type=rm03 |
| DEC RM05 # disk=hp; name=hp0g; type=rm05 |
| DEC RM80 # disk=hp; name=hp0g; type=rm80 |
| DEC RP06 # disk=hp; name=hp0g; type=rp06 |
| DEC RP07 # disk=hp; name=hp0h; type=rp07 |
| DEC RK07 # disk=hk; name=hk0g; type=rk07 |
| DEC RA60 # disk=ra; name=ra0h; type=ra60 |
| DEC RA70 # disk=ra; name=ra0h; type=ra70 |
| DEC RA80 # disk=ra; name=ra0h; type=ra80 |
| DEC RA81 # disk=ra; name=ra0h; type=ra81 |
| DEC RA82 # disk=ra; name=ra0h; type=ra82 |
| DEC R80 # disk=rb; name=rb0h; type=rb80 |
| UNIBUS CDC 9766 # name=up0g; type=9766 |
| UNIBUS AMPEX 300M # disk=up; name=up0g; type=9300 |
| UNIBUS AMPEX 330M # disk=up; name=up0g; type=capricorn |
| UNIBUS FUJITSU 160M # disk=up; name=up0g; type=fuji160 |
| UNIBUS FUJITSU 330M # disk=up; name=up0g; type=capricorn |
| UNIBUS FUJITSU 404M # disk=up; name=up0h; type=eagle |
| MASSBUS CDC 9766 # disk=up; name=hp0g; type=9766 |
| MASSBUS AMPEX 300M # disk=up; name=hp0g; type=9300 |
| MASSBUS AMPEX 330M # disk=up; name=hp0g; type=capricorn |
| MASSBUS FUJITSU 330M # disk=up; name=hp0g; type=capricorn |
| MASSBUS FUJITSU 404M # disk=up; name=hp0h; type=eagle |
| DEC TE16/TU45/TU77 # cd /dev; MAKEDEV ht0; sync |
| DEC TU78 # cd /dev; MAKEDEV mt0; sync |
| DEC TS11 # cd /dev; MAKEDEV ts0; sync |
| DEC TK50/TK70/TA80/TA81 # cd /dev; MAKEDEV tmscp0; sync |
| EMULEX TC11 # cd /dev; MAKEDEV tm0; sync |
| SI 9700 # cd /dev; MAKEDEV ut0; sync |
On hp and ra disks (excluding those on the KDB50), \*(4B uses disk labels in the first sector of each disk to contain information about the geometry of the drive and the partition layout. This information is written with disklabel\|(8). To label the disk containing the root file system, run the following command: # disklabel -rw ${disk}0 $type "optional_pack_name" This sets up the default partition table. Type can be any name listed in /etc/disktab; if you want something other than the default tables, you can edit /etc/disktab and add a new name: e.g., ``ra81-local.'' Alternatively, you can use the -e option to edit the label; you will have to set the ``EDITOR'' environment variable to /bin/ed: # EDITOR=/bin/ed; export EDITOR
You should label all your disks as soon as possible, but you must label the root pack on a VAX-11/750, even if labels are not supported (e.g., on ``up'' disks), as this also creates the boot block. As a general rule, it is always safe to run disklabel: if labels are not supported on some disk, nothing of consequence will happen. Step 8: setting up the /usr file system
The next thing to do is to extract the rest of the data from the tape:
| # date yymmddhhmm (set date, see date\|(1)) |
| .... |
| # passwd root (set password for super-user) |
| New password: (password will not echo) |
| Retype new password: |
| # hostname mysitename (set your hostname) |
| # newfs ${name} ${type} (create empty user file system) |
| (this takes a few minutes) |
| # mount /dev/${name} /usr (mount the usr file system) |
| # cd /usr (make /usr the current directory) |
| # mt fsf |
| # tar xpbf 20 /dev/rmt12 (extract all of usr except usr/src) |
| (this takes about 15-20 minutes) |
| # mt fsf (do not do on 1600bpi tapes) |
| # mkdir src (make directory for source) |
| # mkdir src/sys (make directory for system source) |
| # cd src/sys (make /usr/sys the current directory) |
| # tar xpbf 20 /dev/rmt12 (extract the system source) |
| (this takes about 5-10 minutes) |
| # cd / (back to root) |
| # chmod 755 / /usr /usr/src /usr/src/sys |
| # rm -f sys |
| # ln -s usr/src/sys sys (make a symbolic link to the system source) |
| # umount /dev/${name} (unmount /usr) |
You can check the consistency of the /usr file system by doing # fsck /dev/r${name} The output from fsck should look something like: ** /dev/rxx0h ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 671 files, 3497 used, 137067 free (75 frags, 34248 blocks) .R
If there are inconsistencies in the file system, you may be prompted to apply corrective action; see the document describing fsck for information.
To use the /usr file system, you should now remount it by saying # /etc/mount /dev/${name} /usr You can then extract the source code for the commands (except on RK07's and RM03's this will fit in the /usr file system): # cd /usr/src # mt fsf # tar xpb 20 If you get an error at this point, most likely it was a problem with tape positioning. You can reposition the tape by rewinding it and then skipping over the files already read (see mt\|(1)). Additional software
There is one additional tape file on the distribution tape(s) which has not been installed to this point; it contains user contributed software in tar\|(1) format. On the 1600bpi tape set, this file is the sole file on the third tape. It can be installed by positioning the tape using mt\|(1) and reading in the files as was done for /usr/src above. As distributed, the user contributed software should be placed in /usr/src/new. It may be extracted by mounting the appropriate tape (if not already mounted), positioning the tape at the beginning of this file (for 6250bpi), and extracting with tar : # cd /usr/src # mkdir new # chmod 755 new # cd new # tar xpb 20 Several of the directories for large contributed software subsystems have been placed in a single archive file and compressed to allow Additional conversion information
After setting up the new \*(4B filesystems, you may restore any user files that were saved on tape before beginning the conversion. Note that the \*(4B restore program does its work on a mounted file system using normal system operations (unlike the 4.1BSD restor that accessed the raw file system device and deposited inodes in the appropriate locations on disk). This means that file system dumps may be restored even if the characteristics of the file system changed. To restore a dump tape for, say, the /a file system something like the following would be used: # mkdir /a # disklabel -rw hp1 eagle # newfs hp1g # mount /dev/hp1g /a # cd /a # restore r If you chose to convert 4.1BSD filesystems while copying to a new disk area, do so by piping the output of dump.4.1 directly into restore after bringing up \*(4B.
If tar images were written instead of doing a dump, you should be sure to use the `p' option when reading the files back. No matter how you restore a file system, be sure and check its integrity with fsck when the job is complete.
To convert a compiler from 4.1BSD to \*(4B you should simply have to recompile and relink the various parts. If the processor is written in itself, for instance a P\s-2ASCAL\s0 compiler written in P\s-2ASCAL\s0, the important step in converting is to save a working copy of the 4.1BSD binary before converting to \*(4B. Then, once the system has been changed over, the 4.1BSD binary should be used in the rebuilding process. To do this, you should enable the 4.1 compatibility option when you configure the kernel (see section 4.3).
If no working 4.1BSD binary exists, or the language processor uses some nonstandard system call, you will likely have to compile the language processor into an intermediate form, such as assembly language, on a 4.1BSD system, then bring the intermediate form to \*(4B for assembly and loading.