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.
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:
USB media emergency boot device (if present)
Compact Flash card
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:
The output of " show system boot-messages " displays a statement that the device is unable to boot from Compact Flash (ada0).
show system boot-messages
The Compact Flash is not listed in the show chassis hardware output.
show chassis hardware
The boot messages indicate file system corruption messages.
The current boot interface is listed as Disk.
root@jtac> start shell % sysctl -a | grep bootdev machdep.currbootdev: disk1
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
A few of the causes are listed as follows:
A transient issue with the RE that usually appears after booting
An issue with storage media
RE failure
To troubleshoot this problem, perform the following steps:
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 %
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 .
request system reboot
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)
Example for Step 4
Log in as the root user and execute the following:
root
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 .
2020-08-13: Minor non-technical edit
2022-02-10: Modified Step 1