5.1 System Configuration at Installation Time
When you install Digital UNIX, the installation program initially copies a kernel image to the root partition of your system disk. This kernel image, known as the generic kernel, supports all processors and hardware options that are available for use with the current version of the operating system. In this way, the installation program ensures that you can boot your system regardless of its configuration.
Towards the end of the installation, after all the subsets you selected
have been written to disk and verified, the installation program calls the /usr/sbin/doconfig program. As part of its processing, the /usr/sbin/doconfig program calls another program, known as the sizer program.
The sizer
program determines what hardware and software options are installed on your
system and builds a target configuration file specific to your system. (The
configuration file is the system file that controls what hardware and software
support is linked into the kernel.) The /usr/sbin/doconfig
program then builds your target kernel from this target configuration file.
Unlike the generic
kernel copied to the system at installation time, the target kernel is tailored
to your system. Only the hardware and software options available on your system
are compiled into the target kernel. As a result, the target kernel is much
smaller than the generic kernel.
When the installation is complete, the target kernel resides either
in the root partition of your system disk or in memory, depending upon how
your system was built. (See Section 5.4 for information
about the different ways in which your kernel can be built.) If the appropriate
console boot variables are set, your system always boots the target kernel
automatically. (For information about setting console boot variables, see Chapter 3.)
Some kernel subsystems, such as the decnet subsystem,
are dynamically loadable, meaning that you can add the subsystem to or remove
the subsystem from the kernel without rebuilding the kernel. Often, subsystems
that are dynamically loadable also allow you to dynamically configure the
value of their attributes. Therefore, you can tune the performance of these
subsystems without rebuilding the kernel. The following subsystems provided
by Digital are dynamically loadable and allow
dynamic configuration
of attributes:
Some subsystems, such as required subsystems, are not dynamically loadable.
However, these subsystems might allow you to dynamically configure the value
of attributes. If so, you can configure the value of these subsystem attributes
without rebuilding the kernel.
Digital UNIX offers two methods of dynamically configuring attributes:
If the subsystem you want to add, remove, or configure does not support
dynamic configuration, you must use the static configuration method. You must
also use this method to configure system parameters that do not support dynamic
configuration. For information about the static configuration method, see Section 5.4.
/sbin/sysconfig[-h hostname ] [-i index [-v | -c | -m | -q | -Q | -r | -s | -u ] ] [subsystem-name] [attribute-list]
You must be the superuser to load and unload subsystems.
You must also know the name of the subsystem you want to manage. You
can determine the name of a subsystem by looking in the documentation that
accompanies the subsystem or in the directories into which the subsystem is
installed. Subsystems are installed in either the /subsys
directory or the /var/subsys directory. When a subsystem
is installed, a file named subsystem-name.mod appears in one of those two directories. You use that subsystem
name as input to the /sbin/sysconfig command. The sections
that follow describe the commands you use to manage subsystems.
You can load and unload subsystems on a local system or a remote system.
For information about adding and removing subsystems on remote systems, see Section 5.3.7
If you are writing a loadable device driver or other loadable subsystem,
refer to the Writing Device Drivers: Tutorial manual and the Programmer's Guide. The Writing Device Drivers: Tutorial
manual describes the tasks performed by the system when you install a loadable
device driver. This manual also describes how to write and package loadable
device drivers. The Programmer's Guide gives general information about creating
subsystems that are dynamically configurable and discusses the framework that
supports dynamic configuration of subsystems and attributes.
This state applies only to static subsystems, which can be unconfigured,
but cannot be unloaded.
This state applies only to loadable subsystems, which are automatically
unloaded when you unconfigure them.
If you use the /etc/sysconfig -s command without
specifying a subsystem name, a list of all the configured subsystems is displayed.
For example:
To get information about the state of a single subsystem, include the
name of the subsystem on the command line:
If you frequently configure and unconfigure device drivers you might
notice that the device special files associated with a particular device driver
differ from time to time. This behavior is normal. When you configure a device
driver using the /sbin/sysconfig command, the system creates
device special files. If you unload that device driver and load another one
that uses the same cdev or bdev major
numbers, the system removes the device special files for the unloaded device
driver. Therefore, it must create new device special files the next time
you configure the device.
You maintain the list of automatically configured subsystems by using
the /sbin/init.d/autosysconfig command.
This command has the following syntax:
/sbin/init.d/autosysconfig list[add subsystem-name] [delete subsystem-name]
Use the /sbin/init.d/autosysconfig list command
to see a list of the loadable subsystems that the system automatically configures
at each reboot.
To add a subsystem to the list, use the /sbin/init.d/autosysconfig
add command. For example to add the lat subsystem,
issue the following command:
If you modify an attribute at run time by using the /sbin/sysconfig command, the modification persists as long as the system is running.
If you shut down and reboot the system, the modification is lost. To modify
subsystem attributes so that changes persist across reboots, store the attribute's
value in the /etc/sysconfigtab database, as described in Section 5.3.8.
The system parameters that are set in the system configuration file
and in the param.c file continue to define the system tables,
and should be viewed as establishing default values in the kernel. You can
override these values by using the /sbin/sysconfig command
or by storing a value in the /etc/sysconfigtab database.
For more information about the configuration file and param.c,
see Section 5.4.
You can manage dynamic subsystem attributes either locally or remotely.
For information on how to use the /sbin/sysconfig command
remotely, see Section 5.3.7.
The following example shows how to use this command to determine which
attributes are part of the generic subsystem:
When you use the /sbin/sysconfig -r command
you specify the attribute, its new value, and the subsystem name on the command
line. For example, to modify the dump-sp-threshold attribute
for the generic subsystem, issue a command like the following:
Each system you want to administer remotely must have an /etc/cfgmgr.auth file that contains the full domain name of the local system. The
name in the /etc/cfgmgr.auth file should be identical to
the name in either the /etc/hosts file or in the Berkeley
Internet Domain (BIND) or Network Information Service (NIS) hosts databases,
if you are using BIND or NIS.
You must create the /etc/cfgmgr.auth file; it is not on
your system by default. The following shows an example cfgmgr.auth file:
To manage subsystems and attributes on remote systems, you include the -h flag and a hostname with the /sbin/sysconfig
command. For example, to load the decnet subsystem on a
remote host named MYSYS, you issue the following command:
In the previous example, a decnet.mod file must exist
in either the /subsys directory or the /var/subsys directory on the remote system before the subsystem can be loaded.
If the loadable subsystem subset is kitted correctly, the subsystem-name.mod file is installed on the remote
system when you use the setld command to install the loadable
subsystem.
To add, update, or remove entries in the database, you create a stanza-format
file containing names and values for attributes you want to modify. (For information
about stanza-format files, see
After
you create the stanza-format file, you use the /sbin/sysconfigdb command to update the /etc/sysconfigtab database.
You name the stanza-format file on the command line using the -f flag. The sysconfigdb command reads the specified
file and updates both the on-disk and in-memory copy of the database. However,
the running kernel is not updated. (Use the sysconfig -r
command to update the running kernel, as described in Section 5.3.6.3.)
The sysconfigdb command has the following syntax:
/sbin/sysconfigdb[-a | -d | -l | -m | -r | -s | -u ] [-f file] [subsystem-name]
The sections that follow explain how to use the /sbin/sysconfigdb command to manage entries in the /etc/sysconfigtab
database.
You can also use a text editor to add, update, or delete subsystem attributes
in the /etc/sysconfigtab database. However, if you edit
the /etc/sysconfigtab database, you must run the /sbin/sysconfigdb -s command after you write and quit the
file so that the in-memory copy of the database is updated.
For example, to list the attribute settings for the generic subsystem, issue the following command:
For example, to add the entries stored in a file named add_attrs to the database, issue the following command:
The sysconfigdb command merges the new definitions
into the existing database entry as follows:
For example, suppose that the following entry for the generic subsystem exists in the /etc/sysconfigtab database:
Suppose that you create a file named merge_attrs
for updating this entry, which contains the following information:
To merge the information in the merge_attrs file
into the /etc/sysconfigtab database, issue the following
command:
For example, suppose the generic subsystem is defined
as follows in the /etc/sysconfigtab file:
Suppose that you create a file named update_attrs
for updating this entry, which contains the following information:
To update the attributes, you issue the sysconfigdb
command, as follows:
For example, suppose the generic subsystem is defined
as follows in the /etc/sysconfigtab database:
To remove the definition of the dump-sp-threshold
attribute, first create a file named remove_attrs that
contains the following information:
You can remove definitions of more than one attribute and for attributes
in more than one subsystem from /etc/sysconfigtab database
with a single sysconfigdb -r command. For example, the remove_attrs file could contain attribute definitions that you want
to remove for the lsm and generic subsystems.
If you include more than one subsystem in the remove_attrs
file, you omit the subsystem name from the command line, as shown:
For example, to delete the generic subsystem entry
in the database, issue the following command:
If you modify the kernel to add a device driver, from Digital or from
a company other than Digital, you follow these general steps:
In some cases, the device driver provides a Subset Control Program (SCP)
that executes during the installation procedure and registers the driver in
the necessary system configuration files. In this case, you need not edit
the target configuration file yourself.
If the device driver does not provide an SCP, you must edit the target
configuration file yourself.
If your device driver includes an SCP, build a new kernel by running
the /usr/sbin/doconfig program as described in Section 5.4.3.
If you need to edit the target configuration file before you build a new kernel,
refer to Section 5.4.1.
If you modify the kernel to add support for certain kernel options,
you can build the new kernel by running the /usr/sbin/doconfig
program and choosing the kernel option from a menu displayed during processing.
You then shutdown and reboot your system.
To determine which kernel options you can configure in this way, issue
the /usr/sbin/kopt command. The command displays a list
of kernel options and prompts you for kernel options selections. To exit
from the /usr/sbin/kopt command without choosing options,
press the Return key. For information about running the /usr/sbin/doconfig program to add kernel options using a menu, see Section 5.4.2.
If you build a new static kernel for any other reason, you must modify
one or more system files as part of rebuilding the kernel. The system files
you modify depend upon the change you want to make to the kernel:
Normally, you make these changes using the text editor of your choice
before you begin building the kernel. (Alternatively, you can edit the system
configuration file during the kernel building procedure. However, if you choose
to edit the configuration file during the procedure, define the EDITOR environment variable to be the editor of your choice. The
default editor is the ed line editor.) For information
about running the /usr/sbin/doconfig program to build a
kernel after editing system files, see Section 5.4.3.
The following procedure explains how to determine which device definition
keyword to add to your target configuration file and how to rebuild the kernel
once you have edited the target configuration file. The procedure assumes
that you do not know the appropriate keyword to add. In some cases, you might
be able to determine the appropriate keyword by looking at documentation supplied
with the hardware or with a new version of Digital UNIX. Another source of
this information is an existing configuration file on another system that
already has the device connected to it. If you know what keyword you need
to add to your system, use a text editor to add that keyword to your target
configuration file and rebuild the kernel as described in Section 5.4.3.
If you are unsure of the keyword you need to add to the target configuration
file for your system, connect the new device to the system as directed in
the hardware manual and use the following procedure:
To rebuild the generic kernel, you must have installed all the required
and optional kernel subsets. You can get a list of the kernel subsets, including
information about whether or not they are installed, by issuing the following
command:
After the generic kernel is running and recognizes the new device, continue
with step 5. When the build ends, condider using the strip
command to reduce the size of the kernel. See the
If the new /vmunix file fails to boot, boot using
the kernel you saved at the beginning of the procedure. To use the saved kernel,
follow these steps:
After your system is running again, you can modify the target configuration
file as needed and rebuild the kernel starting at step 3.
If the configuration file name you specify does not currently exist,
the /usr/sbin/doconfig program builds one with that name.
Continue this process by selecting the kernel options in step 10.
If you choose to edit the configuration file, the /usr/sbin/doconfig program invokes the editor specified by the EDITOR
environment variable.
For information about the configuration file, see Section 5.5
After you finish editing the configuration file, the /usr/sbin/doconfig program builds a new kernel.
If the new /vmunix file fails to boot, boot using
the kernel you saved at the beginning of the procedure. To use the saved kernel,
follow these steps:
After your system is running again, you can modify the target configuration
file as needed and rebuild the kernel starting at step 3.
If you choose to edit the configuration file, the /usr/sbin/doconfig program invokes the editor specified by the EDITOR
environment variable.
For information about the configuration file, see Section 5.5
After you finish editing the configuration file, the /usr/sbin/doconfig program builds a new kernel.
If the new /vmunix file fails to boot, boot using
the kernel you saved at the beginning of the procedure. To use the saved kernel,
follow these steps:
After your system is running again, you can modify the target configuration
file as needed and rebuild the kernel starting at step 3.
Avoid deleting the /genvmunix file, which contains
the generic kernel. If you accidentally delete the generic kernel, you can
rebuild it by using the doconfig -c GENERIC command. For
more information about building a kernel using an existing configuration file,
see Section 5.4.3.
When you install a static subsystem, its SCP normally edits the /usr/sys/conf/.product.list file and adds an entry for the subsystem.
After the SCP completes, you run the /usr/sbin/doconfig
program to configure the new subsystem into the kernel.
The /usr/sbin/doconfig program creates the NAME.list file. The NAME
variable is the same as the target configuration file, and by convention,
is your system name in capital letters. For example, the NAME.list file for a system named MYSYS is MYSYS.list.
If you need to modify your system because of a third-party layered product
(for example, to remove a layered product from the kernel being built), make
the necessary modifications to the NAME.list file and build a new kernel.
Each entry in the NAME.list
file consists of six fields separated by a colon (:).
The following example is part of a NAME.list file and shows an entry for a static kernel subsystem that has
been loaded into the /usr/sys/opt/ESB100 directory:
The fields in this entry contain the following information:
The order of the line entries in the NAME.list file reflects the order in which the entries are processed.
The /usr/sbin/doconfig program creates the NAME.list file by copying the .product.list file, if it exists. Note that when using the /usr/sbin/doconfig
-c command, /usr/sbin/doconfig uses the existing
NAME.list file. If the .product.list file changes (for example, a new kernel layered product
was installed) and the -c flag is used, either delete
the NAME.list file or manually
edit it before invoking /usr/sbin/doconfig to propagate
the change in the .product.list file to the NAME.list file.
You can also create the file by copying the .product.list
file to the NAME.list file.
You can then edit the NAME.list
file and either delete the lines that you do not want built into the kernel
or comment them out by putting a number sign (#)
as the first character in each line that you do not want.
Refer to the Writing Device Drivers: Tutorial manual for more information on the
NAME.list and .product.list files.
In some cases, as noted in Table 5-1, a parameter
in the param.c file can also be included in your target
configuration file. In this case, a value specified in the configuration file
overrides the value specified in the param.c file. Therefore,
if you modify the value of a system parameter in the param.c
file, be sure to remove the corresponding entry from the target configuration
file.
5.2 Deciding When and How to Reconfigure Your Kernel
After your target kernel is built and started by the installation procedure,
you can use it without modifications, unless one of the following occurs:
You must reconfigure your kernel, either dynamically or statically,
when one of these situations occurs. The method you use to reconfigure your
kernel depends upon the support provided by the subsystem or subsystem attributes.
If you decide to add or remove these subsystems from the kernel
or configure the value of their attributes, use the procedures described in Section 5.3.
If you purchase a device driver or other kernel subsystem
from a company other than Digital, that product might also be dynamically
loadable or allow you to dynamically configure attribute values. For information
about dynamically configuring your kernel when working with products from
other vendors, see the documentation for that product and Section 5.3.
If you decide to configure attributes of these subsystems,
use the procedures described in Section 5.3.8.
5.3 Dynamic System Configuration
When you need to load, unload,
or modify a dynamic subsystem, you use the /sbin/sysconfig
command. This command has the following syntax:
5.3.1 Configuring Subsystems
To configure (load) a subsystem, enter
the sysconfig command using the -c
flag. Use this command whether you are configuring a newly installed subsystem
or one that was removed using the /sbin/sysconfig -u command.
For example, to configure the DECnet network (decnet) subsystem,
issue the following command:
# /sbin/sysconfig -c decnet
5.3.2 Querying Subsystem State
Subsystems can be known to the kernel,
but not available for use. To determine which subsystems are available for
use, use the /sbin/sysconfig -s command. This command
displays the state of all subsystems. Subsystems can have the following states:
# /sbin/sysconfig -s
cm: loaded and configured
generic: loaded and configured
proc: loaded and configured
io: loaded and configured
vm: loaded and configured
vfs: loaded and configured
ufs: loaded and configured
ipc: loaded and configured
tty: loaded and configured
xpr: loaded and configured
rt: loaded and configured
net: loaded and configured
dli: loaded and configured
lat: loaded and configured
bufcall: loaded and configured
strstd: loaded and configured
streams: loaded and configured
kinfo: loaded and configured
timod: loaded and configured
tirdwr: loaded and configured
xtiso: loaded and configured
dlb: loaded and configured
ldtty: loaded and configured
pts: loaded and configured
bba: loaded and configured
sfbp: loaded and configured
This list includes both statically linked
subsystems and dynamically loaded subsystems.
# /sbin/sysconfig -s lsm
lsm: unloaded
5.3.3 Determining Subsystem Type
You can determine whether a subsystem is
dynamically loadable or static by using the /sbin/sysconfig -m command, as shown:
# /sbin/sysconfig -m kinfo lat
kinfo: static
lat: dynamic
The output from this command indicates that the kinfo subsystem is static, meaning that you must rebuild the kernel
to add or remove that subsystem from the kernel. The cmftest21
subsystem is dynamic, meaning that you can use the sysconfig -c
command to configure the subsystem and the sysconfig -u
command to unconfigure it.
5.3.4 Unloading a Subsystem
To unconfigure (and possibly unload) a subsystem,
use the /sbin/sysconfig -u command, as shown:
# /sbin/sysconfig -u decnet
5.3.5 Maintaining the List of Automatically Configured Subsystems
The system
determines which subsystems to configure into the kernel at system reboot
time by checking the list of automatically configured subsystems. The system
configures each subsystem on that list, using the sysconfig -c command at each system reboot.
# /sbin/init.d/autosysconfig add lat
If you unload a subsystem
that is on the automatically configured subsystem list, you should remove
that subsystem from the list. Otherwise, the system will configure the subsystem
back into the kernel at the next system reboot. To remove the subsystem from
the automatically configured subsystems list, issue the /sbin/init.d/autosysconfig
delete command. For example, to delete the lat
subsystem, issue the following command:
# /sbin/init.d/autosysconfig delete lat
5.3.6 Managing Subsystem Attributes
Occasionally, to improve the performance of a subsystem or of the system
as a whole, you might modify the value of subsystem attributes. You use the /sbin/sysconfig command to determine the names and values of subsystem
attributes. You can also use the command to modify the value of a small number
of attributes in the currently running kernel.
5.3.6.1 Determining the Value of Subsystem Attributes
Use the /sbin/sysconfig -q
command to determine the value assigned to subsystem attributes. When you
issue the /sbin/sysconfig -q command the subsystem you
specify on the command line must be loaded and configured. For information
about getting a list of the loaded and configured subsystems, see Section 5.3.2.
# /sbin/sysconfig -q generic
generic:
clock-frequency = 1024
booted_kernel = vmunix
booted_args = vmunix modules=0xfffffc00005ea000
lockmode = 0
lockdebug = 0
locktimeout = 15
max-lock-per-thread = 8
lockmaxcycles = 0
rt_preempt_opt = 0
rt-preempt-opt = 0
cpu_enable_mask = 18446744073709551615
cpu-enable-mask = 18446744073709551615
msgbuf_size = 4096
message-buffer-size = 4096
dump-sp-threshold = 4096
lite-system = 0
The /sbin/sysconfig -q command
lists all subsystem attributes and their values. Some attributes are configurable
with the /sbin/sysconfig -r command. For information
about which attributes are configurable, see System Tuning and Performance Management.
5.3.6.2 Identifying Dynamic Subsystem Attributes
You can identify which of a
subsystem's attributes are dynamic by using the /sbin/sysconfig -Q command:
# /sbin/sysconfig -Q max-vnodes
vfs:
max-vnodes - type=INT op=CRQ min_val=0 max_val=2147483647
This
example shows using the -Q flag to get information
about the max-vnodes attribute of the vfs
subsystem. The max-vnodes attribute has the integer datatype, a minimum value of zero (0), and a maximum value
of 2147483647. The op field indicates the operations that
can be performed on the max-vnodes attribute. The following
list describes the values that can appear in this field:
5.3.6.3 Modifying Dynamic Subsystem Attributes at Run Time
You can modify the value of an attribute at run time by issuing the /sbin/sysconfig -r command. The modification you make with
this command persists until the next time the system is rebooted. When the
system reboots, any changes made with the /sbin/sysconfig -r command are lost because the new value is not stored. The -r flag to the /sbin/sysconfig command
is useful for testing a new subsystem attribute value. If the new value causes
the system to perform as expected, you can later store it in the subsystem
attribute database as described in Section 5.3.8.
# /sbin/sysconfig -r generic dump-sp-threshold=20480
To modify the value of more than one attribute at a
time, include a list on the /sbin/sysconfig command line.
For example, to modify the dump-sp-threshold attribute
and the locktimeout attribute, issue a command like the
following:
# /sbin/sysconfig -r generic dump-sp-threshold=20480
locktimeout=20
You do not include a comma between the
two attribute specifications.
5.3.7 Managing Subsystems and Attributes Remotely
You can use the /sbin/sysconfig -h command to administer configurable subsystems
and dynamic subsystem attributes remotely on a local area network (LAN). This
ability allows you to administer several systems from a single machine.
salmon.zk3.dec.com
trout.zk3.dec.com
bluefish.zk3.dec.com
# /sbin/sysconfig -h MYSYS -c decnet
5.3.8 Managing the Subsystem Attributes Database
Information
about dynamically configurable subsystem attributes is stored in the /etc/sysconfigtab database. You use this database to record the
values you want to be assigned to subsystem attributes each time the system
is rebooted or a subsystem is configured. No attributes are set automatically
in this database. If you want to change the default values of any attributes,
you must include the subsystem name, the attribute name, and the value in
the database yourself. You must be the superuser to modify the /etc/sysconfigtab database.
Note
The /etc/sysconfigtab database might contain stanza
entries from a configurable subsystem's stanza.loadable
file. This file and the entry in the /etc/sysconfigtab
database are created automatically when you install certain configurable subsystems.
You should not modify these entries in the database.stanza(4)). For example, suppose you want to
set the lockmode attribute in the generic
subsystem to 1. To set this attribute, create a file named, for example, generic_attrs that has the following contents:
generic:
lockmode = 1
5.3.8.1 Listing Attributes in the Database
To
list the entries in the /etc/sysconfigtab database, use
the /sbin/sysconfigdb -l command. If you specify
a subsystem name on the command line, the attributes of that subsystem are
listed. Otherwise, all attributes defined in the database are listed.
# /sbin/sysconfigdb -l generic
generic:
lockmode = 0
5.3.8.2 Adding Attributes to the Database
To add subsystem attributes to the /etc/sysconfigtab database, enter the sysconfigdb -a command.
# /sbin/sysconfigdb -a -f add_attrs generic
5.3.8.3 Merging New Definitions into Existing Database Entries
To merge new definitions
for attributes into an existing entry in the /etc/sysconfigtab
database, enter the sysconfigdb -m command.
generic:
lockmode = 4
dump-sp-threshold = 6000
generic:
lockmode = 0
lockmaxcycles = 4294967295
# /sbin/sysconfigdb -m -f merge_attrs generic
After the
command finishes, the entry for the generic subsystem in
the database appears as follows:
generic:
lockmode = 0
lockmaxcycles = 4294967295
dump-sp-threshold = 6000
You can merge definitions for
more than one subsystem into the /etc/sysconfigtab database
with a single sysconfigdb -m command. For example, the merge_attrs file could contain new definitions for attributes in
the lsm and generic subsystems. If you
include more than one subsystem name in the merge_attrs
file, you omit the subsystem name from the command line, as shown:
# /sbin/sysconfigdb -m -f merge_attrs
5.3.8.4 Updating Attributes in the Database
To update the entire definition
of a subsystem that is already in the /etc/sysconfigtab
database, enter the /sbin/sysconfigdb -u command.
generic:
lockmode = 4
dump-sp-threshold = 6000
generic:
lockmode = 0
lockmaxcycles = 4294967295
# /sbin/sysconfigdb -u -f update_attrs generic
After the
command finishes, the entry for the generic subsystem in
the database appears as follows:
generic:
lockmode = 0
lockmaxcycles = 4294967295
5.3.8.5 Removing Attribute Definitions from the Database
To remove the definitions
of selected attributes from the /etc/sysconfigtab database,
enter the /sbin/sysconfigdb -r command. The -r flag specifies that you want to remove the attribute definitions
stored in a file from the database.
generic:
lockmode = 4
dump-sp-threshold = 6000
generic:
dump-sp-threshold = 6000
Then, issue the following command:
# /sbin/sysconfigdb -r -f remove_attrs generic
After the command finishes, the entry for the generic subsystem in the database appears as follows:
generic:
lockmode = 4
The /sbin/sysconfigdb
command removes only identical entries. In other words, the entries must
have the same attribute name and value to be removed.
# /sbin/sysconfigdb -r -f remove_attrs
5.3.8.6 Deleting Subsystem Entries from the Database
To delete the definition of
a subsystem from the /etc/sysconfigtab database enter the /sbin/sysconfigdb -d command.
# /sbin/sysconfigdb -d generic
The generic subsystem receives its default values the next
time it is configured.
5.4 Static System Configuration
Static system configuration
refers to the commands and files used to build and boot a new kernel and its
static subsystems. The subsystems are viewed as static because they are linked
directly into the kernel at build time. The steps you take to build a statically
linked kernel vary depending upon why you want to modify the kernel.
5.4.1 Building the Kernel to Add Support for a New Device
When you add a
new device to the system and the device installation includes no SCP, you
must edit the target configuration file to allow the operating system to support
the new device. You include the device definition keyword in the target configuration
file. Because Digital UNIX supports many devices, determining which keyword
to add to your target configuration file can be difficult.
# cp /vmunix /vmunix.save
If there are disk space constraints,
you can save the kernel file in a file system other than root. For example:
# cp /vmunix /usr/vmunix.save
# shutdown -h now
>>> boot -fi "genvmunix"
Note
If the /genvmunix file does not exist on your system,
or the generic kernel fails to recognize the device you are adding, rebuild
the generic kernel.
# /usr/sbin/setld -i | grep Kernel
After all kernel subsets
are installed, issue the following command:
# doconfig -c GENERIC
The -c flag specifies that you want to build a kernel using an
existing configuration file, in this case the GENERIC configuration
file. For more information about building a kernel from an existing configuration
file, see Section 5.4.3. strip(1)
reference page.
# /sbin/bcheckrc
If you are using the Logical Storage Manager
(LSM) software, check local file systems and start LSM by issuing the following
command:
# /sbin/lsmbstartup
# sizer -n MYSYS
The sizer -n command
creates a new target configuration file for your system that includes the
appropriate device definition keyword for the new deivce. (This process is
similar to the process that occurs at system installation time. For more
information, see Section 5.1.) The sizer
program stores the new target configuration file in the /tmp
directory.
# diff /tmp/MYSYS MYSYS
Check the differences between these files until you
find the new device definition keyword. (The two files might differ in other
ways if you have customized your existing configuration file, such as by specifying
a nondefault value for the maxusers option.)Note
If you add or remove communications devices from your configuration
file, you must edit the /etc/inittab file and the /etc/securettys file to match your new configuration; that is, to
match the /dev/ttynn special
device files. For more information, see inittab(4) and securettys(4).
# /usr/sbin/doconfig -c MYSYS
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
Saving /usr/sys/conf/MYSYS as /usr/sys/conf/MYSYS.bck
Answer the following prompt to indicate that you do not want to
edit the configuraton file:
Do you want to edit the configuration file? (y/n) [n]: n
*** PERFORMING KERNEL BUILD ***
.
.
.
The new kernel is /usr/sys/MYSYS/vmunix
# mv /usr/sys/MYSYS/vmunix /vmunix
# /usr/sbin/shutdown -r now
# fsck -p
# mount -u /
# mount /usr
# mv /vmunix.save /vmunix
# shutdown -r now
5.4.2 Building the Kernel to Add Selected Kernel Options
If you invoke the /usr/sbin/doconfig program
without using flags, you are given the opportunity to modify the kernel using
a menu. To modify the kernel using a menu, follow these steps:
# cp /vmunix /vmunix.save
If there are disk space constraints,
you can save the kernel file in a file system other than root. For example:
# cp /vmunix /usr/vmunix.save
# /usr/sbin/doconfig
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
Saving /usr/sys/conf/MYSYS as /usr/sys/conf/MYSYS.bck
Enter a name for the kernel configuration file. [MYSYS]: MYSYS
The kernel configuration
processes convert the system name to uppercase when determining what name
to supply as the default configuration file name. For example, on a system
named mysys, the default configuration file is named MYSYS.
A configuration file with the name MYSYS already exists.
Do you want to replace it? (y/n) [n]: y
*** KERNEL OPTION SELECTION ***
Selection Kernel Option
--------------------------------------------------------------
1 System V Devices
2 NTP V3 Kernel Phase Lock Loop (NTP_TIME)
3 Kernel Breakpoint Debugger (KDEBUG)
4 Packetfilter driver (PACKETFILTER)
5 Point-to-Point Protocol (PPP)
6 STREAMS pckt module (PCKT)
7 X/Open Transport Interface (XTISO, TIMOD, TIRDWR)
8 File on File File System (FFM)
9 ISO 9660 Compact Disc File System (CDFS)
10 Audit Subsystem
11 ACL Subsystem
12 LAN Emulation over ATM (LANE)
13 Classical IP over ATM (ATMIP)
14 ATM UNI 3.0/3.1 Signalling for SVCs
15 Asynchronous Transfer Mode (ATM)
16 Advanced File System (ADVFS)
17 All of the above
18 None of the above
19 Help
--------------------------------------------------------------
Enter the selection number for each kernel option you want.
For example, 1 3 [18]:
Do you want to edit the configuration file? (y/n) [n]:
You need not edit the configuraton file unless you have changes
other than adding one or more of the subsystems in the menu to the kernel.
# mv /usr/sys/MYSYS/vmunix /vmunix
# /usr/sbin/shutdown -r now
# fsck -p
# mount -u /
# mount /usr
# mv /vmunix.save /vmunix
# shutdown -r now
5.4.3 Building a Kernel After Editing System Files
If
you or an SCP modify system files, such as the target configuration file,
you can rebuild your kernel using the /usr/sbin/doconfig -c
command. The -c flag allows you to name an existing
configuration file, which the /usr/sbin/doconfig program
uses to build the kernel. To build a new kernel using an existing configuration
file, follow these steps:
# cp /vmunix /vmunix.save
If there are disk space constraints,
you can save the kernel file in a file system other than root. For example:
# cp /vmunix /usr/vmunix.save
# /usr/sbin/doconfig -c MYSYS
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
Saving /usr/sys/conf/MYSYS as /usr/sys/conf/MYSYS.bck
Do you want to edit the configuration file? (y/n) [n]:
If you modified the configuration file before you started this procedure,
indicate that you do not want to edit the configuration file.
# mv /usr/sys/MYSYS/vmunix /vmunix
# /usr/sbin/shutdown -r now
# fsck -p
# mount -u /
# mount /usr
# mv /vmunix.save /vmunix
# shutdown -r now
5.5 Static Configuration Files
To build and run a working kernel, the system depends on the presence
of specific directories under the /usr/sys directory. Figure 5-1 shows the directory structure of the system configuration
files. The dotted lines indicate optional directories and files for third-party
static subsystems.
Figure 5-1: Configuration Files Directory Hierarchy
As shown in Figure 5-1,
the /usr/sys/conf directory contains files that define
the kernel configuration for the generic and target kernels. These files represent
the configuration of the static portion of the kernel. When you work with
the system files to reconfigure the kernel, you are interested primarily in
five files:
The sections that follow provide more information about these
files.
5.5.1 System Configuration Files
The /usr/sys/conf directory contains two important
system configuration files:
Table 5-2 lists the entries that
can be included in the target configuration file.Note
Never delete the /usr/sys/conf/GENERIC file.
5.5.2 Extensions to the Target Configuration File
The /usr/sys/conf directory
contains two optional configuration files that describe extensions to the
target configuration file. These are the /usr/sys/conf/.product.list file and the /usr/sys/conf/NAME
file. These files store information about static kernel subsystems, sometimes
called kernel layered products.
/usr/sys/opt/ESB100:UNXDASH100:920310100739:DASH Systems:controlsys:100
[1] [2] [3] [4] [5] [6]
Note
Never edit the .product.list file.
5.5.3 The param.c File
The param.c file contains default values for a number of system parameters.
You use these parameters to tune your system's performance. Table 5-1
lists system parameters that you can modify. For information about deciding
what values to assign to these parameters, see System Tuning and Performance Management.