JunOS SPACE upgrade to 16.1r2

These are my notes for upgrading JunOS SPACE from 15.2r2 to 16.1r1 or 16.1r2. They are meant to be consumed together with Juniper’s upgrade instructions. Since you are installing a fresh copy of JunOS SPACE as part of this upgrade, maybe now is also a good time to revisit some default settings.

  • 16.1 is the first release where the default partition sizes in the OVA are “sane”. The only partition you’ll need to add to is /var. It is 100GB large by default. An additional 250GB is fine for most installations; large installations with massive DBs might want as much as an additional 1TB.
  • You may not have enough space on the disk to take a backup using the 15.2r2 backup patch as long as OpenNMS remains enabled. In that case, disable it; then after reinstall and import, take additional steps to re-enable it. Disabling OpenNMS is done from Administration -> Applications -> Network Management Platform -> right-click and Manage Services
  • When taking the backup, I then opted not to backup PGSQL (that’s OpenNMS) and FMPM (since I happen not to have any FMPM nodes). This reduced the size to something manageable.
  • You may need the ServiceNow image file when taking the backup. If so, copy it to SPACE using command-line scp, then move it to /var/cache/jboss/jmp/Service-Now.VERSION (the backup process will tell you the exact location), and hit Enter to let the backup continue. For Service Now 16.1r1, the location is /var/cache/jboss/jmp/Service-Now.16.1R1.15
  • You will require an external scp server to copy the backup file to, or you can use a USB stick with FAT32 (no more than 32GB) if upgrading a JA2500 appliance.
  • Front USB is detected as /dev/sdb, use dmesg to make sure. Then mount:
    mkdir /tmp/pendrive
    mount -t vfat /dev/sdb1 /tmp/pendrive
    You can check with fdisk -l
  • To restore from USB, go through initial configuration.  When you come to restore choice (Remote, USB, Local), ssh to device and mount -t vfat /dev/sdb1 /tmp/pendrive, then use serial console to choose USB
  • If you don’t have an scp server, you can choose during backup; then copy the file over to the new server during restore and choose “Local”
  • You will need these things to configure your new SPACE instance:
    DNS server
    NTP server
    VIP IP
    Phys1 IP
    Phys2-N IP
    GW IP
    License File
    List of Apps
    admin password
    maintenance password
  • After restoration, adding space to /var etc, check the settings for Network Management Platform. “Allow device communication” may be off. Turn it on so devices will move to “Up” status.
  • For a secondary node, it doesn’t ask for NTP on initial setup. Set this and TZ manually. Once secondary node is up, you’ll need to add it from GUI as well.
  • Don’t forget chage admin and the ClientAliveInterval / ClientAliveCountMax in /etc/ssh/sshd_config
  • If you disabled OpenNMS before the backup, it won’t start after import. This is how you get it back in a default state.
    Disable OpenNMS from GUI
    service postgresql-9.4 status
    If it’s down: service postgresql-9.4 start
    Now to create the DB:
    service jmp-watchdog stop
    service jmp-opennms stop
    For the following, passwords are postgres and opennms respectively
    psql -U postgres -c ‘ALTER ROLE opennms SUPERUSER’
    psql -U opennms postgres -c ‘drop database opennms;’
    psql -U opennms postgres -c “create database opennms encoding ‘unicode'”
    psql -U postgres -c ‘ALTER ROLE opennms NOSUPERUSER’
    /opt/opennms/bin/install -dis
    service jmp-watchdog start
    Then enable OpenNMS from GUI



JunOS SPACE upgrade hangs at 0%

I attempted to upgrade a JunOS SPACE instance from 15.2R1 to 15.2R2. It would sit at “upgrade process has not started” and 0%. If I changed the URI to the base, I’d be back in the SPACE GUI as if nothing had happened and I had never entered maintenance mode.

This was caused by a failed upgrade months earlier which left a msg.<date> file behind in /var/jmp_upgrade/master/msg . Deleting that file allowed me to successfully upgrade the unit.

After a successful upgrade, the msg/ directory will be empty in both the master and slave directories.

In the process, I learned about a few more files that SPACE looks for. If these exist from a failed upgrade, they can keep a new upgrade from starting. Delete these if they exist:



You can find a clue as to why your upgrade is not proceeding in these two directories:



Look for log files named after the current and target SPACE version.

Also monitor this file for any issues with maintenance mode: