Network Management

Hi,

After the airwave server upgrade  from 7.3.8 (64bit) to 7.5.5 (64bit) ( installation succesfull ) the following message appears ;

login as: root
root@192.168.1.76's password:
Last login: Sat Sep 29 02:09:32 2012 from 192.168.1.66
SVN Root: http://svn.corp.airwave.com/usr/local/svnroot/mercury/tags/RELEASE_7_5 _5

Daemons:
PID PPID PGID %CPU %MEM RSS ELAPSED CMD
3363 1 3363 0.2 0.4 9504 00:28 Daemon::LowLevelServiceWatcher
3266 1 3266 0.0 3.9 82328 00:29 radiusd
2930 1 2930 0.0 0.0 948 00:46 rrdcached

** Look out: /etc/amp_disabled
Current Version: RELEASE_7_5_5
DISABLED - 2!!
[root@localhost mercury]#

What does it mean  DISABLED - 2!!  ? What should I do to bring the server up and running.

Best Regars,

All it means is that a disable message has been passed twice without an enable message. To resolve:
# amp_enable -now
or
# amp_enable
until counter reduces to nil (when message no longer appears)

I'd also suggest possibly having a conversation with support to find out how you got to that state. Did you follow the upgrade steps properly? Did you also upgrade your OS?

I'm have a similar problem with a customer's upgrade where I had to upgrad the OS from CentOS 5 to 6.  We followed the PDF instructions to use the same version of AMP but with the updated OS version.  After the restore, we were able to get 7.6.3 (current customer version) to come up with the newer OS and log into the GUI.  We then ran the 7.7.3 upgrade via the amp_upgrade command in the CLI.  The upgrade seemed generally successfull but with the "DISABLED - 2!!" messages which I cleared but the GUI still won't come up.  I'm happy to work with support but know enough about Linux to poke around in it if I knew what commands and directories that were specific to troubleshooting AMP.  Then I wouldn't have to bother support unless it was really mucked up.

Typically, the upgrade log will show a crash when the upgrade fails.  Upgrade log lives in /var/log/upgrade, and a crash will typically be 2-5 lines long with some form of the word 'error' in it.  Grepping the log for 'error' may get you to the line, but it will also get you several lines for log files that have the word error in it.  You would do better to open the log, jump to the bottom and then page up once or twice to find the crash.  Then based on the nature of the crash, you'll find that most upgrade issues are either RPM update issue or migration issue (database updates).  RPM update issues are typically a matter of yum installing the right package.  While migration issues are probably better worked out through support.

In this case, the issue ended up being a resource allocation issue on the VM.  I assumed the customer had built the new VM with the same or greater specs than the original VM.  They did not, in fact they used very diminished specs, which ultimately caused the failure(s).  Once corrected and the VM was rebuilt the install and upgrade went well.

... now, if I can just get AWMS 7.7.3 to import configs for the new 7200s running AOS 6.3 w/AP225s... (in process and off topic a bit, sorry)

Thanks for the update.  The installation case allows for some very minimal installs.  It's pretty hard to capture a hardware sizing deficiency, though you have a better chance if you get in the habit of running the show_tech_support script.  Another thing to do is get in a habit of checking the System -> Performance page, there you can see the allocated resources that are visible to the AMP.