The MX Series with a Routing Engine 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 the SSD slot 1 or SSD slot 2 (if present)
One or more of the below symptoms can be seen:
-
The "show system boot-messages", will display a statement saying the device is unable to boot from Compact Flash (ada0)
-
Compact Flash not listed in show chassis hardware.
-
Boot messages indicate file system corruption messages.
-
The current boot interface will be listed as Disk.
root@jtac> start shell
% sysctl -a | grep bootdev
machdep.currbootdev: disk1
-
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
Verify the storage partitions detected in hardware output:
An ideal storage output should look like this:
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 case of devices that have SSDs instead of 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 recover the Junos volume:
Login to RE1 (default backup) >>> Since the alarm is seen on Host 1
user@host> request system recover junos-volume
Now, run "
request system reboot" RE1 and once device boots up, verify if the alarm clears off. If the alarm does not clear after recovery, please proceed with
Step 2.
Step 2:
Reboot RE 1 again and wait until you see the Boot menu and hit the space bar to stop the Autoboot. ( Please ensure that you have the console connected to this RE just in case we lose access). You will be directed to boot options Menu as 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 3:
In case you are still unable to recover the file system, please perform
USB recovery.
Example for Step 3:
Login into root user and execute the below:
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 4:
If the above-mentioned steps do not work, it is most probable that there is a hardware issue with RE and you might need replacement. Please contact your JTAC Representative.