Working on what should be a very straight forward task but becoming a nightmare. We have some ICX-7450 stacks (a 2x and 5x member stack). The task is to upgrade from 08.0.30t to 08.0.90a. Thought was to tftp the 08.0.90a code to the secondary along with tftp'ing over the new 10.1.15T boot loader.
The TFTP's complete successfully and a sh flash shows what one would think is a working configuration. Reboot the stack with the 'boot system flash secondary yes' command. Both units in the stack come up successfully. Here is where the frustration starts. Unit 2 reboots due to a stack election (not totally sure why the election occurs when the stack is already been working). Upon this second reboot the boot load reverts back to 10.1.06T and then gives a invalid bootm command and won't load the 08.0.90a code.
I have tried to update the uboot with the bootm functionality. Works once then reverts back again.
So I end up rolling the secondary back to 08.0.30t to get the stack stable again. I then try the same process but using the primary. Again upgrade seems to work but ultimately a unit in the stack reboot and reverts back to older bootloader and has bootm & kernel errors.
I can upgrade stand-alones all day long no issues, but stacks just aren't liking the 08.0.90a upgrade for some reason.
Anyone else seen this or have some suggestion to get past this?
I have not run into this issue, but that is a HUGE upgrade from 10.1.06T to 10.1.15T and from 08.0.30t to 08.0.90a. I generally always upgrade code before deploying new devices and at regular intervals, and I am certain more testing has taken place between each build family and the next build family of code.
Most of those didn't even ship from the factory with 08.0.30 builds but rather 08.0.60 originally, which doesn't support stacking... until 08.0.61 builds.
I would make sure you are in configure terminal when you tell it which flash image to boot. Then do a "write mem" before reloading.
Did you validate that it copied the image to all devices by doing a show flash?
Personally, I would probably jump build families in stages going to say 08.0.61x... Being sure everything works and saving the configuration again.
Then I would then jump to the 08.0.70 builds. Each family runs a pre-parse script and converts and changes the configuration a little. I am not 100% sure that 08.0.90 builds can pre-parse 08.0.30 configurations being how different they are for things like LAGs, Dual-Mode, and PoE
Honestly, it might be easier to export your configuration and compare it against your template to make everything you need for a clean reconfiguration.
Starting with 8.0.90 we introduced the UFI (Unified Fastiron Image). When upgrading from pre 8.0.90 code, you have to first upgrade to 8.0.90 and then do a second upgrade to 8.0.90ufi. If you skip the intermediate steps, it will look like the switch is upgraded but some features will not work correctly. The release notes and the upgrade guide cover the process in detail.
Honestly, the release notes are not very clear on this. All I could find is: "Any systems upgraded from 08.0.70 or earlier releases directly to 08.0.90 manually or using the manifest file must be upgraded a second time using the UFI image. If the upgrade is from 08.0.80, then use the UFI image"
Does the Manifest automatically use the UFI image? Clearly a "show version" will indicate if it installed the UFI build or not.
Please confirm this works perfectly fine from 08.0.80 builds to install 08.0.90c UFI by doing the Manifest installs such as: