In-place Prime Upgrade fails

[DAVID]

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

[Bill Longman]

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.

[DAVID]

So I should be ok with doing the upgrade if I deleted the contents of the /tmp folder?

[Bill Longman]

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.

[DAVID]

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

[Bill Longman]

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>.

[DAVID]

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

[marce1000]

 - ade # sudo -s

   root # cd /tmp ; /bin/rm *

M.

[Bill Longman]

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.

[DAVID]

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.

[Marvin Rhoads]

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.

[DAVID]

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.

[marce1000]

 - 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.

[alois.heilmaier]

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/