2.  Bootstrap procedure  

      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.3BSD you will have to do a full bootstrap. Section 3 describes how to upgrade a 4.3BSD system. An understanding of the operations used in a full bootstrap is helpful in doing an upgrade as well. In either case, it is highly desirable to read and understand the remainder of this document before proceeding.

      The distribution supports a somewhat wider set of machines than those for which we have built binaries. The architectures that are supported only in source form include:

If you wish to run one of these architectures, you will have to build a cross compilation environment. Note that the distribution does not include the machine support for the Tahoe and VAX architectures found in previous BSD distributions. Our primary development environment is the HP9000/300 series machines. The other architectures are developed and supported by people outside the university. Consequently, we are not able to directly test or maintain these other architectures, so cannot comment on their robustness, reliability, or completeness.

2.1.  Bootstrapping from the tape  

The set of files on the distribution tape are as follows:

A dd(1) (HP300), tar(1) (DECstation), or dump(8) (SPARC) image of the root filesystem
A tar image of the /var filesystem
A tar image of the /usr filesystem
A tar image of /usr/src/sys
A tar image of /usr/src except sys and contrib
A tar image of /usr/src/contrib
(8mm Exabyte tape distributions only) A tar image of /usr/src/X11R5

The tape bootstrap procedure used to create a working system involves the following major steps:

Transfer a bootable root filesystem from the tape to a disk and get it booted and running.
Build and restore the /var and /usr filesystems from tape with tar(1).
Extract the system and utility source files as desired.

      The following sections describe the above steps in detail. The details of the first step vary between architectures. The specific steps for the HP300, SPARC, and DECstation are given in the next three sections respectively. You should follow the instructions for your particular architecture. In all sections, commands you are expected to type are shown in italics, while that information printed by the system is shown emboldened.

2.2.  Booting the HP300  

2.2.1.  Supported hardware  

The hardware supported by 4.4BSD for the HP300/400 is as follows:

     |CPU's        68020  based  (318,  319,  320,  330 and |
     |             350), 68030 based (340, 345,  360,  370, |
     |             375,  400)  and  68040  based (380, 425, |
     |             433).                                    |
     |DISK's       HP-IB/CS80  (7912,  7914,  7933,   7936, |
     |             7945,  7957, 7958, 7959, 2200, 2203) and |
     |             SCSI-I (including magneto-optical).      |
     |TAPE's       Low-density CS80 cartridge (7914,  7946, |
     |             9144),   high-density   CS80   cartridge |
     |             (9145), HP SCSI DAT and SCSI Exabyte.    |
     |RS232        98644 built-in single-port, 98642 4-port |
     |             and 98638 8-port interfaces.             |
     |NETWORK      98643 internal and external LAN cards.   |
     |GRAPHICS     Terminal  emulation and raw frame buffer |
     |             support for 98544 / 98545 / 98547  (Top­ |
     |             cat color & monochrome), 98548 / 98549 / |
     |             98550  (Catseye  color  &   monochrome), |
     |             98700  / 98710 (Gatorbox), 98720 / 98721 |
     |             (Renaissance), 98730 /  98731  (DaVinci) |
     |             and A1096A (Hyperion monochrome).        |
     |INPUT        General interface supporting all HIL de­ |
     |             vices.  (e.g. keyboard, 2 and  3  button |
     |             mice, ID module, ...)                    |
     |MISC         Battery-backed  real time clock, builtin |
     |             and 98625A/B HP-IB  interfaces,  builtin |
     |             and   98658A   SCSI  interfaces,  serial |
     |             printers and plotters on HP-IB, and SCSI |
     |             autochanger device.                      |

Major items that are not supported include the 310 and 332 CPU's, 400 series machines configured for Domain/OS, EISA and VME bus adaptors, audio, the centronics port, 1/2" tape drives (7980), CD-ROM, and the PVRX/TVRX 3D graphics displays.

2.2.2.  Standalone device file naming  

The standalone system device name syntax on the HP300 is of the form:

where xx is the device type, a specifies the adaptor to use, c the controller, u the unit, and p a partition. The device type differentiates the various disks and tapes and is one of: ``rd'' for HP-IB CS80 disks, ``ct'' for HP-IB CS80 cartridge tapes, or ``sd'' for SCSI-I disks (SCSI-I tapes are currently not supported). The adaptor field is a logical HP-IB or SCSI bus adaptor card number. This will typically be 0 for SCSI disks, 0 for devices on the ``slow'' HP-IB interface (usually tapes) and 1 for devices on the ``fast'' HP-IB interface (usually disks). To get a complete mapping of physical (select-code) to logical card numbers just type a ^C at the standalone prompt. The controller field is the disk or tape's target number on the HP-IB or SCSI bus. For SCSI the range is 0 to 6 (7 is the adaptor address) and for HP-IB the range is 0 to 7. The unit field is unused and should be 0. The partition field is interpreted differently for tapes and disks: for disks it is a disk partition (in the range 0-7), and for tapes it is a file number offset on the tape. Thus, partition 2 of a SCSI disk drive at target 3 on SCSI bus 1 would be ``sd(1,3,0,2)''. If you have only one of any type bus adaptor, you may omit the adaptor and controller numbers; e.g. ``sd(0,2)'' could be used instead of ``sd(0,0,0,2)''. The following examples always use the full syntax for clarity.

2.2.3.  The procedure  

The basic steps involved in bringing up the HP300 are as follows:

