Overview

There is a known issue on Exinda firmware 7.6.3 (build 0169) where CPU utilisation can run higher than expected. The impact is most visible on low-end and mid-range appliances. Earlier firmware versions (for example 7.6.1, build 0143) are not affected, so downgrading is a valid mitigation while an updated release is pending.

A standard downgrade from 7.6.3 will normally fail (this is reproducible 100% of the time). The failure is caused by configuration-database module-version metadata written by 7.6.3 that the older firmware cannot load. This article documents the confirmed root cause and the supported workaround: install the older image, then correct the module-version metadata in the active config database before rebooting into the older version.

The procedure below applies when downgrading from 7.6.3 (0169) to 7.6.1 (0143). The same approach can be used to downgrade to other older versions; only the target image and naming differ.

In This Article

• Why the Downgrade Fails
• Prerequisites
• Downgrade Procedure
  • Step 1 — Install the older image (do not reboot)
  • Step 2 — Install the restricted-commands license key
  • Step 3 — Patch the active config database
  • Step 4 — Reboot
• Verification
• Additional Information
• FAQ

Why the Downgrade Fails

When Exinda 7.6.3 runs, it stamps newer module-version numbers into the active configuration database for several modules. When the appliance boots into 7.6.1, the older firmware reads the active config DB and rejects the configuration because the recorded module versions are higher than it expects, so the downgrade does not complete cleanly.

The workaround is to take a copy of the active config DB and rewrite the module-version metadata for the affected modules back to the values expected by 7.6.1, then point the appliance at that corrected database before rebooting. The affected modules and their target versions are:

Module path	module_name	module_version (target)
/snmp	snmp	28
/exinda/system/application	application_module	188
/exinda/system/application_group	application_group_module	132

Prerequisites

• Restricted-commands (restricted_cmds) license key. This is mandatory. The built-in internal command cannot be used here because it does not support modifying module versions. Request a key from GFI Support for the specific appliance; keys are issued individually and are valid for 1 working day.
• The target downgrade image — for this example, the Exinda 7.6.1 (0143) firmware image.
• CLI access to the appliance, via SSH or the web UI under Tools > Console.
• A maintenance window. The appliance will reboot at the end of the procedure.

Recommended: Back up the current configuration before starting. The procedure also creates its own copy of the active database (fixed761), but a separate full backup is good practice.

Downgrade Procedure

Step 1 — Install the older image (do not reboot)

Install the 7.6.1 (or other target) firmware image using the normal image-install method, but do not reboot yet.

Confirm the boot state before continuing. The currently booted version should still be exinda-v7.6.3 (0169), and the version set to boot next should be exinda-v7.6.1 (0143):

• Booted: exinda-v7.6.3 (0169)
• To boot next: exinda-v7.6.1 (0143)

Do not proceed until the "to boot next" image is correct.

Step 2 — Install the restricted-commands license key

Apply the restricted_cmds license key provided by GFI Support for this appliance. This unlocks the commands needed to modify the module versions in the next step.

Step 3 — Patch the active config database

From the CLI (SSH, or web UI Tools / Console), run the following commands one by one, in order.

Enter privileged mode and drop to the shell:

en

_shell

Identify the active config database and make a working copy of it:

A=$(cat /config/db/active); echo "source=$A"

cp -p /config/db/"$A" /config/db/fixed761

Rewrite the module-version metadata in the copied database for each affected module:

/opt/tms/bin/mddbreq -a /config/db/fixed761 set modify - /snmp value string /snmp /snmp module_name string snmp /snmp module_version uint32 28

/opt/tms/bin/mddbreq -a /config/db/fixed761 set modify - /exinda/system/application value string /exinda/system/application /exinda/system/application module_name string application_module /exinda/system/application module_version uint32 188

/opt/tms/bin/mddbreq -a /config/db/fixed761 set modify - /exinda/system/application_group value string /exinda/system/application_group /exinda/system/application_group module_name string application_group_module /exinda/system/application_group module_version uint32 132

Point the appliance at the corrected database by making it the active one:

echo fixed761 > /config/db/active

Important: Run each command individually and confirm it returns without error before moving on. Do not skip the copy step — always edit the copy (fixed761), never the original active database directly.

Step 4 — Reboot

Reboot the Exinda appliance. It will boot into 7.6.1 (0143) using the corrected fixed761 configuration database, and the downgrade will complete successfully.

Verification

• After reboot, confirm the running version is the target version (for example exinda-v7.6.1 (0143)).
• Confirm the appliance loads its configuration without errors and that previously configured policies, application objects, and SNMP settings are intact.
• Monitor CPU utilisation to confirm it has returned to expected levels for the appliance class.

Additional Information

• Downgrading to a different version: The same method works for other target versions. Install the desired image in Step 1, and in Step 3 set the module_version values expected by that target version. Name the working copy appropriately (the name fixed761 is only a convention for the 7.6.1 example).
• Why not the internal command: The internal command cannot modify module versions, so a restricted_cmds key is required. There is no way to complete this with internal alone.
• Key validity: Restricted-commands keys are issued per case and expire after 1 working day. Plan the maintenance window so the patch and reboot are completed while the key is valid.
• Root cause: The elevated-CPU behaviour is a known issue specific to 7.6.3 (0169). Older versions do not exhibit it. A permanent fix should be tracked in the relevant engineering ticket; downgrading is a mitigation, not the final resolution.

FAQ

Q1: Can I downgrade from 7.6.3 without the restricted-commands license key?
A1: No. The standard downgrade fails because of module-version metadata written by 7.6.3, and the fix requires modifying those versions with mddbreq, which needs a restricted_cmds key. The built-in internal command cannot modify module versions.

Q2: Why does the downgrade fail in the first place?
A2: Version 7.6.3 stamps higher module-version numbers into the active configuration database for the snmp, application_module, and application_group_module modules. When the appliance boots an older firmware, that firmware rejects the configuration because the recorded versions are higher than it supports. Rewriting those versions to the values the older firmware expects allows the configuration to load.

Q3: Do I edit the live active database directly?
A3: No. Always copy the active database first (the cp -p step creates fixed761), apply the mddbreq edits to that copy, and only then point /config/db/active at the copy. This preserves the original database in case you need to roll back.