NAS520 in a Boot Loop after booting with a Debian/OMV Boot Stick

BePart

Hello Everyone.
As soon as I found out that the device was vulnerable from the outside/internet, I stopped using it and hoped for a secure update. Much later I see that Zyxel has completely given up on NAS products. I asked the smart internet and he/him/she/her/whatever ;) said you can run OMV (OpenMediaVault) with Debian on the same device. I made the stick and see: it boots and you can even access the web interface. But the wrong time was set and DNS didn't resolve. I change the settings and hoped that the hardware is usable farther. The idea was, according to the announcement in readme, to boot with a stick for OpenMediaVault, but after the reboot you have the original OS again. But that's not the case: boot ends in a loop...
Then I asked couple of good souls here who helped me with the reslt: the HHDs are connected externally to a pure Linux environment and the data are all safe and saved...now I want to continue working on "making the hardware usable again and saving it from trashcan.
Please help me: Boot stick with OMV or Linux distribution and suitable NAS software or SMB release, Owncloud, something like that would be great.
If all else fails, the original operating system would also be great, I could use it in intranet. But please help me not to throw away this hardware because only one bit and byte in the bootrom is set incorrectly, thx.

By the way:
Incidentally, the NAS booted with my USB/SDCARD stick including Debian with the ROMS downloaded here, and it still does, but no more Stockrom and the OMV doesn't work fine :(
https://techdudes.de/1930/zyxel-nas-520-540-542-mit-debian-und-openmediavault-omv/

I get an USB stick or a SD card to boot, but no configs are saved or without USB the device is in a continuous boot loop.

Any Ideas people?

Best greetings from Germany
BehshadP

Zyxel_Melen

Have you checked this post?

https://community.zyxel.com/en/discussion/7674/nas542-bootloop-after-debian-omv-get-a-new-firmware-solved

BePart

Hello again. Sure I did and this is my resume:

Problem:

• After installing Debian/OMV and a firmware update, the Zyxel NAS542 gets into a boot loop.

Solution:

• The solution is to boot the NAS via a TFTP server and load the firmware from there.

Tools required:

Another computer with a network connection A serial cable (null modem) A terminal program (e.g. PuTTY) The original firmware (uImage) for the NAS542 A TFTP server (e.g. tftpd32)

Step-by-step instructions:

Establish a serial connection: Turn off the NAS and open the case. Connect the serial cable to the appropriate port on the NAS and your computer. Configure your terminal program (e.g. PuTTY) with the correct settings (baud rate, etc.). You can find the exact settings in the documentation for your NAS.

Set up a TFTP server: Install a TFTP server on your computer (e.g. tftpd32). Copy the original firmware (uImage) to the folder that the TFTP server serves. Boot the NAS and enter commands: Turn on the NAS. Once you see the command prompt, enter the following commands: set ipaddress <ip1> (Replace <ip1> with the IP address you want to assign to the NAS) set tftpserver <ip2> (Replace <ip2> with the IP address of your computer running the TFTP server) tftp uImage <some-address> (Replace <some-address> with the path to the uImage file on your TFTP server, e.g. tftp uImage /tftpboot/uImage) mboot <some-address> (Repeat the path to the uImage file)

Restart NAS: The NAS should now boot from the TFTP file. If the boot process was successful, you can restart the NAS normally.

But as newbe I don't see how to identify the serial port, or is it the USB? You guys could please correct me.

Thx for any help ✌️

Mijzelf

Here is a photo of the main board of the NAS540. Although I haven't seen one, I believe the NAS542 is identical. The serial port is J1, on the upper photo on the bottom, about 2/3 from the left. (Or on the lower photo the white block at 1/3 of the left.)

The pinning is here. Note that you shouldn't use a nullmodem cable. The RS232 levels will fry your SoC. You need a 3.3V TTL device, as explained on that page.

BePart

That's great Sir, Thx a lot 👍️
But another Idea… if I can "boot" with the SD CARD, a debian and even start the OMV, and I can use SSH to connect to the device… wouldn't it make sense to try to access the bootrom and upload a file? I hope my thoughts make sense. From that website before I have downloaded the image and can start from SDCARD, but it doesn't let me configure the OMV, which makes me quite upset… but I see the device working and I have this idea…
And again... I don't want to use the original ROM because of being vulnerable and if someone can help out with configuring the OMV on Debian please don't hesitate to mention a workaround… Thanks a lot

Mijzelf

"Booting" is a complicated word in this context.

From the CPU's point of view booting is loading some code in memory, and executing that. On a NAS542 that is a few kB of NOR flash. This code (the stage 1 loader) loads the stage 2 loader from flash, and executes that. On the '542 that is barebox. Barebox reads it's environment scripts, loads a Linux kernel from NAND flash to memory, generates a command line and passes execution to the kernel.

From Linux' point of view booting consists of being in the memory, detecting and initializing hardware, and getting a rootfs mounted. Then the kernel executes /sbin/init as process 1, and the rest is userland stuff.

Linux is very relaxed about 'getting the rootfs mounted'. There are a lot of ways. The most straightforward is to provide a kernel commandline containing 'root=/dev/sda1', or something like that. After the kernel has initialized the hardware, it tries to mount /dev/sda1 as rootfs, and if that succeeds it executes /sbin/init, and ... , else it logs a kernel panic and halts.
There are problems with this approach, the kernel needs to be able to mount the specified root without any external help. So that doesn't work for raid arrays, disks for which extra drivers are needed, and ... .
For this reason many distros use an initramfs. That is a 'small', temporary rootfs in ram containing all kernel modules and helper files to get the 'real' rootfs mounted, and after mounting it process 1 exchanges the rootfs, and exec's the new /sbin/init in the new rootfs. Normally the whole ramdrive is unloaded and freed, after that.
To get an initramfs loaded, bootloader support is needed.
A ZyXEL nas has a third approach, there is an initramfs embedded in the kernel, which is used as rootfs. And that ramdisk is not exchanged, but external filesystems are mounted on subdirectories in this ramdisk.
Process 1 spawns several processes, among which the script /etc/init.d/rcS. This script tries to mount all partitions it sees, and looks for a script called usb_key_func.sh. If that exists, and certain constraints are met, the script is executed.
Here is where 'booting OMV from SD card' starts. It contains that script, and the script chroots Debian. It cannot exchange the rootfs, as the script is not running in process 1. So instead Debian is chrooted. The Debian rootfs is mounted, and some sort of environment is started which has that rootfs as root. The original rootfs also exists, in combination with some processes which were started earlier. So this Debian runs on the same kernel as the firmware does, and parts of the firmware are still in memory.

To 'really' boot OMV from SD, barebox has to load a kernel and initramfs from the SD card, and boot that. If barebox has SD card support that can be done by editing the bootscripts in the barebox environment. Unfortunately I don't know much about barebox scripts. In u-boot it would be something like (but not exactly)

initsd

extload sd1 uImage 0x04000000


extload sd1 uInitrd 0x05000000


bootm 0x04000000 0x05000000

The sd card should have uImage and uInitrd on and ext partition 1. The rootfs could be on partition 2, and the kernel commandline should specify that. But of course the rootfs could also be on harddisk, or on an NFS drive on a server, or whatever. Debian can generate initramfses which can do it all. The trick is to get the bootloader to load the kernel and initramfs you want, and generate the kernel commandline you want.

Then there is a third way of 'booting from SD'. Being having the rootfs on SD, flash a dedicated kernel in NAND (one without embedded rootfs) and specify the SD card in the root= command line variable.

BTW, that embedded rootfs in the kernel is also the reason you can tftpload the uImage, and boot that.