UCS Blade Falls to EFI Shell After a Service Profile Clone
Two UCS 6454 fabric interconnects in end-host mode serve a 5108 chassis with four B200 M5 blades and VIC 1385. SAN boot is provided by a pair of MDS switches to a Pure array. Each blade has vHBAs pinned to fabric A and B, and boot policy BOOT-SAN-APP lists the fabric-A vHBA first with boot LUN 0, then the fabric-B vHBA. Service profile SP-APP-03 was cloned from SP-APP-02 and associated to blade 3. The blade completes POST but drops to the EFI shell. On the MDS, show flogi database shows the new vHBA PWWNs logged in on both fabrics, and zoning shows the array target and both initiators in the same zone. The array reports the boot LUN presented to both initiator PWWNs at LUN 0. In the service profile the vHBAs were renamed SAN-A and SAN-B during a naming standardization, but the boot policy still references the old vHBA names.
1. Given that fabric login and zoning are healthy, what do you check next, and why does the boot policy matter?
Read the worked answer
Fabric login and zoning prove the SAN path works, not that the server knows which device to boot from. The boot policy is an ordered list of references; each entry must point to a vHBA (or vNIC/local disk) that actually exists in the associated service profile.
Here the vHBAs were renamed to SAN-A and SAN-B after the profile was cloned, but BOOT-SAN-APP still names the old devices, so both boot entries are invalid and the server falls through to the EFI shell. In UCSM, open Servers > Service Profiles > SP-APP-03 > Boot Order and compare each entry with the vHBA names on the profile; also check the boot policy object itself under Policies > Boot Policies.
If you inspect the profile through the CLI, confirm the vHBA names and the boot policy reference before changing anything, because fixing the policy and re-associating reboots the blade.
2. If the names matched, what other settings would you verify before escalating to the storage team?
Read the worked answer
Check the boot LUN ID in the boot policy against what the array presents: LUN 0 in the policy is only valid if the array maps the boot volume at LUN 0 for both initiator PWWNs. Check the configured boot mode (Legacy BIOS versus UEFI) against how the OS was installed; a UEFI boot policy pointed at a legacy-installed LUN also lands in the EFI shell.
Verify that the vHBAs are enabled and that the FI FC ports are configured as FC Uplink rather than FC Storage (FC Storage is for direct-attached targets). Confirm the array's host mapping and LUN masking include both vHBA PWWNs, and check that the boot order does not have local disk ahead of the SAN entries. Comparing against SP-APP-02, which boots successfully, usually reveals the divergence quickly.
3. Give a remediation plan that minimizes disruption to the other blades in the chassis.
Read the worked answer
Correct the boot policy references first: either rename the vHBAs back to the names the policy uses, or edit BOOT-SAN-APP to reference SAN-A and SAN-B. Because the blade is already in the EFI shell, do this in a maintenance window and warn the application owner that re-association reboots the blade.
Before rebooting, reopen the service profile and confirm each boot entry resolves to an existing vHBA with the right LUN and boot mode; this avoids another failed boot cycle. Re-associate (or re-apply) SP-APP-03, then watch the blade's POST and the MDS show flogi database to confirm both initiators log back in.
Finally, check the array event log for a new initiator login and verify the host boots. No other blade or chassis component needs to change, so the impact stays limited to blade 3.