Feature Overview

This feature introduces an automated mechanism to eject or unmount installation media (ISO/USB) during the final stages of an OpenShift Container Platform (OCP) deployment via the Agent-based Installer (ABI) and Assisted Installer (AI). By triggering an "auto-eject" command after Red Hat Enterprise Linux CoreOS (RHCOS) is written to the target disk but before the first reboot, the system ensures that the subsequent boot sequence defaults to the local disk. This prevents "boot loops" back into the discovery ISO, reducing manual intervention and eliminating the "Pending User Action" stall in automated deployments.

Goals

• Automate Post-Install Boot Transition: Enable a seamless transition from installation media to the installed operating system without manual operator intervention.
• Reduce Deployment Stalls: Eliminate the "Pending User Action" status caused by systems booting back into the ISO.
• Support Legacy BIOS and Virtual Environments: Provide a functional equivalent to efibootmgr for BIOS-based systems and persistent virtual media environments (e.g., Nutanix, vSphere).
• Primary Persona: IT Operations Engineers and Infrastructure Architects performing large-scale, remote, or unattended bare-metal and virtualized OpenShift deployments.

Requirements

• Functional:
  • The installer agent must attempt to execute an eject command (e.g., /usr/bin/eject) on the boot source device after the RHCOS image is successfully written to the target persistent storage.
  • The feature must be compatible with physical CD-ROM/USB drives and virtual media (vSphere, Nutanix AHV, and KVM).
  • The ejection must occur strictly before the final reboot command is issued to the host.

• Non-Functional:
  • Reliability (Best-Effort): If the eject command fails (e.g., due to hardware limitations or restricted BMC permissions), the installation process must not fail; it should proceed to reboot as a fallback.
  • Maintainability: The solution should utilize standard Linux utilities already present in the RHCOS live environment.
  • Portability: The mechanism should work across both ABI and Assisted Installer workflows.

Use Case (Problem Description)

Organizations deploying OpenShift clusters often encounter a disruptive failure during the reboot phase. After the installer finishes writing the OS to the disk and reboots the server, the system BIOS/firmware frequently prioritizes the still-attached ISO or USB drive over the newly installed local disk.

This leads to a "boot loop" where the server reloads the discovery environment instead of the installed OCP node. In the Assisted Installer console, these nodes move to a "Pending User Action" state. To resolve this, an operator must manually intervene—often requiring physical access to pull a USB drive or remote BMC access to detach virtual media—which significantly undermines the efficiency of unattended or remote "Edge" deployments.

User Scenarios

• As an Infrastructure Engineer deploying 50 bare-metal nodes with legacy BIOS, I want the installation USB to be logically ejected before reboot so that the nodes boot from their local disks automatically without me having to visit the data center to pull out 50 USB drives.
• As a Cloud Administrator deploying on Nutanix, I want the virtual ISO to be unmounted by the installer so that the VM doesn't loop back into the discovery image, which currently requires manual detachment in the Prism console.

Questions to Answer

• How will the installer identify the correct device path for the boot media across varying hardware and hypervisor configurations?
• Are there specific Baseboard Management Controller (BMC) configurations where an OS-level eject is ignored, and can Redfish/IPMI calls be used as a secondary method?
• Should this be an opt-out or opt-in configuration in the install-config.yaml or agent-config.yaml?

Out of Scope

• Hardware Boot Order Modification: This feature does not aim to permanently reconfigure BIOS/UEFI boot priority settings (beyond existing efibootmgr logic for UEFI).
• Pre-installation Media Management: Managing media before the RHCOS write process is complete.
• Third-party Tooling: Integration with external PXE/DHCP server management to disable network boot.

Links