This chapter describes how to recover
VPC after it has failed to complete a reboot.
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.
from a failed reboot requires that you have access to VPC via a
hypervisor Console port, and have an uncorrupted copy of
the StarOS .bin and .iso image files accessible
to the hypervisor.
The boot recovery sequence
can only be executed via the hypervisor GUI with a connection to
the vConsole port. The sequence can only be viewed via
the vConsole port.
The SYSLINUX bootloader
allows you to specify the priority of the boot image from which
you would like to boot the system. If VPC failed to reload
following a software update, you can initiate a boot from
a previously stored image.
The system recovery
procedure prompts you to enter the priority 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 operating system
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. For
- For StarOS release
16.1 onwards, the image filename is identified
by its platform type and release number. Format = qvpc-si-<release_number>.bin.
VPC virtual machines (VMs) make
use of the SYSLINUX bootloader which provides a limited set of capabilities.
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.
VPC does not support booting
from the network it only supports booting from the local
Refer to the Configuring the Boot
Stack section in the StarOS
Management Operations chapter for additional information on
boot stack entries and prioritization.
Accessing the boot
To access the boot CLI
you must interrupt an in-progress reload (reboot) sequence.
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 vConsole as it steps through its processes.
At the boot: prompt
type the priority number of the desired boot file.
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
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
- 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
The hypervisor supports
a virtual watchdog device. If VPC stops servicing this
watchdog, the hypervisor forces a reboot of the VM. See
the table below.
Table 1 Hypervisor Forced
stops servicing the watchdog.
or hypervisor watchdog
HA (High Availability)
management system invokes HA, assigns VM to another host
and restarts it
Under KVM, a
virtual watchdog device can be provided using the --watchdog i6300esb command
line arguments. VMware provides a proprietary watchdog mechanism.