Showing results for 
Search instead for 
Did you mean: 
Eddie Chami
Cisco Employee
Cisco Employee

Problem statement


RSP-4G/RSP-8G systems have limited boot Disk Space(2G disk), leading to upgrade constrains when moving between Major Releases. Boot disk memory is not field upgradable. This document will discuss the options to ensure an upgrade is successful. The document will also cover options that can be undertaken to have a successful upgrade, the options are:

  1. Disk Space Conservation – A best practice and should always be done
  2. Flexible Disk Installs – Available from IOS XR release 4.3.4 onwards
  3. Rebake an RSP2 in the lab – This option has opex drawbacks, as an RSP needs to be replaced in each location
  4. Turboboot – This should be a last resort option.
  5. When possible migrate to RSP-880, RSP-440 or RSP-LITE(Upgradable to RSP-440)


1 Disk Space Conservation

The RSP2 diskspace is naturally split into two partitions (1.6G/0.4G). This can be altered and re-partitioning ratio changed to 1.9G/0.1G, hence increasing the available space to the XR installer by 300M. If not partitioned one needs to do so. The re-partitioning tool is available from Release 4.2.0 onwards, for Release 4.2.0-4.2.1, a hitless SMU(CSCub41271) can be installed to use the tool, the tool is integrated in 4.2.3. Executing the re-partitioning is not service impacting. Instructions on running the repartitioning tool:

Other methods to conserve disk: memory

  1. Remove the FPD pie on the running Release, as the FPD pie takes a considerable amount of diskspace, and once the FPDs have been upgraded the pie is no longer required. (Note: Auto FPD will not work if the FPD pie is not installed on upgrade, FPD update will need to be manually run after upgrade in this case). Removal of FPD pie on RSP-2 prior to 4.3.0 is not supported, since its bundled with the mini.pie.
    1. Identify the FPD pie, example: show inst ac sum | in fpd


  1. Deactivate the FPD pie, example: “admin#install deactivate disk0:asr9k-fpd-px-4.3.4”
  2. The changes need to be committed before being able to remove them. “admin# install commit”
  3. Remove the FPD pie, example: “admin#install remove disk0:asr9k-fpd-px-4.3.4”
  1. If the above step is followed, then upgrade to the target release without the FPD pie, once on the target release, install the FPD package, this saves about 500-600M of disk space during the upgrade.
  2. Remove the superseded SMUs on the running release(This is advised to be done during a MW, as it maybe traffic impacting for some SMUs).
    1. Identify superseded SMUs using the optimize option of CSM. Partially superseded SMUs can’t be deactivated. CSM User Documentation:
    2. Deactivate the superseded SMUs with “admin# install deactivate <smu>” or from 4.3.2 onwards can use cli “admin#install deactivate superseded”
    3. The changes need to be committed before being able to remove them. “admin# install commit”
    4. Remove the SMU,  “admin# install remove <smu>”
  3. It’s a standard best practice to install SMUs of the target release during an upgrade in a single install operation. To overcome the disk space limitation, the install of the SMUs can be delayed till after the install of the target release is completed. At this point, the removal of the old release can happen and then followed by installing of the SMUs. It’s important to note, this does lead to two reloads. Here is an illustrations:
    1. Activate the target release without SMUs, example: “admin#install activate disk0:asr9k-mini-p-4.2.3”
    2. After bootup : “admin#install commit”
    3. Remove the old release if happy with the upgrade: “admin#install remove inactive”
    4. Install the SMUs of the new release “admin#install add active <New release SMUs/SP>”


2 Flexible disk installs

With flexible disk installs both Disk0 and Disk1 on RSP-4G/RSP-8G(AKA RSP2) can be used as boot media. With that the operator now has 1.9Gx2 at their disposal. At any point in time a single IOS XR image can only be booted from one of the two disks. With this flexibility image A can run from Disk0, the upgrade to image B can be with Disk1 and so on. This option was introduced in 4.3.4.

More information:


3 Rebake RSP2 in the lab

Prebake an RSP with target image + SMUs and use it to upgrade, if a rollback (downgrade) is needed use existing RSP, one can see this as an opportunity to buy/insert a newer processor (if scale or performance can justify the CAPEX). See option 5.

   a) If a spare RSP is found, upgrade an RSP in a non-production router with pies + SMUs and then use it to upgrade.
   b) Send the spare RSP to the site, remove old RSP with old image, use new RSP with new image+ SMUs.
   c) If a downgrade is later needed the existing RSP can be reinserted.

4 Turboboot

Detailed version of Turbobooting is available in the Cisco Support Community link:

1. Clear the ROM Monitor environmental variables on all RSPs:
unset BOOT
Repeat for each RSP in the system

2. Clear BOOT_DEV_SEQ_OPER and MIRROR_ENABLE ROM Monitor environment variables to disable disk mirroring.

3.Change the default behavior of RP in ROMMON to not reset in 30 minutes
Rommon> priv
Rommon> diswd <- Disable the CPU watchdog

4. On the RSP, set the environment variables that configure the Management Ethernet interface for use in ROM Monitor mode. Repeat for each RSP and set it with unique IP address:

5. On the RSP, set the TFTP environment variables. Repeat for each RSP:

6. Set the Turboboot variables on one RSP ONLY :

7. On this RSP, boot the vm image located on the TFTP server: (Works only with the VM image, not the TAR file)
boot tftp://server/directory/filename

8. Now that the system has come up with the desired software, additional optional packages can be 'installed and committed'

5 Migrate to RSP-Lite, RSP-440 or RSP-880

With the EoS of RSP-4G/RSP-8G(AKA RSP2), migrating to a new RSP is recommended


Possible upgrade options is the new RSP-880, RSP-440 or the LT version with is software upgradable to RSP-440.

Eddie Chami
Cisco Employee
Cisco Employee

Considering that your on 390 you should verify all your cards have 4G or ram. We did ship cards with 2G ram on the early days, those won't boot 513. You will need to RMA the card if it has 2G.

Turbo booting uses disk0: that's 2G and you'll be ok 513 will fit there. Make sure you repartition after your on 513. A portion of the 2G is reserved and you can get that back with repartition.

Cisco Employee
Cisco Employee

Thanks a ton Eddie !!

You are a Master!!


Cisco Employee
Cisco Employee

Hi all


I see if the FPD pie is removed support the RMA, but what happend if the customer change the HW

if there is MOD80 then customer replace for a MOD160 when there is not FPD pie. Actually the customer is moving from 4.2.3 to 5.3.4 finally.


is it not necessary to upgrade the FPD ?


best regards


Is there a way to copy the  mini.vm file or the necessary file to do a turboboot from disk0 on the router to a usb so a clean install can be performed . When i list the files on the drive0 it is mostly directories so im not sure if i am copying the correct .vm file?  Also curious if the mini.vm should be a directory or file when you enter mediaboot usb:/release_mini.vm? So in essence, is there a way to copy the file(s) required from the router to do a clean turbo boot?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers
Quick Links