This section provides an understanding of the terms that are associated with installing the software.

• Package: The primary mechanism for changing the install image on a system. A package, also known as an RPM, contains the software and metadata. A package is in .rpm format. A package can be mandatory or optional. Mandatory packages are part of the install image and cannot be removed. Optional packages are not required for the software to work, but can be installed to provide additional functionalities, and can be installed or removed based on requirement.

• ISO image: A bootable image that contains the installable files of the base operating system (OS). The image contains the IOS XR (XR7) infrastructure for fixed and distributed platforms in the form of base ISO image, mandatory RPMs. An ISO image is in .iso format.

• Golden ISO (GISO): A customizable ISO image that is built to contain preferable packages to suit diverse installation requirements. GISO can be customized to include a standard base image with the basic functional components, additional RPMs, bug fixes, and configuration files based on your requirement. GISO can also include a custom image version. From IOS XR Release 7.5.x and later, you can build your GISO image without support from Cisco by using the Build Golden ISO (GISO) Using gisobuild.py Tool feature.

• Source: A location where packages can be installed from. The source can be a repository, local directory or a local tar file.

• Repository: A directory of RPMs and their metadata that a package manager uses to query the packages.

• Active package: A package whose software is currently running on the system.

• Committed package: A package that is committed and remains active following a system reload.

• Atomic Change: Every packaging operation is contained within an atomic change. Atomic changes may contain multiple packaging operations. During an atomic change, any changes to install IOS XR software will not be visible to the system. To make the changes visible to the system, the atomic change must be applied.

• Top-level package: Each block of software has a top-level package and various partition-level packages. The top-level package can be installed or upgraded directly, whereas the partition-level packages cannot be changed directly. The partition-level packages are installed or upgraded automatically as dependencies of the top-level package. The top-level package has the name format xr-<feature>-<release>.x86_64.rpm, whereas the dependent partition-level packages have the longer name format containing information about the partition. You can also use the standard RPM commands to check the summary or description metadata of the package, which will identify whether it is a top-level or a partition-level package.

• Package manager: An entity that handles the semantics to resolve dependencies in packaging operations.

• Packaging operations: The actions performed to change the packages that are installed on the system. The semantics are inherited from the underlying package manager. Examples of packaging operations are upgrade, downgrade, replace, add, or remove packages.

• Synchronous action: Synchronous action requests are supported for install actions using CLI command. Specify synchronous keyword in the install commands, and the prompt will only be returned when either the request has completed, Ctrl + C keys are pressed or a reload occurs. Pressing Ctrl + C keys during a synchronous action request will return the prompt to the user but will not halt the install operation. During the synchronous action request, the user is updated with the status of the request whenever it changes.

• Transaction: All atomic changes occur within a transaction. If the system reloads during an install transaction, the running software will be reverted to its previous state before the transaction was started. To maintain the software changes carried out during a transaction, you must commit the transaction.

• A complete install operation to modify the system’s software requires three phases:

  • Packaging operation

  • Apply: This is required to complete an atomic change and make the software change visible to the system.

  • Commit: This is required to end a transaction and ensure that all software changes will still be present on router reload.

  Note

  If you perform a manual or automatic system reload without completing the transaction with the install commit command, the action will revert the system to the point before the install transaction commenced, including any configuration changes. Only the log is preserved for debugging. This action clears all configuration rollback points available. You will not be able to rollback to, or view, any commits made until the install rollback event. Any new commits made after the install rollback event will start from commit ID ‘1000000001’.

  Note

  In a multinode system, any node reloads that occur during a transaction that are not initiated as part of the install 'apply by reload' phase can result in the reloaded node being in BOOT HOLD state. The node continues to be in the BOOT HOLD state until the transaction is either committed or cancelled.

The base ISO image is contained within a .iso file. Additional optional packages (RPMs) are provided as modular software deliverables to align with diverse use cases and their deployments across the network.

Note	You can create a golden ISO (GISO) with optional packages and bug fixes based on your requirement. Contact Cisco Support to build a GISO.

The software deliverables can be downloaded from Cisco Software Download center.

Note	The telnet package is not part of the ISO image. You must manually install the telnet optional package to use telnet for client or server. This applies to all packages that are not part of the ISO image. SSH is part of the ISO image. Install operation over IPv6 is not supported.