NAS 542 dead

2»

All Replies

  • Pandino84
    Pandino84 Posts: 14
    Third Anniversary
     Freshman Member
    yes.... new error....

    + FW_FILE=/mnt/partnerkey/nas5xx_fw/ras.bin
    + NANDPATH=/firmware/mnt/nand2
    + /firmware/sbin/info_printenv curr_bootfrom
    + awk -F= {print $2}
    + CURR_BOOTFROM=
    + [ -eq 1 ]
    sh: 1: unknown operand
    + [ -eq 2 ]
    sh: 2: unknown operand
    + echo ERROR!!! Invalid INFO value 'curr_bootfrom'!
    ERROR!!! Invalid INFO value 'curr_bootfrom'!
    + setLED SYS RED BLINK
    led_state_map_addr = 409
    + setLED HD RED BLINK
    Unknown LED
    Turn on LED
    Usage: setLED LED_NAME LED_COLOR LED_STATE
       LED_NAME: The name of LED. (HDD1, HDD2, HDD3, HDD4, SYS, COPY)
       LED_COLOR: LED color. (RED , GREEN)
       LED_STATE: ON, BLINK, FAST_BLINK, SLOW_BLINK
    ATTENTION: LED2 can only be red color

    Turn off LEDUseage: setLED LED_NAME OFF
       LED_NAME: The name of LED. (HDD1, HDD2, HDD3, HDD4, SYS, COPY)
       OFF : OFF
    + setLED COPY RED BLINK
    led_state_map_addr = 509
    + exit 1
  • Mijzelf
    Mijzelf Posts: 2,349
    100 Answers 1000 Comments Friend Collector Fifth Anniversary
     Guru Member
    And that is the same device as the previous run? In that it looks like the internal flash is degrading fast. This box has a bootloader (barebox) in flash, and in another flash partition some database containing data needed by the bootloader, and some other stuff, like the device hardware ID, B203 in your case. The function /firmware/sbin/info_printenv reads that database and prints it to stdout.
    The first run of the script the variable curr_bootfrom was read, and it had a valid value 1. Further it read kernel_mtd_1, sysimg_mtd_1, kernel_mtd_2 and sysimg_mtd_2, which all had reasonable values. Then it extracted the firmware file to a ramdisk, read the board id from the same database (I think) and compared it to the target id of the firmware. That didn't match, and so it did nothing anymore. All the script did was reading from flash and usb, and writing to ram.

    The second run directly stopped because it cannot read curr_bootfrom. Which was available on the first run, and I *think* it was available on powerup. (The box has two kernels and initramfs. 'curr_bootfrom' tells the bootloader which to use. While updating the other one is overwritten, and when everything succeeded curr_bootfrom is overwritten. This way a bad flash should not be able to brick the box. (Providing the script detects the bad flash). Without curr_bootfrom I expect a bootloader panic, but maybe it has an emergency default)

    If you want to go further, you can download an 'universal usb_key_func' file, read the readme, enable the telnet daemon, login over telnet and execute 
    /firmware/sbin/info_printenv
    to see what is wrong.

  • Pandino84
    Pandino84 Posts: 14
    Third Anniversary
     Freshman Member
    i try thanks!

Consumer Product Help Center