Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[MX/PTX] Minor alalrm: VMHost x Boot from alternate set

0

0

Article ID: KB36002 KB Last Updated: 30 Jun 2020Version: 1.0
Summary:

This article explains the meaning of the following alarm seen on the device and indicates if any actions need to be taken:

XX@XXXX> show chassis alarms
1 alarms currently active
Alarm time               Class  Description
2019-05-17 12:32:54 UTC  Minor  VMHost 0 Boot from alternate set
Cause:

NG-RE has two SSDs: SSD1 and SSD2. The first disk connected with channel 0 is the primary disk. The other disk is considered as a backup. There are two sets of software boot images on the primary disk, namely set p and set b. We boot with one set, and when an upgrade is needed, it switches to use the other set. Similarly, on rollback, we switch to the other set. Until an upgrade/rollback is done, the BIOS is programmed to boot from the same set of the SSD for any unplanned to planned VMhost reboot.

The minor alarm "VMHost 0 Boot from alternate set" during the following conditions:

  • When the attempt to launch Junos VM using the active set image failed and rollback is attempted to boot from the alternate set. 
  • When the active set fails and root rollover is done during boot.

We need to check and correct the active set and boot the device from the active set in-order to clear the alarm.
 

Solution:

In order to clear the alarm, the Primary set of the SSD needs to be repaired and boot from the same set.

Collect VM host logs from the Routing Engine with KB31910 - [MX/PTX] How to collect /var/log files from Next Generation Routing Engine (NG-RE)

Boot-list order: USB, SSD1, SSD2, LAN
Boot sequencing/retry in case of boot failure due to corruption or hardware failures: SSD1 and SSD2 will be tried twice during the boot sequencing.

Follow the steps below to recover the Routing Engine and clear the alarm:

  1. As required, recover the Routing Engine by using the command ​ 

    > request vmhost snapshot

    If the alarm doesn't clear with the above step follow Step 2

  2. When the device is booted from SSD2, the following must be used to take a complete VMhost snapshot along with partition details to SSD1. This option would be used to recover SSD1 having a corrupted image. 

    > request vmhost snapshot recovery [partition]

    If the state of the backup disk (disk2) is good and the primary disk (disk1) has to be recovered, then use the request vmhost snapshot recovery command to recover the primary disk assuming the Routing Engine is booted from the backup disk. If the state of the primary disk is not known or the partition tables are in bad condition, then include partition option in the command i.e. request vmhost snapshot recovery partition.

    If the state of the primary disk (disk1) is good and the backup disk (disk2) has to be recovered, then use the request vmhost snapshot command to recover the backup disk assuming the Routing Engine is booted from the primary disk. If the state of the secondary disk is not known or the file systems in the disk are not in a consistent state, then include partition option in the command i.e. request vmhost snapshot partition.

      If the alarm doesn't clear with the above step, follow Step 3.
  3. Add the VM host image again and reboot the device to clear the alarm.   

    > request vmhost software add /var/tmp/xxxx
    > request vmhost reboot

    Where XXXX is the same Junos image you have used for VM host.
    To boot from the desired disk, execute 'request vmhost reboot { disk1, disk2}' command.

    4. Take a snapshot after the alarm clears

     > request vmhost snapshot

    It will try to take the copy of config files and other system files along with Junos as a backup and get stored in the alternate bootable media. This is required after reboot to keep Junos versions symmetric on the disk after you fix the “Boot from alternate set” issue.
     
    Note: When a regular install is attempted while the RE is booted from SSD2 (disk2), the image upgrade is done on the SSD1, not on the other set in the same disk. 

    IMPORTANT: It’s always recommended to take the complete snapshot of the Host along with the Junos OS before the upgrade.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search