Digital PDFs

AA-ME90A-TE

May 1988

62 pages

Original

2.0MB

Document:	ULTRIX-32 Guide to System Configuration File Maintenance
Order Number:	AA-ME90A-TE
Revision:	000
Pages:	62
Original Filename:

OCR Text

ULTRIX-32
Guide to System
Configuration File Maintenance

Order No. AA-ME90A-TE

ULTRIX-32 Operating System, Version 3.0

Digital Equipment Corporation

The information in this document is subject to change without notice and should not be
construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation
assumes no responsibility for any errors that may appear in this document.
The software described in this document is furnished under a license and may be used or
copied only in accordance with the terms of such license.
No responsibility is assumed for the use or reliability of software on equipment that is not
supplied by DIGITAL or its affiliated companies.

The following are trademarks of Digital Equipment Corporation:
DEC
DECnet
DECUS
MASS BUS
MicroVAX

PDP

Q-bus
RT
ULTRIX
ULTRIX-11
ULTRIX-32
UNIBUS

VAX
VAXstation
VMS
VT
ULTRIX Worksystem Software
~amaomo

UNIX is a registered trademark of AT&T in the USA and other countries.
IBM is a registered trademark of International Business Machines Corporation.
MICOM is a registered trademark of Micom System, Inc.
This manual was written and produced by the ULTRIX Documentation Group in Nashua, New
Hampshire.

Contents

About This Ma nua I
Audience ..........................................................................................................

Organization ....................................................................................................

Related Documents ........................................................................................

Conventions . . . .. .. . .. . . . . . . . .. . .. . .. . . . . .. . . .. . .. . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . .. . . . . . .. . .. . . . .. . .. . . . .

1 The System Configuration File
1.1 The System Configuration File .............................................................

1-1

1.2 The Generic System Configuration File

1-1

1.3 The Generic System Configuration File Format ................................

1-2

1.3.1 Global Definitions ........................................................................
1-2
1.3.2 System Image Definitions ..........................................................
1-8
1.3.3 Device Definitions ....................................................................... 1-10
1.3.3.1 Adapter Specifications .............................................................
1.3.3.2 Master Specifications ...............................................................
1.3.3.3 Controller Specifications ..........................................................
1.3.3.4 Device Specifications ................................................................
1.3.3.5 Disk Specifications ...................................................................

1-10
1-11
1-12
1-14
1-15

1.3.4 Pseudodevice Definitions ............................................................ 1-16
1.4 Sample Generic Configuration File ....................................................... 1-18
1.5 System Configuration Files for Diskless Clients ................................ 1-24

1.5.1 Default Diskless Configuration File Naming Conventions .....
1.5.2 Diskless Default Configuration File Differences .....................
1.5.3 Diskless Configuration File Use ................................................
1.5.4 Sample Default Diskless Configuration File ............................

1-24
1-25
1-25
1-26

2 Building the Kernel
2.1 When To Build a New Kernel

2-1

2.2 Building a Kernel Automatically ............................................................

2-2

2.2.1 Using the doconfig Program ......................................................
2.2.2 Testing the New Kernel .............................................................

2-2
2-6

2.3 Building a New Kernel Manually .........................................................

2-6

2.3.1 Edit the Configuration File ....................................................... 2-7
2.3.2 Prepare the Directory for the Binary Files ............................ 2-7
2.3.3 Define the Code Dependencies .................................................. 2-8
2.3.4 Compile and Load the Binary Files ......................................... 2-9
2.3.5 Boot the New Kernel ................................................................. 2-10
2.4 Building the Kernel After a Capacity Upgrade Installation ............. 2-11

A Device Mnemonics
Index

Examples
1-1:

Sample Configuration File .................................................................. 1-18

1-2:

Sample QEQDVAX.dlconf Configuration File .................................. 1-27

2-1:

Sample doconfig Execution .................................................................

2-4

Tables
A-1:

Devices Supported by MAKEDEV ...................................................

iv Contents

A-2

About This Ma nua I

This guide provides information on how to maintain the system
configuration file and how to build a new kernel system image. This guide
also explains how to build a new kernel automatically or manually.

Audience
The ULTRIX-32 Guide to System Configuration Fik Maintenance is
written for the person responsible for managing and maintaining an
ULTRIX system. It assumes that this individual is familiar with ULTRIX
commands, the system configuration, the system's controller/drive unit
number assignments and naming conventions, and an editor such as vi or
ed. You do not need to be a programmer to use this guide.

Organization
This manual consists of two chapters, one appendix, and an index. The
chapters are:
Chapter 1:

The System Configuration File
Explains the format of the generic confi~ation file and
provides a sample configuration file. This !chapter also
describes the default configuration files used in a
diskless environment.

Chapter 2:

Building the Kernel
Describes how to build a kernel either automatically or
manually, and explains how to build a new kernel after
a capacity upgrade installation.

Appendix A:

Device Mnemonics
Lists the supported device mnemonics and explains how
to obtain detailed reference page information on devices.

Related Documents
You should have the hardware documentation for your system and
peripherals.

Conventions
The following conventions are used in this manual:
special

In text, each mention of a specific command, option,
partition, pathname, directory, or file is presented in this
type.

command(x)

In text, cross-references to the command documentation
include the section number in the reference manual where
the commands are documented. For example: See the
cat(1) command. This indicates that you can find the
material on the cat command in Section 1 of the reference
pages.

literal

In syntax descriptions, this type indicates terms that are
constant and must be typed just as they are presented.

italics

In syntax descriptions, this type indicates terms that are
variable.

[ ]

In syntax descriptions, square brackets indicate terms that
are optional.
In syntax descriptions, a horizontal ellipsis indicates that
the preceding item can be repeated one or more times.

f u n c t i on

In function definitions, the function itself is shown in this
type. The function arguments are shown in italics.

UPPERCASE

The ULTRIX system differentiates between lowercase and
uppercase characters. Enter uppercase characters only
where specifically indicated by an example or a syntax line.

example

In examples, computer output text is printed in this type.

example

In examples, user input is printed in this bold type.

This is the default user prompt in multiuser mode.

This is the default superuser prompt.

>>>

This is the console subsystem prompt.

vi About This Manual

In examples, a vertical ellipsis indicates that not all of the
lines of the example are shown.
<KEYNAME > In examples, a word or abbreviation in angle brackets
indicates that you must press the named key on the
terminal keyboard.
<CTRL/x>

In examples, symbols like this indicate that you must hold
down the CTRL key while you type the key that follows
the slash. Use of this combination of keys may appear on
your terminal screen as the letter preceded by the
circumflex character. In some instances, it may not appear
at all.

About This Manual vii

The System Configuration File

This chapter explains the contents and format of the generic configuration
file. A sample generic configuration file is provided to illustrate how
specific information defines the hardware, software, and system parameters.
The chapter also contains a description of the default configuration files
and their location in a diskless system environment.

1.1

The System Configuration File

The system configuration file describes how you want the configuration
software to build the kernel. It identifies all of the device driver source
code that needs to be compiled into the kernel, as well as a number of
system parameters that affect how the kernel operates. The kernel is the
system image that controls system scheduling, memory management, input
and output services, device management, and organization of the file
systems. Provided you have enough disk space, you can build more than
one kernel.
Except for diskless systems, the system configuration file resides in
/usr/sys/conf and has the same name as the system name (in uppercase
letters) which was defined during the installation procedure. For example,
if you named your system tucson during the installation procedure, then
the system configuration file name will be /usr/sys/conf/TUCSON. The
/usr/sys/conf directory also has a generic system configuration file that you
can use to tailor other system configuration files to your hardware.

1.2

The Generic System Configuration File

This section describes the organization and entries of the GENERIC
configuration file, /usr/sys/conf/GENERIC, which is a template that you can
use to build other configuration files. In addition to the configuration file
information contained in this chapter, the following information will help
you tailor a configuration file to your system's hardware, options, and
requirements:
•

Section 4 of the UL TRIX Reference Pages contains definitions of
configuration file entries and the syntax to define supported devices.
Use the descriptions in Section 4 to determine the correct syntax for
changes to the configuration file

•

Appendix A provides information on the names of the device
mnemonics supported by MAKEDEV

1.3

The Generic System Configuration File Format

All configuration files, including the generic configuration file, have four
parts:
•

Global definitions

•

System image definitions

•

Device definitions

•

Pseudodevice definitions
Note

In some cases, the system parameters discussed in this section
do not appear in the GENERIC configuration file. These
parameters, as well as some of the arguments to the parameters,
are described here because the parameters are used in some
system configuration files.

1.3.1

Globa I Definitions

The global definitions parameters apply to all the kernels generated by the
configuration file. Each global definition appears on a separate line in the
configuration file. Each line represents a tunable system parameter and
begins with one of these keywords:
machine
cpu
ident
timezone
maxusers
max up re
manuva
maxtsiz
physmem
dmmin
dmmax

1-2 The System Configuration File

smmin
smmax
smseg
smsmat
smbrk
processors
scs_sysid
options

The following paragraphs display the syntax and describe how and when to
use each parameter:
machine type

This parameter defines the hardware; the argument type must be vax:
For example:
machine vax

cpu

type"
This parameter defines the processor; the argument type must be
enclosed in quotes. For example:
cpu

VAX780

The GENERIC configuration file lists the cpu types by processor
class. This is because in some cases, the processor names have been
equivalenced in the configuration software. For instance, the "MVAX"
entry applies to the Micro VAX II and VAXstation 2000 processors.
The VAX3600 entry in the GENE RIC configuration file applies to all
of the MicroVAX 3000, VAX 3000, and VAXserver 3000 type
processors. The VAX 8200 applies to the VAX 8200 processor.
•

If you know your processor class, then you can use that as
your configuration file entry.

•

If you do not know your processor class, then you can use the
exact processor name. For example:
VA,X8800
VAX8820
VAX8700
VAX8600
VAX8550
VAX8530
VAX8500
VAX8350

The System Configuration File 1-3

VAX8300
VAX8200
VAX6210
VAX6220
VAX3600
VAX3500
VAX3400
VAX3300
VAX785
VAX780
VAX750
VAX420
MVAX

•

You can specify more than one c p u type for a kernel that can
be booted on multiple cpu's. However, a kernel for multiple
processors means that during the configuration process, your
system will build more capabilities than it needs. The result is
that in most cases, your kernel will require more memory than
a kernel for a single processor requires. It is also possible that
under these conditions, your system will have to do more
paging and swapping during daily operations, which will affect
system performance.

ident name
This parameter defines the host machine for which you are creating
the configuration file. The name argument is the system name
which you specified during the installation procedure. Enter the
name in upper cases letters.
ident TUCSON

This parameter ensures that all host-specific source code is compiled
during the actual configuration process.
timezone number dst x

This parameter defines timezone information for your site. The
installation procedure enters this value to your system configuration
file according to information you supply during the installation or
when you register a diskless client. The number argument identifies
your time zone, measured by the number of hours west of Greenwich
Mean Time: for example, Eastern Standard Time is five hours west
of Greenwich Mean Time, and Pacific Standard Time is eight hours
west. Negative numbers indicate hours east of GMT. The generic
configuration file time zone entry is set to Eastern Daylight Savings
Time (The entry is timezone 5 dst) .

1-4 The System Configuration File

The argument dst indicates daylight savings time. During the
installation procedure, you can include a number ( x) to request a
particular daylight savings time correction algorithm. The values are:
1 United States (the default value)
2 Australia
3 Western Europe
4 Central Europe
5 Eastern Europe
maxusers number

This parameter defines the maximum number of simultaneously active
users allowed on your system. The number argument should be equal
to or greater than the maximum number of users allowed by your
license agreement.
The number in this field is used in the system algorithms to size a
number of system data structures and to determine the amount of
space allocated to system tables. One such table is the system
process table, which is used to determine how many active processes
can be running at one time.
The maxusers number also affects the number of mbuf pages that
the kernel allocates based on increments of 32. For instance:
•

If the maxusers number is less than 64, the kernel allocates 32
mbuf pages.

•

If the maxusers number is between 64 and 95, the kernel
allocates 64 mbuf pages.

•

If the maxusers number is between 96 and 127, the kernel
allocates 96 mbuf pages.

•

If the maxusers number is between 128 and 159, the kernel
allocates 128 mbuf pages.

maxuprc number

This parameter defines the the maximum number of processes one
user can run simultaneously. The default maxuprc entry is 50.
maxuva num

This parameter defines the maximum aggregate number of user
virtual address space in megabytes allowed by the system. The
default value is 256 Mb.
maxsiz num

This parameter defines the largest text segment in megabytes allowed
by the system. The default value is 12 Mb.

The System Configuration File 1-5

physmem number
This parameter defines an estimate of the amount of physical
memory currently in the system in Mbytes. This number argument
is not used to limit the amount of memory, rather, it is used by the
system to size the system page table, so it should be greater than or
equal to the amount of physical memory in the system.
dmmin numl and dmmax num2
The system satisfies requests for additional virtual memory using the
values for dmmin and dmmax. A process is initially granted numl
512-byte blocks of virtual memory. The next time the process
requests memory, the system grants twice as much ( numl x 2).
This allocation continues until the amount of memory granted is
equal to num2 blocks. After that, additional requests are satisfied
with num2 blocks of memory. The default value for numl is 32.
The default value for num2 is 1024. The numl and num2 values
should be a power of 2, and the num2 value should be a multiple of
numl. Otherwise, the system's behavior may be unpredictable.

The dmmin and dmmax parameters are used to size the maximum
permitable process data segment. To get a maximum permitable
process data segment of about 23 Mbytes, the dmmax value should
be 1024. If you double the dmmax value to 2048, the process data
segment size will be roughly 43 Mbytes. If you double 2048 to
4096, the process data segment size will be roughly 80 Mbytes. You
should note that as the dmmax number increases, so does swap
space fragmentation.
smmin num

This parameter defines the m1mmum number of 512 byte blocks of
virtual memory at which a shared memory segment ( SMS) may be
sized. The default for smmin is 0 blocks. For more information see
shmget( 2) in the ULTRIX Reference Pages.
smmax num

This parameter defines the maximum number of 512 byte blocks of
virtual memory at which a shared memory segment may be sized.
The default for smmax is 256 blocks ( 128 Kbytes). For more
information see shmget( 2) in the ULTRIX Reference Pages.
smseg num

This parameter defines the maximum number of shared memory
segments per process. The default value is 6. For more information
see shmop( 2) in the ULTRIX Reference Pages.

1-6 The System Configuration File

smbrk num

This parameter defines the default spacing between the end of a
private data space of a process and the beginning of its shared data
space in 512 byte blocks .of virtual memory. This value is important
because, once a process attaches shared memory, private data cannot
grow past the beginning of shared data. The default for smbrk is 64
blocks ( 32 Kbytes). For more information on shared memory
operations, see shmop( 2) in the ULTRIX Reference Pages.
smsmat num

This parameter defines the highest attachable address in megabytes
for shared memory segments. The default value is MAXDSIZE.
For more information see shmop( 2) in the ULTRIX Reference Pages.
processors num

This parameter defines the number of processors in the system.
scs_sysid number

This parameter identifies each host uniquely on the CI star cluster to the
SCS subsystem. The number argument must be a unique identifier for
each host. At installation, the system automatically generates this number,
and puts it in the configuration file. If the system does not detect a CI
at installation, it provides a default value of 1.
options optionlist

Although the options field allows optional code to be compiled into
the system, you should leave the options as they appear in the
generic configuration file. However, you can remove any of the
options if they do not pertain to your site, or if your system is
short on physical memory space. These are the possible values for
optionlist:
EMULFLT

Emulates the floating point instruction set if it is
not already present in the hardware.

INET

Provides internet communication protocols. The
inet pseudodevice must also be set.

LAT

Allows you to access your machine from a local
area terminal server on the Ethernet. The lta
and lat pseudodevices must also be set.
If the DECnet layered product is installed, this
option must be set. The decnet pseudodevice
must also be set.
Allows disk quotas to be set.

DECNET

QUOTA

The System Configuration File 1-7

SYS_TRACE Enables the system call tracing capability.
sys_trace pseudodevice must also be set.

The

DLI

Allows mop-mom activity to be invoked. The
mop_mom command is usually included in the
/etc/re.local file as a background task to cause
mop-mom to listen for down-line and up-line load
requests over the network. The dli pseudodevice
must also be set.

BSC
RPC

Allows 2780/3780 emulation. The bsc
pseudodevice must also be set.
Remote Procedure Call facility

NFS

