Going back to the beginning

"I am waiting for you, Vizzni! You told me to go back to the beginning, so I have. When a job went wrong, you went back to the beginning!" - Inigo Montoya, Princess Bride -

Today's topic is a lesson in Change Control, sort of. More like Pre-Change Control.

Most manufacturers post their upgrade instructions. Some of these instructions are fine. Some are even exceptional. But few manufacturers offer instructions for how to downgrade their code. Yet, if an upgrade goes wrong, you will probably want a fall-back plan, to get you back where you were, at least until you can get the vendor to help past the problem(s).

Most console server devices store their OS and boot files in FLASH. But many of them cannot store more than one version of the OS in the on-board FLASH at a time. So, the upgrade process will overwrite the old version. If you plan to revert to the original version, you need to gather a few things before you start;

• A copy of the current code version
  (You may be able to TFTP the file to a server from the device!)
  
• At least a byte-count for the installed currently installed version
• Better is to have the MD5 checksum hash for the currently installed version

A timestamp for the currently installed version may not be very useful, because many devices display the current system time for the files in FLASH. Even if the device displays an older timestamp, it's often the date the code was installed, and not the datestamp of the file was created. Still, if your device gives you older timestamps, it's worth noting the date and times of all of the files in your FLASH, before you start, so you can compare them at the end of the process.

If your device has MD5 implemented, so that you can check the new version for integrity, you should also use MD5 to display the checksum for the current version before you start. (If you need to load the old version back again, you should know what the checksum will be.)

You keep all of the software CDs that came with your devices when they are new, right? (At least ONE copy for each platform, and for each different software version as you collect them.) You should also mark them (the CDs, Manuals, etc.) for the software version they contain. The cost of a bookcase is cheaper then an evening of your wasted time because you cannot easily find the information you need.

"But my vendor keeps all of this stuff on-line. Why bother to keep the old stuff?" you ask. Let me offer a few cases that happen more often than you might expect;

• The vendor goes out of business, and the website goes away.
• The vendor sells the product line, and the new vendor kills it off.
• The vendor gets acquired, and the old website goes away.
• The vendor decides old software is "support", and is worth money.
• Newer versions of software are too big to fit into the FLASH in your device.
• The upgrade instructions had a mistake.
• The new code doesn't like your old hardware.
  
• The vendor decides to remove old versions from the web, to encourage the adoption of newer versions.

You should make a habit of checking for newer coder versions, for all of the hardware devices you own. Read through the release notes, and decide if the code might be useful to you. If you might want to upgrade someday, collect the newer versions (the binary file(s), README file(s), and PDF documents, and any checksum files).

Keep the versions in separate directories, since sometimes the image names are identical, and you don't want to overwrite the old files when you add the newer files. Then, you will be ready to upgrade when the time comes, and you'll also be ready to downgrade again, if needed.

-Z-