Chapter 1

System Startup and Execution Modes

1.1 SYSTEM STARTUP PROCEDURE

1.1.1 Starting System Control IOX (I/O Multiplexer)

Confirm that the system control IOX has started. If it has not started, set the switch in the system control IOX cabinet to RUN to enable startup. Start the system control IOX and wait for multiuser mode to be established.

After startup, confirm that the IOX common daemon (/opt/sx/bin/ffd) has been activated, using the ps command. If the IOX common daemon has not yet been activated, activate it using the following procedure:

# su
Password
#/opt/sx/bin/iox.start start

Before activating the IOX common daemon, confirm the contents of the configuration file for IOX device daemon (/opt/sx/conf/ipi3d.conf) and ISL parameter file (/opt/sx/conf/islparam.XX. XX) is a physical node number. This value is 00 for the single node model.

1.1.2 Activating the SX Operation Function

# sh /opt/sx/bin/sxd.start start

# /opt/sx/bin/sxop
node00>

The sxop command waits for input. The operator can start SUPER-UX with the sxop command and subsequently perform operations such as dump collection.

The operator logs on to the system control IOX through the network, then activates the sxop command. The operator can start SUPER-UX, output a dump, and perform kernel debugging. A SUPER-UX kernel message can be output by executing the sxop command. Input to the SUPER-UX kernel, however, is not possible.

1.1.3 Setting the System Control IOX Connection Channel

Example 1:

If the channel connected to the system control IOX is HIPPI, and the specification is IN channel = 1, OUT channel = 0, I-FIELD = 0x1000003, slave = 0, specify:

node00> setchnl 1st -i 1 -o 0 -I 0x1000003 -s 0

IN/OUT channel and I-FIELD are determined from the hardware configuration. If, however, the system administrator sets the slave number, it must be assigned to each IOX and RAID.

When using HIPPI-SW, however, set I-FIELD only for that system connected to the system control IOX. Set I-FIELD to 0 for a system that does not use HIPPI-SW.

Example 2:

If the channel connected to the system control IOX is Ethernet, and the specification is channel=2, IP address of SX=133.203.2.1, IP address of gateway=133.203.2.254, net mask=0xffffff00, IP address of system control IOX=133.203.2.2, port number used by the IOX common daemon (ffd(1M))=5000, slave=0, specify:

node00> setroute -c1 1 -x1 133.203.2.1 -g1 133.203.2.254 -M 0xffffff00 -i 133.203.2.2 -p 5000 -s 0

The channel is determined from the hardware configuration. The system administrator sets the IP addresses of SX, gateway, and system control IOX, and net mask according to the NetWare environment. Specify an appropriate free port number as the port number used by the IOX common daemon. If, however, the system administrator sets the slave number, it must be assigned to each IOX and RAID.

1.1.4 Specifying and Starting the Kernel

After setting a channel for the system control IOX, enter the following subcommand from the sxop command:

node00> init

Executing the sxop command activates ISL and causes the hardware initialization message to appear. To start the MINI kernel after installing SUPER-UX, or when recovering from an error, use the mini subcommand instead of the init subcommand.

day-of-the-week month day hour:minute:second HW INITIALIZING
day-of-the-week month day hour:minute:second ISL LOADING
day-of-the-week month day hour:minute:second CP BOOTING
day-of-the-week month day hour:minute:second SYSTEM INITIALIZE COMPLETE

When ISL is activated, an ISL message is displayed once the sxop command is entered and the kernel is loaded.

day-of-the-week month day hour:minute:second ISL: Read ISL parameter file name(data = ??? bytes)
day-of-the-week month day hour:minute:second ISL: (XX.XX) is ready.
KERNEL = unix KDB = ON
day-of-the-week month day hour:minute:second ISL: unix (text:0x361400+data:0x222e) loading.
day-of-the-week month day hour:minute:second ISL: KERNEL(unix) LOAD COMPLETED

If KDB is specified after the kernel is loaded, control moves to KDB and the KDB message appears upon execution of the sxop command. KDB waits for command entry. Here, to debug the kernel, enter a KDB command.

To restart the kernel, enter end. Control exits from KDB.

day-of-the-week month day hour:minute:second KDB ON
day-of-the-week month day hour:minute:second KDB:
end

If the boot file system has no kernel specified by the operator, or if ISL is updated, ISL displays the message "BOOT:" ("MINI:" for MINI kernel startup) on the workstation from which the sxop command was activated, then waits for input from the operator.

At this point, the operator can make the following specifications, such as the name of the kernel to be started:

