NAS 542 doesn´t boot anymore, no USB-Stick is working, Serial connection is working

Hello again in this forum,

i tried out Debian with OMV on my NAS 542 and at first, it was working. After Reboot, b1 was damaged and i executed b2 with a fine boot into the zyxel System.

From Zyxel-System i did a flash with the USB-Stick with stock firmware. After the next reboot, nothing did a boot, neither b1 but b2. Both firmwares now have the barebox environment, crc check failed.

I have an Windows System with serial connection (Tera Term) and Linux System with serial connection.

Do you have an idea what i can do? I have read many Posts in this forum, but can´t get any further

Best Answers

  • Mijzelf
    Mijzelf Posts: 1,721  Guru Member
    Accepted Answer
    booting kernel of type uimage from /dev/nand0.kernel1.bb
    Bad Header Checksum
    Failed.
    booting kernel of type uimage from /dev/nand0.kernel2.bb
    Bad Header Checksum

    Either both kernels are corrupted in flash (unlikely), or the environment is corrupted, leading to either a wrong kernel size, (if you load only 2MB of a 3MB kernel, the checksum will be wrong) or a wrong flash address for both kernels.
    Unfortunately I don't know much about barebox. In your case I would try to get tftp working. It seems your box gets an IP from DHCP, and the bootlog mentions tftp being the default mode.
    So just try
    tftp -f imagename -a address
    something like
    tftp -f uImage -a 80010000
    In the log of your tftp server it might log a request. Or maybe barebox will tell you what you are doing wrong. Or which server it is probing, or ....
    If everything seems to work, and you need just an uImage, you can try this uImage. Then boot it with 'bootm 80010000', or whatever address you used.

  • archigraf
    archigraf Posts: 18
    edited September 24 Accepted Answer
    Thanks again to Mijzelf and triu.

    What I did (not a tutorial):

    Read triu's post and all Mijzelf's answers an have a look at the attached files. My case was very similar to the case of triu. The configuration of the environment was wrong and the kernel had to be flashed via tftp.

    additional information: you have 30 seconds after stopping the autoboot process by serial connection. Cutecom helped me a lot (linux) because the commands are saved line by line in the input mask. This makes it possible to quickly enter the commands again with one click.

    Some commands can be saved in the /env/config file. To do this, the command "edit/etc/config" must be entered in barebox. With ctrl + c the editor can be left without saving. Save with ctrl + d. Important: If the file is to be saved in the flash, the command "saveenv" must be entered. Otherwise the change will be lost. This must also be done within 30 seconds. You can work your way up line by line.

    The command to load the image did not work in my case from the configuration file, so it had to be entered manually in the commandline. But the commands for the bootargs, IP... could be saved in /env/config.

    Some unusual reboots happened, for example without the possibility of interrupting the autoboot process. Don't be surprised, just reboot, mabe with new upload of uImage (tftp). If the boot process went correctly, you can hear after some time that the fan is running at increased speed shortly before the end of the boot and then the beep for the completion of the boot. Then you won. If the boot stops (you see this in the serial console, something is gone wrong. You have to look at possible faults in the output of the serial box.
    I then flashed the correct firmware for the NAS via USB (NAS542, you will find this in Mijzelfs repositories) and I did change the Id via Busybox, as described:

    I only had one uImage of the NAS540 (uImage.520.bin). Maybe I just couldn't find the uImage for the NAS542? As a result, there was an incorrect id for the device, which was entered incorrectly in at least two places (scripts). The Id had to be changed in the command line of the barebox ("edit / env / config" in three places from B103 to B403) and later !Additionally! in the commandline of the busybox (via ssh or telnet). The command was here: "info_setenv MODEL_ID B403". If the environment is only to be displayed, in busybox the command is "info_printenv".

    Only after the MODEL_ID had been adjusted in all four places did the NAS resume the saved configuration; previously the NAS had rejected the configuration file because it was corrupt.

    All steps can also be carried out from Windows. Here out of the DOS box. Tera Term was the serial server here, the uImage can be uploaded from the DOS box via tftp. Here you have to adapt the firewall.

    The NAS is now running perfectly again, with the backup planner and all shares and user rights...

    The information from the German service from Zyxel was therefore incorrect. I was told: If the USB is not addressable, the NAS cannot be repaired. Now the NAS doesn't have to be thrown in the trash, climate change will be a tiny bit slower.

«1

All Replies

  • Thank you very much, Mijzelf.

    I manged the tftp connection, like triu, and the system is starting. serial-log is attached.

    please help me, i dont`t know, what i have to do from now on... I think, triu uses an script for the commands on startup. I use the serial console ant type it by copy and paste from textfile. Is there an file at filesystem on the box with an editable commandline (script)?
  • archigraf
    archigraf Posts: 18
    edited September 21
    Hello Mijzelf,

    I found the file env / config and edited it with the information from the thread with triu. Thank you for all the help that is in this thread from me. I have not documented all the steps, otherwise I would try to write a tutorial.

    The NAS boots and reboots up to the startpage via the browser, with the firmware from Zyxel.

    One problem still exists: the NAS thinks it is a 540, but it is a 542. Therefore, a firmware update in the browser also fails. I now have some respect for the NAS ... How can I turn the 540 into a 542? With the rescue stick?



  • Mijzelf
    Mijzelf Posts: 1,721  Guru Member
    No, it's the modelid in the bootloader environment. B103 is NAS540, B203 is NAS520, and B403 is NAS542.
    You can read and write it with fw_printenv and fw_setenv. In think these binaries are in /firmware/sbin, or something like that.
    Of course you can also use the bootloader command prompt.
  • Okay Mijzelf, i'm not sure i got that. I have to edit a file that is in the environment. Can I do this over telnet or ssh?

    how do I get back on the commandline?

    I'm scared of shooting the checksum again here ...

  • archigraf
    archigraf Posts: 18
    edited September 21
    here ist printenv

    i have to change the model_id

    maybe /firmware/sbin/fw_setenv MODEL_ID=B403  ???


    and i think, there are a now lot of lines i have to comment out?
  • Mijzelf
    Mijzelf Posts: 1,721  Guru Member
    First try fw_setenv without arguments, or with '-h' to get a syntax. In the u-boot prompt it would be
    setenv MODEL_ID B403
    saveenv
    I think in barebox it is the same. fw_setenv is designed to provide u-boot compatibility, so I'd expect
    fw_setenv MODEL_ID B403
    (saveenv is not necessary)



  • Thank you for your answer. The system will Boot with the correct B403 as well? 
  • command is ´info_setenv MODEL_ID B403´ but i´ve got BAD MAGIC

    what have i do to now?
  • Okay, I found out. I will write here in the next few days what I have done ...

    Many thanks to Mijzelf and triu, also to other users here in the forum.

    The server is running, the shares are accessible and I'm happy. Now the device has not ended up in the scrap.

    It has now been two weeks with many hours of research.

    I had made a request to the Zyxel service in Germany, where I pointed out that my device is out of warranty and whether the service can reflash the motherboard. The service from Zyxel was unfriendly and harsh and told me to buy a new NAS ... First an offer to send the device in, only then really read my question and quickly closed the ticket.