This option is necessary for RPC-based applications
within the NFS file system. The rpc pseudodevice
must also be set.
Network File System
This option allows you to access the NFS protocol.
It requires the RPC option. The nfs pseudodevice
must also be set.

UFS

1.3.2

ULTRIX File System
This option is the standard, local file system. If
you do not use the NFS option, the UFS option
must be set. If you do not specify this option,
the system will be considered diskless. The ufs
pseudodevice must also be set.

System Image Definitions

There is one system definition in the generic configuration file. However,
you can change the definition or add more lines to the configuration file
you are building to indicate that you want to generate more than one
kernel. For each kernel you wish to generate, specify one line that begins
with the keyword config. Each line can be used to define the root device,
the swap area or areas, the dump area, and the argument processing area
for system calls.
The general format of a line for any one kernel is:
con f i g fikname configuration-dauses

The fil,e name argument is the name to be assigned to the file constituting
the compiled kernel, or system image. The installation procedure assigns
the name vmunix.

1-8 The System Configuration File

The configuration-clauses define the devices for the root file system, for
the paging and swapping area, and for crash dumps. The configurationclauses keywords are: root, swap, and dumps. The syntax and descriptions
of these keywords are:
root [ on ] device

The installation procedure assigns partition a of the system disk to
the root file system. You can change this assignment by editing the
configuration file. For diskless clients, this entry is set to root on
seO.
swap [ on ] device [ and device ] [ size x ] [ boot ]

The first device argument specifies the device and partition that you
want the system to use for a paging and swapping area. The
installation procedure assigns partition b of the system disk for the
paging and swapping area. You can change this assignment by editing
the configuration file.
The second device argument enables you to add another partition so
that the kernel interleaves paging and swapping between the two
partitions. To specify a second paging and swapping area, use the
and clause with a device, a logical unit, and a partition name.
Use the size clause to specify a nonstandard partition size for one or
more swap areas. The value of x represents the number of 512-byte
sectors. A size larger than the associated disk partition is trimmed
to the partition size. The default swap device is partition b of the
device where the root is located.
If you specify swap on boot, the a partition of the booted device

becomes the root, and swap space is assumed to be the b partition of
the same device.
Example configuration file entries are:
swap on raOb
swap on ralh
swap on raOb and ralh

In the first example, the system swaps on partition b of the raO disk.
In the second example, the system swaps on partition h of the ra 1
disk. In the last example, the system swaps on partition b of the
raO disk and partition h of the ra 1 disk.
For diskless systems, if the swap file is remote, then you do not have
to specify a swap device.
dumps [ on ] device

The device argument specifies the partition and the device where
crash dumps are to be stored.
The device that is specified must be
on the same controller as the boot device. The default dump device

The System Configuration File 1-9

is the first swap device configured.
Usually, this entry is unnecessary in a diskless environment because
the dms setup process specifies using the mop_mom command for
dumping. However, customized diskless kernels can specify dumping
to a disk. See mop_mom( 8) for a description of this command. See
the Guide to Diskless Management Services for more information on
the creation of diskless environments.
Device Definitions

1.3.3

This section of the configuration file contains descriptions of each current
or planned device on the system. You need to add definitions for devices
that were not on the system at installation time. You may also want to
delete device definitions for devices that have been removed from the
hardware configuration.
Each line of this section of the file begins with one of these keywords:
adapter
Identifies a physical connection to a system bus such as
VAXBI, MASSBUS, Q-bus, UNIBUS, MSI, IBUS, or Cl.
master

A MASSBUS tape controller.

controller

Identifies either a physical or a logical connection with one
or more slaves attached to it. Some examples are: uda,
kdb, hsc, and uq.

device

An autonomous device which connects directly to a Q-bus,
or to a UNIBUS, MASSBUS, IBUS, or VAXBI adapter (as
opposed to a disk, for example, which connects through a
disk controller).

disk

A disk drive connected to either a master or a controller.

tape

A tape drive connected to either a master or a controller.

The format of the information required for each of these types of devices
varies, as described in the following sections:
1.3.3.1 Adapter Specifications - The adapters discussed in this section
are the VAXBI, MASSBUS, UNIBUS, MSI, CI, IBUS, and Q-bus
adapters. Each adapter is specified by its own format in the configuration
file.
1.

The format for VAXBI adapters is:
adapter vaxbin at nexus?

The n is the unit number of the adapter. The question mark ( ?)
allows the system to pick the appropriate NEXUS for you.

1-1 O The System Configuration File

The format for MASS BUS adapters is:
adapter mban at nexus?

The n is the unit number of the adapter. The question mark ( ?)
allows the system to pick the appropriate NEXUS for you.
3.

The format for IBUS adapters is:
adapter ibusn at nexus?

The format for UNIBUS and Q-bus adapters is the same. Q-bus
adapters are specific to MicroVAX- and VAXstation-type processors.
The format is:
adapter ubaO at nexus ?

The question mark ( ?) allows the system to pick the appropriate
NEXUS for you.
5.

The format for MSI adapters is:
adapter msiO at nexus?

The question mark ( ?) allows the system to pick the appropriate
NEXUS for you.
6.

The formats for CI adapters are:
adapter ciO at nexus?
adapter ciO at vaxbi?

The question mark ( ?) allows the system to pick the appropriate
NEXUS or VAXBI for you.

1.3.3.2 Master Specifications - MASSBUS tape drives must be attached
to a master. The format for specifying a master is:
master

devname

at mbam

driven

dev The name of the tape device, such as htO.
m

The MASSBUS adapter number.

The drive number.

The System Configuration File 1-11

For example:
master
tape
tape

htO
tuO
tul

at mba?
at ht 0
at htO

drive?
slave 0
slave 1

1.3.3.3 Controller Specifications - This section contains examples of the
specifications for the various controllers. The controller examples are for
MSCP, TMSCP and SCSI controllers. This section also defines the format
for specifying other tape-to-disk interface controllers.

MSCP disk controllers

•

For UNIBUS or Q-bus:
control I er
control I er
disk raO at
disk ral at
disk ra2 at
disk ra3 at

•

udaO at ubaO
uqO at udaO csr 0172150 vector uqintr
uqO drive 0
uqO drive 1
uqO drive 2
uqO drive 3

For VAXBI:
cont ro I I er kdbO at vaxb i 0 node?
controller uqO at kdbO vector uqintr
disk raO at uqO drive 0
disk ral at uqO drive 1
disk ra2 at uqO drive 2
disk ra3 at uqO drive 3
controller aiol at vaxbi? node?
controller bvpsspO at aiol vector bvpsspintr
disk raO at bvpsspO drive 0

•

For VAX CI/HSC:
adapter ciO at nexus?
adapter ciO at vaxbi? node?
controller hscO at ciO cinodeO
disk raO at hscO driveO

•

For MSI bus:
adapter msiO at nexus?
controller dsscO at msiO msinode 0
disk raO at dsscO drive 0

1-12 The System Configuration File

TMSCP tape controllers

•

For UNIBUS or Q-bus:
controller klesiuO at ubaO
controller uqO at klesiuO csr 0174500 vector uqintr
tape tmsO at uqO drive 0

•

For VAXBI:
controller klesibO at vaxbiO node 0
controller uqO at klesibO vector uqintr
tape tmsO at uqO drive 0
controller aieO at vaxbi? node?
controller bvpsspO at aieO vector bvpsspintr
tape tmsO at bvpsspO drive 0

•

For MSI Bus:
adapter msiO at nexus?
controller dsscO at msiO msinodeO
tape tmsO at dsscO drive 0

•

For VAX CI/HSC:
adapter ciO at nexus?
adapter ciO at vaxbi? node?
controller hscO at ciO cinodeO
tape tmsO at hscO drive 0

3.
•

SCSI controllers
For disks:
adapter ubaO at nexus?
controller scsiO at ubaO csr Ox200c0080 vector szintr
cont ro I I er scs i 1 at ubaO cs r Ox200c0180 vector sz int r
disk rzl at scsiO drivel
disk rz2 at scsiO drive2
disk rz9 at scsil drivel
disk rzlO at scsil drive2

•

For tapes:
adapter ubaO at nexus?
controller scsiO at ubaO csr Ox200c0080 vector szintr
control I er scsi 1 at ubaO csr Ox200c0180 vector szintr
tape tzl at scsiO drivel
tape tz2 at scsiO drive2
tape tz9 at scsil drivel
tape tzlO at scsil drive2

The System Configuration File 1-13

