Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-8525

Improve Early-Boot & Bootstrap Logging for Single Node OpenShift (SNO)

XMLWordPrintable

    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request

      Improve Early-Boot & Bootstrap Logging for Single Node OpenShift (SNO)

      2. What is the nature and description of the request?

      During Single Node OpenShift (SNO) installation, there is no supported way to access complete system logs from the early boot stages.

      Before SSH is available, and journal logs are not persisted across reboots. Debugging bootstrap issues (network, disk, ignition, kubelet startup) is extremely difficult.

      Currently, users rely on unsupported workarounds such as:

      • Editing GRUB to force single-user mode
      • Resetting the core password mid-bootstrap
      • Using emergency shell
      • Attempting to scrape logs manually after installing
      • Relying on BMC consoles (not available on edge hardware)

      These actions can interrupt the bootstrap process, causing unpredictable cluster state and requiring full reinstall attempts.

      Why This Is an Issue

      SNO is heavily used in:

      • Edge and embedded deployments
      • Air-gapped / disconnected environments
      • Bare-metal installations without BMC
      • Sensitive deployments (Gov/Defense)
      • Hypervisor-based SNO (KVM/Proxmox/ESXi)

      In all these scenarios, bootstrap visibility is very low, and failures in early-boot stages cannot be diagnosed or retrieved once the node transitions to later phases.

      Common failures that cannot currently be diagnosed include:

      • Incorrect NIC selection / NIC renaming (predictable names)
      • DHCP timeouts
      • VLAN configuration issues
      • Disk selection failures by coreos-installer
      • Pull secret or registry connectivity failures
      • Ignition configuration errors
      • kubelet not starting post-install

      These failures generate logs only in transient early-boot journals that are lost.

      Expected Outcome

      Users can reliably diagnose bootstrap issues without:

      • Dropping into emergency mode
      • Resetting core password mid-boot
      • Interrupting installation
      • Reinstalling repeatedly
      • Relying on BMC hardware consoles

      Logs remain available for support escalation.

      3. Why does the customer need this? (List the business requirements here)

      • SNO adoption is rapidly increasing across edge, industrial, and telco verticals.
      • Many of these deployments lack BMC access, making early log capture mandatory.
      • Improved logging reduces installation failures and supportsability burden.
      • Lack of early logs is a key friction point blocking scale-out SNO deployments.
      • Reduces repeated install attempts and accelerates time-to-value.

      This RFE improves reliability, usability, and debuggability for SNO customers.

      4. List any affected packages or components.

              dfroehli42rh Daniel Fröhlich
              rhn-support-chdeshpa Chinmay Deshpande
              None
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                None
                None