All rights reserved.
%sccs.include.redist.roff%
@(#)2.t 1.8 (Berkeley) 05/07/91
.bp .nr H1 2 .nr H2 0 .bp
2. BOOTSTRAP PROCEDURE .R
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 you will have to do a full bootstrap. Chapter 3 describes how to upgrade a 4.2BSD system. 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. Booting from tape
The tape bootstrap procedure used to create a working system involves the following major steps:
The following sections describe the above steps in detail. In these sections references to disk drives are of the form xx\|(d, p) and references to files on tape drives are of the form xx\|(c,d, p) where xx are device types described in section 1.4, c is the (optional) controller unit number, d is the drive unit number, and p is a disk partition or tape file offset numbers as described in section 1.4. For the sake of simplicity, all disk examples will use the disk type ``dk'' and all tape examples will similarly use ``cy''; the examples assume drive 0, partition 0. Commands you are expected to type are shown in italics, while that information printed by the system is shown emboldened.
If you encounter problems while following the instructions in this part of the document, refer to Appendix B 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. The vdformat program included in the distribution, or a vendor supplied formatting program, may be used to format disks if this has not already been done. The vdformat program is capable of formatting any of the disk drives listed in section 1.1, when booting from tape; when booting from disk, it supports any drive listed in /etc/disktab.
To load the vdformat program, perform the following steps.
| (machine powered up) |
| MIB POC |
| Type '#' to cancel boot |
| # (cancel automatic reboot) |
| CP [a10.h0]#>\|h (halt the cpu) |
| #>\|fd cyp(0,0) (make cypher default device) |
| #>\|p23 3. 00000000 (set boot flags) |
| #>\|y. (initialize the machine) |
| #>\|fb (boot machine) |
| cyp(0,0)/etc/fstab |
| CP cold boot |
| 4 way interleave set |
| CPU memory test |
| ECC CPU memory test |
| cyp(0,0)/. |
| CPU POC1 |
| cyp(0,0)/poc1 |
| CPU POC2 |
| cyp(0,0)/poc2 |
| FPP POC (only if floating point processor present) |
| cyp(0,0)/fppoc |
| FPP WCS (only if floating point processor present) |
| cyp(0,0)/fppwcs |
| BOOT SYSTEM cyp(0,0)/boot |
| Boot |
| :cy(0,0)stand/vdformat (load and run from first tape file) |
| 52224+17408+1177716 start 0x1000 |
| VDFORMAT Berkeley Version 1.6 |
The vdformat program should now be running and awaiting your input. If you made a mistake loading the program off the tape you should get either the ``:'' prompt again (from the boot program) or the ``#>'' prompt from the console processor. In either case you can retype the appropriate command to try again. If something else happened, you may have a bad distribution tape, or your hardware may be broken; refer to Appendix B for help in troubleshooting.
Vdformat will create sector headers and verify the integrity of each sector formatted. The program starts up by identifying the disk controllers installed in the machine. Old VDDC controllers which support only SMD drives are indicated as ``smd'' while newer controllers capable of supporting both SMD and extended-SMD drives are tagged as ``smd-e''. Vdformat will prompt for the information required as shown below. If you err in answering questions, ``Delete'' or backspace erase the last character typed, and ``^U'' erases the current input line. At any point you can ask for assistance by typing ``help''; vdformat will list the possible answers to the current question. vdformat>\|format Format on which controllers?\|1 Drives on controller 1?\|0 Number of patterns to use while verifying?\|1 Drive type for controller 1, drive 0?\|egl Module serial number for controller 1, drive 0?\|1 vdformat>\|list The following operations will occur when Start is issued: Format: Controller 1, drive 0, type EGL. vdformat>\|start Starting format on controller 1, drive 0, type EGL. (bad sectors will be indicated) vdformat> Once the root device has been formatted, vdformat will prompt for another command. Return to the bootstrap by typing vdformat>\|exit or halt the machine by typing ``~h''. vdformat> ~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, or vdformat may be brought in off a disk drive as described in \(sc6.1. Step 2: copying the mini-root file system
The second step is to run a simple program, copy, to copy a small root file system into the second partition of the disk. (Note that the disk partitions used by \*(4B may not correspond to those used by vendor supplied software.) This file system will serve as the base for creating the actual root file system to be restored. The generic 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. Disk 0 is normally used for this operation; this is reflected in the example procedure. Another disk may be substituted if necessary, although several modifications will be necessary to create special files for the alternate disk. Copy is loaded just as the vdformat program was loaded; if you don't have the bootstrap running, repeat the previous instructions until you see the prompt from boot (a colon), and then:
| :\|cy(0,0)copy (load and run copy program) |
| From: cy(0,1) (tape drive unit 0, second tape file) |
| To: dk(0,1) (disk drive unit 0, second disk partition) |
| Copy completed: 205 records copied |
| Boot |
| : |
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.'' As before, load the bootstrap if you do not already have it running. At the colon prompt:
| : dk(0,1)vmunix (get vmunix from disk drive 0, second partition) |
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 16Mb bytes of memory, then 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 (VIOC's or MPCC's), or all the mass storage peripherals you have, especially if you have more than two of anything. You will correct this when you create a description of your machine from which to configure a site-dependent version of 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 to ask you for the name of the root file system to use. This happens because the distribution system is a generic system, i.e. it can be bootstrapped on a Tahoe cpu with its root device and paging area on any available disk drive. You should respond to the root device question with ``dk0*''. This response supplies two pieces of information: first, ``dk0'' shows that the disk it is running on is drive 0 of type ``dk'', and, secondly, the \*(lq*\*(rq shows that the system is running \*(lqatop\*(rq the paging area. The latter is extremely 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? dk0* WARNING: preposterous time in file system -- CHECK AND RESET THE DATE! erase ^?, kill ^U, intr ^C #
The \*(lqerase ...\*(rq message is part of the /.profile that was executed by the root shell when it started. This message is present to inform you as to what values the character erase, line erase, and interrupt characters have been set. Step 4: restoring the root file system
UNIX is now running, and the UNIX Programmer's manual applies. The ``#'' is the prompt from the Bourne shell, and lets you know that you are the super-user, whose login name is \*(lqroot\*(rq.
To complete installation of the bootstrap system one step remains: the root file system must be created. If the root file system is to reside on a disk other than unit 0, you will have to create the necessary special files in /dev and use the appropriate value in the following example procedures.
For example, if the root must be placed on dk1, you should create /dev/rdk1a and /dev/dk1a using the MAKEDEV script in /dev as follows: #\|cd /dev; MAKEDEV dk1
To actually create the root file system the shell script \*(lqxtr\*(rq should be run: #\|disk=dk0 tape=cy xtr (Note, ``dk0'' specifies both the disk type and the unit number. Modify as necessary.)
This will generate many messages regarding the construction of the file system and the restoration of the tape contents, but should eventually stop with the message: ... Root filesystem extracted # Step 5: rebooting the completed root file system
With the above work completed, all that is left is to reboot: #\|sync (synchronize file system state) #\|~h (halt cpu) #>\|y. (initialize machine) #>\|p23 2. (set boot flags) #>\|fr boot ...(boot program is eventually loaded)... Boot : dk(0,0)vmunix (vmunix from disk drive 0, partition 0) (Modify unit number as necessary.)
271944+78848+92812 start 0x12e8 4.3 BSD #1: Sat Jun 4 17:11:42 PDT 1988 (karels@okeeffe.Berkeley.EDU:/usr/src/sys/GENERIC) real mem = ### avail mem = ### using ### buffers containing ### bytes of memory (... information about available devices ...) root on dk0 WARNING: preposterous time in file system -- CHECK AND RESET THE DATE! erase ^?, kill ^U, intr ^C #.R
If the root device selected by the kernel is not correct, it is necessary to reboot again using the option to ask for the root device. On the Tahoe use ``p23 3.''. At the prompt from the bootstrap, use the same disk driver unit specification as used above: ``dk(0,0)vmunix''. Then, to the question ``root device?,'' respond with ``dk0''. 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 6: placing labels on the disks
\*(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). Note that recent CCI releases, and apparently Harris releases, may use a different form of disk label, also in the first sector. As the formats of these labels are incompatible, skip this step if your machine is using disk labels already. Recent firmware for the console processor (CP) may use these labels, and thus the labels must be retained. Eventually, it will be possible to use both formats simultaneously. You may wish to experiment on a spare disk once the system is running.
For each disk that you wish to label, run the following command: #\|disklabel -rw dk# type "optional_pack_name" The # is the unit number; the type is the CCI disk device name as listed in section 1.4 or any other name listed in /etc/disktab. The optional information may contain any descriptive name for the contents of a disk, and may be up to 16 characters long. This procedure will place the label on the disk using the information found in /etc/disktab for the disk type named. The default disk partitions in \*(4B are the mostly the same as those in the CCI 1.21 release, except for CDC 340Mb xfd drives; see section 4.2 for details. If you have changed the disk partition sizes, you may wish to add entries for the modified configuration in /etc/disktab before labeling the affected disks.
Note that the partition sizes and sectors per track in /etc/disktab are now specified in sectors, not units of kilobytes as in the vendors' 4.2BSD and System V systems. For most SMD disks, the sector size is 512 bytes, and is listed explicitly. ESDI disks on a Power 6/32SX use a sector size of 1024 bytes. Step 7: setting up the /usr file system
The next thing to do is to extract the rest of the data from the tape. You might wish to review the disk configuration information in section 4.2 before continuing; the partitions used below are those most appropriate in size.
For the Cipher tape drive, execute the following commands: # cd /dev; MAKEDEV cy0 Then perform the following:
| # 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 dk#c (create empty user file system) |
| (dk is the disk type, # is the unit number, c |
| is the partition; this takes a few minutes) |
| # mount /dev/dk#c /usr (mount the usr file system) |
| # cd /usr (make /usr the current directory) |
| # mt -t /dev/rmt12 fsf (space to end of previous tape file) |
| # tar xbpf 40 /dev/rmt12 (extract all of usr except usr/src) |
| (this takes about 15-20 minutes) |
| # mkdir src (make directory for source) |
| # cd src (make source directory the current directory) |
| # mt -t /dev/rmt12 fsf (space to end of previous tape file) |
| # tar xpbf 40 /dev/rmt12 (extract the system source) |
| (this takes about 5-10 minutes) |
| # cd / (change directory, back to the root) |
| # chmod 755 /usr/src |
| # umount /dev/dk#c (unmount /usr) |
You can check the consistency of the /usr file system by doing # fsck /dev/rdk#c The output from fsck should look something like: ** /dev/rdk#c ** 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 fsck(8) or Fsck -- The UNIX File System Check Program for more details.
To use the /usr file system, you should now remount it with: # /etc/mount /dev/dk#c /usr
If you are using 1600bpi tapes, the second reel of the distribution is no longer needed; you should now mount the third reel instead. The installation procedure continues from this point on the 6250bpi tape. # mkdir /usr/src/sys # chmod 755 /usr/src/sys # cd /usr/src/sys # mt -t /dev/rmt12 fsf # tar xpbf 40 /dev/rmt12
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. As distributed, the user contributed software should be placed in /usr/src/new. # mkdir /usr/src/new # chmod 755 /usr/src/new # cd /usr/src/new # mt -t /dev/rmt12 fsf # tar xpbf 40 /dev/rmt12 Several of the directories for large contributed software subsystems have been placed in a single archive file and compressed due to space constraints within the distribution. Additional conversion information
After setting up the new \*(4B filesystems, you may restore the 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. 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 # newfs dk#c # mount /dev/dk#c /a # cd /a # restore x
If tar images were written instead of doing a dump, you should be sure to use its `-p' option when reading the files back. No matter how you restore a file system, be sure to unmount it and and check its integrity with fsck(8) when the job is complete.