Once HP-UX takes control from the Boot ROM, it performs two tasks:
• Find the root file system .
• Start the init process and bring the system to run-level 2, which is multi-user HP- UX.
HP-UX Finds the Root File System
Once HP- UX starts, it searches for the root file system. The root file system is the portion of the file system that forms the base of the file system hierarchy-that is, the portion of the file system on which other file systems can be mounted. The root file system contains the critical files (such as the kernel in /hp-ux). Generally, the root file system is found on the disk from which HP- UX booted. For cluster clients, the root file system is on the cluster server.
(N ote, clusters are not supported on Series 800 as of HP- UX 9.0.)
After finding the root file system, the operating system starts a shell to read commands from /etc/pre_init_rc. Among these commands is fsck(lM), which checks the root file system (currently in a read-only state). (fsck is discussed in Chapter 8, "HFS File System" of this manual and in Chapter 6,
"File System Problems", in Solving HP- UX Problems.) Any problems fsck encounters that it is unable to fix are caught later by / etc/bcheckrc. After fsck exits, the operating system remounts the file system in a read-write state.
Caution Do not modify the / etc/pre_ini t_rc script; it might cause the system to be unbootable.
HP-UX Starts the init Process
Then, HP -UX starts its first process, / etc/ ini t. The ini t process has process ID one (1) and no parent process.
The ini t process reads the / etc/ ini ttab initialization file to define the environment for normal working conditions.
2 .. 20 Iystem Startup
System Initialization File - /etc/inittab
The init process reads the /etc/inittab file one line at a time, each line containing an entry that describes an action to take.
The syntax of ini ttab entries is:
id: run-levels: action: process
id A one- or two-character ID that uniquely identifies the entry.
run-levels Defines the run-levels in which the entry can be processed. You can specify multiple run-levels. If this field is empty, all run-levels are assumed.
action
Typically, entries tell ini t to run a process at specific run-levels. If no run -levels are specified, the process can execute in any run-level.
For example, the following entry tells ini t to run the / etc/ getty process in all run-levels:
cons::respawn:/etc/getty console H
Identifies what action to take for this entry. The actions are as follows:
sysini t Performs system initialization on devices needed by ini t for obtaining run-level information at the console, such as tty characteristics. sysini t entries must finish executing before /etc/inittab continues.
ini tdefaul t Causes the initial (default) run-level to be the value of the run-levels field. If more than one run-level
boot
is specified in run-levels, ini t uses the highest specified run -level.
Run the command specified in the process field at boot-time only. Do not wait for process to die before reading the next entry.
Before enabling other users to access the system, ini t executes all / etc/ ini ttab entries marked boot or bootwai t. These processes are known as boot processes.
System Startup 2-21
2
2
process
boot wait Run the command specified in the process field at boot-time only. Wait for process to die before reading the next entry.
The following entries tell ini t to execute the recoversl program and brc shell script, respectively. ini t must wait for each process to die before moving to the next entry.
slib::bootwait:/etc/recoversl </dev/console >/dev/console 2>~1 #shared libs brc2::bootwait:/etc/brc >/dev/console 2>~1 #boottime commands
wait
respawn
On entering the run-level that matches the run-levels field of this entry, run process and wait the run-level and/or the action field indicates such action.
HP- UX recognizes any text following the # symbol as commentary.
Each system architecture has its own /etc/inittab file, with some unique architecture-specific / etc/ ini ttab characteristics. For example, on the Series 800, first /etc/inittab calls ioinit, which initializes kernel I/O data structures using information from /etc/ioconfig and then calls insf to assign logical unit numbers and create special files for all new devices on the system.
The /etc/inittab entry is as follows:
io::sysinit:/etc/ioinit -i >/dev/console 2>&1
Series 300/400/700 systems do not require this initialization of kernel I/O data structures.
Default Run Levels-initdefault
The /etc/inittab file sets up system run levels. The entry marked ini tdefaul t sets the default run-level to 2:
2-22 System Startup
init:2:initdefault:
(See Chapter 6, "Run-Levels" for information about run levels.)
Among the /etc/inittab entries, are programs that ensure system integrity and set up essential processes. These programs are discussed in the next subheads.
Boot Check Run Command-/etc/bcheckrc
If your system is using disk mirroring (an optional feature of the Series 800 only), the /etc/bcheckrc (Boot Check Run Command) program calls / etc/mirrorrc as its first operation. mirrorrc configures mirrored disks, runs fsck, sets up logging for the mirrored disks, and reimages the disks.
If you are implementing the Logical Volume Manager (LVM), bcheckrc then calls / etc/l vrnrc to activate LVM volume groups.
On the Series 700, if appropriate, bcheckrc runs eisa_config.
On all systems, / etc/bcheckrc verifies that the system was properly shut down. To determine this, bcheckrc calls the fsclean program, which checks each file system of type hfs in /etc/checklist for consistency. fsclean looks at a flag called the clean byte in the primary superblock of each file system.
When a file system is created, the clean byte flag is set to FS_CLEAN. When the file system is mounted (using the mount command), the clean byte flag is set to FS_OK. During a normal shutdown (that is, during execution of the reboot or shutdown command), the clean byte is reset to FS_CLEAN. Thus, under normal conditions, the file system can be unmounted and set to FS_CLEAN, or mounted and set to FS_OK.
If it encounters the file system unmounted and its clean byte set to FS_OK, fsclean perceives the file system to be in an inconsistent state (due to a crash or other incorrect shutdown). In this case, fsclean exits and bcheckrc runs / etc/fsck -P, fsck in preen mode. This will correct most errors found.
If fsck run from bcheckrc fails for any reason, bcheckrc starts a shell with the prompt (in bcheckrc)#, instructing you to run fsck interactively. If this occurs, you must run fsck to ensure the integrity of your file system.
Some file system problems must be fixed in this way to minimize risk of data loss. After running fsck interactively, you may be instructed to reboot the system. If so, reboot the system using reboot -n to ensure your system's
System Startup 2-23
2
2
integrity. Iffsck does not tell you to reboot, exit the shell by typing (CTRLXQ).
This returns control to bcheckrc.
bcheckrc then ensures that /lib is not a mounted volume. Since HP- UX uses shared libraries, /lib must be on the root partition, and thus available to all commands that need them to boot the system.
Finally, bcheckrc mounts all type hfs file systems and exits.
Shared Libraries Check - jetcjrecoversl
After bcheckrc exits, ini t calls recoversl to check for the existence of shared libraries critical to the system. recoversl checks for (and corrects, if necessary) the owner, group, and permissions of these shared libraries.
The shared libraries considered critical to the system are dId. sl (the dynamic loader) and libc. s1. If any of these libraries are missing or damaged,
recoversl guides the system administrator through procedures to recover the shared libraries from update media.
Additional Boot Tasks-jetcjbrc
The / etc/brc program does these tasks:
• Sets the system PATH variable, which defines the default command search path for all users.
• Downloads the floating point microcode if y~ur system is set up for the floating point accelerator. (Series 300 only)
• Removes the /etc/rcflag file (used later as a check for startup condition).
• Looks for and removes the / etc/mnttab file on a standalone or cluster server system. The /etc/mnttab file, a list of mounted file systems, is recreated later when /etc/rc remounts the file systems.
• Creates a new /dev/crt file, if needed. (Series 300 only.) Initial Customization Script-jetcjrc
The following entry in /etc/inittab invokes /etc/rc:
rc::wait:/etc/rc >/dev/console 2>&1 # system initialization
2·24 System Startup
The / etc/rc script consists of a main script program and several shell functions (subroutines in a shell program).
The main program checks to see if it is boot time according to whether the /etc/rcflag is present or absent. (If the boot process has proceeded properly, / etc/brc will have removed / etc/rcflag.) / etc/rc determines whether to perform system initialization and start various daemon (background)
processes. The actual tasks performed by / etc/rc depend on the configuration of the machine (see Table 2-1). /etc/rc determines if you are running as a standalone system, a cluster server, or a cluster client. It then calls shell functions applicable to your system.
When finished, /etc/rc calls a shell function called localrc. This is the shell function you should use to customize the / etc/rc script. It should contain any tasks you wish to perform that are not part of the standard / etc/rc functions.
In the localrc shell function, you can add commands you wish to perform every time the system is booted or whenever there is a change in run-level which ini t does not handle.
For each system state (standalone, cluster server, or cluster client), Table 2-1 shows what functions /etc/rc does. Note that some commands (such as networking commands) may not be available or installed. / etc/rc checks for the existence of all such commands before attempting to run them.
The ini t process waits until / etc/rc dies before processing the next entry in /etc/inittab.
System Startup 2-25
2
2
Table 2·1. jetcjrc functions
Function Stand- Root Diskless
alone Server Cnode1 Mount all hfs volumes listed in the letc/checklist X X X file.
Initialization: set TZ and other variables; set device X X X files used by I etc/rbootd, set up vt gateway.
Set host name in variable SYSTEM_NAME. X X X
Set the date. X X
Save a core image of a previously crashed system. X X X Start swapping to all swap devices in I etcl checklist X X X
Start the syncer. X X
Start the lp scheduler. X X
Clean up editor and uucp files. X X
Start networking. X X X
Start cluster server processes (letc/csp). X X
Start the remote boot daemon (/etc/rbootd). X X
Start cron. X X X
Start pty allocation daemon. X X X
Start vtdaernon. X X X
List files found in Itrnp and lusr/trnp directories. X X X
Clean up logging (lusr/adrn/$LOG) files. X X X
Start diagnostic logging for the I/O subsystem (Series X X X 700/800 only).
Start logging system messages (Series 700/800 only). X X X
Start auditing processes. X X
Set local initialization functions to rc. X X X
1 HP-UX clusters are not supported on Series 800 as of HP-UX 9.0.
2·26 System Startup
Powerfail Routines-jetejpowerfail
A local powerfail is a power failure that halts the computer by affecting its central bus. The Series 800 HP- UX operating system provides a mechanism for recovery from a local powerfail, to ensure that any program running on the system at the time of failure can resume executing when power to the bus is restored.
Powerfail routines are invoked from / ete/ ini ttab to ensure that power is maintained to the system in case of emergency.
pf: :powerwait:/etc/powerfail >/dev/console 2>&1 #power fail routines
If need be, powerfail can be disabled by reconfiguring an operating-system parameter as follows:
pfail_enabled 0;
Be sure to follow guidelines for correct shutdown and start-up of a system necessitated by powerfail. These guidelines are given in Chapter 3, "Starting and Stopping HP- UX" of the System Administration Tasks manual.
Note, although powerfail appears in all / ete/ ini ttab files, the entry is only used on systems that support powerfail.
Terminal Processes Startup-jetejgetty
Once / ete/re has finished its run-level 2 execution, control returns to ini t, which runs the commands from the process field of all run-level 2 entries in /ete/inittab. Typically, /ete/inittab's run-level 2 command field entries consist of / ete/ getty commands, one for each terminal on which users log in.
(When you add a new terminal with the SAM utility, it automatically adds an appropriate fete/getty entry to /ete/inittab.) The lete/getty command runs the login process on the specified terminal, allowing users to login on the terminal.
For example, the following / ete/ ini ttab entry runs a getty at the system console:
cons:0123456:respawn:/etc/getty -h console console # system console
The respawn action field tells ini t to restart the getty process after it dies.
This means that each time you log off the system console, a new login:
prompt is displayed, so you can log in the next time. The 0123456 run-levels
System Startup 2-27
2
2
field indicates that init runs getty in run-levels 0 through 6. However, when getty respawns other terminal login processes, it is often set up to run only in run-levels 2 and 3 or only 2.
As shipped, / ete/ ini ttab invokes / ete/ getty only for the system console. If your system has additional terminals on which you wish to support logins, you must add the appropriate getty entries to /ete/inittab. (Note, however, that SAM automatically creates these entries when you use it to add terminals).
The fete/getty command is the first command executed for each login terminal. It specifies the location of the terminal and its default communication protocol, as defined in the / ete/ gettydefs file. It prints the / ete/ issue file (if present) and it causes the first login: prompt to be displayed. Eventually, the getty process is replaced by your shell's process (see Chapter 4, "Login").
When you logout, the /ete/init process is signaled and takes control again.
The ini t process then checks / ete/ ini ttab to see if the process that signaled it is flagged as continuous (denoted by respawn). If the process is continually respawned, ini t again invokes the command in the command field of the appropriate ini ttab entry as described above (that is, the getty runs and a new login: prompt appears). If the process is not flagged as continuous, it is not restarted.
At the end of /ete/inittab is an entry that runs powerfail recovery procedures in case of power failure.
Note Do not add fete/getty entries to /ete/inittab for un configured terminals, unless action is "off".
If the system finds itself having to respawn entries too rapidly, it assumes that a problem exists and goes to sleep for five minutes before trying to respawn again. If the problem involves the getty for the system console, the system might not be bootable without repair.
Users can log in at all terminals for which getty processes have been executed.
2-28 System Startup
For More Information
The sections in this chapter describe the default operation of the system as shipped to you. However, by altering certain configuration or system files, any of the procedures can change. If, for example, you write your own / etc/rc script, the paragraphs which follow may no longer apply.
Table 2-2 shows where to look for additional information.
Table 2-2. Additional Startup Information To Learn More about ... Refer to ...
Processes Chapter 5, "Process Management"
Run-Levels Chapter 6, "Run Levels"
/ete/init Chapter 6, "Run Levels"
init(lM) in the HP- UX Reference /ete/inittab Chapter 6, "Run Levels"
inittab( 4) in the HP- UX Reference /ete/bre the / et e/bre file
brc(lM) in the HP- UX Reference /ete/beheekre the /ete/beheekre file
/ete/re the /ete/re file
jete/getty getty(lM) in the HP- UX Reference /ete/reeoversl recoversl(lM) in the HP- UX Reference
System Startup 2-29
2