05-12-2021 08:44 AM
Hello,
I recently tried to upgrade my ESA (virtual appliance) from 13.5.3-010 release to the latest GD release 14.0.0.682/
Once i download the stuff, and try to install , few seconds after i have the following kind of error (attached an extract)
I already tried this :
- retry (2/3 times) => failed
- reboot appliance ( 3 times) and retry => failed
- make more space available ( > 50 go avaialble) - reboot and retry => failed
- tried the same on another ESA virtual applaince which host the same config => failed
I've seen on forum some people experienced this issue with previous release (https://community.cisco.com/t5/email-security/upgrade-esa/td-p/4031552 ) , which has not been my case. it seems they succedded after several times of reboot/retry.
did someone already experienced this issue with this release or another one , and find or received a explananation/answer from support?
Best regards,
Solved! Go to Solution.
05-12-2021 01:13 PM
That behavior was already noticed by TAC engineers and the following defect was filed:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvy23969
It happens with older images in which this built-in partition is not big enough to handle the upgrade image of v.14.
Workaround is to download a newer image from Cisco website, transfer configuration while the two vESAs are on the same version and upgrade the newer image, wipe the old one if you like to.
05-12-2021 01:13 PM
That behavior was already noticed by TAC engineers and the following defect was filed:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvy23969
It happens with older images in which this built-in partition is not big enough to handle the upgrade image of v.14.
Workaround is to download a newer image from Cisco website, transfer configuration while the two vESAs are on the same version and upgrade the newer image, wipe the old one if you like to.
05-14-2021 05:47 AM - edited 05-14-2021 10:52 AM
To clarify, you're saying there will be no fix to permit virtual ESAs to upgrade to AsyncOS 14 if they were built using an older virtual ESA image (i.e., version 9.x or below)? So, it is therefore necessary to deploy new virtual ESAs with a 13.x release image to upgrade to AsyncOS 14? We have two clusters with ten virtual ESAs in each. You're saying we will need to rebuild each of these virtual ESAs using a newer image so that we can upgrade to AsyncOS 14?! That's quite a bit of work, so I want to be sure I understand what is going to be required to move forward. There is absolutely no way to add space where it is needed to overcome this issue?
05-21-2021 10:28 PM - edited 05-22-2021 08:57 AM
I ran into the same error and found a reference to the bug. Well and sigh... This is stupid, frustrating and outrageous. It is easy to give an advice like this, just reinstall it and then you are golden. What about licenses, what about quarantines, what about logs, how am I supposed to transfer them from the old appliance to the new one ? I'm seriously hurt by such a bug. And I'm in a position to influence my current and potential other clients not to look into renewing subscriptions with Cisco Email security just because of that and many other unfulfilled promises to fix the product and implement feature requests. And I can feel it for the previous poster with a cluster of ESAs. This is hell of a work just because product developers don't allow access to the file system and delete older images and files associated with them.... I'm seething slowly...
05-27-2021 06:23 AM
Hopefully a fix will be available by mid of June with a refresh build.
Will keep you guys posted on the development.
06-06-2021 11:54 PM
It seems that bug CSCvy23969 is now in the state of "fixed". Does that mean that there is now a build of AsyncOS 14 that can be upgraded from these old images? Currently my systems see only the old build 14.0.0-692 that cannot be used on these systems.
FYI: old installs of C000V (Lab environment) show for "ipcheck"
Root 400MB 52%
Nextroot 400MB 109%
Var 400MB 4%
Log 179GB 16%
DB 2GB 0%
Swap 6GB
Mail Queue 10GB
New installs:
Root 4GB 8%
Nextroot 4GB 6%
Var 400MB 4%
Log 172GB 11%
DB 2GB 0%
Swap 6GB
Mail Queue 10GB
Best regards, Matthias
06-07-2021 12:45 AM
@SriramV thanks for your last answer , but do you have more info about availability of this fix? I checked right now and i've the same partition size as @Matthias Geiser (400MB , 108%) . Even if i've replied at first the "workaround" can be an accepted solution and do a fresh install is sometimes really relevant, i'm also convinced it can be technically solved by a good fix...and if it's the case maybe i'll not need to take times and reinstall all my ESAs....
06-07-2021 02:14 AM
Unfortunately there is no workaround for this issue.
As you would have notices, bug CSCvy23969 is in fixed state.
As updated in the above post, a refresh build will be available by mid June, I don't have another update for now.
06-17-2021 05:57 AM - edited 06-17-2021 06:08 AM
There is a way to migrate the spam quarantine to a new appliance:
https://community.cisco.com/t5/email-security/backup-move-quarantine/td-p/2921836
07-06-2021 02:34 AM
Hi, good news, The issue is fixed in phoebe-14-0-0-698 build.
07-06-2021 10:10 AM
07-06-2021 10:27 AM
07-06-2021 11:31 PM
07-07-2021 06:54 AM
Could you run the ipcheck command and share what is displayed for the nextroot value following the update?
07-07-2021 08:54 AM
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