I will second that statement without a doubt. We upgraded over 50
in-place production pm2's for a company that had them installed all
over the US, and had about a 20% failure rate. We used exactly
the same procedure at all locations, and the original equipment had
many different ComOS versions. We understood the two-step upgrade
process, the net boot process, versions of PMconsole, etc, very
well before starting.
We found the following to be true:
1. The more data that was passing through a particular pm2 at the
time the ComOS was downloaded, the greater the probability was
of the pm2 having a corrupted ComOS when rebooted.
2. When a download from PMconsole reports a "successful" upgrade,
the anouncement is not based on any form of valid binary
data checks (e.g., CRC of the transferred file).
3. The changes that have occured over time to the format of the
configuration data within the pm2 was not dealt with consistently
by the newer ComOS versions. The greater the difference
from the old ComOS to the newer ComOS in terms of version levels,
the greater the probability was of corrupted config data.
4. The only way to ensure 100% upgrade success in the shortest
period of time was to write all config parameters on paper, and
download the new ComOS while the pm2 was disconnected from all
other sources of data. Any other combination would result in
at least some corruption to either config data or to the ComOS
itself. Some of the corruption was not detectable until much
later.
This particular client was using just about every option provided
in the pm2 and pm2e including several forms of data tunneling
(from one pm2 to another), remote unix serial ports, ppp, etc.
Rich