Description

This article lists some of the symptoms and causes for a router to be unable to boot from the primary partition and details the steps to troubleshoot the issue.

Symptoms

An MX Series device with a Routing Engine (RE) that has a Hard Disk or a solid-state drive (SSD) attempts to boot from the storage media in the following order:

  1. USB media emergency boot device (if present)

  2. Compact Flash card

  3. Hard Disk / Solid-state drive (SSD) in SSD slot 1 or SSD slot 2 (if present)

One or more of the following symptoms are then seen:

  1. The output of " show system boot-messages " displays a statement that the device is unable to boot from Compact Flash (ada0).

  2. The Compact Flash is not listed in the show chassis hardware output.

  3. The boot messages indicate file system corruption messages.

  4. The current boot interface is listed as Disk.

root@jtac> start shell                                       
% sysctl -a | grep bootdev
machdep.currbootdev: disk1                        
  1. There is an active alarm on the affected RE:

user@host> show chassis alarms no-forwarding

1 alarms currently active
Alarm time               Class  Description
2020-05-05 19:53:05 PDT  Minor  Host 1 Boot from alternate media

Solution

A few of the causes are listed as follows:

  1. A transient issue with the RE that usually appears after booting

  2. An issue with storage media 

  3. RE failure

To troubleshoot this problem, perform the following steps:

  1. Verify the storage partitions detected in the hardware output. An ideal storage output should look like the following:

user@host> show chassis hardware
Routing Engine 0 REV 18   74xx-xxxxx   xxxxxxxxxxxx    RE-S-2000
ada0    976 MB  xxxxxxxxxxxx    UNIxxxx xxxxxxx        Compact Flash
ada1  38154 MB  xxxxx           5xxxxxxxx              Hard Disk
usb0 (addr 1)  Uxxx root xxx 0       Intel             uhub0
Routing Engine 1 REV 18   74xx-xxxx   xxxxxxxxx        RE-S-2000
ada0    976 MB  Uxxxxxxxxxxxx    UNxxxx xxxxxxxx       Compact Flash 
ada1  38154 MB   xxxxxxxx       5xxxxxxx               Hard Disk 
usb0 (addr 1)  Uxxx root xxx 0       Intel             uhub0

Note: In the case of devices that have SSDs instead of a Hard Disk, you will be seeing (SSD 0: ad1 and SSD 1: ad2) in the output list.

Check the boot list:
root@jtac> start shell                                       
% sysctl -a | grep bootdev
machdep.currbootdev: compact-flash
machdep.nextbootdev: usb
machdep.bootdevs: usb,compact-flash,disk1,lan
%

Step 1

To clear the alarm, try to boot the device from the Junos volume by logging in to RE1 (default backup) since the alarm is seen on Host 1.

user@host> request system reboot junos

If the device reboots successfully with the Junos volume after performing the above step, the alarm should be clear.

If the alarm does not clear after the reboot, this means that the device is still booting from the OAM volume. Proceed with Step 2 .

Step 2

To recover the Junos volume, from RE1, run the following command:

user@host> request system recover junos-volume

Now run " request system reboot " on RE1. After the device boots up, verify that the alarm has cleared. If the alarm has not cleared after recovery, proceed with  Step 3 .

Step 3

Reboot RE 1 again and wait until you see the Boot menu. When you see the Boot menu, press the Space bar to stop Autoboot. (Ensure that you have the console connected to this RE just in case you lose access). You will be directed to the boot options menu as shown below:

Main Menu                
1.  Boot [J]unos volume
2.  Boot Junos volume in [S]afe mode                                  
3.  [R]eboot    
4.  [B]oot menu
5.  [M]ore options                  
Choice: Autoboot in 3 seconds...
Enter 5 to go to the Options menu:                                 
Options Menu
1.  Recover [J]unos volume
2.  Recovery mode - [C]LI                  
3.  Check [F]ile system                
4.  Enable [V]erbose boot                  
5.  [B]oot prompt                   
6.  [M]ain menu
Enter 3 to choose "Check [F]ile system".  Issue the following command:                
# fsck_ufs /dev/ada0p2    
You will see the below output:     
 # fsck_ufs /dev/ada0p2
            ** /dev/ada0p2
            ** Last Mounted on /.mount
 ** Phase 1 - Check Blocks and Sizes
 ** Phase 2 - Check Pathnames
 ** Phase 3 - Check Connectivity
 ** Phase 4 - Check Reference Counts
 ** Phase 5 - Check Cyl groups
 SUMMARY BLK COUNT(S) WRONG IN SUPERBLK
 SALVAGE? yes

19141 files, 2921404 used, 2110321 free (1529 frags, 263599 blocks, 0.0% fragmentation)
                            
***** FILE SYSTEM WAS MODIFIED ****
Run request system reboot on the backup RE.

Step 4

If you are still unable to recover the file system, perform  USB recovery .

Example for Step 4

  • Log in as the root user and execute the following:

root@host% dd if=/var/tmp/filename of=/dev/da1 bs=1m    <-- Run for 20 seconds and press CNTRL+C to stop
The device writes the installation media image to the USB device:
root@host% dd if=<installation media image> of=/dev/da0 bs=1m
1399+0 records in
1399+0 records out
1466957824 bytes transferred in 394.081902 secs (3722469 bytes/sec)

Step 5

If the above steps do not work, it is most likely that there is a hardware issue with the RE and that it might need replacement. Contact Support .

Modification History

2020-08-13: Minor non-technical edit

2022-02-10: Modified Step 1

Related Information