---

3    Starting Up and Shutting Down the System

• Boot operation

• Different startup states and the corresponding boot preparation

• Run levels

• Resolving problems that occur during the boot operation

Refer to the Installation Guide for information about installing the system and performing the initial boot operation. The information in this chapter assumes that you are booting or rebooting an installed operating system.

Shutting down the system is a routine task that you should perform periodically. Usually, you can shut down the system easily and with minimal disruption to system users. Occasionally, you must shut down the system rapidly, causing a moderate degree of disruption to users. Under some circumstances (that are out of your control), the system shuts itself down suddenly, causing substantial disruption to users.

---

3.1    Understanding the Boot Operation

• The system always boots either automatically or manually.

  In an automatic boot, the system controls the entire operation. When you boot the system to multiuser mode, or shut down the system with the reboot flag, or when the system panics and recovers, you are relying on an automatic boot. With an automatic boot, the system begins the initialization process and continues until completion or failure.

  Manual intervention may be required if the automatic boot fails for some reason, for example, if the fsck command fails.

  In a manual boot, the system controls the initial operation, turns control of the procedure over to you, then reinstates control to complete the operation. When you boot the system to single-user mode, you are relying on a manual boot. In an automatic or a manual boot, the operation either succeeds or fails:

  • If the boot operation succeeds, the system is initialized. In single-user mode, the system displays the root prompt (#) on the console or on the terminal screen. In multiuser mode, the system displays the login prompt or a startup display. The prompt or startup display differs according to hardware capability and available startup software.

  • If the boot operation fails, the system displays an error message followed by a console firmware prompt (>>>). In the worst case, the system hangs without displaying a console prompt.

• The system boots to either single-user or multiuser mode.

  • In a boot to single-user mode, the software loads the kernel and proceeds through the initialization tasks associated with process 0 (initialization) and process 1 (init). The init program creates a Bourne shell (sh), turns control over to you, and waits for you to exit from the shell with the exit command or Ctrl/d before continuing with its startup tasks.

    Because init does not invoke the startup script prior to turning control over to you, the root file system is mounted read only, startup of the network and other daemons does not occur, file checking and correction are not enabled, and other operations necessary for full system use are not automatically available to you.

    Usually you boot to single-user mode to perform specific administrative tasks that are best accomplished without the threat of parallel activity by other users. You perform these tasks manually before exiting from the Bourne shell. For example, you might check new hardware, mount and check aberrant file systems, change disk partitions, or set the system clock. When you finish your work, you return control to the system, and init continues with its startup tasks and boots to multiuser mode.

  • In a boot to multiuser mode, the system loads the kernel and moves through various phases such as hardware and virtual memory initialization, resource allocation, scheduling, configuration, module loading, and so on. At the conclusion of the main initialization tasks (process 0), init (process 1) starts an additional set of tasks that includes reading the /etc/inittab file, acting on instructions found there, and executing the relevant run command scripts. These scripts contain entries that initiate activities such as mounting and checking file systems, removing temporary files, initializing the clock daemon, initializing the network daemon, setting up printer spooling directories and daemons, enabling error logging, and performing other tasks specified within the scripts or in related directories. At the conclusion of these activities, the system is enabled and accessible to users.

---

3.2    Preparing to Boot the Installed System

• A powered-down system

• A powered-up, halted system

• A powered-up system in single-user mode

• A crashed system

---

3.2.1    Preparing to Boot a Powered-Down System

1. Confirm that the hardware and all peripheral devices are connected. Refer to the operator's guide for your hardware for information and instructions for interpreting diagnostic output.

2. Power up the hardware and peripheral devices. Remember to power up all devices that you powered down earlier. Refer to the operator's manual or the hardware user's guide for instructions on starting your hardware and peripherals.

3. Confirm that the hardware completed its restart and diagnostic operations. Most hardware provides a diagnostic check as a routine part of its startup operation. Refer to the operator's manual for your hardware for information about your hardware's restart and diagnostic operations.

4. Wait for the console prompt (>>>). If you have enabled your system to boot automatically upon powerup, press the halt button to display the console prompt. Refer to the hardware operator's guide for the location of the halt button on your system. See Section 3.3 for more information on setting the default boot action for your system.

5. Decide which startup mode you want to initiate:

   • If you have tasks you need to accomplish and want the system to restrict access to all users but root, plan to boot to single-user mode.

   • If you do not require single-user access and you want the system to initialize full functionality, plan to boot to one of the multiuser modes: multiuser without networking or multiuser with networking.

6. Enter the boot command that corresponds to the desired startup mode.

   Refer to Section 3.3 for the commands and procedures required to boot your system.

---

3.2.2    Preparing to Boot a Powered-Up, Halted System

1. Decide which startup mode you want to initiate:

   • If you have tasks you need to accomplish and you want the system to restrict access to all users but root, plan to boot to single-user mode.

   • If you do not require single-user access and you want the system to initialize full functionality, plan to boot to one of the multiuser modes: multiuser without networking or multiuser with networking.

2. Enter the boot command that corresponds to the desired startup mode.

   Refer to Section 3.3 for the commands and procedures required to boot your system.

---

3.2.3    Preparing to Transition from Single-User Mode

1. Decide if you should continue in single-user mode or if you should go to multiuser mode:

   • If you have additional tasks that you need to perform and you want the system to deny access to all users but root, plan to continue in single-user mode.

   • If you do not require single-user access, or if you have completed your tasks and you want the system to initialize full functionality, plan to go to one of the multiuser modes: multiuser without networking or multiuser with networking.

2. When you are ready to go to multiuser mode, press Ctrl/d. Refer to Section 3.3 for the commands and procedures required to boot your system.

---

3.2.4    Preparing to Boot a Crashed System

1. Confirm that the hardware and all peripheral devices are connected.

2. Power up the hardware, if necessary. Always power up peripherals and devices before the processor.

3. Monitor the hardware restart and diagnostic operations. Refer to the operator's guide for your hardware for information and instructions for interpreting diagnostic output.

   • In the unlikely event that the diagnostic test indicates hardware failure, contact your Digital field representative. Because hardware damage is a serious problem, do not continue or try to bypass the defective hardware.

   • If you have enabled your system to boot automatically, press the halt button to display the console prompt. Refer to the hardware operator's guide for the location of the halt button on your system.

4. Decide which startup mode you want to initiate:

   • If you need to deny access to all users but root, plan to work in single-user mode. After a crash, it is wise to work initially in single-user mode. You should check all file systems thoroughly for inconsistencies and perform other postcrash operations before enabling system access to other users.

   • If you need to allow access to you and to all other users with login permission, plan to boot to one of the multiuser modes: multiuser without networking or multiuser with networking.

5. Enter the required boot command.

   Refer to Section 3.3 for the commands and procedures required to boot your system.

---

3.3    Booting the System

• Processor type

• Run level

• Location of the kernel that you are booting (on the system disk or on a remote server)

• Whether you are booting all processors or a single processor (in a multiprocessor system)

• Whether any console environment variables are defined

• Whether you are booting the default kernel or an alternate kernel

---

3.3.1    Defining the Console Environment Variables and Using the Boot Commands

1. Set the auto_action variable to halt:

   >>> set auto_action halt

   The previous command will halt the system at the console prompt each time your system is turned on, when the system crashes, or when you press the halt button.

2. For DEC 3000 and DEC 7000 processors, set the boot_reset variable to on to force the resetting of the hardware before booting:

   >>> set boot_reset on

3. For DEC 3000 processors, set the time to wait to reset the SCSI device before booting:

   >>> set scsi_reset 4

4. Use the following procedure to set the boot_osflags variable and the boot device:

   1. Determine which options to the boot_osflags variable you want. Table 3-2 lists the options.

      ---

      Table 3-2: Options to the boot_osflags Variable

      Option	Action
      a	Boot to multiuser mode. (By default, the kernel boots to single-user mode.)
      k	Use the kdebug debugger to debug the kernel. (By default, kdebug is not used.)
      d	Use full crash dumps. (By default, partial dumps are used.)
      i	Prompt for the kernel and special arguments. (By default, no questions are asked.)

      ---

      The options are concatenated into the boot_osflags variable to achieve the desired effect. For example, to boot to multiuser mode and use full crash dumps, enter:

      >>> set boot_osflags ad

      If you want the defaults, clear the variable as shown in the following example:

      >>> set boot_osflags ""

   2. Determine the unit numbers for your system's devices:

      >>> show device

      If you want to boot from the dual SCSI TURBOchannel option card (PMAZB or PMAZC), complete the following steps:

      1. Identify the slot number of the PMAZB or PMAZC option card:

         >>> show conf

         The previous command displays the system configuration.

      2. Determine the unit number of your system's devices:

         Use the conf command with the slot number to identify the unit numbers of the devices attached to that controller. For example, to look at the devices attached to the controller in slot 1, enter:

         >>> t tc1 cnfg

         A display appears identifying the unit number of each device attached to that controller. Identify the unit number of the device from which you want to boot.

   3. Set the default boot device:

      By default, you must provide a boot device when you boot your system. If you always boot from the same device, use the following command syntax with the bootdef_dev variable to set a default boot device:

      set bootdef_dev device

      For example, to boot the system off of disk dka0, enter:

      >>> set bootdef_dev dka000

      To boot the system from the first disk on the PMAZB or PMAZC option card in TURBOchannel slot 1, enter the following command. Note that the double quotes (") are necessary for the console to understand where it is booting from.

      >>> set bootdef_dev "1/dka000"

   4. You have the option of booting from an alternate kernel. If you want to do this, enter:

      >>> set boot_osflags i

      When booting, the system prompts you to enter a file name. For example:

      Enter [kernel_name] [option_1 ... option_n]: genvmunix

      The system will display informational messages.

      On DEC 4000 and DEC 7000 processors, you can also boot an alternate kernel by setting the boot_file variable to the name of the kernel you want to boot. For example, to boot a genvmunix kernel, enter:

      >>> set boot_file genvmunix

      On DEC 4000 and DEC 7000 processors, you must clear the boot_file variable if you want to boot the default kernel, /vmunix. For example:

      >>> set boot_file ""

>>> b

---

3.3.2    Overriding the Boot Commands

• Overriding bootdef_dev

  To override the bootdef_dev variable, supply the desired boot device as an argument to the boot command. For example, if your boot device is set to boot from disk dka0 and you want to boot from disk dkb0, enter:

  >>> b dkb0

• Overriding boot_osflags

  The boot_osflags variables are ignored if you specify the -fl option to the boot command, as follows:

  >>> b -fl

  To override the boot_osflags variables, pass the desired choices to the -fl option. For example, the following command boots to the interactive prompt so you can specify an alternate kernel, and then boots to multiuser mode:

  >>> b -fl ai

• Overriding boot_file

  To boot a kernel other than that specified by boot_file, enter the boot command with the following syntax:

  b -fi kernel

  For example, to boot the genvmunix kernel, enter:

  >>> b -fi genvmunix

---

3.4    Identifying the System Run Levels

---

3.5    Changing the System Run Levels

Before changing to a new run level, use the wall or write command to warn users that you intend to change the run level. Since a change in run level could result in termination of the user's getty process (which disables their login capability) as well as termination of other processes that they are running, you should communicate the change to each logged in user. Check the getty entry for user terminals to verify that the new run level is specified in the entry. If it is not, request that users log off so that their processes will not terminate in response to a kill signal from init.

When the system is initialized for the first time, it enters the default run level that is defined by the initdefault line entry in the inittab file. The system continues at that run level until init receives a signal to change run levels. The following sections describe these signals and provide instructions for changing run levels.

---

3.5.1    Changing Run Levels from Single-User Mode

INIT: New run level: 3

---

3.5.2    Changing Run Levels from Multiuser Mode

init [0 | s | 2 | 3 | q ]

The init command invokes the following run levels:

---

3.5.2.1    Changing to a Different Multiuser Run Level

# init 3

In response to your entry, init reads the inittab file and follows the instructions that correspond to the change in run level.

---

3.5.2.2    Changing to Single-User Mode

# init s

# /usr/sbin/shutdown +10 Bringing system down to single-user for testing

Alternatively, you can reboot the system by using one of the following commands:

# /usr/sbin/shutdown -r now

# /sbin/reboot

---

3.5.2.3    Reexamining the inittab File

# init q

In response, init reexamines the inittab file and starts new processes, if necessary. For example, if you recently added new terminal lines, init activates the getty process for these terminal lines in response to the init q command.

Refer to the getty(8) reference page for further information about the relationship between terminal lines and the init command.

---

3.6    Symmetric Multiprocessing

If your system is a multiprocessor system and it is running Digital UNIX, it is running in an SMP environment. The objective of the operating system in an SMP environment is to take advantage of the incremental computes available to the system as additional processors are added. To do this, the operating system must allow multiple threads of execution to operate concurrently across the available processors.

From a system administrator's point of view, this additional computing power requires little to no additional system management work. All the administrator should see is additional available computes. It may be that additional I/O capabilities will be required to more efficiently utilize these extra computes.

---

3.6.1    Adding CPUs to an Existing System

---

3.6.2    Unattended Reboots on Multiprocessor Systems

---

3.7    Setting and Resetting the System Clock

To set the date and time, log in as root and use the following syntax with the date command:

date [[cc]yy]mmddHHMM[.ss]

To set the date to 09:34:00 AM Jan 7, 2000 using the mmddHHMM[[cc]yy][.ss] Digital format:

# date  010709342000

# date  0107093400.00

# date  010709342000.00

Note

If you are changing the year, the system disk must be updated with the new year information. In single-user mode, enter the mount -u / command after you enter a date containing a new year. This command writes the new year into the superblock on the system disk. Note also that the root file system will now be mounted read-write.

Refer to the date(1) reference page for more information.

---

3.8    Resolving Booting Problems

• Hardware failure

  Check the hardware manual accompanying your system for hardware test procedures. If a hardware problem exists, follow the instructions in the guide for resolving the problem.

• Software failure

  Software can fail for the following reasons:

  • An incorrect boot path was specified

    Refer to Section 3.3 or your system's hardware guide for instructions on specifying the correct boot path.

  • The kernel is corrupt

    If you suspect that the kernel may be corrupt, try booting the generic kernel, /genvmunix. This will provide you with a fully functional system and you can begin debugging procedures using the kdbx or dbx utilities to analyze crash dumps. Refer to the kdbx(8) or dbx(1) reference pages for more information. Refer to Section 3.3.1 for information on booting an alternate kernel.

  • A disk or file system is corrupt

    If a disk or file system is corrupt, run the fsck command on the file system. The fsck command checks and repairs UNIX File Systems (UFS). If fsck finds something wrong, it prompts you for an action to take. Use extreme care under these circumstances so that you do not inadvertently overwrite or remove any files. Refer to the fsck(8) reference page for more information. If you have an Advanced File System (AdvFS), disk corruption is very unlikely.

    AdvFS provides disk recovery during the mount procedure that corrects the disk structures. You do not need to run the fsck command or any other command. Consequently, recovery of AdvFS is very rapid.

---

3.9    Shutting Down the System

Note

You can also use the SysMan dxshutdown command for some of these tasks.

There are several good reasons to stop the system in a controlled shutdown. For example:

• You need to upgrade your software or add new hardware to your configuration. You shut down the system to set up the new additions, make the necessary adjustments to your configuration files, and build a new kernel.

• You have been monitoring the hardware error log and have noticed repeated warnings. You suspect that your hardware may soon fail so you shut down the system and examine the problem.

• You notice that system performance is degrading rapidly. You check the system statistics and conclude that some changes to the system would improve performance. You shut down and tune the system.

• You notice signs of possible file system corruption. You shut down the system and run the fsck program to fix problems or to confirm that none exist.

In each of these and similar situations a variety of options are available to you. Regardless of how you decide to resolve the situation, your first step is to initiate a controlled shutdown of the system. There are practical and reasonable ways to shut down your system from single-user mode or multiuser mode.

A system that has panicked or crashed presents you with a different set of circumstances than a system that has shut down in an orderly fashion. However, this chapter discusses orderly shutdowns only.

---

3.10    Stopping Systems While in Multiuser Mode

The following sections describe typical shutdown operations and provide examples of what happens when you use the command flags. Refer to the shutdown(8) reference page for more information.

---

3.10.1    Shutting Down the System and Warning Other Users

1. Log in as root and change to the root directory:

   # cd /

2. Use the following syntax with the shutdown command:

   shutdown time [warning-message]

# shutdown +10 Maintenance shutdown

When the system's shutdown completion message appears, the shutdown is complete. You can access the system through the console to perform the desired administrative tasks. When you are finished, reboot the system.

---

3.10.2    Shutting Down and Halting the System

1. Log in as root and change to the root directory:

   # cd /

2. Use the following syntax with the shutdown command:

   shutdown -h time [warning-message]

# shutdown -h +5 Maintenance shutdown in five minutes

---

3.10.3    Shutting Down and Automatically Rebooting the System

# shutdown -r +15 Shutdown and reboot in 15 minutes

---

3.10.4    Shutting Down and Halting Systems Immediately

1. Log in as root and change to the root directory. For example, enter the following command:

   # cd /

2. Enter the shutdown command as follows:

   # shutdown -h now

Note

Do not use this command when there are other users on the system. Users get no warning messages and their processes are immediately stopped.

---

3.11    Stopping Systems While in Single-User Mode

# sync

# sync

# halt