Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

IOS-XR Install FAQ


This guide is meant to provide answers to some of the common install questions and provide a basic overview of the install architecture XR employs.

Basic Concepts

How is installing and upgrading IOS-XR different from IOS?

IOS runs a monolithic kernel and a single .bin file. XR runs a microkernel and uses packaging, similar to Linux, to allow the user to choose which features they want loaded and to enable patching of individual components through SMUs. Upgrading IOS involves putting a new .bin on the device and reloading. Upgrading XR is done through an upgrade process.

What are all the packages?

This is published in the release notes

See as an example

From time to time there have been minor differences such as integrating the FPD package into the mini.pie file and taking lawful intercept out of the mini file, but for the most part this list does not change. Note that the mini package is a composite package with multiple packages such as OS, admin, base, and forwarding included.

How do we perform a clean install?

The mini.vm is used for turboboot. See for more information on turboboot.

How do we upgrade?

Upgrades are performed using, at a minimum, the install add, install activate, and install commit commands. It is recommended to check the upgrade guides listed here for any caveats and more detailed steps.

What is install add?

Install add decompresses the packages into memory on the dSC and then concurrently writes to the boot device of all management nodes, typically disk0:.

Examples of management nodes would be RSP0, RSP1, SC0, and SC1. Note that SCs are used in CRS multichassis.

The opposite of this is install remove which also has no impact.

Why do we do install add?

This is a way to prepare the router for upgrade without affecting the running executables, this helps to divide the install process into three basic phases. It is recommended to perform install add before the maintenance window.

How do I remove all inactive packages?

    While some people may wish to keep multiple install points on the router, other people may prefer to remove anything not currently used.

    We can remove all packages which are 'added' but not 'active' via 'admin install remove inactive'

What is install activate?

This is where all the magic happens! Install activate changes what executables the router is running. Depending on the type of SMU/upgrade method the effects of the install could be hitless, a process restart, router reload, or ISSU.

Note: The opposite of this is install deactivate and has the same implications, meaning a reload may happen.

What is install commit?

This is how we keep the running packages persistent across reloads after performing an install activate/deactivate. This command is much quicker than install add or activate as only metadata has to be updated. There is no impact on the currently running packages. Note that during a maintenance window this can be omitted until the end just in case a rollback might be needed, with this a reload of the router will cause the router to go back to the previous code.

How do we downgrade?

Downgrades are essentially the same process as upgrades but with different caveats for different releases. In some cases we can just reload the router, if install commit has not been used, or even use a rollback.

One thing to remember is that PX code cannot be downgraded to P. This is the case with CRS-3 -> CRS-1 and ASR9K 4.3.0+ -> pre-4.3.0. On CRS any PX component requires the PX image, that being the fabric, LCs, or PRP, or from 4.2.0 onwards. On ASR9K PX pre-4.3.0 is only needed for the RSP440, starting with 4.3.0 both P and PX based systems will use PX.

How do we patch the router in XR?

Patching is done through the concept of SMUs, see for more information. To summarize a SMU is a patch which changes a few lines of code in a particular component. C-SMUs, umbrella SMUs, and service packs touch multiple components.

Common Questions

Can I move the install add process outside of a maintenance window?

Yes, we recommend this to save time.

How do I upgrade an nV Edge system?

The upgrade of an nV Edge System can be through regular install and having both racks reload at the same time, or through the use of the nV Edge Upgrade script which is recommended for many reasons.

See for more information.

Is ISSU supported?

The short answer is no. The longer answer is that we do support release to release ISSU for some releases, and we have been increasing the number of SMUs which are ISSU. NG-XR (NCS6K) will support full ISSU. Support can be found here for ASR9K.

How do I know if I need a particular SMU?

Recommended SMU packs, C-SMUs, umbrella SMUs, and even service packs should be considered a minimum. Beyond that it is recommended to use the CSM tool to determine what you need.

What is CSM?

CSM is Cisco Software Manager and can be used to manage SMUs and be alerted when new SMUs are posted. This tool can be downloaded from the downloads section on

What is a Service Pack?

A service pack is a collection of every SMU to-date for a particular release rolled up into one package. The advantage of service packs, for some, is that it makes patching easier and less trivial. The downside is that once you go to service packs you have to stay with service packs. More information to come soon.

How can I monitor the progress of an install?

When starting an install operation (e.g. add, activate, commit) the synchronous keyword can be given and allows the install operation to complete before the CLI prompt is returned. If the synchronous keyword is not given then the CLI prompt is returned and the install happens in the background. If you then want to see the progress of an installation when in asynchronous mode use ‘show install request’ or attach to the install operation with ‘install attach’ which is similar to using the synchronous keyword.

Can I upgrade and install SMUs at the same time?

Yes, this really comes down to disk space and dependencies though.

Can I upgrade the FPDs at the same time?

Yes, as long as the current release you are running supports auto-FPD.

How do I check the reload type for a SMU?

This information is in the readme file for the tar but also can be checked via CLI.

