02-02-2018 05:50 AM - edited 03-01-2019 06:23 PM
It seems every time I want to do an in-place upgrade for Prime, the install fails with either the upgrade file is corrupt or disc space. However I checked and verified the MD5 of the file and free space is more than enough. I am running PI Enterprise on a VM and I am forced to standup a new PI VM and restore the backup the new VM. This happened when I wanted to upgrade from 3.1 to 3.2 and now it's happening again when I want to do an in-place upgrade from 3.2.to 3.3
02-02-2018 06:01 AM
One thing you have to do before upgrade is to check space in /tmp. It has to be absolutely clean. I've had the upgrade fail if there is not enough space there. I even mounted a new larger /tmp to get around it.
02-02-2018 06:08 AM
So I should be ok with doing the upgrade if I deleted the contents of the /tmp folder?
02-02-2018 07:46 AM
Well, that is at least one of the most common issues I've seen. You might have other issues, but clearing /tmp is the first thing to check.
02-02-2018 09:44 AM
I logged in to the PI shell and I can see the contents of the /tmp folder but I am unable to delete the files
02-02-2018 11:21 AM
Man...that hurts...kicked to the curb by Linux permissions... :-)
You can use sudo as the admin user, then the world is your oyster. Or the sky is the limit. Or <insert favorite metaphor here>.
02-02-2018 12:09 PM
I'm not as versed with my Linux skills as I would like so I am assuming that the delete command is run from the shell
RRSPRIME/admin# shell
Enter shell access password :
Starting bash shell ...
ade # sudo
usage: sudo [-D level] -h | -K | -k | -V
usage: sudo -v [-AknS] [-D level] [-g groupname|#gid] [-p prompt] [-u user name|#uid]
usage: sudo -l[l] [-AknS] [-D level] [-g groupname|#gid] [-p prompt] [-U user name] [-u user name|#uid] [-g groupname|#gid] [command]
usage: sudo [-AbEHknPS] [-r role] [-t type] [-C fd] [-D level] [-g groupname|#gid] [-p prompt] [-u user name|#uid] [-g groupname|#gid] [VAR=value] [-i|-s] [<command>]
usage: sudo -e [-AknS] [-r role] [-t type] [-C fd] [-D level] [-g groupname|#gid] [-p prompt] [-u user name|#uid] file ...
What is the syntax to delete all contents of the /tmp directory
02-02-2018 12:14 PM
- ade # sudo -s
root # cd /tmp ; /bin/rm *
M.
02-02-2018 12:53 PM
Myself I don't like to do that. If the cd fails, you remove *.
sudo -s cd /tmp ls -A #to make sure you are really there rm -rf ./* ./.??* #to remove local files only
ls -A #files should be gone
df -h #you need at least 2G free in /tmp
But to do this, you really should be in a shut down state, not with anything running, so there's a lot more to this than just removing the /tmp files. You really should do "init S"first before you remove the above files.
02-02-2018 03:25 PM
Thanks for all the help. Unfortunately I am going to try again to as I did not have the NCS services stopped before I deleted the contents of the /tmp folder. However, with that being said the upgrade failed once again stating either low disk space or corrupted file. It seems everytime I wanted to upgrade from 3.1, 3.2 to the next release I would run into the same issue. Also it seems that each new upgrade/install will somehow down the road require TAC assistance because of some bug in the database that never get resolved with patching.
The issues that are plaguing me with PI is the lack of data within the dashboards specifically the AP utilization when the controller syncs with no issues with PI but PI continues to be haphazard in whether it will show any historical AP utilization on any given AP.
02-03-2018 11:56 PM
Given the repeated issues you've encountered it may be better to start fresh.
Have you considered instead doing a backup of PI and then restore onto a newly-built VM (or re-imaged physical appliance)?
Even better, if you don't need historical data and reports, export your devices and maps and use that as the seed for a newly imaged installation.
02-04-2018 04:21 PM
If I do what you suggest this will make the second time. First from the upgrade from 3.1 to 3.2 and now from 3.2 to 3.3. I may just wait until PI 3.4 or later to see if it is even worth it.
02-04-2018 10:43 PM
- As stated by others, you must have some specific issue with your Prime installation, because this is not commonly seen. If you would like to pursue it further, you could again as root goto /localdisk/defaultRepo and cleanup everything in there (too); before the PI-Upgrade file is downloaded. If the upgrade fails because of a corrupt-installer-file error; one possible ding to do is to re-verify the md5 checksum in that directory when the installer file is downloaded as in root@cisco-prime # md5sum PI-Upgrade.... ; in such a way the integrity of the file can be checked on the Prime server itself (and or before an upgrade is attempted). M.
M.
10-04-2018 03:01 PM
you need not wait for PI 3.4 it also fails inplace upgrade.
Seems inplace upgrades do not work at all.
https://community.cisco.com/t5/network-management/upgrade-prime-3-1-to-3-4/
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide