Catalyst 6506 MSFC Issue

who · ‎08-16-2002

I have Bootloader and MSFC Images on Catalyst 6506 switch. When the image corrupted. The MSFC will not bootup with bootloader automatically. I have both statements that point to both images in my configuration. When the image corrupted, the MSFC just keep like LOOPING, and will not be able to go to BootLoader image. Any suggestion?

Prashanth Krishnappa · ‎08-16-2002

Set up a bootldr variable using

6506-12a(config)#boot bootldr bootflash:

Also set the config-register to 0x2102

who · ‎08-16-2002

The following line already added.

6506-12a(config)#boot bootldr bootflash:

Config-register already point to 0x2102

Also set the config-register to 0x2102

efrahim · ‎08-16-2002

Sometimes it happens, even though the bootloader is there, but somehow the msfc still goes into loops, at that time like you have to break the loop,sending the break signal, and bring the MSFC into ROMMON, and boot the MSFC using the boot image and then delete the image ad even sometimes, you have to take out the bootflash SIM, to make it work again as mentioned in this document.

http://www.cisco.com/warp/customer/473/124.html

Prashanth Krishnappa · ‎08-16-2002

If you have the correct bootvariables, it should boot fine. Can you paste the outputs of dir bootflash:, sh bootvar and sh ver

who · ‎08-16-2002

I already verify all bootvar and bootflash:, Erum Frahim also posts same issue happening sometimes. This is not the first time it happens, and we have to send a tech out there to do "Missing MSFC recovery". We are still looking for the cause of this.

Prashanth Krishnappa · ‎08-16-2002

There is no "known" reason for the MSFC to behave this way if it has correct bootvariables and valid IOS files. If this is happening often, I suggest that you contact TAC

who · ‎08-16-2002

We simulate the issue by tftp a corrupted image and good bootloader, and have the bootvar point to the bootloader. It will go to a LOOP because of the corrupted image. Recently, we have TAC cases open and do some MSFC recovery. We want to find out the cause to avoid this happening, because we need to send out a tech everytime time happen. Thanks.