Other controllers
The format for controllers for the magnetic tape interface (ts) and
the disk interface i'-.
controller dev at condev[ csr n ] vector vec
tape unit at dev drive n

dev

The device name and logical unit number of the controller.

condev

unit

The name and logical unit number of the device to which
the controller is connected.
For the controller, n represents the octal address of the
control status register for the device. Note that the
address needed here is a 16-bit address. This entry is not
needed for the VAXBI. For the tape, n represents the
logical name of the tape unit.
The unit number of the tape drive.

vec

The address of any interrupt vector for the controller.

This example shows a sample entry for a TU80 or TSV05 (for
MicroVAX) magnetic tape interface:
controller zsO at
tape
tsO at

ubaO csr 0172520 vector tsintr
zsO drive 0

1.3.3.4 Device Specifications - The format for the hardware classified as
devices is:
device dev

condev [csr n] [ flags f ]

vector

vl ...

Tab characters are used to indicate continuation lines, if needed.
arguments are:

The

dev

The device name and logical unit number of the device.

condev

The name and logical unit number of the adapter or controller to
which the device is connected.

The octal address of the control status register for the device.
The csr n option is not needed for VAXBI devices. A number
used to convey information about the device to the device driver.
The only flags for DIGITAL-supported devices are for line
printers and communications multiplexers.

The default page width for all DIGITAL line printers is 132
columns. To change the page width, use flags f, where f is a
decimal number giving the desired width in columns. For
example, to change to 80 columns, enter flags 80.

1-14 The System Configuration File

The DH, DZ, DMB, DHU, DMF, and DMZ communications
multiplexers accept a hexadecimal flag value to specify any lines
that should be treated as hardwired with carrier always present.
The DHV-11, DZQ, and DZV serve the same function as the Qbus. The format of the hexadecimal number is Oxnn, where nn
is a hexadecimal number consisting of digits ranging from 0-9, af.
Because bits are numbered from right to left, setting bit 0 of the
flag indicates that ttyOO is hardwired, setting bit 1 of the flag
indicates that ttyOl is hardwired, and so forth. This example
shows that tty02 is hardwired with carrier always present: flags
Ox04

The names of interrupt vector routines for the device driver.

vl...

The following example shows a sample device specification for the DEUNA
10-Mbyte Ethernet interface:
device deO at ubaO csr 0174510 vector deintr

The following example shows a sample device specification for a DZ-11
communications multiplexer:
device dzO at ubaO csr 0160100 flags Oxff vector dzrint dzxint

The following example shows a sample device specification for a DMB32
communications controller device:
device dmbO at vaxbi2 node3 flags OxOOff vector dmbsint dmbaint dmbl int

1.3.3.5

Disk Specifications - The format for specifying disks is:

disk dev

at condev drive n

dev

The device name and logical unit number of the disk.

condev

The name and logical unit number of the adapter or controller to
which the disk is connected.

The physical unit number of the disk. If your disk is on a
MASSBUS device, you can specify a question mark ( ?) for n.
A question mark ( ?) allows the system to assign the physical
number to the disk for you.

Here is an example of a device specification for MSCP disks:
disk raO at uqO drive 0

The System Configuration File 1-15

The MAKEDEV program allows you to make up to 32 RA units. You can
have physical drive numbers ( n) from 0 through 251, and logical drive
numbers ( dev) from 0 through 31. Number the drives consecutively. The
physical drive number should correspond with its assigned logical drive
number whenever possible, as shown in the preceding example. Therefore,
the physical drive numbers from 32 through 251 are rarely used. Refer to
MAKEDEV( 8) for more information.
1.3.4

Pseudodevice Definitions

A pseudodevice is an operating system component for which there is no
associated hardware such as a pseudoterminal or one of the various
supported protocols. Pseudodevice definitions are needed in the config file
so that the operating system will recognize these components.
Each pseudodevice definition line in the config file defines a driver for a
particular pseudodevice. Each pseudodevice definition line begins with the
keyword pseudodevice, followed by the pseudodevice name. The format is:
pseudo-device name

[max n]

The name is the name of the pseudodevice.
the following pseudodevice names:

Configuration files can have

pty

For pseudoterminal support (default = 16, specify max n for
more than 16).

inet

For DARPA internet protocols.

loop

For network loopback interface.

ether

For 10-Mbyte Ethernets.
For local area terminal (LAT) protocols.

lat
lta

For pseudoterminal driver (default = 16, specify max n for more
than 16).

For support of DECNET, and is only required when the
DECNET layered product is installed.
sys_trace For support of the system call trace capability.
dee net

dli

For DLI support of mop_mom activity.

bsc

For support of 2780/3780 emulation. To work, the dpvO or dupO
devices must be defined in the configuration file as shown in the
example in Section 1.2.

rpc

For Remote Procedure Call facility.

nfs

For Network File System (NFS) protocol support.

1-16 The System Configuration File

ufs

For local ULTRIX file system use.

scsnet

For Systems Communications Services ( SCS) network interface
driver. See scs( 4) in the ULTRIX Reference Pages for more
information.

The optional max n argument lets you assign more pseudoterminals. By
default, pty and lta are set to 16. If you need more pseudoterminals you
must specify a max n value. For example:
pseudo-device pty 32
pseudo-device lta 32

The System Configuration File 1-17

1.4

Sample Generic Configuration File

Example 1-1 illustrates a typical generic configuration file. Be aware that
the generic configuration file supplied with your system may be different
from the one shown here.

Example 1-1: Sample Configuration File
#

# @(#)GENERIC4.1.l.18 (ULTRIX) 9/14/88
# GENERIC VAX
#

#Global Definitions
#

machine
vax
cpu
VAX8800
cpu
VAX8600
cpu
VAX8200
VAX6210
cpu
c pu
VAX3600
cpu
VAX785
cpu
VAX780
cpu
VAX750
cpu
VAX420
cpu
MVAX
ident
GENERIC
timezone
5 dst
maxusers
2
maxuprc
10
physmem
6
processors
1
scs_ sys id
32
options
QUOTA
options
UFS
options
INET
options
EMULFLT
11

11
11

#
#

#System Image Definitions
#
#

conf ig

vmunix

swap on boot

(continued on next page)

1-18 The System Configuration File

#Adapter Specifications
#
#

adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter
adapter

xmiO at nexus?
vaxbiO at nexus?
vaxbil at nexus?
vaxb 2 at nexus?
vaxb 3 at nexus?
vaxb 4 at nexus?
vaxb 5 at nexus?
vaxb 11 at nexus?
vaxb 12 at nexus?
vaxb 13 at nexus?
vaxb 14 at nexus?
mbaO at nexus?
mbaO at nexus?
mbal at nexus?
mbaO at nexus?
mbal at nexus?
mba2 at nexus?
mba3 at nexus?
ubaO at nexus?
ubal at nexus?
uba2 at nexus?
uba3 at nexus?
uba4 at nexus?
uba5 at nexus?
uba6 at nexus?
ibusO at nexus?
ibusl at nexus?
ibus2 at nexus?
ibus3 at nexus?
ibus4 at nexus?
ibus5 at nexus?
ibus6 at nexus?
ibus7 at nexus?
msiO at nexus?
ciO at nexus?
ciO at vaxbi? node?

#Controller Specifications
#
#

control ler
control I er
control ler
control ler
control ler
control ler

hscOat
hscl at
hsc2 at
hsc3 at
h s c4 at
hsc5 at

ciO
ciO
ciO
ciO
ciO
ciO

cinode
cinode
cinode
cinode
cinode
cinode

1
2
3
4
5

(continued on next page)

The System Configuration File 1-19

control I er
control I er
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
contro ler
control ler
control ler
control ler
control ler
control ler
control ler
control ler
controller
control I er
controller
control I er
control I er
control I er
control I er
control I er
control I er
controller
control I er
controller
control I er
controller
control I er
controller
control I er
controller
control I er
controller
control I er
control I er
control I er

hsc6 at ciO cinode 6
hsc7 at ciO cinode 7
dsscO at ms 0 ms node 0
dsscO at ms 0 ms node 0
dsscl at ms 0 ms node 1
dssc2 at ms 0 ms node 2
dssc3 at ms 0 ms node 3
dssc4 at ms 0 ms node 4
dssc5 at ms 0 ms node 5
dssc6 at ms 0 msinode 6
dssc7 at ms 0 msinode 7
aioO at vaxb ? node?
aiol at vaxb ? node?
aieO at vaxb ? node?
node?
aiel at vaxb
aie2 at vaxb ? node?
aie3 at vaxb ? node?
node?
kdbO at vaxb
kdbl at vaxb ? node?
kdb2 at vaxb ? node?
kdb3 at vaxb ? node?
kdb4 at vaxb ? node?
node?
kdb5 at vaxb
kdb6 at vaxb ? node?
node?
kdb7 at vaxb
kdb8 at vaxb ? node?
kdb9 at vaxb ? node?
kdblO at vaxbi? node?
kdbll at vaxbi? node?
klesibO at vaxbi? node?
klesibl at vaxbi? node?
klesib2 at vaxbi? node?
udaO at uba?
udal at uba?
uda2 at uba?
uda3 at uba?
klesiuO at uba?
klesiul at uba?
klesiu2 at uba?
klesiu3 at uba?
uqO at udaO csr 0172150 vector
uql at udal csr 0172150 vector
uq2 at uda2 csr 0172150 vector
uq3 at uda3 csr 0172150 vector
uq4 at kdbO vector uqintr
uq5 at kdbl vector uqintr
uq6 at kdb2 vector uqintr
uq7 at kdb3 vector uqintr

uqintr
uqintr
uqintr
uqintr

(continued on next page)

1-20 The System Configuration File

control ler
control ler
control ler
control ler
control ler
control ler
control I er
control I er
control I er
control I er
control I er
control ler
control ler
control ler
control I er

bvpsspO at aioO vector bvpsspintr
bvpsspl at aiol vector bvpsspintr
bvpssp2 at aieO vector bvpsspintr
uqO at udaO csr 0172150 vector uqintr
uql at udal csr 0172150 vector uqintr
uq2 at uda2 csr 0172150 vector uqintr
uq3 at uda3 csr 0172150 vector uqintr
csr 0174500 vector uqintr
uql6 at klesiuO
csr 0174500 vector uqintr
uql7 at klesiul
csr 0174500 vector uqintr
uql8 at klesiu2
csr 0174500 vector uqintr
uql9 at klesiu3
vector uqintr
uq20 at klesibO
vector uqintr
uq21 at klesibl
scsiO at ubaO csr Ox200c0080 vector szintr
scsil at ubaO csr Ox200c0180 vector szintr

#
#
# Disk Specifications
#
#

disk
disk
disk
disk
disk
disk
d sk
d sk
d sk
d sk
d sk
d sk
d sk
d sk
d sk
disk
d sk
d sk
d sk
d sk
d sk
d sk
d sk
disk
disk
disk
disk

hpO at mba? drive 0
hpl at mba? drive 1
hp2 at mba? drive 2
hp3 at mba? drive 3
hp4 at mba? drive 4
hp5 at mba? drive 5
hp6 at mba? drive 6
hp7 at mba? drive 7
raO at uqO dr ve 0
ral at uqO d r ve 1
ra2 at uqO d r ve 2
ra3 at uqO d r ve 3
ra4 at uqO dr ve 4
ra5 at uqO dr ve 5
ra6 at uqO dr ve 6
rzO at scs 0 d r i veO
rzl at scs 0 drivel
rz2 at scs 0 d r i ve2
rz3 at scs 0 d r i ve3
rz4 at scs 0 d r i ve4
rz5 at scs 0 d r i ve5
rz6 at scs 0 d r i ve6
r z7 at scs 0 drive?
rz8 at scs 1 d r i veO
rz9 at scs 1 drive 1
rzlO at scsil d r i ve2
rzll at scsil d r i ve3

(continued on next page)

The System Configuration File 1-21

# Tape Specifications
#
#

tape
tape
master
tape
tape
tape
tape
master
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape
tape

stO at
tsO at
htO at
tuO at
tul at
tu2 at
tu3 at
mtO at
muO at
mul at
mu2 at
mu3 at
tms 1 at
tms2 at
tms3 at
tms4at
tms5 at
tms6 at
tms 7 at
tzO at
tzl at
tz2 at
tz3 at
tz4 at
tz5 at
tz6 at
tz7 at
tz8 at
tz9 at
tzlO at
tzllat
tzl2 at
tzl3 at
tzl4 at
tzl5 at

stcO d r i veO
zsO d r i veO
mba? d r i ve?
htO slave 0
htO slave 1
htO slave 2
htO slave 3
mba? drive ?
mtO slave 0
mtO slave 1
mtO slave 2
mtO slave 3
mscp dr ve 1
mscp dr ve 2
mscp dr ve 3
mscp dr ve 4
mscp dr ve 5
mscp dr ve 6
mscp dr ve 7
scs 0 dr ve 0
scs 0 dr ve 1
scs 0 dr ve 2
scs 0 dr ve 3
scs 0 dr ve 4
scs 0 dr ve 5
scs 0 dr ve 6
scs 0 dr ve 7
scs 1 dr ve 8
scs 1 dr ve 9
scs 1 dr ve 10
scs 1 dr ve 11
scs 1 dr ve 12
scs 1 dr ve 13
scs 1 dr ve 14
scs 1 dr ve 15

#
#
# Workstation Specifications
#
#

device
device
device
device
device
device

qvO
qdO
qdl
smO
sgO
I xO

at
at
at
at
at
at

ubaO csr 0177200 flags Ox Of vector qvkint qvvint
ubaO csr 0177400 flags Ox Of vector qddint qdaint qd i int
ubaO csr 0177402 flags OxOf vector qddint qdaint qd i int
ubaO csr Ox200f0000 flags Ox Of vector smvint
ubaO csr Ox3c000000 flags Ox Of vector sgaint sgf int
vaxbi? node? vector lxbvpint

(continued on next page)

1-22 The System Configuration File

#Network Specifications
#
#

dev·ce
dev ce
dev ce
dev ce
dev ce
dev ce
dev ce
dev ce
dev ce

bvpniO
bvpnil
bvpni2
bvpni3
deO at
del at
qeO at
seO at
lnO at

vector bvpni intr
at aieO
vector bvpni intr
at aiel
vector bvpni intr
at aie2
vector bvpni intr
at aie3
uba?
csr 0174510 vector deintr
uba?
csr 0174510 vector deintr
ubaO
csr 0174440 vector qeintr
ubaO
csr Ox200e0000 vector seintr
ibusO vector lnintr

#
#

#Terminal and Printer Specifications
#
#

dev ce
ssO at uba? csr Ox200a0000 flags OxOf
dev ce
shO at ubaO csr Ox38000000 flags Oxf f
lpO at uba? csr 0177514 vector lpintr
dev ce
dev ce
dmbO at vaxb ? node? flags Oxf f vector
dev ce
dmb 1 at vaxb ? node? flags Oxf f vector
dev ce
dmb2 at vaxb
node? flags Oxf f vector
dev ce
dmb3 at vaxb ? node? flags Oxf f vector
dev ce
dmb4 at vaxb
node? flags Oxf f vector
device
dmb5 at vaxb ? node? flags Oxf f vector
device
dmb6 at vaxb
node? flags Oxf f vector
device
dmb7 at vaxb ? node? flags Oxf f vector
device
dmb8 at vaxbi? node? flags Oxf f vector
device
dmb9 at vaxbi? node? flags Oxf f vector
#
#
# Pseudodevice Specifications
#
#
pseudo-device
ufs
pty
pseudo-device
pseudo-device
loop
pseudo-device
inet
pseudo-device
ether
pseudo-device
scsnet

vector ssrint ssxint
vector shrint shxint
dmbsint
dmbsint
dmbsint
dmbsint
dmbsint
dmbsint
dmbsint
dmbsint
dmbsint
dmbsint

dmbaint
dmbaint
dmbaint
dmbaint
dmbaint
dmbaint
dmbaint
dmbaint
dmbaint
dmbaint

dmbl
dmbl
dmbl
dmbl
dmbl
dmbl
dmbl
dmbl
dmbl
dmbl

The System Configuration File 1-23

nt
nt
nt
nt
nt
nt
nt
nt
nt
nt

1.5

System Configuration Files for Diskless Clients

This section describes the default system configuration files that the
Diskless Management Services ( dms) utility uses to establish diskless
clients on a server. The section:
•
•

Identifies the diskless configuration file naming conventions
Explains some of the differences between the diskless configuration
files and the configuration files on systems that have disks

•

Describes how dms utility uses the diskless configuration files to
configure diskless clients

•

Provides a sample of a diskless configuration file

1.5.1

Default Diskless Configuration File Naming Conventions

The default diskless configuration files reside in /usr/var/diskless/defs, or in
/var/diskless/defs if you did an advanced installation. In either case, the
names of these files all end with .dlconf. The upper case letters that
precede .dlconf identify the processor type. These upper case letters use
the following conventions:
•

The first two letters identify the Ethernet communications device.
These letters agree with the corresponding communications device
mnemonic, for example QE or SE.

•

The second two letters identify the graphics device. These letters
agree with the corresponding graphics device mnemonic, for example,
QD, QV, SM, or SG. One exception is that non-graphic devices have
the letters TE to denote a non-graphic terminal. Additionally, the
second two letters can be followed by 2 to denote a dual-headed
processor, for example QD2.

•

The remaining three letters identify the architecture type, for example
VAX.

An example of a diskless default configuration file name is
QEQDVAX.dlconf.
The available default system configuration files and their corresponding
systems are:
•

•
•

QEQDVAX.dlconf - A VAXstation 11/GPX that uses a VCB02 video
subsystem ( QDSS monochrome or color), or a VAXstation 3000
processor that uses a VCB02 video subsystem ( QDSS color)
QEQVVAX.dlconf - A VAXstation II processor that uses a VCBOl
video subsystem ( QVSS monochrome)
QEQD2VAX.dlconf - A VAXstation 11/GPX, dual-headed processor
that has two VCB02 video subsystems ( QDSS monochrome or color)

1-24 The System Configuration File

•

QETEVAX.dlconf - A MicroVAX II, non-graphic device or a
MicroVAX 3000 processor

•

SESGVAX.dlconf - A VAXstation 2000 processor that uses a color
monitor

•

SESMVAX.dlconf - A VAXstation 2000 processor that uses a
monochome monitor

•

SETEVAX.dlconf - A Micro VAX 2000 non-graphic device

•

LNTEVAX.dlconf - A VAX 3400 processor

•

PVSGVAX.dlconf - A VAXstation 3100 processor that uses a color
monitor

•

PVSMVAX.dlconf - A VAXstation 3100 processor that uses a
monochrome monitor

1.5.2

Diskless Default Configuration File Differences

This section lists some of the differences between the entries in these
configuration files and the entries in configuration files for systems that
have disks. These differences include the following:
•

The timezone entry is not included in the diskless configuration file.
The dms utility puts the server's timezone information into the
client's configuration file automatically.

•

The root entry in the diskless configuration file is always an Ethernet
device such as qeO or seO depending on the processor type. This is
because the client's root is on the server's system and can only be
accessed over the network.

•

By default, none of the diskless configuration files specify the xos
pseudodevice. When installed into the diskless environment, the
worksystem software puts this entry into the client's configuration file
automatically.

•

Two of the default configuration files ( QEQDVAX.dlconf and
QEQTEVAX.dlconf) specify more than one cpu. This is so the
kernel can be booted on more than one processor type.

1.5.3

Diskless Configuration File Use

The dms utility uses the doconfig command to configure a diskless client
on a server system. The form of the doconfig command that dms invokes
is:
/etc/doconf i g

c $i

-p $INSDIR

The System Configuration File 1-25

The $i variable is the default configuration file name. The $1NSDIR
variable defines the full pathname of a diskless default root area.
Upon completion of a typical dms client installation, the diskless client will
have access to a kernel that exists in one of two places depending on
whether an advanced installation was performed. If an advanced installation
was performed, the client will have access to a kernel on the server's disk
in:
/var/diskless/dlenvx/rootx.vax/usr/sys/config_file_name.dlconf/vmunix
If an advanced installation was not performed, then the client will have

access to a kernel on the server's disk in:
/usr/var/diskless/dlenvx/rootx.vax/usr/sys/config_file_name.dlconf/vmunix

In this syntax, x is a number denoting a particular diskless environment
where config_file_name.dlconf coincides with one of the default
configuration files listed in Section 1.3.1. An example pathname for a
client who has installed a VAXstation II/GPX using an advanced
installation is:
/var/diskless/dlenvO/rootO.vax/usr/sys/QEQDVAX.dlconf/vmunix

This pathname structure enables many clients to share the same kernel.
However, in some d ms client installations, you may choose to set the
diskless client up with its own kernel in its own root directory. The
process of creating diskless clients or changing the location of a client's
kernel is described in the Guide to Diskless Management Services.
Note

Never make changes to the supplied default configuration files. If
you want to build a customized diskless system kernel, copy the
default file to a separate area and make the changes to the
copied version.
It is important to maintain the same default file names because the
dms utility only builds kernels based on the default files supplied with

the system.

1.5.4

Sample Default Diskless Configuration File

Example 1-2 shows a sample QEQDVAX.dlconf default configuration file.
All of the configuration files have the same format as this one and except
for the specified devices, are almost identical.
Refer to Section 1.1 for a detailed description of each of the entries.

1-26 The System Configuration File

Example 1-2: Sample QEQDVAX.dlconf Configuration File
# @(#)QEQDVAX.dlconf
machine
vax
ident
QEQDVAX
cpu
MVAX
cpu
VAX3600
max users
32
processors
1
maxuprc
25
physmem
4
timezone
11
11

options
options
options
options
options

3.7

INET
NFS
RPC

LAT
EMULFLT

conf ig

vmunix

adapter
device
device

ubaO
qeO
qdO

pseudo-dev ce
pseudo-dev ce
pseudo-dev ce
pseudo-dev ce
pseudo-dev ce
pseudo-dev ce
pseudo-dev ce
pseudo-device

root on qeO
at nexus ?
vector qeintr
at ubaO csr 0174440
at ubaO csr 0177400 flags OxOf vector qddint qdaint qd i int
pty
loop
ether
inet
nfs
rpc
lat
It a

The System Configuration File 1-27

Building the Kernel

This chapter describes how to build a kernel. There are three procedures
from which to choose:
1.

You can build a new kernel automatically using the doconfig
command. Section 2.1 describes this procedure.

You can build the kernel manually following the steps listed in
Section 2.2. If you opt to build the kernel manually, make sure you
understand the contents and format of the configuration file. Chapter
1 describes this file.

You can build a kernel when you are performing a capacity upgrade
installation. Section 2.3 describes this procedure.

Choose the procedure that best complements your experience and the needs
of your particular installation.

2.1

When To Build a New Kernel

You need to build a new kernel after any of the following events:
•

If you add a new device and its driver to your configuration. When
you add a new device and device driver, you need to rebuild the
kernel to include the specifications in the configuration file.

•

If you delete a device and its driver from your configuration. When
you delete a device and device driver from your configuration and
edit the configuration file to include only the actual hardware and
software at your installation, you need to rebuild the kernel to match
this configuration.

•

If you tune the operating system. When you alter the default
configuration or change the original disk setup, you need to rebuild
the kernel. For example, if you create swap areas on two disk
drives, thereby modifying the original single swap area on disk, you
need to rebuild the kernel.

•

If you upgrade your system. For example, if you increase the log-in
capacity on your system, you need to rebuild the kernel.

•

2.2

If you add layered products. For example, if you add the DECnet
facility, or any layered product to your configuration, you need to
rebuild the kernel.

Building a Kernel Automatically

The ULTRIX software provides the /etc/doconfig program with which you
build your kernel automatically. The program prompts you for information
about your system configuration, generates the necessary files and
directories, then automatically builds the new kernel. The following section
describes this procedure.
Note

Be aware that the command line entry for the /etc/doconfig
program differs for diskless systems. Refer to Chapter 1 and to
the Guide to Diskless Management Services for information about
the diskless client kernel.

2.2.1

Using the doconfig Program

When updating an existing configuration file or creating a new one with
/etc/doconfig, the system must be operating the generic kernel, vmunix.
To use the /etc/doconfig program, follow these steps:
1.

Shut the system down to single-user mode by typing:
#shutdown +5

You must be superuser to execute the

"Building a new kernel"

Before building the kernel, you must be in single-user mode because
when doconfig completes, it rearranges the previously-defined symbols.
3.

Save the running vmunix as vmunix.old.

Move /genvmunix to /vmunix.

Reboot the system to single user mode.

Check file systems.

Mount the /usr file system.

2-2 Building the Kernel

Run the doconfig program by typing:
# /etc/doconf ig

When the program finishes, it prints a message showing the path and
location of the new vmunix.
9.

Move /vmunix to /genvmunix.

10.

Copy the new vmunix to /vmunix. (Make certain that you use the
pathname for vmunix that the doconfig program printed when it
finished executing.)

11.

Reboot the system.

Refer to doconfig( 8) in the ULTRIX Reference Pages for details on the
command and its options.
Example 2-1 depicts a sample execution of the doconfig program. It
demonstrates how doconfig works on a VAXstation II/GPX, dual-display
system ( qdO, qdl devices).
•

Entries in square brackets [] are the default values. When you run
doconfig, press the RETURN key to select the default value. The
example shows the default entries typed in for presentation purposes
only.

•

After you enter the system name and the date and time information,
the doconfig program builds a configuration file. When doconfig
completes the configuration file build process, it loads vmunix,
rearranges the symbol table, and makes the special files for the
system based on the configuration.

Building the Kernel 2-3

Example 2-1: Sample doconfig Execution
# /etc/doconf ig

Type the name of your system using alphanumeric characters.
The first character must be a letter.
For example, tinker.
Type your system name:tinker
You typed tinker as the name of your system.
Is this correct? Type y or n [y]: y
***

SPECIFY THE DATE AND TIME ***

Enter the current date and time in this format:
yymmddhhmm. Use two digits for year (yy),
mo n t h (mm) , day ( d d) , ho u r ( h h) , and m i nut e (mm) .
You type the time in 24-hour format. For example,
for 11:30 p.m. on May 14, 1987, the response
would be:
8705142330
Type the date and time [no default]: 8705142330
***

SPECIFY THE TIME ZONE INFORMATION ***

Enter the time zone for your area,
listed in this table:

using the options

Time Zone

Options

Eastern
Central
Mountain
Pacific
Greenwich

e
c
m
p
g

You can also enter the number of hours (-12 to 12)
west of Greenwich.

in time

Type the time zone [no default]: p
Does your area alternate between Day! ight Savings
and Standard time [yes] ?yes

(continued on next page)

2-4 Building the Kernel

Enter the geographic area for Day I ight Savings Time,
using the options I isted in this table:
Geographic Area
Options
USA
Australia
Eastern Europe
Central Europe
Western Europe

u
a
e
c
w

Type the geographic area [u]: u
Tue May 10 12:29:00 EDT 1988
*** System Configuration Procedure * * *

Configuration f i I e complete.
Do you want to edit the configuration f i I e? (y/n)

[ n] : n

*** PERFORMING SYSTEM CONFIGURATION ***
work
work
work
work
work
work
work
work
work

ng
ng
ng
ng
ng
ng
ng
ng
ng

Tue May
Tue May
Tue May
Tue May
Tue May
Tue May
Tue May
Tue May
Tue May

10 12:29:00 EDT 1988
10 12:31:01 EDT 1988
10 12:33:02 EDT 1988
10 12:35:03 EDT 1988
10 12:37:04 EDT 1988
10 12:39:05 EDT 1988
10 12:41:06 EDT 1988
10 12:43:07 EDT 1988
10 12:45:09 EDT 1988

*** DEVICE SPECIAL FILE CREATION ***

working
Tue May
working ..... Tue May

3 12:05:59 EDT 1988
3 12:08:00 EDT 1988

Building the Kernel 2-5

2.2.2

Testing the New Kernel

Upon completion of the automatic configuration process, you can test the
new kernel that you have built by performing the following steps:
1.

Save your original kernel:
#mv /vmunix /vmunix.old

Put the newly-created kernel in the root directory. For instance, to
put the kernel created in example 2-1 into the root directory, you
would type:
#mv /sys/TINKER/vmunix /vmunix

Reboot the system:
# /etc/reboot

If you have any problems booting the new kernel, you can reboot the
system using the original kernel that you copied to /vmunix.old.

Refer to the Guide to System Shutdown and Startup for booting
information.

2.3

Building a New Kernel Manually

You can build a new kernel manually in either single-user or multiuser
mode. However, it is recommended that you build it in single-user mode so
that users will not affect the process of rebuilding the kernel. You can
shut down the system to single-user mode with the following command:
#shutdown +5 "Building a new kernel"

To build a new kernel manually in either single-user or multiuser mode,
you must perform the following steps:
1.

Edit the configuration file

Prepare the directory for the binary files

Define code dependencies

Compile and load the binary files

Boot the new kernel

Each of these steps is described in the following sections.
follow these steps consecutively.

2-6 Building the Kernel

You must

2.3.1

Edit the Configuration File

The configuration file resides in the directory /usr/sys/conf and has the
same name as your system, but in uppercase letters. For example, if your
system is named myvax, your configuration file is named
/usr/sys/conf /MYVAX.

The configuration file is the file you copy and edit when you build a new
kernel. This file includes definitions for all supported devices. The
supported devices are listed in Appendix A.
Follow these steps to copy and then to edit the configuration file.
1.

Change your working directory to /usr/sys/conf by typing:
#

cd /usr/sys/conf

Make a backup copy of the original configuration file. To do this,
copy the original configuration file to another file in the same
directory. The name of the working configuration file should be the
same as the original configuration file, with NEW. as a prefix. For
example, if your configuration file is MYVAX, type:
# cp MYVAX NEW.MYVAX

Change the file access permissions (mode) of the working
configuration file to permit the owner (superuser) to write to it. For
example, if your working configuration file is named NEW.MYVAX,
type:
# chmod +w NEW.MYVAX

Edit the working file. If your configuration file is named MYVAX,
then NEW.MYVAX is the file you should edit. Add or delete the
entries you want to change, using the format and rules described in
Chapter 1:
#

2.3.2

vi NEW.MYVAX

Prepare the Directory for the Binary Files

The second step is to create a directory for building the binary files that
are used to create the new kernel. Use the mkdir command to make an
empty directory. Then run the config utility to place the necessary binary
files in the directory. The config utility uses the name of the configuration
file you edited in step 1.

Building the Kernel 2-7

To generate the new binary files:
1.
Make sure your working directory is /usr/sys/conf.
this directory after editing the configuration file.)
2.

Run the mkdir command to create a directory in the /usr/sys
directory. The directory and configuration file names must be the
same as your system name, but in uppercase letters. For example, if
the name of your system is myvax, the command to create the
appropriate directory is:
# mkdir

(You should be in

.. /NEW.MYVAX

Run the config utility with the name of the working configuration file
you edited in Section 2.2.1. When the utility finishes, it displays a
reminder message for you to do a make depend. This example
shows the command for a system named myvax:
# conf ig NEW.MYVAX
Don't

2.3.3

forget

run

make depend 11

Define the Code Dependencies

The third step is to define the code dependencies. The code dependencies
determine which binary files are needed and how they are to be built,
based on your kernel's configuration.
To define the code dependencies:
1.

Change your working directory to the one you created in Section
2.2.2. For example, if your system is named myvax, type:
#

cd /usr/sys/NEW.MYVAX

Execute the make command with the clean parameter.
#

For example:

make clean

This command ensures that the /usr/sys/NEW.MYVAX directory
contains only the required files for creating the kernel specified by
the NEW.MYVAX configuration file.
3.

Execute the make command with the depend parameter.
example:
# make depend

2-8 Building the Kernel

For

This command instructs make to build or rebuild the rules that it
needs to recognize interdependencies in the system source code.
Executing this command will ensure that any changes to the system
source code will be recompiled the next time you run the make
command. The make command modifies the makefile, appending the
dependencies to the end of the file. After make successfully
completes, it updates the makefile.
2.3.4

Compile and Load the Binary Files

The fourth step is to compile and load the new binary files using the
makefile that you created when you defined the code dependencies (Section
2.2.3).
To compile and load the binary files:
1.

Use the make command to produce a complete binary system image,
the kernel. The kernel is stored in the current directory. The system
responds by displaying a number of messages as it compiles and
loads the binary files. When the make command completes, the
system redisplays the system prompt. For example:
# make

Save the original kernel in the root ( I) directory in case your new
kernel fails to work. If the new kernel fails, you can recover by
booting from the original kernel. Boot instructions are in Section
2.2.5. Move the original kernel to another filename in the root
directory. For example:
# mv /vmunix

/vmunix.old

The output of the make command is a kernel named vmunix in the
current directory. Move this file to the root directory and. then
change its mode. For example:
# mv vmunix
/vmunix
# chmod 755 /vmunix

The original /vmunix file is replaced by the new vmunix file and is
ready to be booted. The original /vmunix resides in /vmunix.old
because you copied it there in step 2.

Building the Kernel 2-9

2.3.5

Boot the New Kernel

If you are in single-user mode, use the reboot command to boot the new
kernel, /vmunix. To boot the new kernel, type:
# /etc/reboot

If you are in multiuser mode, use the shutdown command with the
appropriate options to boot the new kernel.
# /etc/shutdown -r +5 "Rebooting new kernel"

In this example, the processor halts and then automatically reboots using
the default boot device. The system boots the /vmunix image.
If the new kernel fails to boot or displays errors, you can recover by
booting the original kernel (lvmunix.old) and running that kernel until you
determine the cause of the problem.
If the new kernel runs but displays errors:

Shut the system down:
# /etc/shutdown -h now

After the system is halted, boot the system using the conversational
mode, as described in the Guide to System Shutdown and Startup.
When the boot prompt appears, boot the old kernel using the name
of the original kernel that you saved in Section 2.2.4.
The following example shows how to reboot the old kernel in
conversational mode on a VAX-11/780:
>>> b ask

Enter image name:vmunix.old

In this example, the system boots the default system disk in
conversational mode using the original system image which was
renamed to vmunix.old. See the Guide to System Shutdown and
Startup for processor-specific booting information and for information
on booting in conversational mode.

2-10 Building the Kernel

2.4

Building the Kernel After a Capacity Upgrade
Installation

After you have completed an ULTRIX operating system capacity upgrade
installation, you need to build a new kernel. You should use the doconfig
command to build the kernel.
The doconfig command asks you questions about your system, such as
what time zone you are in, if you have daylight savings time, and so forth.
It also shows you possible responses.
When doconfig asks if you want to edit the configuration file, type yes.
The doconfig command then asks for the name of the editor you want to
use. Once you are editing the configuration file, change the maxusers
number to the new number of authorized users provided in your upgrade
installation kit. For example, if your system currently has a maximum of
32 users, and you have an upgrade installation kit for 64 users, substitute
the number 64 for 32. In this case, the new entry would read:
maxusers 64

Exit the editor and continue answering the doconfig utility prompts. Most
of your answers will be no, unless you are adding or deleting devices.
After the doconfig utility completes, you can test the new kernel that you
have built by performing the following steps:
1.

Save your original kernel:
#mv /vmunix /vmunix.old

Put the newly-created kernel in the root directory. For example, to
put the kernel created in Example 2-1, you would type:
#mv /sys/TINKER/vmunix /vmunix

Reboot the system:
# /etc/reboot

If you have any problems booting the new kernel, you can reboot the
system using the original kernel that you copied to /vmunix.old.

Refer to the Guide to System Shutdown and Startup for booting
information. If you have any problems booting the newly-created
kernel, you can boot the old kernel /vmunix.old and then try the
capacity upgrade installation again.
Also, if you have difficulties using the doconfig command, you can
build the kernel manually using the steps described in this chapter.

Building the Kernel 2-11

Device Mnemonics A

This appendix identifies and defines the mnemonics that are used to attach
any hardware or software device to your system. The mnemonics are used
by the /dev/MAKEDEV shell script to create the character or block special
files that represent each of the devices. The mnemonics also appear in
the system configuration file as described in the Guide to System
Configuration File Maintenance.
Table A-1 lists the mnemonics in seven categories: generic, consoles, disks,
tapes, terminals, modems, and printers. The generic category lists the
mnemonics of a general nature and includes memory, null, trace, and tty
devices. The consoles category lists the system console devices that the
ULTRIX operating system uses. The disks, tapes, terminals, modems, and
printers categories identify the appropriate mnemonics for those devices.
The description heading in Table A- 1 identifies the corresponding device
name. It does not define the mnemonic's use. For detailed information
on the use of each mnemonic in relation to both the MAKEDEV script and
the system configuration file, refer to the reference pages in Section 4 of
the ULTRIX Reference Pages. If on-line reference pages are available, you
can also use the man command. For instance, if you enter at the system
prompt:
# man

the system displays the reference page for the Mass Storage Control
Protocol (MSCP) disk controller driver. Where appropriate, the SYNTAX
section of the reference page defines the device's syntax as it appears, or
should appear, in the config file. Refer to /dev/MAKEDEV for additional
software device mnemonics that MAKEDEV uses. Refer to MAKEDEV( 8) in
the ULTRIX Reference Pages for a description of the MAKEDEV utility.
You should note that Table A- 1 uses the convention of an asterisk ( *)
beside a mnemonic and a question mark ( ?) beside a device name to mean
a variable number. The range of the variable number is dependent on the
particular device.

Table A-1: Devices Supported by MAKEDEV
Category

Mnemonic

Description

Generic

boot*
mvax*
vaxstation *
std
drum
err log
kUmem
kmem
mem
null
trace
tty
local

Boot and std devices by cpu number; e.g., boot750
All MicroVAX setups; e.g., mvax2000
A VAXstation 2000 setup; e.g., vaxstation2000
Standard devices below with all console subsystems:
Kernel drum device
Error log device
Kernel Unibus/Q-bus virtual memory
Virtual main memory
Physical memory
A null device
A trace device
A tty device
Customer specific devices

Consoles

console
crl
cs*
ctu*
cty*
cfl
ttycp

System console interface
Console RL02 disk interface for VAX 86?0
Console RX50 floppy interface for VAX 8??0
Console TU58 cassette interface for VAX 11/750
Console extra serial line units for VAX 8??0
Console RXOl floppy interface for 11/78?
Console line used as auxiliary terminal port

Disks

hp*
ra*
ese*
rb*

MASSBUS disk interface for RM?? drives
UNIBUS/Q-bus/BI/HSC MSCP disk controller interface
UNIBUS/Q-bus/BI/HSC MSCP electronic ESE20 disk
UNIBUS IDC RL02 disk controller interface
for RB?? drives
VAXstation 2000 and Micro VAX 2000 RD type drives
SCSI disks ( RZ22/RZ23/RZ55/RRD40)
UNIBUS RK?? disk controller interface
UNIB US/Q-bus RL ?? disk controller interface
VAXstation 2000 and Micro VAX 2000 RX type drives

rd*
rz
rk*
rl*
rx*
Tapes

mu*
tms*
rv*
ts*
tu*
st*

A-2 Device Mnemonics

TU7 8 MASS BUS magtape interface
UNIBUS/Q-bus/BI/HSC TMSCP tape controller interface
UNIBUS/Q-bus/BI/HSC TMSCP optical disk
UNIB US/Q-bus TS 11/TS 05/TU80 magtape interface
TE16/TU45/TU77 MASSBUS magtape interface
VAXstation 2000 and Micro VAX 2000 TZK50
cartridge tape

Mnemonic

Description

tz*

SCSI tapes ( TZ30/TZK50)

cxa*
cxb*
cxy*
dfa*
dhq*
dhu*
dhv*
dmb*

dzq*
dzv*
lta*
pty*
qd*
qv*
sm*
sg*

Q-bus cxa16
Q-bus cxb16
Q-bus cxt08
Q- bus DF AOl comm multiplexer
Q- bus DHQll comm multiplexer
UNIBUS DHUll comm multiplexer
Q- bus DHVll comm multiplexer
BI DMB32 comm multiplexer including dmbsp
serial printer/plotter
BI DHB32 comm multiplexer
UNIBUS DMF32 comm multiplexer including dmfsp
serial printer/plotter
UNIBUS DMZ32 comm multiplexer
UNIBUS DZll and DZ32 comm multiplexer
Micro VAX 2000, 8 serial line expansion option
VAX station 2000 and Micro VAX 2000 basic
4 serial line unit
Q- bus DZQll comm multiplexer
Q- bus DZVl 1 comm multiplexer
Sets of 16 network local area terminals (LAT)
Sets of 16 network pseudoterminals
Q- bus VCB02 ( QDSS) graphics controller/console
Q- bus VCBOl ( QVSS) graphics controller/console
VAXstation 2000 monochrome bitmap graphics/console
VAXstation 2000 color bitmap graphics console

Modems

dfa*

DFAOl integral modem communications device.

Printers

dmbsp*
dmfsp*
lp*
lpv*

BI DMB32 serial printer/plotter
UNIBUS DMF32 serial printer/plotter
UNIBUS LPl 1 parallel line printer
Q- bus LPl 1 parallel line printer