Before performing install add this can be checked with 'admin show install pie-info <filename> detail' under 'Restart information'

If the install add has already been performed then 'admin show install package <package> detail' can be used

How do I abort an installation?

If the synchronous option was used then hit 'ctrl+c'

If asynchronous mode was used then we can use 'admin install abort'

Note that only activation, deactivation, and rollback operations can be aborted.

How can I verify packages on the router?

If for some reason it is suspected that corruption might have taken place then 'admin install verify' commands can be used to determine this, and can even repair the corruption in some instances. This is typically used by TAC.

Can I turboboot the standby RP?

No, once an RP is active and the dSC all other RPs in the same or different chassis will look to the dSC for information on booting. The dSC is determined on bootup of the entire system. Once an RP finds that they are not dSC they will sync packages, meta-data, and configuration files as needed.

How do I find the MD5 of a file?

While install does automatically detect and validate the MD5s this can also be done with ‘show md5 file’ using the absolute path.

An example would be:

RP/0/RSP0/CPU0:ASR9001#show md5 file /harddisk:/asr9k-asr9000v-nV-px.pie-4.3.1

Tue Feb 11 16:46:19.069 EAST



Tips and Tricks

  • Install activate can use a wildcard such as ‘harddisk:*4.3*’ when specifying the packages to activate. Note that this can cause issues if not done properly and I do not advise using this.
  • Use the install ID created from the install add when doing install activate, this reduces any possible typos.
  • The ‘source’ option can be given in the install add command to reduce the CLI length and any possible typos.
  • Starting in 5.1.1 an upgrade can take place which is not 1:1. Normally to upgrade from the current software to a newer release we must, at a minimum, upgrade all packages, we cannot leave out any v2 (new) packages if a v1 (old) version is installed. Using the 'ignore-pkg-presence-check' option with install activate we can now upgrade to v2 without having all the v2 packages we had in v1. This will split the operation into two separate operations, deactivation and activation. Ex. If we have the mini, mpls, and mcast packages in v1 and only specify the mini for v2 then the mpls and mcast v1 packages are deactivated and then the activation of mini v2 will occur. This is only supported on the RSP2.
  • Move the install add and install commits to pre- and post- maintenance window, respectfully, to allow for more time during the maintenance window and for a rollback.

Common Issues

Install Complaining about incompatibilities

Install operation 120 '(admin) install activate disk0:asr9k-services-p-4.2.3
disk0:asr9k-mini-p-4.2.3 disk0:asr9k-optic-4.2.3 disk0:asr9k-video-p-4.2.3
disk0:asr9k-mpls-p-4.2.3 disk0:asr9k-mcast-p-4.2.3
synchronous test' started by user 'admin' via CLI at 20:40:51 UTC Tue Feb 26 2013.
Warning:  No changes will occur due to 'test' option being specified. The following is the
predicted output for this install command.
Error:    Cannot proceed with the activation because of the following package
Error:      asr9k-mgbl-supp-4.2.1 needs iosxr-fwding-4.2.1, or equivalent, to be active on
the same nodes.


Error:    Suggested steps to resolve this:
Error:     - check the installation instructions.
Error:     - activate or deactivate the specified packages on the specified nodes.
Install operation 120 failed at 20:41:23 UTC Tue Feb 26 2013. 

For this check to see what packages are currently active via ‘show install active summary’ and compare this to the v2 packages you are trying to activate.

RP/0/RSP0/CPU0:asr9k#admin show install active
Wed Feb 27 15:05:19.796 UTC
Secure Domain Router: Owner
Node 0/RSP0/CPU0 [RP] [SDR: Owner]
    Boot Device: disk0:
    Boot Image: /disk0/asr9k-os-mbi-4.2.1.CSCub42561-1.0.0/0x100000/mbiasr9k-rp.vm
    Active Packages:

The following packages are active: mini, optic, doc, services, k9sec, video, mpls, mgbl, mcast

The v2 activation we tried only had mini, optic, services, video, mpls, and mcast

Here the solution is to include the doc, k9sec, and mgbl packages as well in the activation command.

Package Syncing to Backup-RSP Failing

Mar 07 21:41:03.431 : Install (Node Preparation): Completed sync of all 
packages and meta-data.
Insthelper encountered a fatal error condition, and is exiting: Operation 
(Failed to set up node), Error value = (2), Error string =
(No such file or directory)

This indicates an error copying either the packages or meta-data to the RSP and means there is some kind of ‘corruption’. One example of where this is seen is when an upgrade was performed and CSCua50217 was not installed.

The corruption can be verified with 'admin install verify'

Why is my install failing with "File too large" or "Value too large"?

This  is typically caused by a tar file which the filesystem cannot handle.  For example QNX4 has a limitation of 2GB-1B for a single file.

More information can be found here

Version history
Revision #:
1 of 1
Last update:
‎02-11-2014 11:39 AM
Updated by:
Labels (1)
Everyone's tags (2)
New Member



Very informative.