Obtain a second disk and format it, if necessary.
Copy a root filesystem from the tape onto the beginning of the disk.
Boot the UNIX system on the new disk.
(Optional) Build a root filesystem optimized for your disk.
Label the disks with the disklabel(8) program.  Step 1: selecting and formatting a disk  

      For your first system you will have to obtain a formatted disk of a type given in the ``supported hardware'' list above. If you want to load an entire binary system (i.e., everything except /usr/src), on the single disk you will need a minimum of 290MB, ruling out anything smaller than a 7959B/S disk. The disklabel included in the bootstrap root image is laid out to accommodate this scenario. Note that an HP SCSI magneto-optical disk will work fine for this case. 4.4BSD will boot and run (albeit slowly) using one. If you want to load source on a single disk system, you will need at least 640MB (at least a 2213A SCSI or 2203A HP-IB disk). A disk as small as the 7945A (54MB) can be used for the bootstrap procedure but will hold only the root and primary swap partitions. If you plan to use multiple disks, refer to section 2.5 for suggestions on partitioning.

      After selecting a disk, you may need to format it. Since most HP disk drives come pre-formatted (except optical media) you probably will not, but if necessary, you can format a disk under HP-UX using the mediainit(1m) program. Once you have 4.4BSD up and running on one machine you can use the scsiformat(8) program to format additional SCSI disks. Any additional HP-IB disks will have to be formatted using HP-UX.  Step 2: copying the root filesystem from tape to disk  

      Once you have a formatted second disk you can use the dd(1) command under HP-UX to copy the root filesystem image from the tape to the beginning of the second disk. For HP's, the root filesystem image is the first file on the tape. It includes a disklabel and bootblock along with the root filesystem. An example command to copy the image from tape to the beginning of a disk is:

dd if=/dev/rmt/0m of=/dev/rdsk/1s0 bs=20b
The actual special file syntax may vary depending on unit numbers and the version of HP-UX that is running. Consult the HP-UX mt(7) and disk(7) man pages for details.

      Note that if you have a SCSI disk, you don't necessarily have to use HP-UX (or an HP) to create the boot disk. Any machine and operating system that will allow you to copy the raw disk image out to block 0 of the disk will do.

      If you have only a single machine with a single disk, you may still be able to install and boot 4.4BSD if you have an HP-IB cartridge tape drive. If so, you can use a more difficult approach of booting a standalone copy program from the tape, and using that to copy the root filesystem image from the tape to the disk. To do this, you need to extract the first file of the distribution tape (the root image), copy it over to a machine with a cartridge drive and then copy the image onto tape. For example:

dd if=/dev/rst0 of=bootimage bs=20b
rcp bootimage foo:/tmp/bootimage
<login to foo>
dd if=/tmp/bootimage of=/dev/rct/0m bs=20b
Once this tape is created you can boot and run the standalone tape copy program from it. The copy program is loaded just as any other program would be loaded by the bootrom in ``attended'' mode: reset the CPU, hold down the space bar until the word ``Keyboard'' appears in the installed interface list, and enter the menu selection for SYS_TCOPY. Once loaded and running:
From: ^C                              (control-C to see logical adaptor assignments)
hpib0 at sc7
scsi0 at sc14
From: ct(0,7,0,0)                     (HP-IB tape, target 7, first tape file)
To: sd(0,0,0,2)                       (SCSI disk, target 0, third partition)
Copy completed: 1728 records copied

This copy will likely take 30 minutes or more.  Step 3: booting the root filesystem  

      You now have a bootable root filesystem on the disk. If you were previously running with two disks, it would be best if you shut down the machine and turn off power on the HP-UX drive. It will be less confusing and it will eliminate any chance of accidentally destroying the HP-UX disk. If you used a cartridge tape for booting you should also unload the tape at this point. Whether you booted from tape or copied from disk you should now reboot the machine and do another attended boot (see previous section), this time with SYS_TBOOT. Once loaded and running the boot program will display the CPU type and prompt for a kernel file to boot:


: /kernel

After providing the kernel name, the machine will boot 4.4BSD with output that looks about like this:

597480+34120+139288 start 0xfe8019ec
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California.
Copyright (c) 1992 Hewlett-Packard Company
Copyright (c) 1992 Motorola Inc.
All rights reserved.

4.4BSD UNIX #1: Tue Jul 20 11:40:36 PDT 1993
HP9000/433 (33MHz MC68040 CPU+MMU+FPU, 4k on-chip physical I/D caches)
real mem = xxx
avail mem = ###
using ### buffers containing ### bytes of memory
(... information about available devices ...)
root device?

      The first three numbers are printed out by the bootstrap program 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 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 ``root device?'' prompt was printed by the system to ask you for the name of the root filesystem to use. This happens because the distribution system is a generic system, i.e., it can be bootstrapped on a cpu with its root device and paging area on any available disk drive. You will most likely respond to the root device question with ``sd0'' if you are booting from a SCSI disk, or with ``rd0'' if you are booting from an HP-IB disk. This response shows that the disk it is running on is drive 0 of type ``sd'' or ``rd'' respectively. If you have other disks attached to the system, it is possible that the drive you are using will not be configured as logical drive 0. Check the autoconfiguration messages printed out by the kernel to make sure. These messages will show the type of every logical drive and their associated controller and slave addresses. You will later build a system tailored to your configuration that will not prompt you for a root device when it is bootstrapped.

root device? sd0
WARNING: preposterous time in filesystem -- CHECK AND RESET THE DATE!
erase ^?, kill ^U, intr ^C

      The ``erase ...'' message is part of the /.profile that was executed by the root shell when it started. This message tells you about the settings of the character erase, line erase, and interrupt characters.

      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 ``root''.

      At this point, the root filesystem is mounted read-only. Before continuing the installation, the filesystem needs to be ``updated'' to allow writing and device special files for the following steps need to be created. This is done as follows:

# mount_mfs -s 1000 -T type /dev/null /tmp                (create a writable filesystem)
(type is the disk type as determined from /etc/disktab)
# cd /tmp                                                 (connect to that directory)
# ../dev/MAKEDEV sd#                                      (create special files for root disk)
(sd is the disk type, # is the unit number)
(ignore warning from ``sh'')
# mount -uw /tmp/sd#a /                                   (read-write mount root filesystem)
# cd /dev                                                 (go to device directory)
# ./MAKEDEV sd#                                           (create permanent special files for root disk)
(again, ignore warning from ``sh'')  Step 4: (optional) restoring the root filesystem  

      The root filesystem that you are currently running on is complete, however it probably is not optimally laid out for the disk on which you are running. If you will be cloning copies of the system onto multiple disks for other machines, you are advised to connect one of these disks to this machine, and build and restore a properly laid out root filesystem onto it. If this is the only machine on which you will be running 4.4BSD or peak performance is not an issue, you can skip this step and proceed directly to step 5.

      Connect a second disk to your machine. If you bootstrapped using the two disk method, you can overwrite your initial HP-UX disk, as it will no longer be needed (assuming you have no plans to run HP-UX again).

      To really create the root filesystem on drive 1 you should first label the disk as described in step 5 below. Then run the following commands:

# cd /dev
# ./MAKEDEV sd1a
#newfs /dev/rsd1a
#mount /dev/sd1a /mnt
#cd /mnt
#dump 0f - /dev/rsd0a | restore xf -
(Note: restore will ask if you want to ``set owner/mode for '.'''
to which you should reply ``yes''.)

      When this completes, you should then shut down the system, and boot on the disk that you just created following the procedure in step (3) above.  Step 5: placing labels on the disks  

      For each disk on the HP300, 4.4BSD places information about the geometry of the drive and the partition layout at byte offset 1024. This information is written with disklabel(8).

      The root image just loaded includes a ``generic'' label intended to allow easy installation of the root and /usr and may not be suitable for the actual disk on which it was installed. In particular, it may make your disk appear larger or smaller than its real size. In the former case, you lose some capacity. In the latter, some of the partitions may map non-existent sectors leading to errors if those partitions are used. It is also possible that the defined geometry will interact poorly with the filesystem code resulting in reduced performance. However, as long as you are willing to give up a little space, not use certain partitions or suffer minor performance degradation, you might want to avoid this step; especially if you do not know how to use ed(1).

      If you choose to edit this label, you can fill in correct geometry information from /etc/disktab. You may also want to rework the ``e'' and ``f'' partitions used for loading /usr and /var. You should not attempt to, and disklabel will not let you, modify the ``a'', ``b'' and ``d'' partitions. To edit a label:

# export EDITOR
# disklabel  -r  -e  /dev/rXX#d
where XX is the type and # is the logical drive number; e.g. /dev/rsd0d or /dev/rrd0d. Note the explicit use of the ``d'' partition. This partition includes the bootblock as does ``c'' and using it allows you to change the size of ``c''.

      If you wish to label any additional disks, run the following command for each:

#disklabel  -rw  XX#  type  "optional_pack_name"
where XX# is the same as in the previous command and type is the HP300 disk device name as 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. 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.

      You have now completed the HP300 specific part of the installation. Now proceed to the generic part of the installation described starting in section 2.5 below. Note that where the disk name ``sd'' is used throughout section 2.5, you should substitute the name ``rd'' if you are running on an HP-IB disk. Also, if you are loading on a single disk with the default disklabel, /var should be restored to the ``f'' partition and /usr to the ``e'' partition.

2.3.  Booting the SPARC  

2.3.1.  Supported hardware  

The hardware supported by 4.4BSD for the SPARC is as follows:

     |CPU's        SPARCstation  1 series (1, 1+, SLC, IPC) |
     |             and SPARCstation 2 series (2, IPX).      |
     |DISK's       SCSI.                                    |
     |TAPE's       none.                                    |
     |NETWORK      SPARCstation Lance (le).                 |
     |GRAPHICS     bwtwo and cgthree.                       |
     |INPUT        Keyboard and mouse.                      |
     |MISC         Battery-backed real time clock, built-in |
     |             serial  devices,  Sbus  SCSI controller, |
     |             and audio device.                        |

Major items that are not supported include anything VME-based, the GX (cgsix) display, the floppy disk, and SCSI tapes.

2.3.2.  Limitations  

There are several important limitations on the 4.4BSD distribution for the SPARC:

You must have SunOS 4.1.x or Solaris to bring up 4.4BSD. There is no SPARCstation bootstrap code in this distribution. The Sun-supplied boot loader will be used to boot 4.4BSD; you must copy this from your SunOS distribution. This imposes several restrictions on the system, as detailed below.
The 4.4BSD SPARC kernel does not remap SCSI IDs. A SCSI disk at target 0 will become ``sd0'', where in SunOS the same disk will normally be called ``sd3''. If your existing SunOS system is diskful, it will be least painful to have SunOS running on the disk on target 0 lun 0 and put 4.4BSD on the disk on target 3 lun 0. Both systems will then think they are running on ``sd0'', and you can boot either system as needed simply by changing the EEPROM's boot device.
There is no SCSI tape driver. You must have another system for tape reading and backups.
Although the 4.4BSD SPARC kernel will handle existing SunOS shared libraries, it does not use or create them itself, and therefore requires much more disk space than SunOS does.
It is currently difficult (though not completely impossible) to run 4.4BSD diskless. These instructions assume you will have a local boot, swap, and root filesystem.
When using a serial port rather than a graphics display as the console, only port ttya can be used. Attempts to use port ttyb will fail when the kernel tries to print the boot up messages to the console.

2.3.3.  The procedure  

      You must have a spare disk on which to place 4.4BSD. The steps involved in bootstrapping this tape are as follows:

Bring up SunOS (preferably SunOS 4.1.x or Solaris 1.x, although Solaris 2 may work -- this is untested).
Attach auxiliary SCSI disk(s). Format and label using the SunOS formatting and labeling programs as needed. Note that the root filesystem currently requires at least 10 MB; 16 MB or more is recommended. The b partition will be used for swap; this should be at least 32 MB.
Use the SunOS newfs to build the root filesystem. You may also want to build other filesystems at the same time. (By default, the 4.4BSD newfs builds a filesystem that SunOS will not handle; if you plan to switch OSes back and forth you may want to sacrifice the performance gain from the new filesystem format for compatibility.) You can build an old-format filesystem on 4.4BSD by giving the -O option to newfs(8). Fsck(8) can convert old format filesystems to new format filesystems, but not vice versa, so you may want to initially build old format filesystems so that they can be mounted under SunOS, and then later convert them to new format filesystems when you are satisfied that 4.4BSD is running properly. In any case, you must build an old-style root filesystem so that the SunOS boot program will work.
Mount the new root, then copy the SunOS /boot into place and use the SunOS ``installboot'' program to enable disk-based booting. Note that the filesystem must be mounted when you do the ``installboot'':
# mount /dev/sd3a /mnt
# cp /boot /mnt/boot
# cd /usr/kvm/mdec
# installboot /mnt/boot bootsd /dev/rsd3a
The SunOS /boot will load 4.4BSD kernels; there is no SPARCstation bootstrap code on the distribution. Note that the SunOS /boot does not handle the new 4.4BSD filesystem format.
Restore the contents of the 4.4BSD root filesystem.
# cd /mnt
# rrestore xf tapehost:/dev/nrst0
Boot the supplied kernel:
# halt
ok boot sd(0,3)kernel -s		[for old proms] OR
ok boot disk3 -s			[for new proms]
... [4.4BSD boot messages]

To install the remaining filesystems, use the procedure described starting in section 2.5. In these instructions, /usr should be loaded into the ``e'' partition and /var in the ``f'' partition.

After completing the filesystem installation you may want to set up 4.4BSD to reboot automatically:

# halt
ok setenv boot-from sd(0,3)kernel	[for old proms] OR
ok setenv boot-device disk3		[for new proms]
If you build backwards-compatible filesystems, either with the SunOS newfs or with the 4.4BSD ``-O'' option, you can mount these under SunOS. The SunOS fsck will, however, always think that these filesystems are corrupted, as there are several new (previously unused) superblock fields that are updated in 4.4BSD. Running ``fsck -b32'' and letting it ``fix'' the superblock will take care of this.
If you wish to run SunOS binaries that use SunOS shared libraries, you simply need to copy all the dynamic linker files from an existing SunOS system:
# rcp sunos-host:/etc/ld.so.cache /etc/
# rcp sunos-host:'/usr/lib/*.so*' /usr/lib/
The SunOS compiler and linker should be able to produce SunOS binaries under 4.4BSD, but this has not been tested. If you plan to try it you will need the appropriate .sa files as well.

2.4.  Booting the DECstation  

2.4.1.  Supported hardware  

The hardware supported by 4.4BSD for the DECstation is as follows:

     |CPU's        R2000   based  (3100)  and  R3000  based |
     |             (5000/200, 5000/20, 5000/25,  5000/1xx). |
     |DISK's       SCSI-I  (tested RZ23, RZ55, RZ57, Maxtor |
     |             8760S).                                  |
     |TAPE's       SCSI-I (tested DEC  TK50,  Archive  DAT, |
     |             Emulex MT02).                            |
     |RS232        Internal  DEC  dc7085 and AMD 8530 based |
     |             interfaces.                              |
     |NETWORK      TURBOchannel PMAD-AA and internal  LANCE |
     |             based interfaces.                        |
     |GRAPHICS     Terminal  emulation and raw frame buffer |
     |             support for 3100 (color  &  monochrome), |
     |             TURBOchannel  PMAG-AA, PMAG-BA, PMAG-DV. |
     |INPUT        Standard DEC keyboard (LK201) and mouse. |
     |MISC         Battery-backed real time clock, internal |
     |             and  TURBOchannel  PMAZ-AA  SCSI  inter­ |
     |             faces.                                   |

Major items that are not supported include the 5000/240 (there is code but not compiled in or tested), R4000 based machines, FDDI and audio interfaces. Diskless machines are not supported but booting kernels and bootstrapping over the network is supported on the 5000 series.

2.4.2.  The procedure  

      The first file on the distribution tape is a tar file that contains four files. The first step requires a running UNIX (or ULTRIX) system that can be used to extract the tar archive from the first file on the tape. The command:

tar xf /dev/rmt0
will extract the following four files:
A) root.image: dd image of the root filesystem
B) kernel.tape: dd image for creating boot tapes
C) kernel.net: file for booting over the network
D) root.dump: dump image of the root filesystem
There are three basic ways a system can be bootstrapped corresponding to the first three files. You may want to read the section on bootstrapping the HP300 since many of the steps are similar. A spare, formatted SCSI disk is also useful.  Procedure A: copy root filesystem to disk  

      This procedure is similar to the HP300. If you have an extra disk, the easiest approach is to use dd(1) under ULTRIX to copy the root filesystem image to the beginning of the spare disk. The root filesystem image includes a disklabel and bootblock along with the root filesystem. An example command to copy the image to the beginning of a disk is:

dd if=root.image of=/dev/rz1c bs=20b
The actual special file syntax will vary depending on unit numbers and the version of ULTRIX that is running. This system is now ready to boot. You can boot the kernel with one of the following PROM commands. If you are booting on a 3100, the disk must be SCSI id zero because of a bug.
DEC 3100:    boot -f rz(0,0,0)kernel
DEC 5000:    boot 5/rz0/kernel
You can then proceed to section 2.5 to create reasonable disk partitions for your machine and then install the rest of the system.  Procedure B: bootstrap from tape  

      If you have only a single machine with a single disk, you need to use the more difficult approach of booting a kernel and mini-root from tape or the network, and using it to restore the root filesystem.

      First, you will need to create a boot tape. This can be done using dd as in the following example.

