my first approach with an SRX router was very unlucky.
Probably due to a power outage, my SRX210HE2 with JUNOS 12.1X44-D15.5 now shows the following prompt:
I'm not familiar with SRX, so the the first attempts was an help from prompt:
=> ?? - alias for 'help'askenv - get environment variables from stdinbase - print or set address offsetboot - boot default, i.e., run 'bootcmd'bootd - boot default, i.e., run 'bootcmd'bootelf - Boot from an ELF image in memorybootloader - upgrade u-bootbootloader - upgrade loaderbootloader - upgrade ushellbootloader - check u-bootbootloader - check loaderbootm - boot application image from memorybootoct - Boot from an Octeon Executive ELF image in memorybootoctelf - Boot a generic ELF image in memory. NOTE: This command does not support simple executive applications, use bootoct for those.bootoctlinux - Boot from a linux ELF image in memorybootp - boot image via network using BootP/TFTP protocolbootvx - Boot vxWorks from an ELF imagecmp - memory comparecp - memory copycpld - peek/poke CPLDcrc32 - checksum calculationdhcp - invoke DHCP client to obtain IP/boot paramsdumpoct - dump octeon regsdumpstats - dump cavium statsecho - echo args to consoleerase - erase FLASH memoryfatinfo - print information about filesystemfatload - load binary file from a dos filesystemfatls - list files in a directory (default /)flinfo - print FLASH memory informationgo - start application at address 'addr'gpio - read/write on gpio pinshelp - print online helpi2c - read/write on i2c busid_eeprom - peek/poke EEPROMide - IDE sub-systemiminfo - print header information for application imageimls - list all images found in flashloop - infinite loop on address rangels609x_read_reg - Read 88E6097 registermd - memory displaymdkinit - start MDKmm - memory modify (auto-incrementing)mtest - simple RAM testmw - memory write (fill)nand_format - format nand flashnand_patch_verify - verifies patch in nand flashnfs - boot image via network using NFS protocolnm - memory modify (constant address)pci - list and access PCI Configuration Spacepciemd - pcie memory displaypciemw - pcie memory writepciereset - do PCIE resetping - send ICMP ECHO_REQUEST to network hostprintenv- print environment variablesprotect - enable or disable FLASH write protectionrarpboot- boot image via network using RARP/TFTP protocolread64 - read 64 bit word from 64 bit addressread64b - read 8 bit word from 64 bit addressread64l - read 32 bit word from 64 bit addressread_cmp - read and compare memory to valreset - Perform RESET of the CPUrun - run commands in an environment variablesaveenv - save environment variables to persistent storagesetenv - set environment variablessleep - delay execution for some timesmi - peek/poke SMI devicestftpboot- boot image via network using TFTP protocolusb - USB sub-systemusbboot - boot from USB deviceversion - print monitor versionwatchdog <start | stop | show | pat>write64 - write 64 bit word to 64 bit addresswrite64b - write 8 bit word to 64 bit addresswrite64l - write 32 bit word to 64 bit address=>
Then tried the bootm command. The result was disappointing:
=> bootm## Booting image at 20000000 ...Bad Magic Number=>
So, I tried to look something on Junos documentation but did not find any help.
Any suggestion to "resurrect" my SRX ?
Thanks a lot in advance to anybody will help me.
You can try the steps mentioned below to restore the device.
Thanks a lot SHKM.
Big question: can I use another SRX as TFTP server, as I usually do with Cisco routers ?
Which commands do I need to enable TFTP server on the router ?
No, SRX we can't use it as TFTP server however, I see that SRX stops in U-boot prompt
if you do reset to reboot the system. Does it go beyond U-boot prompt or again it stops at same => prompt?
If it stops at same => prompt then we need to process RMA. If it goes beyond and gets to "loader >" prompt then we can install Junos using tftp or usb.
I was stuck with an SRX550 looping with U-boot exceptions on start up for the past couple of days. I was able to recover it using the following steps. I'm not sure if it will help you, but give it a try. I am assuming that you've got a spare working SRX210HE2 lying aroud because the following steps require you to take a snapshot from it on a USB.
Boot up the working SRX210HE. Once you are in the operator mode, plug in a USB (4GB+ I think), and perform the following steps:
Press Enter to stop auto bootsequencing and to enter loader prompt.
Type '?' for a list of commands, 'help' for more detailed help.loader>
6. At the loader prompt, enter nextboot usb
7. Plug in the USB with the snapshot on to the faulty SRX210 and then enter reboot.
8. Now your faulty SRX210 should boot up from the USB. If it does boot up completely and you are able to enter the operator mode, enter the following command to copy the snapshot over to your faulty SRX.
request system snapshot media internal factory partition
9. Then enter request system reboot media internal to reboot the SRX from the internal media. You unplug the USB from the SRX now.
Your SRX should be able to boot up now (hopefully). The commands are from memory, so there might be mistakes. Let me know if it woked. 🙂
Got these steps from here... http://forums.juniper.net/t5/SRX-Services-Gateway/can-t-load-kernel-and-can-t-load-kernel-old/td-p/64491
Thanks a lot Juno-AU. I will try it, even if t looks a bit complex.
I'm wondering why those guys designing routers get simple things as a recovery of Junos so complex. It's a little bit disappointing to tell the truth.
If you are not getting loader prompt, it is quite possible that compact flash has gone faulty.
You will have to oepn up a ticket with JTAC for troubleshooting/RMA.
Very bad stuff, Raveen. Tomorrow I will try to do something. If unsuccessful I will contact some friend in Juniper.
By the way, what did it happen in your opinion ?
Thanks a lot.
As a matter of fact I can't get the loader> prompt. Tried it but was unsuccessful.
Sorry SHKM, being new to JUNOS, I'm not aware of the meaning "we need to process RMA". What does it mean ?
RMA stands for Return Material Authorization. If a hardware failure is determined by the JTAC engineer and repair/replacement is needed, an RMA will be raised.
Processing RMA means if JTAC deduce the problem to be with hardware, you would be provided with replacement device.