I've got a question regarding fallback procedure with upgrading from 4.2.X to 4.3.X (two RSPs).

This is how I imagine it would look like:

  1. pull RSP2 out before the upgrade,
  2. proceed with upgrading to 4.3.X via TURBOBOOT
  3. apply SMUs,
  4. after upgrade has completed, check the traffic and configuration that everything is OK,
  5. re-insert RSP2, which will sync it's SW to the new version.

If something isn't right in step 4:

  1. turn off the router,
  2. pull the RSP1 out (upgraded to 4.3.X),
  3. insert RSP2,
  4. turn on the router,
  5. after booting is complete re-insert RSP1, which should sync from new SW version to the old one.


Thanks for your answer,


Cisco Employee

Hi Karlo,


There are two valid rollback methods when going from pre-4.3.0 to 4.3.0+

1. Pull out the standby (ex RSP1) and keep it out until the upgrade is confirmed at which point the card is inserted and syncs to the active, or if a rollback is needed shut down RSP0 and let RSP1 boot up into the 'old' code, after which inserting RSP0 will cause it to format the 4.3.0+ data and be on the 'old' code.

2. If after upgrading you need to downgrade turboboot the RSP.


The steps you list are accurate, but as a note for step 2 the upgrade can be done via turboboot or regular install upgrade commands.

It is only the downgrade that we has some architectural limits and a downgrade via install activate or rollback command are not supported. That is why we have listed a turboboot is needed, otherwise inconsistencies are seen, but as well the RSP pull-out method is a valid alternative for some customers and one I personally prefer.




Cisco Employee

Hi Karlo,


I was checking with a few people to verify why the no commit + reload does not work when going from <4.3.0 to 4.3.0+ and it seems to have been bad wording.

So if you are going from 4.2.x to 4.3.x just omit the install commit and reload if you need a rollback method.


I apologize for this and am working to fix the various documents.




New Member

Is there a way to lock out other users from making changes during the activate process?  Something similar to 'config exclusive'?  We just want to make sure no other user is in the system doing anything at the time of an upgrade.

This is a great how-to guide!



Cisco Employee

Hi Ben,

By default the configuration is locked (don't recall at what percentage into the activation), but before the software actually changes what version of code is running or any other executables the config is locked.



New Member

Thanks, Sam.  We saw this in the lab but were concerned that we could sometimes execute config changes and other times we could not while the activate process was running.  I think we are ok with the answer that changes can't be made to the config while the activate process is making changes too.  It's seems similar to the install process executing a 'config exclusive' while it's doing it's thing.


New Member

If I want to upgrade from 4.1.0 to 6.0.1 I understand from the PDF at:

that it is not supported and I have to go the Turboboot method.  I looked and found this:

but it is related to CRS and not ASR9000.

So I finally got to:

and from what I gather I need:


Where does one get this file? 

Is there an easier way?  Is there a way to just wipe everything out and somehow load 6.0.1 from scratch?


Cisco Employee

We don't recommend using 6.0.1. It would be much better to take 6.1.4 instead. It will be available on CCO tomorrow:

This document explains why we suggest 6.1.4:

For turboboot you can take the -vm pie of your choice and load it directly. See this document:

When moving from 4.1.0, you should also take note of the pie signing change:

Hope this helps,


New Member

For Turboboot - I need - asr9k-mini-p-4.2.0

Where does one get this file? 




Hi Hank,

you don't need 4.2.0 for turboboot. You are probably looking for 4.2.0 because Xander has used it in his tutorial. This document is 4 years old.

You should go now with 6.1.4 which has been released last Friday. Just download "ASR9K-iosxr-px-6.1.4-turboboot.tar", start the turboboot procedure which is well explained and after that install all necessary packages. 

What hardware do you have in your A9K? Do a show platform and paste it here please.

New Member

Thanks!  That was the clue I needed. When I went to the d/l page and went to 4.2.1 I did not see any Turboboot:

Now that I look in the folder for 6.1.4 (or 6.0.1 which I had been looked at):

I now see turboboot.tar!  That was the part I was missing. I see that the turboboot.tar is only available from 5.1.3 and not for previous versions.

Thanks again!



please keep in mind that your HW could not be supported on 6.x

Check out this link please.

If it's the case please go with 5.3.4 + latest service pack. This one is working great.

p.s. The file "asr9k-mini-p.vm-4.2.0" is for turboboot, VM is the key name. You can find it inside the .tar. But you really don't need it. 

Cisco Employee

In prior versions the mini.vm file was part of the regular tar files. What we were finding is that customers were just loading the entire tar on their routers, however QNX has a filesystem limitation of 2GB - 1B and the tar files were > 2GB. So to prevent customers the pain of trying to upload the entire tar file just to have it fail or in the case of an emergency where the turboboot mini.vm file is needed only needing to download that file instead of the entire tar we created the turboboot.tar file.

As others have mentioned please check your hardware if you wish to go to the latest code, or go to our extended maintenance release 5.3.4