Revert or Uninstall

If an upgrade or patch succeeds but the system does not function to your expectations, you may be able to revert or uninstall.

Revert vs Uninstall

Whether you revert or uninstall depends on the release type.

Table 1. Revert vs Uninstall

Revert

Uninstall

Releases

Major and maintenance upgrades to Version 7.2+.

Patches.

Details

Returns the software to its state just before the last major or maintenance upgrade (a snapshot). For details, see Reverted Configurations.

Returns the software to the version you patched from. Does not change configurations.

Restrictions

Not supported for container instances. For more scenarios that prevent revert, see Revert Guidelines.

For scenarios where uninstall is not supported or recommended, see Uninstall Guidelines.

Revert/Uninstall From

Use Devices > Device Management to revert threat defense upgrades.

Use expert mode (CLI) on the device to uninstall threat defense patches.

Example: Revert vs Uninstall

Reverting after patching also removes the patch. For example:

  1. Upgrade threat defense from Version 7.2.0 → 7.2.5.

  2. Patch from Version 7.2.5 → 7.2.5.2.

  3. You can now either:

    • Uninstall the patch to go back to Version 7.2.5.

      This removes the patch only.

    • Revert the upgrade to go back to Version 7.2.0.

      This removes the patch and the maintenance release.

Revert Threat Defense Upgrades

Revert Guidelines

This section discusses general guidelines for revert. To check for version-specific revert issues, see the upgrade guidelines in the release notes: https://cisco.com/go/fmc-ftd-release-notes-74.

Reverting High Availability or Clustered Devices

When you use the management center web interface to revert threat defense, you cannot select individual high availability units or clustered nodes.

Revert is more successful when all units/nodes are reverted simultaneously. When you initiate revert from the management center, the system automatically does this. If you need to use the device CLI, do this manually—open sessions with all units/nodes, verify that revert is possible on each, then start the processes at the same time. Simultaneous revert means that interruptions to traffic flow and inspection depend on interface configurations only, as if every device were standalone.

Note that revert is supported for fully and partially upgraded groups. In the case of a partially upgraded group, the system removes the upgrade from the upgraded units/nodes only. Revert will not break high availability or clusters, but you can break a group and revert its newly standalone devices.

Reverting the Firepower 4100/9300

Reverting does not downgrade FXOS.

For the Firepower 4100/9300, major threat defense versions have a specially qualified and recommended companion FXOS version. After you return to the earlier version of threat defense, you may be running a non-recommended version of FXOS (too new).

Although newer versions of FXOS are backwards compatible with older threat defense versions, we do perform enhanced testing for the recommended combinations. You cannot manually downgrade FXOS, so if you find yourself in this situation and you want to run a recommended combination, you will need a full reimage.

Scenarios Preventing Revert

If you attempt to revert in any of these situations, the system displays an error.

Table 2. Scenarios Preventing Revert

Scenario

Solution

Revert snapshot is not available because:

  • You did not enable revert when you upgraded the device.

  • You deleted the snapshot from either the management center or the device, or it expired.

  • You upgraded the device with a different management center.

  • You reverted to the version you are running now (you are trying to perform multiple reverts in succession).

None.

The revert snapshot is saved on the management center and the device for thirty days, after which it is automatically deleted and you can no longer revert. You can manually delete the snapshot from either appliance to save disk space, but this removes your ability to revert.

The system only saves one snapshot. You cannot revert more than once, that is:

  • Supported: A → B → C → B

  • Not supported: A → B → C → B → A

Last upgrade failed.

Return the device to its pre-upgrade state by canceling the upgrade. Or, fix the issues and try again.

Revert is for situations where the upgrade succeeds, but the upgraded device does not function to your expectations. Reverting is not the same as canceling a failed or in-progress upgrade. If you cannot revert or cancel, you will have to reimage.

Management access interface changed since the upgrade.

Switch it back and try again.

Clusters where the units were upgraded from different versions.

Remove units until all match, reconcile cluster members, then revert the smaller cluster. You may also be able to revert the newly standalone units.

Clusters where one or more units were added to the cluster after upgrade.

Remove the new units, reconcile cluster members, then revert the smaller cluster. You may also be able to revert the newly standalone units.

Clusters where the management center and FXOS identify a different number of cluster units.

Reconcile cluster members and try again, although you may not be able to revert all units.

Reverted Configurations

Reverted Configurations

Configurations that are reverted include:

  • Snort version.

  • Device-specific configurations.

    General device settings, routing, interfaces, inline sets, DHCP, SNMP — anything you configure on the Devices > Device Management page.

  • Objects used by your device-specific configurations.

    These include access list, AS path, key chain, interface, network, port, route map, and SLA monitor objects. If you edited these objects after you upgraded the device, the system creates new objects or configure object overrides for the reverted device to use. This allows your other devices to continue handling traffic according to their current configuration.

    After a successful revert, we recommend you examine the objects used by the reverted device and make any necessary adjustments.

Configurations Not Reverted

Configurations that are not reverted include:

  • Shared policies that can be used by multiple devices; for example, platform settings or access control policies.

    A successfully reverted device is marked out-of-date and you should redeploy configurations.

  • For the Firepower 4100/9300, interface changes made using the Secure Firewall chassis manager or the FXOS CLI.

    Sync interface changes after a successful revert.

  • For the Firepower 4100/9300, FXOS and firmware.

    If you are required to run the recommended combination of FXOS and threat defense, you may need a full reimage; see Revert Guidelines.

Revert a Threat Defense Upgrade

You must use the management center to revert the device, unless communications between the management center and device are disrupted. In those cases, you can use the upgrade revert CLI command on the device. To see what version the system will revert to, use show upgrade revert-info .


Caution

Reverting from the CLI can cause configurations between the device and the management center to go out of sync, depending on what you changed post-upgrade. This can cause further communication and deployment issues.

Before you begin

  • Make sure revert is supported. Read and understand the guidelines.

  • Revisit the Planning Your Upgrade chapter. In general, prepare for reverting an upgrade in the same way you prepared for installing it. It is especially important that you back up to a secure external location. A failed revert may require a reimage, which returns most settings to factory defaults.

Procedure

Step 1

Choose Devices > Device Management.

Step 2

Next to the device you want to revert, click More (more icon) and select Revert Upgrade.

With the exception of high availability pairs and clusters, you cannot select multiple devices to revert.

Step 3

Confirm that you want to revert and reboot.

Interruptions to traffic flow and inspection during revert depend on interface configurations only, as if every device were standalone. This is because even in high availability/clustered deployments, the system reverts all units simultaneously.

Step 4

Monitor revert progress.

In high availability/clustered deployments, traffic flow and inspection resume when the first unit comes back online. If the system shows no progress for several minutes or indicates that the revert has failed, contact Cisco TAC.

Step 5

Verify revert success.

After the revert completes, choose Devices > Device Management and confirm that the devices you reverted have the correct software version.

Step 6

(Firepower 4100/9300) Sync any interface changes you made to threat defense logical devices using the chassis manager or the FXOS CLI.

On the management center, choose Devices > Device Management, edit the device, and click Sync.

Step 7

Complete any other necessary post-revert configuration changes.

For example, if you edited objects used by device-specific configurations after you upgraded the device, the system creates new objects or configures object overrides for the reverted device to use. We recommend you examine the objects used by the reverted device and make any necessary adjustments.

Step 8

Redeploy configurations to the devices you just reverted.

A successfully reverted device is marked out-of-date. Because the device will be running an older version, newer configurations may not be supported even after a successful deploy.

Uninstall Threat Defense Patches

Uninstall Guidelines

This topic discusses general guidelines for uninstall. To check for version-specific uninstall issues, see the upgrade guidelines in the release notes: https://cisco.com/go/fmc-ftd-release-notes-74.

Patches that Support Uninstall

Uninstalling a patch applies only to the software. After uninstalling a patch that updates the operating system or other components not reversed by the uninstall, you may be unable to deploy configuration changes, or you may experience other incompatibilities between the newer components and the older software. In these cases, we recommend you do not uninstall.

Because patches are cumulative, and because uninstalling a patch returns the software to the version you started from, we also recommend against uninstalling later patches if it will take you to a version earlier than the affected patch. For example, if Patch 5 updates the operating system, do not uninstall Patch 5, but also do not uninstall Patch 6+ if you started at Patch 4 or earlier (including the base version).

Specific patches that you should not install due to this or any other reason are listed in the release notes. If you need to uninstall one of these patches, contact Cisco TAC.

Uninstalling in Security Certifications Compliance (CC/UCAPL) Mode

If a patch updates the operating system and security certifications compliance is enabled, FSIC (file system integrity check) fails when the appliance reboots. The software does not start, remote SSH access is disabled, and you can access the appliance only via local console.

Uninstall is not recommended in security certifications compliance mode. If you need to do this, contact Cisco TAC.

Uninstalling Hotfixes and Hotfixed Patches

