.\" Copyright (c) 1980, 1991 The Regents of the University of California.
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" 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
.\" @(#)reboot_vax.8 6.9 (Berkeley) 3/16/91
is started by placing it in memory
at location zero and transferring to the entry point.
Since the system is not reenterable,
it is necessary to read it in from disk or tape
each time it is to be bootstrapped.
.Sy Rebooting a running system .
is running and a reboot is desired,
If there are no users then
Reboot causes the disks to be synced and allows the system
to perform other shutdown activities such as resynchronizing
hardware time-of-day clocks.
A multi-user reboot (as described below) is then initiated.
This causes a system to be
booted and an automatic disk check to be performed. If all this succeeds
without incident, the system is then brought up for many users.
option avoids the sync. It can be used if a disk or the processor
reboots quickly and ungracefully, without shutting down running
normally logs the reboot using
and places a shutdown record in the login accounting file
These actions are inhibited if the
.Sy Power fail and crash recovery.
Normally, the system will reboot itself at power-up or after crashes.
Provided the auto-restart is enabled on the machine front panel,
an automatic consistency check of the file systems will be performed,
and unless this fails, the system will resume multi-user operations.
These are processor-type dependent.
On an 11/780, there are two floppy files for each disk controller,
both of which cause boots from unit 0 of the root file system
of a controller located on mba0 or uba0.
One gives a single user shell, while the other invokes the multi-user
automatic reboot. Thus these files are
storage module controller and disks
controllers and disks such as the RA81,
There is also a script for booting from the default device,
which is normally a copy of one of the standard multi-user boot scripts,
but which may be modified to perform other actions
or to boot from a different unit.
The situation on the 8600 is similar, with scripts loaded from the console RL02.
would boot the system from (e.g.) an RP06 and run the automatic consistency
be necessary to type control-P
to gain the attention of the
before getting the >>> prompt.)
invokes a version of the boot program in a way which allows you to
specify any system as the system to be booted.
It reads from the console a device specification (see below) followed
immediately by a pathname.
The scripts may be modified for local configuration if necessary.
The flags are placed in register 11 (as defined in
The boot device is specified in register 10.
The encoding of this register is also defined in
The current encoding has a historical basis, and is shown in the following
.Bd -unfilled -offset indent -compact
0-7 boot device type (the device major number)
24-27 adaptor number (UNIBUS or MASSBUS as appropriate)
The adaptor number corresponds to the normal configuration on the 11/750,
and to the order in which adaptors are found on the 11/780 and 8600
(generally the same as the numbers used by
On an 11/750, the reset button will boot from the device
selected by the front panel boot device switch. In systems
with RK07's, position B normally selects the RK07 for boot.
This will boot multi-user. To boot from RK07 with boot flags you
.Bd -unfilled -offset indent -compact
.Li \&>>>B/ Ns Fl n No DMA0
of 1 causes the boot program
to ask for the name of the system to be bootstrapped,
of 2 causes the boot program to come up single
of 3 causes both of these actions to occur.
The ``DM'' specifies RK07, the ``A'' represents the adaptor number
and the ``0'' is the drive unit number.
Other disk types which may be used are DB
A non-zero disk partition can be used by adding (partition times 1000 hex)
The boot procedure on the Micro
A switch on the back panel sets the power-up action
When halted, the processor may be booted using the same syntax
The 11/750 boot procedure uses the boot roms to load block 0 off of
the specified device. The /usr/mdec directory contains a number
of bootstrap programs for the various disks which should be placed
II boot procedure loads a boot parameter block
from block 0 of the disk.
contains the correct parameters for an
finds the corresponding file on the given device
by default), loads that file
into memory location zero, and starts the program at the entry address
specified in the program header (after clearing off the high bit
of the specified entry address).
The file specifications used with
.Dl device(adaptor,controller,unit,minor)
is the type of the device to be searched,
number of the adaptor to which the device is attached,
is the unit number of the controller or
tape formatter on that adaptor,
is the unit number of the disk or transport slave unit of the tape,
is the disk partition or tape file number.
Leading adaptor or controller numbers default to 0.
Normal line editing characters can be used when typing the file specification.
The following list of supported devices may vary from installation to
.Bd -unfilled -offset indent -compact
up UNIBUS storage module drive
ht TE16,TU45,TU77 on MASSBUS
kra storage module on a KDB50
ra storage module on a MSCP-compatible UNIBUS controller
rb storage module on a 730 IDC
tm TM11 emulation tape drives on UNIBUS
tms TMSCP-compatible tape
to boot from a file system which starts at cylinder 0
For tapes, the minor device number gives a file offset;
would specify the fifth file on slave 3 of the formatter
On an 11/750 with patchable control store,
microcode patches will be installed by
exists in the root of the filesystem from which the system is booted.
In an emergency, the bootstrap methods described in the paper
.%T Installing and Operating 4.3bsd
can be used to boot from a distribution tape.
.Bl -tag -width /usr/mdec/xxboot -compact
sector-0 boot block for 750, xx is disk type
second-stage boot for 750, xx is disk type
microcode patch file on 750