This post is more than 5 years old
11 Posts
0
1843
January 6th, 2017 13:00
NetWorker Virtual Edition upgrade failure - "Failed to get package metadata"
I'm attempting to upgrade a 9.0.1 NetWorker Virtual Edition appliance using the newly release upgrade *.avp package from support.emc.com. The package has been downloaded and placed in the /data01/avamar/repo/packages directory (I had to create it) and MD5 checksum verified. The Repository tab of the https://hostname/avi UI picks the package up, but shows a "Rejected" message with "Failed to get package metadata" as the cause. Anyone else encounter this type of error? I've got SR 83973448 open but wanted to ping the community as well.
As a note, I was able to successfully do this in a vLab Flex environment last night, so it's definitely something with my other lab installation.
Regards,
Levi
Levi_Spears_EMC
11 Posts
0
January 7th, 2017 09:00
In case anyone else runs into this, the problem was due to a missing folder in the repo directory on my appliance. This is evidently something that has occurred on AVE appliances in the past, and the AVE / NVE share a common update / installer architecture. You can reference SR 83973448 if you have access to support.emc.com, but the issue was identified by reviewing the installation log, located at:
/usr/local/avamar/var/avi/server_log/avinstaller.log.0
The package repository structure looked like this:
/data01/avamar/repo/packages - no other folders
Once the package was uploaded, the following error is logged in the avinstaller.log.0 file:
SEVERE: Command: gpg --output /data01/avamar/repo/temp/NveUpgrade-9.1.0-91.avp_1483719820697/NveUpgrade-9.1.0-91.avp /data01/avamar/repo/packages/NveUpgrade-9.1.0-91.avp returned: gpg: error creating `/data01/avamar/repo/temp/NveUpgrade-9.1.0-91.avp_1483719820697/NveUpgrade-9.1.0-91.avp': No such file or directory
gpg: handle plaintext failed: No such file or directory.
I'm not sure of the OS user running the installer process, but it evidently didn't have permissions to create the ./temp folder. Manually created the /data01/avamar/repo/temp folder and assigned permissions to match the /packages folder (chmod 755). I'm not sure how to trigger the package scan again once it's failed, but simply using an OS mv command to move the file out of the packages directory and then back into it allowed the scan to rerun, after which the package was determined to be valid, and installation was available from the SW Updates tab in the installation manager UI.
HTH