12-29-2014 04:32 PM - edited 03-11-2019 10:16 PM
Hello all, I've been working on this issue for a few days and am running out of ideas. I'm looking for some direction at this point and to see if anyone has troubleshooting suggestions.
Environment: ASA 5520 pair running failover active/standby
Problem: After a reload or power off/on, the pri/standby ASA will POST, provide the option for ROMMON, then attempt to boot from disk0 and finally hang on
'Loading disk0:/asa842-k8.bin...'
How it started: I incorreclty attempted an IOS upgrade on the standby first. I attempted to upgrade the IOS by deleting the original image file (asa842-k8.bin) and copying over tftp the new image on the standby. I issued the 'boot system...' command for the new image and then write mem MISTAKENLY on the secondary. This caused the pair to break failover. Reloaded, the standby ASA never came back online. After console in I found it hanging on the loading error for the new file.
What I have tried:
1. Reloaded and entered ROMMON. I loaded the original image off TFTP using the management port, the ASA booted, replicated with the mate and showed as part of the failover running a 'show failover'.
2. Copied the original IOS image asa842-k8.bin onto flash and verified the md5. Verified boot parameters on active and standby ASA. Verified .bin file on active and standby ASA. Reloaded pri/standby ASA. Same issue, hangs.
3. Downloaded the original .bin file from Cisco site and copied to disk0 on pri/sec, verified md5, reload standby. Same issue, hangs. Reload to ROMMON, download using tftp, boots, replicates, ok. Reload standby, same issue.
Some output:
ASA-Firewall/sec/act# sh boot
BOOT variable = disk0:/asa842-k8.bin
Current BOOT variable = disk0:/asa842-k8.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
ASA-Firewall/sec/act# sh disk0
--#-- --length-- -----date/time------ path
... other stuff
128 25159680 Dec 24 2014 10:46:15 asa842-k8.bin
... other stuff
62947328 bytes total (2797568 bytes free)
ASA-Firewall/sec/act# failover exec mate sh boot
BOOT variable = disk0:/asa842-k8.bin
Current BOOT variable = disk0:/asa842-k8.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
ASA-Firewall/sec/act# failover exec mate sh disk0
--#-- --length-- -----date/time------ path
... other stuff
106 25159680 Dec 24 2014 10:50:08 asa842-k8.bin
... other stuff
63035392 bytes total (2971648 bytes free)
Does anyone have any suggestions on what to try? I'm just listing the major things I've tried but nothing has worked. I've tried booting from different .bin files with same results. I've booted from the actual original file and a re-downloaded file from cisco site with same results. I haven't had any other error messages when working with flash, no copy errors or anything. TFTP load from ROMMON works every time. Cisco wants to replace the ASA but it doesn't appear that this is a hardware failure so I'd rather try and solve the problem with equipment in place. Any help would be appreciated.
Regards,
Chris
12-29-2014 06:07 PM
Hi Chris ,
At this point , I would try to format the flash
ciscoasa# format disk0:
ciscoasa# fsck disk0:
Copy the image again and try boot up the ASA.
As well you can follow the procedure on the following document:
http://www.cisco.com/public/technotes/smbsa/en/us/remote/5500_image_rcvry.pdf
If no luck , this may end up in a RMA of the ASA.
Please rate helpful posts !
Hope it helps
- Randy -
01-01-2015 05:59 AM
I would suggest running a filesystem check before formatting the flash. This will in most cases identify and correct issues with flash.
fsck flash or fsck disk0
--
Please remember to select a correct answer and rate helpful posts
01-02-2015 08:32 PM
if none of the other suggestions work, try pulling the memory modules one-by-one, and booting the device and/or swapping with another known working 5520. this smells like a problem I had whereby a long-running ASA would not boot. I went around in circles, only to find out that the DRAM (not the flash!) was bad!
Had the problem on two ASA 5520's actually. Ordered new memory from crucial.com (by giving them the spec's off the original sticks (which were made by micron - same company).
This was honestly one of the most stupid problems I had in a while, as it appeared like a flash problem, but really was a DRAM problem.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: