How Ignite Works

When deciding the best way to use Ignite in your data center, it might be useful to understand the structure of Ignite – how it gets started on the client and the functional steps it performs. This section describes the major components of Ignite and where they come from. Ignite installation and recovery is described in terms of phases, with each phase described in detail.

The Ignite-UX Install Environment

HP-UX installation and recovery is accomplished using the Ignite-UX install environment.

The Ignite install environment is a small subset of the HP-UX operating system that allows HP-UX to install itself onto a system. During the initial phases of installation and recovery, the install environment runs in client memory without any disk-based storage. A memory-based RAM disk holds the initial root file system needed for HP-UX operation. While operating with a memory-based root disk file system, file system space is very limited. On smaller memory systems, memory for the HP-UX kernel and processes might also be limited. Command libraries and other files must be loaded and removed as needed. (Increasing the size of the memory-based root disk to make more space would result in insufficient memory being available for the processes that accomplish installation and recovery.) Once the correct disks are identified, volumes and file systems are created. The install environment then switches to a disk-based file system. When that is completed, some of the RAM disk space is freed.

The Ignite install environment consists of:

[W|V|I]INSTALL – The HP-UX install kernel, which is statically linked and includes a wide variety of I/O and other modules so it is able to run on all supported systems.
[W|V|I]INSTALLFS – The initial HP-UX install file system, which is copied into the root RAM disk during boot. The first 8 KB can contain Ignite-UX configuration content.
INSTCMDS or INSTCMDSIA, SYSCMDS or SYSCMDSIA, and RECCMDS or RECCMDSIA – Archives of commands, libraries, and other files needed to accomplish installation and recovery, but are not needed to initially get the install environment running. These are loaded as needed during installation and recovery.

The Ignite-UX install kernel and install file system are loaded into system memory by the standard HP-UX boot loader or virtual system boot loader software. Note that there are a number of boot sources where the Ignite install environment may reside. Also, the details of booting vary according to your Ignite data center configuration.

Boot Sources

Ignite always retrieves the install kernel and install file system from the boot source. By default, Ignite retrieves INSTCMDS[IA], SYSCMDS[IA], and RECCMDS[IA] from that same boot source, but can get these command archives from a different source if requested to. Ignite can determine the boot source by querying the HP-UX kernel.

Ignite can switch its source for command archives and depots if configuration information in the install file system instructs it to, or if instructed to by the Ignite user interface.

Ignite will operate in the same manner, regardless of the boot source.

Installation Versus Recovery

Ignite internally uses the same approach, regardless of whether you are performing an installation or recovery. The terms “installation” and “recovery” are valuable to describe intended use, but Ignite's internal operation make it possible to blur the distinction between the two, such as when you use golden images.

This design is quite powerful, and allows Ignite to handle significant system differences during recovery by adapting as needed and regressing to more install-like behavior if required.

Network Booting and IP Addresses

When a system boots HP-UX from an Ignite-UX server, it needs an IP address to get the operating system kernel. This first IP address is not necessarily the same IP address the system will be assigned for networking when its kernel is up and running. The mechanisms for distributing the first and second IP addresses are sometimes different.

PA-RISC Systems

When a PA-RISC system boots from an Ignite-UX server, the first IP address request is answered by the instl_bootd daemon. This communication uses ports 1067 and 1068. The file /etc/opt/ignite/instl_boottab is referenced to assign the first IP address to the booting system whether it is registered or anonymous.

After HP-UX is running on a PA-RISC system, it requests a second IP address for networking. This request is answered by bootpd using ports 67 and 68. The /etc/bootptab file is referenced for registered clients; DHCP services are used for anonymous clients.

Itanium-Based Systems

When an Itanium-based system boots from an Ignite-UX server, the first IP address request is answered by the bootpd daemon. This communication uses ports 67 and 68. The file /etc/bootptab is referenced to assign the first IP address to a registered booting system. If the system is not registered, and you are running HP-UX 11i v2 or HP-UX 11i v3 on the Ignite-UX server, DHCP is used to assign the booting IP address.

When Itanium-based systems request a second IP address for networking, it uses the same daemon, file and ports described above. Configuring DHCP for booting is separate from configuring DHCP for assigning network IP addresses. See “Configuring an Ignite Server to Boot Anonymous Itanium-Based Clients” for information about how to configure DHCP for assigning first (boot) and second (networking) IP addresses without conflict.

Phases of Operation

Ignite uses the sequence of high-level phases outlined below to accomplish installation and recovery. Depending on configuration information, some steps within these phases might be skipped. At a very high level, Ignite operates in four phases:

