cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6625
Views
190
Helpful
27
Replies

CSCvn65598 - Write Mem command and ASDM load fails with "flash device is in use by another task"

Joe C
Level 1
Level 1

Not sure why this problem is taking Cisco so long to get a fix.  We've taken 3 firewall outages related to this bug and the problem description does not include additional details that could be very important.  In each outage the ASA "reload" command hung in shutting down the disk process.  As a result the only way to get the ASA to reboot was to issue a "reload quick" command.  Second, even though our ASA config was backed up to an external server, we LOST ALL CERTIFICATES as well as the SSH key after the reboot.  Fixing the SSH key was easy but we had to go out to our Certificate Authority to generate new certs which extended our outage.  BE SURE TO EXPORT YOUR CERTIFICATES prior to reload in case they are lost and you need to import them after the reload.

27 Replies 27

Thanks...we need some clarity on this bug.

Not a sales rep but our Cisco SE in communication with the TAC Sev 2 person assigned to my SR.

Our Cisco SE just got back with me to clear up the confusion on this bug.  It was Resolved in CSCvj28643.  This is a different bug, but this is what he was told from engineering.  Cisco is working to get the release notes updated.

ASA 9-8-4-7 Release note does not mentions anything about CSCvj28643 either. I also checked the other 2 bugid associated with CSCvn65598 and found nothing. I cannot find any description for CSCvj28643.



Any volunteers to test that version?


I was told yesterday by TAC engineer assigned to my Sev 2 SR that it's fixed in 9.8.4 versions and they were working on updating the release notes information and bug notes information.

Just received clarification from both my Cisco SE and the TAC engineer assigned to my SR.  Bug CSCvn65598 is ONLY fixed in 9.8.4.x versions.  All other 9.8.x versions do NOT have the fix.  The 9.8 release notes are still somewhat vague in that they show bug CSCvn65598 as open.  

Ive had an update from Cisco:

 

As per the developers, 9.8.4.8 will be the fixed for the bug (CSCvn65598). Which will be published on 07/24/2019.

That's great. However, our Cisco reps advised us strongly to NOT run anything in the 9.8(4) train as it's very broken in other critical areas. I do not recall the specifics off hand but the rep told us about 1 or 2 things then upon further research, 9.8(4) is not going on any device I manage

Thanks for the update.  My Cisco SE indicated a few weeks ago that even though 9.8.4 had the "flash device" fix that I should hold off because it has some VPN problems.  I will look at the 9.8.4(8) release notes when it comes out to see if the VPN problems have been resolved.

This is also affecting Cisco Adaptive Security Appliance Software Version 9.12(1)

Scenario:
-ASDM in launched and started to download updated software. 

-During this period, write memory returns 'The flash device is in use by another task.'

-If the boot system command is configured on the ASA and the ASA is reloaded whilst ASDM is still running whilst 'getting updated software', the device will not boot the first priority image and fall back to the secondary image.

-The boot system configuration, ASDM image and rest-api configurations are also cleared.

 

Regards,

Simon

did a reboot to clear the problem as other mentioned that it would do. Connected using ssh and did a write mem. The problem occurred right away - there were no other people connected either via ssh or asdm. Am not sure if it's the failover that replicate the config but when I log in the firewall that just got rebooted, it had the latest configuration saved - not just the running-config.

 

 

Ended up rolling back the upgrade and now I am back to normal. It is bad when a simple wr mem breaks the system. I always say that if something obvious is not caught in dev, what other hidden problems may be lurking out there?

 

What I don't understand is the problem seems to affect a bunch of versions and still has not been fixed yet. The bug ID says it is a severe condition, shouldn't Cisco do something about it.

I can tell you that when this happens in a failover config it creates a mess. We were not even sure what config it came back up with. However, a reboot of both boxes did resolve the issue and we should not recreate it until we uploaded a file with the ASDM.

A simple wr did not cause any harm for use, it was only when uploading a file using the ASDM that triggered the symptoms.