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

Mijzelf

BAD MAGIC is the output of ´info_setenv MODEL_ID B403´? In that case I suppose the bootloaders environment partition has a wrong header (or footer) somehow.

You can try to do it from the bootloader prompt, maybe that will restore the right header.

Did fw_printenv work without complaints?

archigraf

No, not the output from info_setenv MODEL_ID B403, i saw it in Tera Term while booting up. But the System ist running. I had some strange situations, but never touch a running System...

info_printenv.txt is attached. I think a few lines are not necessary anymore.

archigraf

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.

archigraf

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.