System Recovery

This chapter describes how to recover a system after it has failed to complete a reboot following a power off cycle or interruption of the normal boot sequence following a reload command.


Caution

This system recovery process interrupts subscriber service by dropping any existing flows and preventing traffic from being processed during the boot interval. It should only be initiated as an emergency measure.

This chapter includes the following sections:

Prerequisites

Recovery from a failed reboot requires that you have access to the VPC-SI or VPC-DI CF VM via a hypervisor console, and have an uncorrupted copy of the StarOS .bin and .iso image files accessible to the hypervisor.

Console Access

The boot recovery sequence can only be executed via the hypervisor console.

Boot Image

The SYSLINUX bootloader allows you to specify the priority of the boot image from which you would like to boot the system. If a VPC VM failed to reload following a software update, you can initiate a boot from a previously stored image.

The system recovery process will prompt you to enter the path name for the location of the StarOS boot image from which the system will boot. By default the boot command will timeout and attempt to reload the highest priority image from flash memory using the default configuration file.

The StarOS software is delivered as a single binary file (.bin file extension) and is loaded as a single instance for the entire system.
  • The image filename is identified by its platform type and release number. Format = platform-release_number.bin.

Multiple boot priorities are provided, each of which consist of a boot image (.bin) and configuration file. The lowest boot priority will be automatically booted on each boot. However, on startup a different priority can be manually booted by entering its number at the SYSLINUX "boot:" prompt.


Note

VPC VMs do not support booting from the network; they can only be booted from the local vHDD.

Refer to the Configuring the Boot Stack section in the Software Management Operations chapter for additional information on boot stack entries and prioritization.

Accessing the boot CLI

To access the boot CLI you must interrupt an in-progress reload (reboot) sequence.


Caution

This system recovery process interrupts subscriber service by dropping any existing flows and preventing traffic from being processed during the boot interval. It should only be initiated as an emergency measure.

Initiate a Reboot

A reload is initiated by restarting the VM via the hypervisor GUI. This will automatically bring up the SYSLINUX bootloader.

The boot sequence displays messages on the console as it steps through its processes.

At the boot: prompt, type the priority number of the desired boot file.

Interrupt the Boot Sequence

When the "Booting priority" message line appears (and not before), press CTRL+C to break out of the boot process as shown in the example below: 

Booting priority 8 
   image : /flash/image_filename.bin 
   config: /flash/system.cfg 
Entry at 0x000000000cba45e0

Press CTRL+C at this point in the sequence.

A message similar to the following appears after the boot process has been interrupted: 

*******9/0 Ctrl-C Pressed------------------------------------------------------- 
Failed. 
   aborted by user 
8/0:boot>

Enter CLI Mode

With the boot prompt displayed, enter cli to access the boot recovery CLI. The CLI prompt changes as shown below: 

8/0:boot>cli 
8/0:cli>

boot Command Syntax

The boot recovery command has the following syntax: 

boot [ -show | -priority=* | -config=* | -noconfig ] { bootfile_URL }
The options for this command include:
  • -show: displays the current boot configuration
  • -priority=*: selects the desired boot stack priority (*)
  • -config=*: enters the desired configuration filename (*), if not the default file
  • -noconfig: boots using no configuration file

bootfile_URL is the URL for the location of the StarOS boot image file. It specifies the path and file name of the StarOS .bin file from which the system will be booted.

The URL may refer to a local file (flash) or an external file on a memory device attached to the management card. The URL must be entered in the following format: 

{ /flash | /pcmcia1 | /usb1 }/filename

Booting from a Selected Image

You will issue a boot command via the boot CLI to initiate the system recovery process.

Boot Using No Configuration FIle

This procedure boots the system using the specified boot image without also loading a configuration file. A sample command string appears below: 

8/0:cli>boot -noconfig /flash/ image_filename .bin

The boot sequence ends with a prompt to enter the Quick Setup Wizard for creating a configuration file. 

Launching StarOS 
Starting program at 0x0000000000100000 
Starent Networks ASR5500 Intelligent Mobile Gateway 
management_card is starting up.............................. 
Starting software image_version_number... 
No configuration found, press enter to continue.  
1. Do you wish to continue with the Quick Setup Wizard[yes/no]:

You can exit the Quick Setup Wizard by entering no in response to the above prompt. Load a desired configuration file using the Exec mode configure command followed by the URL for the configuration file as shown in the example below: 

[local]host_name# configure /flash/system.cfg

Boot Using A Specified Configuration File

This procedure boots the system using the specified boot image and configuration file. A sample command string appears below: 

8/0:cli>boot -config=/flash/system.cfg /flash/ image_filename .bin

The boot sequence ends with the appearance of the CLI prompt. 

[local]host_name#

Confirm that the desired configuration has loaded by running the Exec mode show configuration command.

Recovering from a Bad Startup Configuration File

In the event the startup configuration file is corrupt or unusable (such as, an empty configuration file, one with no administrators or invalid passwords), the VPC VM can be recovered as follows:
  • Reboot the VM.
  • At the SYSLINUX "boot:" prompt type priority_number config= where priority_number is a boot priority with a known good .bin file.

The VM will then boot with that priority's .bin file but with no startup configuration