Trouble with 2960X Stack IOS Upgrade

[Terence Lockette]

All,

I have a simple question but I was wondering why I can't successfully get my stacks of 2960X switches to boot all the switches in my stack with a newer version of IOS after issuing the reload command?  Here is what I mean.  I copy the new IOS image to all flash directories (flash:, flash:1, flash2:, etc.).  Then I issue the boot system switch all flash:/<image.bin> command.  I run the show boot command to verify the boot path for each switch.  I also run the dir command for each flash directory to ensure that they all have the correct image.  Lastly, I reload the switch to reboot the entire switch stack but each switch sits there with an amber Sys light.  Each switch is acting as master.  The only workaround that's been successful is to manually reboot each switch simultaneously and ensuring the master switch starts booting first.  Once this happens, then each switch in the stack boots normally and is joined to the master.  Am I doing something wrong?

P.S. I'm upgrading to the current 2960X suggested release which is 15.2(2)E4

Thanks,

Terence

[Leo Laohoo]

I copy the new IOS image to all flash directories (flash:, flash:1, flash2:, etc.). 

As in copy the BIN files to each switch member of the stack?  If this is so, then I'd recommend using the TAR upload script.  Why?  The using the "archive download-sw" command with the IOS TAR means that the automation will CORRECTLY download the IOS to all switch members of the stack.  Additionally, the "archive download-sw" also provides additional information if the IOS was pushed correctly or not, which the "copy" command won't do.  For example, if the BIN file used to copy the IOS to each stack member, is corrupt there is no way to find out.  Plus using the "copy" command one has to be mindful of the number of times the command needs to be invoked in order to ensure every stack member gets the file.  But with the "archive download-sw" automation command the stack master will automatically determine how many members in the stack and, most importantly, at the end of the execution of the script will tell the operator if the IOS was pushed successfully or not.  

[Terence Lockette]

Leo,

Thank you for the feedback and insight to this problem.  I will attempt to update the IOS using this method instead and will provide an update and mark your response as correct if it works for me.

Thanks again,

Terence

[Terence Lockette]

Leo,

I tried using the archive command to push the IOS to all switches in the stack and it worked.  However, when I issued the reload command, both switches booted up independent of each other just like when I copied the .bin files to each flash file system.  Once again, I had to drive over an hour to get the switches back online.  I did this simply by removing the power cords and reconnecting them by doing the master switch first followed by the member switch.  I guess my solution to this would be to connect the switches to a network power strip so that I can power off/on the equipment the next time I need to upgrade.

[Leo Laohoo · Accepted solution]

Once again, I had to drive over an hour to get the switches back online.  I did this simply by removing the power cords and reconnecting them by doing the master switch first followed by the member switch.

Terence, 

This is due to CSCur56395.  I only found this out a week ago when I hit this as well.  The summary is this:  The switches will need a complete power reboot.

[Terence Lockette]

Leo,

Hopefully this will be addressed but the solution I'm putting in place using IP based PDUs will have to do for now.  Thank you for all your support and feedback.  I'm glad I'm not the only one to experience this.

Terence

[Leo Laohoo]

I'm glad I'm not the only one to experience this.

There are, as of today, 910 Support Cases.  I'd say this is one of Cisco's "most popular" bugs.  (Image below)