cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4154
Views
0
Helpful
7
Replies

UCS 2.0(1s) - b200-m2 - remove hard disk - constant error

JEFFREY SESSLER
Level 1
Level 1

Setting up new UCS with 2.0(1s). The bundle shipped with the hard disks in each b200-m2. Prior to installing ESX5, the hard disks were removed (blade powered down) and blanking panels inserted. The service profile has a "no local storage policy" and the profile associates with the blades, boots, etc... but...

three of the four blades are reporting a dual F0181 errors:

Local disk 1 on server 1/4 operability: inoperable sys/chassis-1/blade-4/board/storage-SAS-1/disk-1/fault-F0181

Local disk 2 on server 1/4 operability: inoperable sys/chassis-1/blade-4/board/storage-SAS-1/disk-2/fault-F0181

I've re-acked the blades, I've decommisioned them, then re-ack'd the slots, etc. but can't seem to get the errors to clear.

Thoughts?

When I setup my fist UCS a year ago, I did the same process (removing the HD's) and don't recall having the issue.

Jeff

7 Replies 7

anikas
Cisco Employee
Cisco Employee

There is a defect out there that may explain your issue.

CSCtt87598 Incorrect fault "local disk inoperable" set and cannot be cleared

1. When the LSI 1064E option ROM or the OS driver loads, it issues a port enable command to firmware for each drive in the blade. Once the port is enabled, the link between the LSI 1064E controller and the disk drive is brought up.

2. When the link between the LSI 1064E controller and a disk drive is down for any reason, the controller asserts the corresponding fault signal. If the link is up, the controller deasserts the corresponding fault signal.

3. When SAN Boot is configured, UCSM disables the LSI 1064E option ROM. Additionally, if an OS isn't booted, the LSI 1064E OS driver isn't loaded.

When SAN Boot is configured and no OS is booted, a port enable command isn't issued to firmware. Consequently, the link between the LSI 1064E controller and the disk drive isn't brought up. This results in the fault signal being asserted which is then reported to the user by UCSM.

This is expected behavior.

Sent from Cisco Technical Support iPhone App

So in my case, I'm booting from SAN, but the fault is still up once the ESXi5 hypervisor has booted.

I'm sorry I thought you had the error before esxi was loaded. I have found some instances of this error after people upgraded to 2.0. In these instances not everything was upgraded on the server like the board controller or CIMC. Can you check this under firmware management for this blade and compare it against the working ones? If this does not turn up anything then you would be best served by opening a TAC case. The fault should be clearing after you boot from SAN.

Sent from Cisco Technical Support iPhone App

anikas
Cisco Employee
Cisco Employee

What is the local disk policy set to. Is it set to none?

Sent from Cisco Technical Support iPhone App

It is currently set to none, and I also tried it as "any configuration"

I believe the problem is solved.

I had to:

Disassociate the service profile

Wait for the process to complete and the blade was in a power off state.

Remove the blade from the chassis

When the slot error came up, tell it to remove the server.

One the server was gone from UCS manager, re-insert the blade.

Once the server had completed its deep discovery, re-associate the service profile.

F0181 errors are gone.

anikas
Cisco Employee
Cisco Employee

Excellent news looks like it was that defect and the deep discovery did the trick. Thanks for the follow up.

Sent from Cisco Technical Support iPhone App

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: