Hotfixes and Line Modules

For line modules, a hotfix consists of one or more image fixes specific to a particular model of module or to a module type, depending on the fix. When a hotfix is activated, each image fix contained in the hotfix is activated on all applicable modules that are installed in the router. When existing line modules come online during startup and when new line modules are inserted in the chassis, image fixes for that particular line module are requested and activated during module startup.

Line module image hotfixes that have been armed as startup hotfixes are activated before application configuration occurs on the line module.

Only image fixes contained in hotfixes that are active on the primary SRP module can be activated on the line modules during startup. Hotfixes that are armed but not active on the primary SRP module are not activated on line modules.

A hotfix can contain a combination of image fixes. System controller (SC) and interface controller (IC) image fixes are cumulative and activated in the order in which they were armed. For forwarding controller (FC) image fixes, the last one armed is the only one applied.

Note: Because image fixes are activated in a particular order, we recommend that you create a list of any hotfixes that you are currently running or intend to run with a new FC image fix. JTAC can then provide you with the correct order of activation.

A hotfix cannot be partially activated on a router. If activation of any image hotfix fails on any corresponding module, the entire activation fails for all applicable line modules. Activation failure results in the generation of an appropriate log message. E-series routers do not support activation of a hotfix on a per-slot basis or a per-subsystem basis.

For example, suppose that a hotfix contains an image fix for the SRP module and the GE-2 line module. The SRP image fix is successfully activated on the SRP module, but the activation of the GE-2 image fix fails for some reason. In this case, the SRP module image fix is deactivated and no further attempts are made to activate the image fix on other GE-2 modules.

boot hotfix

• Use to arm the specified hotfix as a startup hotfix that is automatically activated the next time the SRP module reboots.
• Arming fails if the specified hotfix depends on a hotfix that is not already armed. In this event, the CLI displays an error message similar to the following:

  % The hotfix, 975, requires the following hotfixes to be armed:

  990

• Arming fails if the hotfix is not compatible with the armed release. The CLI displays the following error message:

  % Hotfix is incompatible with armed release.

• When a router reverts to its backup boot settings, as specified by the boot backup command, no armed hotfixes are activated. The armed hotfix settings are retained in the event the router reverts back to its normal boot settings.
• Example

  host1(config)#boot hotfix hf63037.hfx

• Use the no version to disarm a specified hotfix. You can disarm all hotfixes armed for all releases by specifying the all-releases keyword. If any startup hotfixes are armed, the CLI then prompts you to confirm the deletion,

  If the hotfix being disarmed is a dependency for another armed hotfix, the command fails and the CLI displays an error message similar to the following:

  The hotfix, 990, has the following armed dependents which must be disarmed

  first:

  975

  % Disarming failed

  When you disarm hotfixes that have dependencies, you must disarm them in the reverse sequence from which they were armed. However, if you have issued the all-releases keyword, the disarming automatically takes place in the correct order.

• See boot hotfix.

no boot hotfix all-releases

• Use in Boot mode to disarm all armed hotfixes for all releases.
• Example

  :boot##no boot hotfix all-releases

• There is no affirmative version of this command; there is only a no version.
• See no boot hotfix all-releases.

hotfix activate

• Use to manually activate the specified hotfix.
• Each image fix contained in the hotfix is downloaded from the local flash card to the SRP module and any corresponding line module, and then activated on the modules.
• When a new line module is inserted in the router, all applicable image fixes are activated during initialization of the module. Activation is performed by the line module operational image before application configuration takes place on the module.
• An activation failure for any image fix on its corresponding line module causes the entire activation to fail. The image fix is then deactivated on any modules on which it was successfully activated.
• Activation fails if the specified hotfix is incompatible with the running release, In this event, an error message similar to the following is displayed:

  % Hotfix is incompatible with running release.

• Activation fails if the specified hotfix depends on other hotfixes that have not been activated. The CLI displays an error message similar to the following:

  The hotfix, 975, requires the following hotfixes to be activated:

  990

  % Activation failed

• Startup hotfixes cannot be manually activated. If you attempt to manually activate a startup hotfix, the operation fails and generates the following error message:

  % Manual activation not allowed

• Example

  host1#hotfix activate hf63037.hfx

• Use the no version to manually deactivate the specified hotfix. Deactivation restores the system to the state that existed before the hotfix was activated. You can specify the all keyword to deactivate all active hotfixes.

  When you deactivate hotfixes that have dependencies, you must deactivate them in the reverse sequence from which they were armed. However, if you have issued the all keyword, the disarming automatically takes place in the correct order.

• See hotfix activate.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.