You must uninstall hotfixes and patches in the exact reverse order from their installation (last in, first out). For example:

  • Install: Patch A → Hotfix B → Hotfix C → Patch D → Hotfix E

  • Uninstall: Hotfix E → Patch D → Hotfix C → Hotfix B → Patch A

To view your update history, use expert mode: cat /etc/sf/patch_history.

Uninstall is not recommended for hotfixes and hotfixed patches. If you need to do this, contact Cisco TAC.

Uninstalling from High Availability or Clustered Devices

Minimize disruption by uninstalling from one device at a time. Unlike upgrade, the system does not do this for you. Wait until the patch has fully uninstalled from one unit before you move on to the next.

High Availability: You cannot uninstall a patch from devices configured for high availability. You must break high availability first.

  1. Break high availability.

  2. Uninstall from the former standby.

  3. Uninstall from the former active.

  4. Reestablish high availability.

Clusters: Uninstall from one unit at a time, leaving the control unit for last. Clustered units operate in maintenance mode while the patch uninstalls.

  1. Uninstall from the data modules one at a time.

  2. Make one of the data modules the new control module.

  3. Uninstall from the former control.

Scenarios Preventing Uninstall

You cannot uninstall a patch if you reverted to the version you are running now. Upgrading to a major or maintenance release deletes old patch uninstallers.

Uninstall a Threat Defense Patch

Use the Linux shell (expert mode) to uninstall patches. You must have access to the device shell as the admin user for the device, or as another local user with CLI configuration access. You cannot use a management center user account. If you disabled shell access, contact Cisco TAC to reverse the lockdown.


Caution

Do not make or deploy configuration changes during uninstall. Even if the system appears inactive, do not manually reboot, shut down, or restart an uninstall in progress. You could place the system in an unusable state and require a reimage. If you encounter issues with the uninstall, including a failed uninstall or unresponsive appliance, contact Cisco TAC.

Before you begin

  • Make sure uninstall is supported. Read and understand the guidelines.

  • Revisit the Planning Your Upgrade chapter. In general, you should prepare for uninstalling a patch in the same way you prepared for installing it.

  • Break high availability pairs.

Procedure

Step 1

If the device's configurations are out of date, deploy now from the management center.

Deploying before you uninstall reduces the chance of failure. Make sure the deployment and other essential tasks complete. Tasks running when the uninstall begins are stopped, become failed tasks, and cannot be resumed. You can manually delete failed status messages later.

Step 2

Access the threat defense CLI on the device. Log in as admin or another CLI user with configuration access.

You can either SSH to the device's management interface (hostname or IP address) or use the console. If you use the console, some devices default to the operating system CLI and require an extra step to access the threat defense CLI, as follows.

Firepower 1000

Firepower 2100

Secure Firewall 3100

Secure Firewall 4200

connect ftd

Firepower 4100/9300

connect module slot_number console, then connect ftd (first login only)

ASA 5500-X series

ISA 3000

—

Threat defense virtual

—

Step 3

Use the expert command to access the Linux shell.

Step 4

Verify the uninstall package is in the upgrade directory.

ls /var/sf/updates

Patch uninstallers are named like upgrade packages, but have Patch_Uninstaller instead of Patch in the file name. When you patch a device, the uninstaller for that patch is automatically created in the upgrade directory. If the uninstaller is not there, contact Cisco TAC.

Step 5

Run the uninstall command, entering your password when prompted.

sudo install_update.pl --detach /var/sf/updates/uninstaller_name

Caution

 

The system does not ask you to confirm. Entering this command starts the uninstall, which includes a device reboot. Interruptions in traffic flow and inspection during an uninstall are the same as the interruptions that occur during an upgrade. Make sure you are ready. Note that using the --detach option ensures the uninstall process is not killed if your SSH session times out, which can leave the device in an unstable state.

Step 6

Monitor the uninstall until you are logged out.

For a detached uninstall, use tail or tailf to display logs:

tail /ngfw/var/log/sf/update.status

Otherwise, monitor progress in the console or terminal.

Step 7

Verify uninstall success.

After the uninstall completes, confirm that the device has the correct software version. On the management center, choose Devices > Device Management.

Step 8

In high availability and clustered deployments, repeat steps 2 through 7 for each unit.

For clusters, never uninstall from the control unit. After you uninstall from all the data units, make one of them the new control, then uninstall from the former control.

Step 9

Redeploy configurations.

Exception: Do not deploy to mixed-version high availability pairs or device clusters. Deploy before you uninstall from the first device, but not again until you have uninstalled the patch from all group members.

What to do next

  • For high availability, reestablish high availability.

  • For clusters, if you have preferred roles for specific devices, make those changes now.