When clicking the upgrade button, customers are unable to pass the validation step. An error message states that there is not enough space on the disk. There are two directories being check for space in the Linux box:
The more common issue is that /opt/apache/tomcat does not have 2 GB of space left. As of now, the WAR files, as well as possible log files, are not being cleared out.
In order to clear out the WAR files, you can either use MSTRBak to create a backup, backup the snapshots from the AWS console, or use Remote Desktop Protocol (RDP) to connect to a environment from the Developer box and stop tomcat. Once tomcap is stopped, it is safe to remove the WAR files. Stopping tomcat and then manually deleting the WAR files poses a relatively low risk.
For older upgrades, the hotfix files were not cleaned post-installation. As a result, customers may still have hotfix files from previous upgrades in /opt/mstr/tmp. If there is a failure message that states the download files could not be added to the Linux box because the directory already exists, go into the Linux box, and delete the hotfixfiles directory under /tmp/hotfix_files. Reattempt the upgrade.
Note: If there is a developer box under this environment that successfully upgraded, you will need to roll back the environment and upgrade again.
The installation step fails more often than not, because the build files were not successfully downloaded. Check opt/mstr/tmp/Installations/QueryReportingAnalysis_Linux/ under your machine and verify that the build files and the setup.sh shell script exists. If they do not exist, it could be because of customized permission issues within the directories. If permissions have been changed to restrict additional files from being downloaded or executed, then this may be causing the problem for either the build files being downloaded in the first place, or being executed during the upgrade process. If permissions are fine but the files do not exist, there could be something wrong with the S3 bucket permissions. In this case, a tech support engineer or software engineer should be contacted.
It is highly advised to not manipulate directory permissions without /opt/mstr, as this can cause a number of problems down the line. If security enhancements of a customer include restricting the permissions of directories in /opt/mstr, the upgrade step can be problematic, specifically with the backup and restore scripts that be moving many files from the apache folder between directories. Verify that the permissions on the directories where files are being moved from have write and execute permission from user mstr.
