Configuring Root Partitions on SRX Series Devices

Boot Media and Boot Partition on SRX Series Firewalls

When the SRX Series Firewall powers on, it tries to boot the Junos OS from the default storage media. If the device fails to boot from the default storage media, it tries to boot from the alternate storage media.

Table 1 provides information on the storage media available on SRX Series Firewalls.

With the dual-root partitioning scheme, the SRX Series Firewall first tries to boot Junos OS from the primary root partition and then from the backup root partition on the default storage media. If both primary and backup root partitions of a media fail to boot, then the SRX Series Firewall tries to boot from the next available type of storage media. The SRX Series Firewall remains fully functional even if it boots Junos OS from the backup root partition of the storage media.

Important Features of the Dual-Root Partitioning Scheme

The dual-root partitioning scheme has the following important features:

• The primary and backup copies of Junos OS images reside in separate partitions. The partition containing the backup copy is mounted only when required. With the single-root partitioning scheme, there is one root partition that contains both the primary and the backup Junos OS images.

• The request system software add command for a Junos OS package erases the contents of the other root partition. The contents of the other root partition will not be valid unless software installation is completed successfully.

• Add-on packages, such as jais or jfirmware, can be reinstalled as required after a new Junos OS image is installed.

• The request system software rollback command does not delete the current Junos OS image. It is possible to switch back to the image by issuing the rollback command again.

• The request system software delete-backup and request system software validate commands do not take any action.

Understanding Automatic Recovery of the Primary Junos OS Image with Dual-Root Partitioning

The auto-snapshot feature repairs the corrupted primary root when the device reboots from the alternate root. This is accomplished by taking a snapshot of the alternate root onto the primary root automatically rather than manually from the CLI.

When this feature is enabled, and the device reboots from the alternate root (because of a corrupted primary root or power cycle during restart), the following actions take place:

1. A prominent message is displayed indicating a failure to boot from the primary root.

2. A system boot from backup root alarm is set. This is useful for devices that do not have console access.

3. A snapshot of the alternate root onto the primary root is made.

4. Once the snapshot is complete, the system boot from backup root alarm is cleared.

During the next reboot, the system determines the good image on the primary root and boots normally.

Enable this feature with the set system auto-snapshot command. Once the primary root partition is recovered using this method, the device will successfully boot from the primary root partition on the next reboot.

Execute the delete system auto-snapshot command to delete all backed up data and disable auto-snapshot, if required.

Use the show system auto-snapshot command to check the auto-snapshot status.

When auto-snapshot is in progress, you cannot run a manual snapshot command concurrently and the following error message appears:

Understanding How the Primary Junos OS Image with Dual-Root Partitioning Recovers Devices

If the SRX Series Services Gateway is unable to boot from the primary Junos OS image, and boots up from the backup Junos OS image in the backup root partition, a message appears on the console at the time of login indicating that the device has booted from the backup Junos OS image.

Because the system is left with only one functional root partition, you must immediately restore the primary Junos OS image using one of the following methods:

• Install a new image using the CLI or J-Web user interface. The newly installed image will become the primary image, and the device will boot from it on the next reboot.

• Use a snapshot of the backup root partition by entering the request system snapshot slice alternate command. Once the primary root partition is recovered using this method, the device will successfully boot from the primary root partition on the next reboot. After the procedure, the primary root partition will contain the same version of Junos OS as the backup root partition. Once the snapshot is complete, the system boot from backup root alarm is cleared.

  Note:

  You can use the CLI command request system snapshot slice alternate to back up the currently running root file system (primary or secondary) to the other root partition on the system along with following:

  • Save an image of the primary root partition in the backup root partition when the system boots from the primary root partition.

  • Save an image of the backup root partition in the primary root partition when the system boots from the backup root partition.

  Warning:

  The process of restoring the alternate root by using the CLI command request system snapshot slice alternate takes several minutes to complete. If you terminate the operation before completion, the alternate root might not have all required contents to function properly.

Understanding How Junos OS Release 10.0 or Later Upgrades with Dual-Root Partitioning

To format the media with dual-root partitioning while upgrading to Junos OS Release 10.0 or later, use one of the following installation methods:

• Installation from the boot loader using a TFTP server. We recommend this if console access to the system is available and a TFTP server is available in the network. See Installing Junos OS on SRX Series Firewalls from the Boot Loader Using a TFTP Server

• Installation from the boot loader using a USB storage device. We recommend this method if console access to the system is available and the system can be physically accessed to plug in a USB storage device. See Installing Junos OS on SRX Series Firewalls from the Boot Loader Using a USB Storage Device

• Installation from the CLI using the partition option. We recommend this method only if console access is not available. This installation can be performed remotely.