OmniSwitch 9702 Stuck in certified

[runtelldat]

Trying to update the AOS on this OmniSwitch 9702. I've tftp'd the files onto the /flash/working/ directory and am now unable to copy those files from the working directory to the certified directory. I seem to be stuck in certified mode.

reload working no rollback-timeout
-With this command; the switch reboots but doesn't boot from the working directory.

copy working certified
-Command doesn't work since I am in stuck in certified mode
--"ERROR: Invalid request, CERTIFY requested while running on certified"

write memory
-Unable to use due to directory
--"ERROR: Write memory is not permitted when switch is running in certified mode"

Modify
-The only available syntax after this command is "boot parameters"

How do I switch the running directory to "working" rather than "certified"?

Unable to post configs but can provide as much info as needed:

Current AOS version: 6.4.3.520.R01
Upgrade to: 6.4.3.884.R01

show running-directory:
Running CMM: Primary
CMM Mode: Mono CMM
Current CMM Slot: A
Running configuration: Certified
Certify/Restore Status: Certify needed

SO, the question is, how do I change the running configuration to Certified? Hi Silvio

[silvio]

now unable to copy those files from the working directory to the certified directory.

Normal behavior, because you have changed the images within working.

reload working no rollback-timeout
-With this command; the switch reboots but doesn't boot from the working directory.

one possible reason is, that the image file within working are corrupt....

copy working certified
-Command doesn't work since I am in stuck in certified mode
--"ERROR: Invalid request, CERTIFY requested while running on certified"

write memory
-Unable to use due to directory
--"ERROR: Write memory is not permitted when switch is running in certified mode"

Normal behavior too, because the switch has started from certified.

Try the following:
> copy certified working
than you can try write memory again.
For the update you need to copy the new image to flash/working again ... and reload working no rollback-timeout.

BR Silvio

[runtelldat]

Thank you Silvio!

I'll do a checksum to check for corruption...

So you recommend that I:
1. copy certified working
2. write mem
3. remove and re-tftp the images to /working again
4. reload working no rollback

In that order?

Also, could it be an issue that some of my images are newer and some are older?
My Jdiag.img, Jdni.img and software.lsm are from the previous version; while Jbase.img, Jadvrout.img, Jeni.img, Jos.img, Jesecu.img, Jencrypt.img are from the current version I'm attempting to update to.

[silvio]

Order is correct.
software.lsm is not important. diag you can leave too. But about the dni I am not sure. I do not know the function of this packet.
But normaly this shouldn't the reason for not starting. At the serial of the cmm you can look into the boot process. Maybe you can see there the reason for not starting from working.
BR Silvio

[runtelldat]

Viewed the boot process and found the following error:

Loading working /Jos.img...

2224302 bytes read
## Booting image at 010000 ...
Image Name: Jos.img
Verifying Checksum ... Bad Data CRC
Loading Certified /Jos.img

##Booting image at 01000000 ...
Image Name: Jos.img
Verifying Checksum ... OK

So, it is attempting to reload from working but the Jos.img that I uploaded appears to be corrupted or something.

image integrity-check
-This command doesn't appear to be available.

Also, are there any other consequences to the "copy certified working" command?

Thank you

[runtelldat]

***UPDATE***
Found the issue.

When TFTP'ing AOS image files; do not use the "ascii" syntax.

For example:
tftp [tftp Server IP] get source-file [filename] destination-file [file path] [binary|ascii]
--Omitting the last syntax will default to binary file format
*******************************************************************************************************************
For the uboot and miniboot update:
1. Transfer uboot.bin and miniboot.boot to /flash
2. Execute command "update uboot-miniboot"
3. When update complete; delete uboot/miniboot files from /flash
4. Execute "reload working no rollback-timeout"

Could someone provide insight as to why we must delete those files after transferring them? This doesn't seem logical.

[silvio]

you do not need to delete the files. But they are not longer necessary in the flash after the update command. With this command the files will be transfered to an other partition.
BR Silvio

[runtelldat]

you do not need to delete the files. But they are not longer necessary in the flash after the update command. With this command the files will be transfered to an other partition.
BR Silvio

Thank you Silvio!