cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2419
Views
8
Helpful
11
Replies

Upgrade to 2.1(3a)

yuvalba
Level 1
Level 1

Did anyone upgrade sucessfully to 2.1(3a)?

I find a funny bug in the release notes saying:

Defect ID
Symptom
Workaround
First Bundle Affected

CSCui99339

When you upgrade to Release 2.1(3) from 2.1(2) using FW Auto Install to  install infrastructure firmware, upgrade fails with an "Upgrade  Validation Failed" error.

This issue has no known workaround.

2.1(3a)A

What does it mean? Is it not possible then to upgrade from 2.1(2a) to 2.1(3a)?

Yuval

1 Accepted Solution

Accepted Solutions

Keny Perez
Level 8
Level 8

Yuval,

That applies if you use the new Auto Install Feature that we release in UCSM 2.1, but with that feature we did not remove the option to still do it manually.

So if you want to avoid that bug, do it old school

-Kenny

View solution in original post

11 Replies 11

Keny Perez
Level 8
Level 8

Yuval,

That applies if you use the new Auto Install Feature that we release in UCSM 2.1, but with that feature we did not remove the option to still do it manually.

So if you want to avoid that bug, do it old school

-Kenny

Ah thanks.

I'm a bit of a UCS newbie, I guess old school is via CLI?

Any idea when the upgrade via auto install will be fixed?

Yuval,

No problem, that what we are here for... to learn from others.

You may do it from CLI but to me that is a lot more complicated

Auto Install is a feature that allows to do the upgrade almost with no user intervention, old schoold would mean to do it manually from UCSM and doing the upgrade of each component one at the time but it has an order.

For example you can use a guide like this one to upgrade from  2.0 to 2.1 manually:

http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/upgrading/from2.0/to2.1/b_UpgradingCiscoUCSFrom2.0To2.1.html#concept_C70F7CFF31AC46C7AD03E8022299C808   <<< 

Summary of Steps for Manually Upgrading from Release 2.0

Not sure when the fix will be available, but you may sunscribe to the bug if you want updates when that is done:

http://www.cisco.com/cisco/support/notifications.html

1-Click on “Add Notification”

2-Under “Notification Name” enter a name you can easily remember, enter the email where you want to receive the notification and hit “Continue”

3-Choose “Track a specific Bug ID” and “Continue”

4-Enter “ Bug Number” and “Continue”

5-Click on “Finish”

Here is a guide for this process.

http://www.cisco.com/web/tsweb/flash/support/ngw/cisco_support_cns.html    <<<<<< This is a simple video that will show how to do this and each field within the tool

I hope that helps,

-Kenny

Thanks

I will look into the manual install.

Hi,

did yesterday an upgrade from 2.1.1a to 2.1.3a with Auto-Update, but musst have overseen this note.

Anyway, after the IO-Modules get the update, every interface on any blade went down.

No more connections from any blade is possible an VIF.

Message F0283 with "Bound Physical Interface down" on Switch A and B on all VIF.

But any physical interface, as far as i can see, is up and running.

Any ideas, how i get my blades (B200M3) up and running again? Lucky me, that this was "only" our testing environment....

Also did an upgrade of firmware on two blades to 2.1.3a, hoped that this will resolve may problem.

But nothing so far....

Any help or tips are welcome.

Best

Timo

Hi,

short update on the case above. After "Re-acknowledge" each blade (really bloody with the gui, powertool-doku: not much of an help) i only have the F0283 now for the vHBAs (SAN-Part).

If anyone has an idea for that, because before the upgrade, there where not such error, youre welcome. ;-)

Thx.

Best

Timo

Timo,

Have you checked your DCE interfaces  (Adapter) and backplane interfaces (IOM) ?

Can you attach an screenshot of both if you don't mind ?

-Kenny

Hi Kenny,

i tracked it now down to this. Not a single VIF is bound to an vPC/PC as far as i can tell.

This is a screen of a server. Every physical port is up type DCE. Every Port of the IOM, seems fine.

I have absolutely no idea, what went wrong (or is wrong).

And that is what i see on the NXOS part for a VIF:

###############################################

(nxos)# sh int vethernet XXXX

VethernetXXXX is down (nonParticipating)

    Bound Interface is --

  Hardware: Virtual, address: xxx.xxxx

  Description: server 1/1, VNIC VNIC9-xxxxx

  Encapsulation ARPA

  Port mode is trunk

  EtherType is 0x8100

  Rx

    0 unicast packets  0 multicast packets  0 broadcast packets

    0 input packets  0 bytes

    0 input packet drops

  Tx

    0 unicast packets  0 multicast packets  0 broadcast packets

    0 output packets  0 bytes

    0 flood packets

    0 output packet drops

########################################################

Any ideas on that?

I thought the Re-Ack of the Blade did the trick. But it seems, i am wrong from a CLI-Point of View.

From the GUI, it seems pretty fine for the vNICs....

But thats obviously not true.....

Best

Timo

Timo,

Just to confirm, this server has an OS installed? If so, what do you see in the KVM?

When you say that the IOM ports are fine, can you confirm you checked Backplane ports AND network ports?

Also, can you share a "show interfaces fex-fabric"  also from nxos; and "show pinning interface vethernet XXX" ?

-Kenny

Hi Kenny,

your input, about OS, was the key to this. I asked the Dev-Team who tested some things on that system an they had no OS directly installed, as i found out today. They had booted the servers via PXE. The systems run complettly in memory and no FC-related drivers installed or used.

Anyway, after installing a real OS with all the necessary drivers (enic, fnic) on a server, the message, about the VIF, especially the vHBA disappeared. But on them, who no system is installed, the message are still there.

The problem i see is, if there is no real traffic on the systems, or not really installed as it seems, you get a lot of errors and the UCS-admin totally confused. Anyway in the future to avoid such a scenario?

Thx again for your help!

Best

Timo

Timo,

I am glad you were able to confirm the absense of a OS was the culprit, usually when we see "VethernetXXXX is down (nonParticipating)" the problem is that there is no OS.

In regards to those faults you see, you should be able to use Fault Supression, taking advantage that you are using 2.1 already.

http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/gui/config/guide/2.1/b_UCSM_GUI_Configuration_Guide_2_1_chapter_0110000.html#concept_2979E86A5D50446EBE9F8868DA6F70A9

I think in this type of cases, "default-server-maint" should work.

-Rate ALL helpful answers

-Kenny

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: