IBM Server Hangs at “Connecting Boot Devices and Adapters”: Troubleshooting Guide

Quick Answer

An IBM server that remains at “Connecting Boot Devices and Adapters” needs investigation of its firmware, adapters, and attached boot devices. The message alone does not identify a defective disk or RAID controller. Documented causes include unavailable storage boot paths and specific combinations of server and adapter firmware.

Start by recording the server model and recent changes, checking management-controller logs, and removing unnecessary external boot media. Then investigate the configured storage paths and applicable firmware advisories. Preserve the existing storage configuration: do not initialize disks, recreate RAID arrays, or reset firmware settings as an initial troubleshooting step.

What the Message Means

This message appears during the server’s firmware startup sequence, before the operating system loads. UEFI, the Unified Extensible Firmware Interface, is the firmware environment that prepares the system for booting. POST means Power-On Self-Test.

The displayed text is a startup status message, not a unique error code. A prolonged pause can indicate device discovery delays, an adapter initialization problem, or a firmware compatibility issue. The last visible message does not necessarily identify the component responsible.

This guide focuses on IBM System x and related Lenovo x86 servers. BladeCenter and other platforms require their own service procedures. Hardware removal, firmware updates, and storage changes should be performed by an authorized technician or administrator.

Distinguish a Delay from a Startup Failure

There is no universal timeout that proves a server has hung. Compare the elapsed time with that server’s normal startup behavior and its documented configuration. A changing seconds counter alone does not prove that device initialization is progressing.

Before You Begin

• Arrange a maintenance window and coordinate with the owners of affected applications or virtual machines.
• Record the machine type/model, installed adapters, firmware versions, and exact screen message.
• Identify whether the server boots from local disks, internal flash media, or a storage area network (SAN).
• Record recent hardware, firmware, cabling, storage, and boot-setting changes.
• Confirm the latest usable backup and access to any required encryption recovery keys before changing firmware or boot settings.
• Make one diagnostic change at a time and record the result.

Step 1: Capture Logs and Hardware Indicators

Where available, connect to the server’s Integrated Management Module (IMM or IMM2). Check the event log for entries around the failed startup and record any illuminated diagnostic LEDs.

On IMM2, open Events > Event Log. Export relevant events before making changes or clearing anything. Lenovo documents timestamped events and an Export function in this interface. Menu names differ on other management controllers. 

Look for entries identifying a particular adapter, PCIe slot, storage controller, memory component, power supply, or thermal condition. Follow the service procedure for an explicit hardware error before assuming the boot message identifies the cause.

Expected result: You have a record of the failure and any associated hardware events. An empty event log does not rule out a firmware or adapter problem.

Step 2: Remove Unnecessary External Boot Media

The following are general isolation checks, not a documented universal fix for this message:

1. Confirm that no firmware update, installation, or recovery operation is running.
2. With the server powered off, disconnect unnecessary external USB storage, external optical drives, and USB hubs. Retain the keyboard or console access needed for troubleshooting.
3. Disconnect unused virtual installation media from the remote-management session.
4. Leave production storage connections and required boot media intact.
5. Start the server and compare its behavior with the recorded baseline.

Do not remove an internal USB or SD device without identifying its purpose; it may contain the operating system or hypervisor.

Expected result: If startup succeeds, reconnect unnecessary devices individually during controlled tests to identify the trigger. If nothing changes, continue with storage and adapter checks.

If a full power removal is needed, follow the exact model’s service instructions. A blade-server power procedure differs from a rack-server procedure; do not power down an entire chassis to troubleshoot one blade.

Step 3: Check Storage and Boot-Target Availability

Servers that boot from local storage

If firmware setup or the storage-controller utility is accessible, inspect the existing configuration without modifying it:

• Confirm that the expected controller and boot logical drive are detected.
• Record missing, offline, degraded, or foreign-configuration indications.
• Compare the configured boot device with the previously working configuration.
• Investigate changes to controller firmware, disks, or cabling that immediately preceded the failure.

A RAID logical drive presents an array of physical disks as a storage device. A degraded array requires its own recovery procedure; it is not a reason to recreate the array.

Servers that boot from SAN storage

Ask the storage administrator to verify the configured boot target, adapter-port connectivity, switch configuration, and access to the correct logical unit number (LUN). A LUN identifies a storage volume presented by the storage system.

Emulex release notes document extended startup delays at this message when a storage port is down. For the affected configurations, the vendor advises restoring connectivity to configured SAN boot targets or removing obsolete SAN boot configuration when the target is no longer available.

Expected result: Required targets are reachable and obsolete entries are addressed through the storage change process. Reboot and compare the startup delay. If the failure remains, investigate adapter compatibility and firmware.

Step 4: Check Documented Firmware Conditions

The following are historical, hardware-specific advisories. Match the complete configuration before using them. Their listed versions identify the documented fixes; they are not universal firmware recommendations for other servers.

BladeCenter HS23 or HS23E with Broadcom CFFh adapters

