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.
  • For StarOS releases prior to 16.1, the image filename is identified by its release version and corresponding build number. Format = production.build_number.platform.bin.
  • For StarOS release 16.1 onwards, 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.

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

Recovering from an Unbootable System

If VPC becomes unbootable (for reasons such as, deleting all images or mis-configuring boot priorities), it can be recovered by booting the installer ISO (.ssi.iso file) and choosing option 2 (recover). This option installs a new bootable .bin file and creates a new boot priority list. The vHDD will not be reformatted (choose option 1 to do that), so the configuration files will persist.