dd if=kernel.tape of=/dev/nrmt0 bs=1b
dd if=root.dump of=/dev/nrmt0 bs=20b
The actual special file syntax for the tape drive will vary depending on unit numbers, tape device and the version of ULTRIX that is running.

      The first file on the boot tape contains a boot header, kernel, and mini-root filesystem that the PROM can copy into memory. Installing from tape has only been tested on a 3100 and a 5000/200 using a TK50 tape drive. Here are two example PROM commands to boot from tape.

DEC 3100:    boot -f tz(0,5,0) m    # 5 is the SCSI id of the TK50
DEC 5000:    boot 5/tz6 m           # 6 is the SCSI id of the TK50
The `m' argument tells the kernel to look for a root filesystem in memory. Next you should proceed to section 2.4.3 to build a disk-based root filesystem.  Procedure C: bootstrap over the network  

      You will need a host machine that is running the bootp server with the kernel.net file installed in the default directory defined by the configuration file for bootp. Here are two example PROM commands to boot across the net:

DEC 3100:	boot -f tftp()kernel.net m
DEC 5000:	boot 6/tftp/kernel.net m
This command should load the kernel and mini-root into memory and run the same as the tape install (procedure B). The rest of the steps are the same except you will need to start the network (if you are unsure how to fill in the <name> fields below, see sections 4.4 and 5). Execute the following to start the networking:
# mount -uw /
# echo localhost >> /etc/hosts
# echo <your.host.inet.number> myname.my.domain myname >> /etc/hosts
# echo <friend.host.inet.number> myfriend.my.domain myfriend >> /etc/hosts
# ifconfig le0 inet myname
Next you should proceed to section 2.4.3 to build a disk-based root filesystem.

2.4.3.  Label disk and create the root filesystem  

There are five steps to create a disk-based root filesystem.

Label the disk.
# disklabel -W /dev/rrz?c		# This enables writing the label
# disklabel -w -r -B /dev/rrz?c $DISKTYPE
# newfs /dev/rrz?a
# fsck /dev/rrz?a
Supported disk types are listed in /etc/disktab.
Restore the root filesystem.
# mount -uw /
# mount /dev/rz?a /a
# cd /a

        If you are restoring locally (procedure B), run:
# mt -f /dev/nrmt0 rew
# restore -xsf 2 /dev/rmt0

        If you are restoring across the net (procedure c), run:
# rrestore xf myfriend:/path/to/root.dump

        When the restore finishes, clean up with:
# cd /
# sync
# umount /a
# fsck /dev/rz?a
Reset the system and initialize the PROM monitor to boot automatically.
DEC 3100:	setenv bootpath boot -f rz(0,?,0)kernel
DEC 5000:	setenv bootpath 5/rz?/kernel -a
After booting UNIX, you will need to create /dev/mouse to run X Window System as in the following example.
rm /dev/mouse
ln /dev/xx /dev/mouse
The 'xx' should be one of the following:
pm0	raw interface to PMAX graphics devices
cfb0	raw interface to TURBOchannel PMAG-BA color frame buffer
xcfb0	raw interface to maxine graphics devices
mfb0	raw interface to mono graphics devices
You can then proceed to section 2.5 to install the rest of the system. Note that where the disk name ``sd'' is used throughout section 2.5, you should substitute the name ``rz''.

2.5.  Disk configuration  

      All architectures now have a root filesystem up and running and proceed from this point to layout filesystems to make use of the available space and to balance disk load for better system performance.

2.5.1.  Disk naming and divisions  

      Each physical disk drive can be divided into up to 8 partitions; UNIX typically uses only 3 or 4 partitions. For instance, the first partition, sd0a, is used for a root filesystem, a backup thereof, or a small filesystem like, /var/tmp; the second partition, sd0b, is used for paging and swapping; and a third partition, typically sd0e, holds a user filesystem.

      The space available on a disk varies per device. Each disk typically has a paging area of 30 to 100 megabytes and a root filesystem of about 17 megabytes. The distributed system binaries occupy about 150 (180 with X11R5) megabytes while the major sources occupy another 250 (340 with X11R5) megabytes. The /var filesystem as delivered on the tape is only 2Mb, however it should have at least 50Mb allocated to it just for normal system activity. Usually it is allocated the last partition on the disk so that it can provide as much space as possible to the /var/users filesystem. See section 2.5.4 for further details on disk layouts.

      Be aware that the disks have their sizes measured in disk sectors (usually 512 bytes), while the UNIX filesystem blocks are variable sized. If BLOCKSIZE=1k is set in the user's environment, all user programs report disk space in kilobytes, otherwise, disk sizes are always reported in units of 512-byte sectors[note 3] . The /etc/disktab file used in labelling disks and making filesystems specifies disk partition sizes in sectors.

2.5.2.  Layout considerations  

      There are several considerations in deciding how to adjust the arrangement of things on your disks. The most important is making sure that there is adequate space for what is required; secondarily, throughput should be maximized. Paging space is an important parameter. The system, as distributed, sizes the configured paging areas each time the system is booted. Further, multiple paging areas of different sizes may be interleaved.

      Many common system programs (C, the editor, the assembler etc.) create intermediate files in the /tmp directory, so the filesystem where this is stored also should be made large enough to accommodate most high-water marks. Typically, /tmp is constructed from a memory-based filesystem (see mount_mfs(8)). Programs that want their temporary files to persist across system reboots (such as editors) should use /var/tmp. If you plan to use a disk-based /tmp filesystem to avoid loss across system reboots, it makes sense to mount this in a ``root'' (i.e. first partition) filesystem on another disk. All the programs that create files in /tmp take care to delete them, but are not immune to rare events and can leave dregs. The directory should be examined every so often and the old files deleted.

      The efficiency with which UNIX is able to use the CPU is often strongly affected by the configuration of disk controllers; it is critical for good performance to balance disk load. There are at least five components of the disk load that you can divide between the available disks:

The root filesystem.
The /var and /var/tmp filesystems.
The /usr filesystem.
The user filesystems.
The paging activity.

The following possibilities are ones we have used at times when we had 2, 3 and 4 disks:

                  |        |     | disk|s       |
                  |what    | 2   | 3   | 4     |
                  |root    | 0   | 0   | 0     |
                  |var     | 1   | 2   | 3     |
                  |usr     | 1   | 1   | 1     |
                  |paging  | 0+1 | 0+2 | 0+2+3 |
                  |users   | 0   | 0+2 | 0+2   |
                  |archive | x   | x   | 3     |

      The most important things to consider are to even out the disk load as much as possible, and to do this by decoupling filesystems (on separate arms) between which heavy copying occurs. Note that a long term average balanced load is not important; it is much more important to have an instantaneously balanced load when the system is busy.

      Intelligent experimentation with a few filesystem arrangements can pay off in much improved performance. It is particularly easy to move the root, the /var and /var/tmp filesystems and the paging areas. Place the user files and the /usr directory as space needs dictate and experiment with the other, more easily moved filesystems.

2.5.3.  Filesystem parameters  

      Each filesystem is parameterized according to its block size, fragment size, and the disk geometry characteristics of the medium on which it resides. Inaccurate specification of the disk characteristics or haphazard choice of the filesystem parameters can result in substantial throughput degradation or significant waste of disk space. As distributed, filesystems are configured according to the following table.

             Filesystem   Block size   Fragment size
             root         8 kbytes     1 kbytes
             usr          8 kbytes     1 kbytes
             users        4 kbytes     512 bytes

      The root filesystem block size is made large to optimize bandwidth to the associated disk. The large block size is important as many of the most heavily used programs are demand paged out of the /bin directory. The fragment size of 1 kbyte is a ``nominal'' value to use with a filesystem. With a 1 kbyte fragment size disk space utilization is about the same as with the earlier versions of the filesystem.

      The filesystems for users have a 4 kbyte block size with 512 byte fragment size. These parameters have been selected based on observations of the performance of our user filesystems. The 4 kbyte block size provides adequate bandwidth while the 512 byte fragment size provides acceptable space compaction and disk fragmentation.

      Other parameters may be chosen in constructing filesystems, but the factors involved in choosing a block size and fragment size are many and interact in complex ways. Larger block sizes result in better throughput to large files in the filesystem as larger I/O requests will then be done by the system. However, consideration must be given to the average file sizes found in the filesystem and the performance of the internal system buffer cache. The system currently provides space in the inode for 12 direct block pointers, 1 single indirect block pointer, 1 double indirect block pointer, and 1 triple indirect block pointer. If a file uses only direct blocks, access time to it will be optimized by maximizing the block size. If a file spills over into an indirect block, increasing the block size of the filesystem may decrease the amount of space used by eliminating the need to allocate an indirect block. However, if the block size is increased and an indirect block is still required, then more disk space will be used by the file because indirect blocks are allocated according to the block size of the filesystem.

      In selecting a fragment size for a filesystem, at least two considerations should be given. The major performance tradeoffs observed are between an 8 kbyte block filesystem and a 4 kbyte block filesystem. Because of implementation constraints, the block size versus fragment size ratio can not be greater than 8. This means that an 8 kbyte filesystem will always have a fragment size of at least 1 kbytes. If a filesystem is created with a 4 kbyte block size and a 1 kbyte fragment size, then upgraded to an 8 kbyte block size and 1 kbyte fragment size, identical space compaction will be observed. However, if a filesystem has a 4 kbyte block size and 512 byte fragment size, converting it to an 8K/1K filesystem will result in 4-8% more space being used. This implies that 4 kbyte block filesystems that might be upgraded to 8 kbyte blocks for higher performance should use fragment sizes of at least 1 kbytes to minimize the amount of work required in conversion.

      A second, more important, consideration when selecting the fragment size for a filesystem is the level of fragmentation on the disk. With an 8:1 fragment to block ratio, storage fragmentation occurs much sooner, particularly with a busy filesystem running near full capacity. By comparison, the level of fragmentation in a 4:1 fragment to block ratio filesystem is one tenth as severe. This means that on filesystems where many files are created and deleted, the 512 byte fragment size is more likely to result in apparent space exhaustion because of fragmentation. That is, when the filesystem is nearly full, file expansion that requires locating a contiguous area of disk space is more likely to fail on a 512 byte filesystem than on a 1 kbyte filesystem. To minimize fragmentation problems of this sort, a parameter in the super block specifies a minimum acceptable free space threshold. When normal users (i.e. anyone but the super-user) attempt to allocate disk space and the free space threshold is exceeded, the user is returned an error as if the filesystem were really full. This parameter is nominally set to 5%; it may be changed by supplying a parameter to newfs(8), or by updating the super block of an existing filesystem using tunefs(8).

      Finally, a third, less common consideration is the attributes of the disk itself. The fragment size should not be smaller than the physical sector size of the disk. As an example, the HP magneto-optical disks have 1024 byte physical sectors. Using a 512 byte fragment size on such disks will work but is extremely inefficient.

      Note that the above discussion considers block sizes of up to only 8k. As of the 4.4 release, the maximum block size has been increased to 64k. This allows an entirely new set of block/fragment combinations for which there is little experience to date. In general though, unless a filesystem is to be used for a special purpose application (for example, storing image processing data), we recommend using the values supplied above. Remember that the current implementation limits the block size to at most 64 kbytes and the ratio of block size versus fragment size must be 1, 2, 4, or 8.

      The disk geometry information used by the filesystem affects the block layout policies employed. The file /etc/disktab, as supplied, contains the data for most all drives supported by the system. Before constructing a filesystem with newfs(8) you should label the disk (if it has not yet been labeled, and the driver supports labels). If labels cannot be used, you must instead specify the type of disk on which the filesystem resides; newfs then reads /etc/disktab instead of the pack label. This file also contains the default filesystem partition sizes, and default block and fragment sizes. To override any of the default values you can modify the file, edit the disk label, or use an option to newfs.

2.5.4.  Implementing a layout  

      To put a chosen disk layout into effect, you should use the newfs(8) command to create each new filesystem. Each filesystem must also be added to the file /etc/fstab so that it will be checked and mounted when the system is bootstrapped.

      First we will consider a system with a single disk. There is little real choice on how to do the layout; the root filesystem goes in the ``a'' partition, /usr goes in the ``e'' partition, and /var fills out the remainder of the disk in the ``f'' partition. This is the organization used if you loaded the disk-image root filesystem. With the addition of a memory-based /tmp filesystem, its fstab entry would be as follows:

/dev/sd0a   /      ufs    rw                                     1   1
/dev/sd0b   none   swap   sw                                     0   0
/dev/sd0b   /tmp   mfs    rw,-s=14000,-b=8192,-f=1024,-T=sd660   0   0
/dev/sd0e   /usr   ufs    ro                                     1   2
/dev/sd0f   /var   ufs    rw                                     1   2

      If we had a second disk, we would split the load between the drives. On the second disk, we place the /usr and /var filesystems in their usual sd1e and sd1f partitions respectively. The sd1b partition would be used as a second paging area, and the sd1a partition left as a spare root filesystem (alternatively sd1a could be used for /var/tmp). The first disk still holds the the root filesystem in sd0a, and the primary swap area in sd0b. The sd0e partition is used to hold home directories in /var/users. The sd0f partition can be used for /usr/src or alternately the sd0e partition can be extended to cover the rest of the disk with disklabel(8). As before, the /tmp directory is a memory-based filesystem. Note that to interleave the paging between the two disks you must build a system configuration that specifies:

config	kernel	root on sd0 swap on sd0 and sd1
The /etc/fstab file would then contain
/dev/sd0a   /            ufs    rw                                     1   1
/dev/sd0b   none         swap   sw                                     0   0
/dev/sd1b   none         swap   sw                                     0   0
/dev/sd0b   /tmp         mfs    rw,-s=14000,-b=8192,-f=1024,-T=sd660   0   0
/dev/sd1e   /usr         ufs    ro                                     1   2
/dev/sd0f   /usr/src     ufs    rw                                     1   2
/dev/sd1f   /var         ufs    rw                                     1   2
/dev/sd0e   /var/users   ufs    rw                                     1   2

      To make the /var filesystem we would do:

# cd /dev
# disklabel -wr sd1 "disk type" "disk name"
# newfs sd1f
(information about filesystem prints out)
# mkdir /var
# mount /dev/sd1f /var

2.6.  Installing the rest of the system  

      At this point you should have your disks partitioned. The next step is to extract the rest of the data from the tape. At a minimum you need to set up the /var and /usr filesystems. You may also want to extract some or all the program sources. Since not all architectures support tape drives or don't support the correct ones, you may need to extract the files indirectly using rsh(1). For example, for a directly connected tape drive you might do:

# mt -f /dev/nrmt0 fsf
# tar xbpf 20 /dev/nrmt0
The equivalent indirect procedure (where the tape drive is on machine ``foo'') is:
# rsh foo mt -f /dev/nrmt0 fsf
# rsh foo dd if=/dev/nrmt0 bs=20b | tar xbpf 20 -
Obviously, the target machine must be connected to the local network for this to work. To do this:
# echo  localhost >> /etc/hosts
# echo  your.host.inet.number  myname.my.domain  myname >> /etc/hosts
# echo  friend.host.inet.number  myfriend.my.domain  myfriend >> /etc/hosts
# ifconfig  le0  inet  myname
where the ``host.inet.number'' fields are the IP addresses for your host and the host with the tape drive and the ``my.domain'' fields are the names of your machine and the tape-hosting machine. See sections 4.4 and 5 for more information on setting up the network.

      Assuming a directly connected tape drive, here is how to extract and install /var and /usr:

# mount -uw /dev/sd#a /                                 (read-write mount root filesystem)
# date yymmddhhmm                                       (set date, see date(1))
# passwd -l root                                        (set password for super-user)
New password:                                           (password will not echo)
Retype new password:
# passwd -l toor                                        (set password for super-user)
New password:                                           (password will not echo)
Retype new password:
# hostname mysitename                                   (set your hostname)
# newfs rsd#p                                           (create empty user filesystem)
(sd is the disk type, # is the unit number,
p is the partition; this takes a few minutes)
# mount /dev/sd#p /var                                  (mount the var filesystem)
# cd /var                                               (make /var the current directory)
# mt -f /dev/nrmt0 fsf                                  (space to end of previous tape file)
# tar xbpf 20 /dev/nrmt0                                (extract all of var)
(this takes a few minutes)
# newfs rsd#p                                           (create empty user filesystem)
(as before sd is the disk type, # is the unit number,
p is the partition)
# mount /dev/sd#p /mnt                                  (mount the new /usr in temporary location)
# cd /mnt                                               (make /mnt the current directory)
# mt -f /dev/nrmt0 fsf                                  (space to end of previous tape file)
# tar xbpf 20 /dev/nrmt0                                (extract all of usr except usr/src)
(this takes about 15-20 minutes)
# cd /                                                  (make / the current directory)
# umount /mnt                                           (unmount from temporary mount point)
# rm -r /usr/*                                          (remove excess bootstrap binaries)
# mount /dev/sd#p /usr                                  (remount /usr)
If no disk label has been installed on the disk, the newfs command will require a third argument to specify the disk type, using one of the names in /etc/disktab. If the tape had been rewound or positioned incorrectly before the tar, to extract /var it may be repositioned by the following commands.
# mt -f /dev/nrmt0 rew
# mt -f /dev/nrmt0 fsf 1
The data on the second and third tape files has now been extracted. If you are using 6250bpi tapes, the first reel of the distribution is no longer needed; you should now mount the second reel instead. The installation procedure continues from this point on the 8mm tape. The next step is to extract the sources. As previously noted, /usr/src requires about 250-340Mb of space. Ideally sources should be in a separate filesystem; if you plan to put them into your /usr filesystem, it will need at least 500Mb of space. Assuming that you will be using a separate filesystem on sd0f for /usr/src, you will start by creating and mounting it:
# newfs sd0f
(information about filesystem prints out)
# mkdir /usr/src
# mount /dev/sd0f /usr/src

First you will extract the kernel source:

# cd /usr/src
# mt -f /dev/nrmt0 fsf                                (space to end of previous tape file)
(this should only be done on Exabyte distributions)
# tar xpbf 20 /dev/nrmt0                              (extract the kernel sources)
(this takes about 15-30 minutes)

The next tar file contains the sources for the utilities. It is extracted as follows:

# cd /usr/src
# mt -f /dev/nrmt0 fsf             (space to end of previous tape file)
# tar xpbf 20 /dev/rmt12           (extract the utility source)
(this takes about 30-60 minutes)

      If you are using 6250bpi 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 8mm tape.

      The next tar file contains the sources for the contributed software. It is extracted as follows:

# cd /usr/src
# mt -f /dev/nrmt0 fsf                                (space to end of previous tape file)
(this should only be done on Exabyte distributions)
# tar xpbf 20 /dev/rmt12                              (extract the contributed software source)
(this takes about 30-60 minutes)

      If you received a distribution on 8mm Exabyte tape, there is one additional tape file on the distribution tape that has not been installed to this point; it contains the sources for X11R5 in tar(1) format. As distributed, X11R5 should be placed in /usr/src/X11R5.

# cd /usr/src
# mt -f /dev/nrmt0 fsf             (space to end of previous tape file)
# tar xpbf 20 /dev/nrmt0           (extract the X11R5 source)
(this takes about 30-60 minutes)
Many of the X11 utilities search using the path /usr/X11, so be sure that you have a symbolic link that points at the location of your X11 binaries (here, X11R5).

      Having now completed the extraction of the sources, you may want to verify that your /usr/src filesystem is consistent. To do so, you must unmount it, and run fsck(8); assuming that you used sd0f you would proceed as follows:

# cd /                 (change directory, back to the root)
# umount /usr/src      (unmount /usr/src)
# fsck /dev/rsd0f
The output from fsck should look something like:

** /dev/rsd0f
** Last Mounted on /usr/src
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
23000 files, 261000 used, 39000 free (2200 frags, 4600 blocks)

      If there are inconsistencies in the filesystem, you may be prompted to apply corrective action; see the fsck(8) or Fsck - The UNIX File System Check Program (SMM:3) for more details.

      To use the /usr/src filesystem, you should now remount it with:

# mount /dev/sd0f /usr/src
or if you have made an entry for it in /etc/fstab you can remount it with:
# mount /usr/src

2.7.  Additional conversion information  

      After setting up the new 4.4BSD filesystems, you may restore the user files that were saved on tape before beginning the conversion. Note that the 4.4BSD restore program does its work on a mounted filesystem using normal system operations. This means that filesystem dumps may be restored even if the characteristics of the filesystem changed. To restore a dump tape for, say, the /a filesystem something like the following would be used:

# mkdir /a
# newfs sd#p
# mount /dev/sd#p /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 filesystem, be sure to unmount it and check its integrity with fsck(8) when the job is complete.