When the OS Install Software web interface appears to hang and not process requests to start an upgrade you may need to execute it from the command shell. I experienced this specific issue on upgrading CUCM 6.1(1) to 6.1(3). But, knowing how to do what you need to via the CLI is always a handy tool.
{readmore}
Usually the web interface is preferred for this operation because it provides status feedback while the CLI does not. However, I recently had an issue where the Install Software web interface was misbehaving and I couldn’t get anywhere. I could have restarted tomcat but why do that unnecessary step when you can use the CLI.
The main branch of the CLI that we work with is the ‘utils system upgrade’ CLI. Description of each of these commands is fairly well document in the CCO documentation. Check the Operating System Administration guide for your respective version.
What this blog covers is the order of execution for a software update. The commands seem to operate independently, but in reality they work in conjunction and must be executed in a specific order.
Assume that you have a host 10.10.10.10, which is an SFTP server and you are upgrading to Version 6.1.3 of CUCM from 6.1.1. You have done backups, control tests, etc. For whatever reason you either want or need to execute an install from the CLI instead of the web portal.
From the shell prompt:
1. First, we have to tell the host that we wish to start the upgrade process. This is done by using the ‘list’ command to provide information on the source host and path for the file
admin:utils system upgrade list remote sftp 10.10.10.10 userID /install/softwarefiles/
This command will then prompt you for the user ‘userID’ password. Once the password is provided, the CUCM/CUPS server will connect to the SFTP server and check for valid and signed files in the specified folder. Any valid files that are found are displayed.
2. Next, we need to retrieve the appropriate upgrade file. Again, from the command line:
admin: utils system upgrade get remote UCOS_6.1.3.1000-16.sgn.iso
Now, this is the bummer. The CLI will say that it is retrieving the file but give no other status information. If your SFTP server has a way to provide status of bytes sent, then I would look there. You could also look at the network activity on a host that isn’t doing much more than serving this upgrade file or you could step away. Watching a non-moving CLI will drive you crazy. The 6.1.3 upgrade is 2GB+ by itself.
3. Once the file is uploaded, we want to start the upgrade
admin: utils system upgrade start
You could also provide the “reboot” keyword at the end to force the system to reboot after the upgrade. I don’t do that myself.
The upgrade starts and you wait. 6.1(2) and 6.1(3) both take between 1 hour and 1 hour 15 minutes to complete. 4. Done. You now have an updated version in your standby partition. Check this with:
admin: show version active
admin: show version inactive
The one thing that the command guide doesn’t explain is that there is some global variable tagged when you start the upgrade process from the CLI. Executing the ‘list’ command gets it going and the SFTP server and path are temporarily stored in memory. You can confirm this by using the list command and then going to the OS web interface. In the web interface click on Install/Upgrade Software and the system will say “Upgrade in Process”. In fact, once you get an upgrade in process from the CLI, you can assume control and then complete the upgrade from the web interface (or visa versa).
In my case, I did the ‘list’ and ‘get’ commands from the CLI because my web interface was not playing nice. I then ‘Assumed Control’ from the web interface to execute the actual ‘start’ command. I liked the visual progress and live dump of the install log. I suppose you could get a live dump of the install log from the CLI by using the ‘file tail’ command in another ssh/console session. This is a separate topic for another day.