IBM documents a startup hang involving HS23/HS23E servers, the Broadcom 10 Gb Ethernet Expansion Card configurations listed in its advisory, adapter firmware 2.1.9b, and UEFI releases 1.30 or 1.32. The hang can occur before the F1 setup screen becomes available.

IBM identifies UEFI 1.40 as the fix for that specific issue. Verify the machine type, adapter part number, supported update path, and package instructions before proceeding. The advisory also describes a historical downgrade workaround; do not apply that sequence to unrelated configurations.

Emulex adapters with two FCoE boot targets

Release notes for the Emulex OneConnect OCe11100 series describe a hang when both Fibre Channel over Ethernet (FCoE) ports have boot targets configured with a BladeCenter 10 GbE Pass-Thru Module. The notes report that the hang does not occur with a boot target configured on only one port, while listing no general workaround.

This is a configuration-specific diagnostic clue. Any reduction in boot-path redundancy requires review by the storage administrator and confirmation of the applicable vendor guidance.

NeXtScale nx360 M5 console-message issue

IBM separately documents a harmless occurrence of this message under particular serial-console settings on NeXtScale nx360 M5 systems. The affected build is THE106B; the documented correction is UEFI 1.20, build THE108J, or later. This advisory concerns a displayed message and must not be treated as proof that an unresponsive server is healthy. 

Apply firmware changes carefully

• Use packages intended for the exact machine type and adapter.
• Read prerequisites, required update order, supported firmware combinations, and reboot requirements.
• Record existing versions and save configuration information where supported.
• Use stable power and allow the update to finish without interruption.
• If the operating system cannot start, use only an offline or management-controller update method documented for that platform and component.

Expected result: The intended firmware versions are reported after the update, the server passes the previous stopping point, and required devices remain available.

Step 5: Isolate Adapters and Internal Hardware

Advanced troubleshooting: If the previous checks do not identify the cause, use the exact server’s service manual to plan hardware isolation. Begin with a recently installed or nonessential adapter when the evidence points to it.

1. Photograph and label adapter slots and cable connections.
2. Have a qualified technician remove or isolate one nonessential component using the supported procedure.
3. Test whether the server progresses through firmware startup.
4. Restore the component before testing another, unless the documented isolation procedure requires otherwise.

If removing an adapter allows startup to proceed, the adapter, its firmware, its slot, or an attached device becomes the focus of investigation. This result does not by itself prove the adapter is defective.

For a minimum-configuration test, use the component requirements in the model-specific service manual. Lenovo’s x3650 M5 service guide includes this diagnostic approach, but its configuration must not be assumed valid for every System x model.

If the boot controller is intentionally absent during an approved isolation test, reaching a no-boot-device message can demonstrate progress through POST. It does not mean normal operation has been restored.

Verify the Fix and Restore Normal Operation

• Confirm that startup passes the previous stopping point and reaches the intended operating system.
• Check that expected storage volumes, network interfaces, and applications are available.
• Verify RAID health and, where applicable, SAN path redundancy.
• Review management-controller logs for new errors.
• Perform a controlled restart within the maintenance window to check repeatability.
• Record the change that resolved the problem and the resulting firmware or hardware configuration.

If a diagnostic change does not help, restore the recorded setting or connection before proceeding. Reinstall removed hardware using the service procedure. For firmware recovery, follow the package and platform documentation; do not assume that flashing an older version is supported.

When to Escalate

Contact the hardware support provider if the server remains unresponsive with the documented minimum configuration, reports persistent component errors, cannot access its expected storage, or requires firmware recovery.

Provide the machine type/model, firmware inventory, screenshot, elapsed startup time, exported event logs, recent changes, and results of individual isolation tests. Share diagnostic files through an approved support channel.

Frequently Asked Questions

Should I reinstall Windows, Linux, or VMware ESXi?

Not as an initial response to a failure that remains in firmware startup. Investigate the preboot problem first. Operating-system repair becomes relevant when startup reaches the bootloader or operating system and fails there.

Should I switch between UEFI and Legacy boot?

Only when correcting a verified configuration mismatch. An arbitrary change can prevent the existing installation from booting. Record the original mode and preserve the working boot configuration.

Will clearing CMOS fix the problem?

There is no universal CMOS-reset fix for this message. Resetting firmware settings can alter boot behavior and remove important configuration. Use it only when the model’s recovery procedure or support provider specifically calls for it.

What if F1 setup never opens?

Capture the screen and use the management controller to collect available logs. Some documented firmware conflicts occur before setup becomes accessible. Check the relevant advisory and supported recovery options instead of assuming the keyboard is the cause.

Does a successful boot after removing a device prove that device is faulty?

No. The result narrows the investigation to that device and its dependencies. Compatibility, firmware, cabling, a PCIe slot, or an attached storage target may explain the behavior.

Sources

• Lenovo: IMM2 event log and export options
• Emulex: Lenovo firmware and boot-code release notes for OneConnect OCe11100-series adapters
• IBM: BladeCenter HS23/HS23E startup hang with specific UEFI and Broadcom firmware versions
• IBM: UEFI debug-message issue on NeXtScale nx360 M5 systems
• Lenovo: System x3650 M5 Type 5462 Installation and Service Guide