knl=kernel-name
Any kernel can be specified at restart or when a kernel name is found to be incorrect at startup. ISL loads the specified kernel. The kernel must be placed immediately under the boot file system in advance.

isl(=isl-name)
Updates the ISL to be activated. If the isl name is omitted, ISL is updated from the isl existing immediately under the boot file system. isl is updated only when SUPER-UX is upgraded.

kdb
sets KDB to ON or OFF. Repeatedly specifying kdb causes KDB to toggle between ON and OFF.

display
Displays the ISL parameter read by ISL.

system
Displays the name of the kernel to be started, and whether KDB is ON or OFF.

reinit
Specifies that restart is to be performed after ISL has been updated. This specification results in the same operation as that performed when startup is specified with the sxop command.

After entering the ISL command, perform the following to instigate startup:

day-of-the-week month day hour:minute:second BOOT:Return key

1.1.5 Checking the Root File System and Determining the System Status

Once the system has been normally booted, the shell script described in the /etc/bcheckrc file is executed. In the setting at release, the root file system is checked and the root file system is registered in /etc/mtab.

First, a check of whether the root file system is normal is made. If an error is detected, the file system is corrected with the fsck(1M) command. System restart is required if a file system error has occurred.

This completes the processing by the /etc/bcheckrc shell script. The subsequent operation varies with the system setting. The run mode is determined by the value specified in the second field of the init default entry of the /etc/inittab file. The file system starts in this mode. In general, specify "s" in this field to indicate single user mode, or "2" to indicate multiuser mode. "s" is set at release to enable the setting of various environments in single user mode immediately after the release. Specify "2" in this field to enable a general user to use the system immediately after startup of the system.

An example of the initdefault entry in the /etc/inittab file is shown next.

is:2:initdefault:

1.1.6 Single-User Mode

The system enters single-user mode if started with the initdefault entry of the /etc/inittab file set to "s" or if "shutdown-i1" is executed in multiuser mode.

Upon the start of single-user mode operation, the system starts operation as a single user at the console terminal of the system control IOX. The following message appears:

SINGLE USER MODE

In this status, the syscond(1M) daemon, which controls the I/O for a virtual console used for a single user, is activated. To acquire the single user console, the operator must perform remote login (rlogin) for the SX system from any terminal (or window) in an operation network. Once remote login has been completed, the shell is activated for a single user to enable transition to single-user mode.

1.1.7 Multiuser Mode

The system enters multiuser mode when started with the initdefault entry of the /etc/initab file set to "2", or when "init 2" is executed in single-user mode.

When the system enters multiuser mode, a sequence of processing is performed as part of system initialization. This processing is accomplished by executing shell script files in ?? number order. These shell script files have names beginning with "S??" (??: 2-digit number) and are stored in the /etc/rc2.d directory. At release, the following shell script files are supported:

Delete or add shell scripts as necessary for the operation of the system.

Once execution of the previous shell script ends, the system enters multiuser mode and the login prompt message appears on each terminal. A general user can use SUPER-UX by entering the login name from a terminal.

1.2 SYSTEM RESTART

1.2.1 Restart by the shutdown Command

Executing the shutdown(1M) command causes SUPER-UX to automatically restart after SUPER-UX has been shut down by specifying user parameters. A kernel name cannot be specified at restart. A kernel can, however, be specified at restart by specifying conversational mode.

1.2.2 Restart After an Error

When a mainframe failure prevents a kernel from operating, if a CPU remains operable and the failure was caused by a software (kernel) error, a panic message is output, then isl outputs a dump and automatically restarts the system. For details on obtaining a dump, refer to Chapter 4 in the System Administrator's Guide.

1.3 SYSTEM EXECUTION MODES

SUPER-UX supports the execution modes listed in Table 1-1.

Multiuser mode is used for normal operation. Single-user mode should be set when general users are not permitted to use SUPER-UX while special work, such as maintenance, is being performed. Levels 3 and 4 can be defined as run modes specific to the site. Set system reboot mode when the system must be restarted for reasons such as kernel change. Upon entering system reboot mode, the system reloads SUPER-UX after performing the necessary processing. Upon entering system end mode, the system performs postprocessing, then terminates the SUPER-UX system. Run mode can be changed in either of the following two ways:

• Specify a run level as the argument of the init command.
  init 2

• Specify a run level as the -i option of the shutdown command.
  shutdown -i0

1.4 SYSTEM FILES

1.4.1 System Files

Several files are provided to support the running of the SUPER-UX system. These files are outlined next.

/etc/acctcode

Defines an account code, account ID, and which user can use that account code.

/etc/checklist

The file systems described in this file are checked when /etc/fsck is executed with no file system arguments.

/etc/fstab

Describes information relating to the file system used by the system. The mount and mountall commands mount file systems based on this information.

/etc/gettydefs

Describes information relating to the line speeds and terminal settings required by /etc/getty.

/etc/group

Defines a group that uses the system, as well as its ID.

/etc/init.d

Directory into which the procedure used to change a system run level (system startup or end) is written. The shell procedure in this directory is linked to the /etc/rcn.d (n: number) directory as a file having a name beginning with S (start) or K (stop).

/etc/inittab

Defines the process that is activated or stopped by /etc/init whenever the system run level changes.

/etc/iotab

Describes information relating to the peripheral devices used by the system. Based on this information, the /sbin/ioconf command inserts the peripheral devices into the system.

/etc/motd

Describes the day and time message to be output at login.

/etc/passwd

Defines a user who uses the system, as well as the user ID.

/etc/profile

Defines the environments to be executed by all users. This file is executed from /bin/sh at login.

/etc/rc0

Procedure to be executed from /etc/shutdown. When the system run level changes to 0, 5, or 6, the shell procedure in the /etc/rc0.d directory is executed.

/etc/rc0.d

Directory containing the shell procedure to be executed by /etc/rc0 when a system run level changes to 0, 5, or 6. The files in this directory are linked to those under /etc/init.d having file names beginning with S or K. A procedure having a name beginning with K performs end processing upon a change to a new run level. A procedure having a name beginning with S performs the start processing.

/etc/rc2

Executes the shell procedure that is executed from /etc/init and executed for the /etc/rc2.d directory when the system run level changes to 2.

/etc/rc2.d

Directory containing the shell procedure to be executed by /etc/rc2 when the system run level changes to 2. A file in this directory is linked to a file under /etc/init.d having a name beginning with S or K. The procedure having a name beginning with K performs the end processing upon a change to a new run level. The procedure having a name beginning with S performs the start processing.

/etc/shutdown

Shell procedure that shuts down the system safely.

/etc/rc.console

Shell procedure for syscond activation and initial network activation, used to provide the console in single-user mode. For details, refer to the System Administrator's Guide.

/etc/syscond.athrz

Authorized file used by syscond(1M), which runs in single-user mode. syscond enables connection only for a user who is allowed connection using this file.

/etc/TIMEZONE

Sets shell environment variable TZ, which indicates the time zone.

/etc/utmp

Contains information on the current run level.

/etc/wtmp

Contains the system login history.

/etc/font

Directory storing font data for the characters to be output to a page printer.

/usr/adm/sulog

The su command use history is written into this file. The size of this file must be carefully monitored because it increases indefinitely.

/usr/lib/cron/log

The /etc/cron operation history is written into this file. The size of this file must be carefully monitored because it increases indefinitely.

/usr/lib/help/HELPLOG

The /usr/bin/help processing history is written into this file. The size of this file must be carefully monitored because it increases indefinitely.

/usr/lib/spell/spellhist

When the spell utility is installed, all unmatched word histories are written into this file.

/usr/news

Directory used to store news files. This directory must be carefully monitored and old files managed as necessary.

/usr/spool/cron/crontabs

Directory into which the crontab file of a login name user, described in adm, root, sys, and cron.allow, is stored.

/etc/logindeny

Directory into which the name of a terminal user, who is denied access to the system, is stored.

/etc/logindef

Contains the specification that controls login command operation.

/etc/printcap

Printer database used for BSDLP spooling.

/etc/syslog.conf

Configuration file defining syslogd daemon operation.

/etc/shadow

Describes an encoded login password for each user.

1.4.2 IOX System File

1.4.2.1 ISL PARAMETER FILE (/opt/sx/conf/islparam.## (##: node number))

A user creates this file under /opt/sx/conf on a system control IOX. In this file, the user specifies the settings for the BOOT and dump devices. At startup, ISL reads this file and loads a kernel from the specified BOOT device. Dump collection after the occurrence of an error is also performed for all devices described in this file. As it is essential to startup, this file must be handled with care.

1.4.2.2 DEVICE DAEMON CONFIG FILE

The ipi3d.conf file (/opt/sx/conf/ipi3d.conf) contains the parameters used for activating the daemon when ffd(1M) receives the activation request command packet of the device daemon under IOX via the HIPPI interface.

1.4.2.3 sxop.conf FILE

The sxop configuration definition file (/opt/sx/conf/sxop.conf) defines the correspondence between a node existing in the system and the RS-232C special file.