Install add command for later reboot

[hafnerj]

We have multiple 9200,9300 & 9500 switches. According to the documentation the #request platform software is being depreciated for the #install add syntax. This is install mode. 

Prior to this we would load and install code and schedule reboots with the additional ability to allow power outages reboot the units for us. This allowed for minimal engagement when we could reset equipment. 

The problem I have is I cannot figure out how to do this with the #install syntax. I've been able to do an #install add randomly however it still requires the activate command at a later date which involves waiting up to three minutes before it ask you to reboot. This is problematic when you are working 20 switches at  time. We have over 300.  Is there a work around for this? 

We are using  16.12.4, through 17.3.4

[balaji.bandi]

I  may not or never tested this requirement, which means we are taking a chance that the switch may come up when the power outage occurs or maybe not. ( so this needs to take consider as a risk my point of view if we are working in a critical environment)

You may test this :

#install add file flash:cat9k_iosxe.bin activate commit

when it asks for reloading, say N, then test for one switch(remove the power and see if that come back as expected ?)

is this works for you ?

[hafnerj]

That does not work. 

[Georg Pauwen]

Hello,

what is the exact syntax you are trying to execute ? EEM scripts can be run at any scheduled time, and they also automate interactive command execution. So that could be an option...

[paul driver]

Hello

---

@hafnerj wrote:

The problem I have is I cannot figure out how to do this with the #install syntax. I've been able to do an #install add randomly however it still requires the activate command at a later date which involves waiting up to three minutes before it ask you to reboot.

---

try:
install add file xxxx activate commit 
or 
install add file xxxx activate reloadfast commit  ( fast software upgrade, if applicable

[hafnerj]

That just boots the switch in real time, please read my OP. 

[Leo Laohoo · Accepted solution]

9300/9300X and 9500 "vanilla" still support the old command:  

request platform software package  install switch all flash:<FILENAME> on-reboot new auto-copy verbose

NOTE:  

The "on-reboot" is a developer "type-o" and a bug, CSCve94966.  It is meant to be "no-reboot" and stops the switch/stack from rebooting after the package files are unpacked.  

For "consistency" purposes, 9200/9200L, 9500 (high performance) and 9500X support only the newer command:  

install add file bootflash:<FILENAME> activate commit

When this command is entered, it will ask for operator's permission to reboot the entire stack.  If you want to reboot the switch/stack at a later time/date, enter "N".  

1.  When the prompt appears, look for two files using this command:  

dir flash:*conf

2.  Notice the timestamp of the date of the "packages.conf" file and compare it to the other "conf" file with the updated package files.  3.  The contents of the packages.conf points to the current/existing firmware.  The other package file points to the packages you want to upgrade to.  What needs to happen is to rename the newer file into "packages.conf".

WARNING:  This process needs to be done to every switch member of the stack, including VSS pairs.  

4.  Rename the old "packages.conf" into something else:  

rename flash:packages.conf flash:packages.conf.0--

5.  If you have a stack of switches, the command slightly changes to:  

rename flash-X:packages.conf flash-X:packages.conf.0-- where "flash-X:" is the switch member number. 

6.  Next, rename that new "conf" file to packages.conf:  

rename flash-X:<FILENAME>.conf flash-X:packages.conf

7.  Check the boot variable string:  

sh boot

8.  Verify the contents of the packages.conf file and make sure it is pointing to the correct version you want to upgrade to:  

more flash-X:packages.conf | begin for CAT

8.  Schedule the reboot for a different time and date. 

NOTE:  
I upgrade our 9300 and 9500 (vanilla and high performance) and I do an "on the spot" upgrade/reboot (and I do not use PI nor DNAC either).  I always unpack the packages and set the reboot at a later time/date.  I use the above method for 9500 high performance and I never had a "failure" to boot the correct firmware version.  

[hafnerj]

That worked thanks. I upgraded and downgraded a switch using this info. A bit cumbersome but worked fine. Cisco needs to stop screwing around with capabilities, stop thinking like  programmers and more like on hands engineers 

[Leo Laohoo]

---

@hafnerj wrote:

That worked thanks. I upgraded and downgraded a switch using this info. 

---

The steps I have highlighted is not officially documented by Cisco.  I developed this myself. 

---

@hafnerj wrote:

Cisco needs to stop screwing around with capabilities, stop thinking like  programmers and more like on hands engineers 

---

Read the last sentence below:  17.7.X software introduces a new set of "install" commands that allow you to manage the platform easily.

 

As of today, 21 March 2022, the "new set of install commands" is undocumented in the Release Notes (Release Notes for Cisco Catalyst 8500 Series Edge Platforms, Cisco IOS XE Cupertino 17.7.x).

[hemmerling]

I'm not sure what was wrong with the previous way of updating IOSes, the new way requires extra steps and adds the ability to make a typo that will stop the device from booting. It also isn't clear, when you type "N" it doesn't say, it was installed ok, or that if you jerk around with the .conf files you can make it boot on the new IOS, it just has a fit.
I'm also not sure how Cisco thinks we update their switches in the wild, but it sure isn't during the work day while we are sitting in front of it. We install the update, then set a reload outside of business hours. The new way of doing it shows that no one at Cisco understands that.
All your new method is going to do is push us back into bundled mode, where it's clear what is happening, I set it to boot from a .bin, it does that, not this 15 words and error message, then me playing with config.sys and autoexec.bat to get it to boot correctly.
You need to bring back "no-reload"" (or "on-reload" as the case may be)

This operation may require a reload of the system. Do you want to proceed? [y/n]n
FAILED: install_add_activate_commit /flash/cat9k-wlc.17.03.06.SPA.pkg /flash/cat9k-webui.17.03.06.SPA.pkg /flash/cat9k-srdriver.17.03.06.SPA.pkg /flash/cat9k-sipspa.17.03.06.SPA.pkg /flash/cat9k-sipbase.17.03.06.SPA.pkg /flash/cat9k-rpboot.17.03.06.SPA.pkg /flash/cat9k-rpbase.17.03.06.SPA.pkg /flash/cat9k-lni.17.03.06.SPA.pkg /flash/cat9k-guestshell.17.03.06.SPA.pkg /flash/cat9k-espbase.17.03.06.SPA.pkg /flash/cat9k-cc_srdriver.17.03.06.SPA.pkg: Cannot proceed activate because of user input

And what exactly does that look like when done on a stack, I haven't tried it, but I bet I need to rename the .conf file on each of the switches flash: directories don't I? 

[Leo Laohoo]

Only the 9300 and 9500 vanilla supports the "request platform software package install switch all flash:<FILENAME> on-reboot new auto-copy verbose" command.  The 9200, 9400, 9500 HP and 9600 will not/never support this.  As to why, I can only speculate that this has something to do with DNAC.