Startup – The install environment is loaded from the boot source to the client memory. Ignite runs in client memory. The operation is configured and launched. If the installation or recovery is interactive, the user interface is run to create a configuration.
Phase 1 – Storage is set up and Ignite moves to the client disk.
Phase 2 – HP-UX archives and depot software are installed. The HP-UX kernel is built. A reboot is required to start the final HP-UX kernel and make the new file system the root file system.
Phase 3 – Software is configured. The system is now fully installed or recovered after a reboot or halt.

Startup

Ignite-UX software is started and the Ignite user interface is run to select, create, or modify the configuration that will be used to control installation or recovery. The result of this phase is a detailed system configuration to be used for installation or recovery. Processing for this phase is done on a RAM file system.

The install kernel and install file system are loaded from the boot source to the client memory via boot loader functionality. The HP-UX install kernel is started.
The Ignite software is started by the install kernel as an application process running on the install file system.
Additional RAM file systems are created to allow enough file system space for loading system setup content.
If the system has SAS disks, the I/O configuration is modified as needed to make the mapping between bays and HW paths consistent. This aids consistent installation and recovery. (Improved agile device selection and recovery has eliminated the need for this feature and might result in this step being removed in the future.)
Configuration content from the install file system is loaded to determine if the Ignite TUI should be started and if special inventory control is needed. (The Ignite TUI is started by default.)
A system I/O inventory is performed. This identifies devices where HP-UX may be installed, and identifies devices and networks used to accomplish installation. Install file system configuration and boot loader option content may be used to control inventory. The boot source is also determined.
Unless configuration information directs otherwise, the Ignite TUI is launched on the client.
- The operation to be performed is set. (Advanced Install is the default operation.)
- Networking configuration information is determined, if the installation requires the network.
- The complete set of Ignite configuration files is read and parsed. Note that changing the Configuration or Environment will result in rereading and parsing config content, since these changes generally result in changes to the set of config files.
- System, software, file system, and other configuration changes are gathered via the interface.
- When Go! is selected from the user interface, the requested installation or recovery is launched.
- Configuration sanity checking is performed. If there are problems, you are returned to the TUI.
- The modified configuration is saved to control installation or recovery processing.
If the TUI was not selected to launch, sanity checking is done on the selected config.

Phase 1

Storage is set up and Ignite relocates to the new disk file system. The result of this phase is the install or recovery functionality running on what appears to be a normal disk-based file system, and if recovery, an I/O configuration that appears to be restored. Some aspects of the configuration cannot be fully restored until reboot. Processing for this phase is done on a RAM file system.

During a recovery, the original I/O configuration is restored if I/O instance data is present in the config. Some aspects of the configuration might be instantly changed. Some aspects are temporarily changed and will be finalized during reboot. If the current system is different, some aspects of the I/O configuration will be impossible to restore.
Create disk partitions if needed (Integrity systems only).
Create volume manager volumes as needed.
Create and mount file systems.
Determine software sources and selections.
Run pre-config control scripts.
Set boot path.
Set up and enable swap space.
Save final volume configuration data to disk file system.
Set locale.
Move needed content from RAM file system to disk file system. Load the complete set of commands, libraries, and other files required to accomplish installation and recovery from Ignite command archives to the new disk file system (SYSCMDS or SYSCMDSIA).
Change the root directory to the disk file system with chroot.

Phase 2

File content is installed or restored. The result of this phase is the final disk file system and content. Some cleanup and processing that must be done after system reboot is still required. For the HP-UX install kernel, the RAM file system is still the root disk. For the commands in this phase, the new disk file systems is the root file system. A reboot is required to change the HP-UX kernel root disk from the RAM disk to the final disk.

Release RAM disk space to accommodate software installation and kernel build processes to be done later.
Load the archive if indicated in the config (for recovery and golden image installation).
Update mnttab so it appears to be correct during installation and kernel build.
Create device special files.
If needed, rename device files to make the I/O configuration appear fully restored.
Update bootconf.
Change I/O configuration files to match final instance config using ioinit and ioscan -M.
Load depot-based software if indicated in the configuration.
Save configuration so it is available for reuse.
Build final system kernel.
Set up the inittab file so final Ignite-UX processing will be done after reboot.
Reboot system.

Phase 3

Software is configured and final installation or recovery cleanup is done. The result of this phase is a fully installed or recovered system, ready for use after reboot. If configuration has been deferred, the system will be set up to run FIRST-BOOT set_parms on initial boot so you may choose the hostname, IP address, and other settings. Processing for this phase is done using the final disk-based file system.

Update the AUTO boot file.
Configure software.
Configure final networking.
Generate a system manifest.
Save the installation information for deferred configuration.
Perform final cleanup.
Reboot or halt system.