Welcome! Log In Create A New Profile

Advanced

Zyxel NAS326 Installation

Posted by bodhi 
Zyxel NAS326 Installation
August 20, 2019 05:48PM
Zyxel NAS326 Installation
Updated 20 Aug 2019

I'm in the process of writing a new installation instruction for this box to boot with kernel linux-5.2.9-mvebu-tld-1. The instruction below is good for kernel linux-5.1.7-mvebu-tld-1 or earlier. For 1st time installation, this instruction below is still good to use.


Note: for HHD booting issues after your installation, see this thread.

Installation for NAS326 box can be done with serial console connected (section A), or inside stock OS and without serial console (section B for USB rootfs, section C for SATA rootfs). Note: for section A and B, the USB rootfs must be inserted to the front USB port (USB 2.0).


A. Instruction for the booting the NAS326 with a USB rootfs (serial console setup)

A1. Requirements

1. Serial console connected during set up (which should be removed later during normal operation).

2. Download either the latest ARM32 version or the x86-64 version of kwboot. Use it depending on the architecture of serial console converter host. Please see this post for ARM32 kwboot. (I'll need to recompile the x86-64 version and reupload).

3. Prepare the rootfs Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2 as described in the Debian rootfs release section:

Quote

Updated 04 Feb 2017:

This Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2 has been uploaded.

A2. Installation

Warning: Step 4 in the instruction in this section uses a "env/code injection" to replace the Zyxel NAS326 stock u-boot bootcmd with a different command during boot. It's a simple trick that change u-boot env bootcmd (it does not touch u-boot binary in NAND). However, this hack should not be used on a different MVEBU box (any box other than the NAS326). Doing this without examining your box's stock u-boot source code could likely messing up your u-boot envs and prevent booting, or in the worse case bricking it. Please post questions regarding installation for other MVEBU boxes, it might be possible to do this.

1. Start kwboot on the serial console host

For ARM32 kwboot:
./kwboot -t -B 115200 /dev/ttyUSB0 -d

For x86-64 kwboot:
./kwboot -t -B 115200 /dev/ttyUSB0


2. Power up the NAS326, and wait at serial console, observe kwboot spinning / while waiting for handshake.

3. After a period of time, the NAS326 will time out and start booting its stock u-boot. Interrupt u-boot at countdown. Get a listing of your current u-boot envs, and save it to a notepad in case you want to restore it later.

printenv


4. Enter the following commands (copy/paste each line to the u-boot prompt).

setenv curr_bootfrom 1
setenv next_bootfrom 1
setenv load_dtb_addr 0x1000000
setenv load_initrd_addr 0x2900000
setenv load_image_addr 0x02000000
setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'
setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/zImage; ext2load usb 0:1 $load_dtb_addr /boot/dts/armada-380-zyxel-nas326.dtb; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootz $load_image_addr $load_initrd_addr $load_dtb_addr'
setenv bootcmd_custom 'if run usb_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '
saveenv


5. Reset the NAS326, exit kwboot.

reset
And then press "Control \ c" to exit kwboot

6. Start kwboot again on the serial console host (use the same command as in step 1)

7. After a period of time, the NAS326 will time out and start booting its stock u-boot. Observe kernel loading and booting until seeing the Debian prompt. At this point we can either login directly with serial console, or by SHH. If login is through SSH, find the NAS:

ping debian.local

When the ping returns successful response, then login (root password is root);
ssh root@debian.local


If for whatever reason (e.g. firewall), the NAS326 cannot be found as debian.local, then find its IP in the router webpage. Or use a scanning app such as Linux nmap or IOS Fing to find the IP.

8. DONE.


A3. Normal Operation

The USB rootfs should be plugged in permanently, and the serial console module should be removed.

1. Whenever the NAS326 is rebooted or cold started, to boot without manual intervention, the serial console module must be unplugged from the NAS326. If the serial console module is plugged in, then step 1 in the installation instruction A2 must be executed (so that the NAS326 will continue booting when it detected the serial console present). Note that reboot in some instance will work with serial console plugged in.

2. If you want to boot back to stock OS in NAND, just shutdown the box, unplug the USB and power up the box. It will boot the kernel 1 in NAND and then if not successful, it will try kernel 2.

This also serves as a rescue system. Whenever the rootfs on USB has problem and cannot boot (the effect is just like the USB drive is not plugged in), the NAS326 will fall back to booting the kernel 1 or 2 in NAND. When this occurs, the u-boot envs in step 4 must be reentered at serial console again to allow booting back to USB rootfs.


A4. Reverse to stock OS permanently

To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at serial console:

setenv kernel_addr_1 0x00E00000
setenv bootargs 'console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2'
saveenv
boot


B. Instruction for booting the NAS326 with a USB rootfs (setup without serial console)

B1. Requirements

1. Prepare the rootfs Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2 as described in Debian rootfs release section:

Quote

Updated 04 Feb 2017:

This Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2 has been uploaded.

B2. Installation

Warning: Step 4 in the instruction in this section uses a "env/code injection" to replace the Zyxel NAS326 stock u-boot bootcmd with a different command during boot. It's a simple trick that change u-boot env bootcmd (it does not touch u-boot binary in NAND). However, this hack should not be used on a different MVEBU box (any box other than the NAS326). Doing this without examining your box's stock u-boot source code could likely messing up your u-boot envs and prevent booting, or in the worse case bricking it. Please post questions regarding installation for other MVEBU boxes, it might be possible to do this.

1. Gain SSH to the NAS326 box.

Use the Zyxel NAS326 instruction (came with the box) for logging as admin user through the web page of the box, set password, and Enable SSH.

2. Open a termimal and connect to the NAS326 with SSH, and login to the box as root user.

3. After logging in, get a listing of your current u-boot envs, and save it to a notepad in case you want to restore it later.

fw_printenv


4. Enter the following commands (copy/paste each line to the stock OS command line).

fw_setenv curr_bootfrom 1
fw_setenv next_bootfrom 1
fw_setenv load_dtb_addr 0x1000000
fw_setenv load_initrd_addr 0x2900000
fw_setenv load_image_addr 0x02000000
fw_setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'
fw_setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
fw_setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
fw_setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
fw_setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
fw_setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/zImage; ext2load usb 0:1 $load_dtb_addr /boot/dts/armada-380-zyxel-nas326.dtb; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootz $load_image_addr $load_initrd_addr $load_dtb_addr'
fw_setenv bootcmd_custom 'if run usb_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
fw_setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '
fw_setenv change_boot_part 1

And then list the u-boot envs again, and save it to a notepad in case there is problem with booting and it needs to be referenced.
fw_printenv


5. Plug in the USB rootfs Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2, and reboot

sync
sync
/sbin/reboot

7. After a period of time, the NAS326 will start rebooting. Wait for about 30 seconds and login through SSH.

To find the NAS:
ping debian.local

When the ping returns successful response, then login (root password is root);
ssh root@debian.local

If for whatever reason (e.g. firewall), the NAS326 cannot be found as debian.local, then find its IP in the router webpage. Or use a scanning app such as Linux nmap or IOS Fing to find the IP.

8. DONE.


B3. Normal Operation

The USB rootfs should be plugged in permanently, and if there is serial console module attached before then it should be removed during booting.

1. Whenever the NAS326 is rebooted or cold started, to boot without manual intervention, the serial console module must be unplugged from the NAS326. If the serial console module is plugged in, then step 1 in the Section A2 installation instruction must be executed (so that the NAS326 will continue booting when it detected the serial console present). Note that reboot in some instance will work with serial console plugged in.

2. If you want to boot back to stock OS in NAND, just shutdown the box, unplug the USB and power up the box. It will boot the kernel 1 in NAND and then if not successful, it will try kernel 2.

This also serves as a rescue system. Whenever the rootfs on USB has problem and cannot boot (the effect is just like the USB drive is not plugged in), the NAS326 will fall back to booting the kernel 1 or 2 in NAND. When this occurs, the u-boot envs in step 4 must be reentered at Debian command line again to allow booting back to USB rootfs.

B4. Reverse to stock OS permanently

To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at the Debian command line:

fw_setenv kernel_addr_1 0x00E00000
fw_setenv bootargs 'console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2'
and then reboot
sync
shutdown -r now

C. Instruction for booting the NAS326 with rootfs on internal HDD (setup without serial console)

C1. Requirements

1. Prepare the rootfs Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2, using one of the internal HDD, as described in Debian rootfs release section:

Quote

Updated 04 Feb 2017:

This Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2 has been uploaded.

C2. Installation

Warning: Step 4 in the instruction in this section uses a "env/code injection" to replace the Zyxel NAS326 stock u-boot bootcmd with a different command during boot. It's a simple trick that change u-boot env bootcmd (it does not touch u-boot binary in NAND). However, this hack should not be used on a different MVEBU box (any box other than the NAS326). Doing this without examining your box's stock u-boot source code could likely messing up your u-boot envs and prevent booting, or in the worse case bricking it. Please post questions regarding installation for other MVEBU boxes, it might be possible to do this.

1. Gain SSH to the NAS326 box.

Use the Zyxel NAS326 instruction (came with the box) for logging as admin user through the web page of the box, set password, and Enable SSH.

2. Open a termimal and connect to the NAS326 with SSH, and login to the box as root user.

3. After logging in, get a listing of your current u-boot envs, and save it to a notepad in case you want to restore it later.

fw_printenv


4. Enter the following commands (copy/paste each line to the stock OS command line).

fw_setenv curr_bootfrom 1
fw_setenv next_bootfrom 1
fw_setenv load_dtb_addr 0x1000000
fw_setenv load_initrd_addr 0x2900000
fw_setenv load_image_addr 0x02000000
fw_setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
fw_setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
fw_setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'

fw_setenv sata_init 'mw.l f1018100 20420000; mw.l f1018140 003ca800; sleep 3; scsi init'
fw_setenv sata_bootcmd 'echo Booting from SATA ...; setenv fdt_skip_update yes; run sata_init; ext2load scsi 0:1 $load_image_addr /boot/zImage; ext2load scsi 0:1 $load_dtb_addr /boot/dts/armada-380-zyxel-nas326.dtb; ext2load scsi 0:1 $load_initrd_addr /boot/uInitrd; run sata_set_bootargs; bootz $load_image_addr $load_initrd_addr $load_dtb_addr'
fw_setenv sata_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
fw_setenv bootcmd_custom_sata 'if run sata_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
fw_setenv bootcmd_custom 'run bootcmd_custom_sata'
fw_setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '

And then list the u-boot envs again, and save it to a notepad in case there is problem with booting and it needs to be referenced.
fw_printenv


5. Insert the HDD with rootfs Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2, if not already inside the box, and reboot

sync
sync
/sbin/reboot

7. After a period of time, the NAS326 will start rebooting. Wait for about 30 seconds and login through SSH.

To find the NAS:
ping debian.local

When the ping returns successful response, then login (root password is root);
ssh root@debian.local

If for whatever reason (e.g. firewall), the NAS326 cannot be found as debian.local, then find its IP in the router webpage. Or use a scanning app such as Linux nmap or IOS Fing to find the IP.

8. DONE.


C3. Normal Operation

The HDD rootfs should be plugged in permanently, and if there is serial console module attached before then it should be removed during booting.

1. Whenever the NAS326 is rebooted or cold started, to boot without manual intervention, the serial console module must be unplugged from the NAS326. If the serial console module is plugged in, then step 1 in the Section A2 installation instruction must be executed (so that the NAS326 will continue booting when it detected the serial console present). Note that reboot in some instance will work with serial console plugged in.

2. If you want to boot back to stock OS in NAND, just shutdown the box, remove the HDD rootfs and power up the box. It will boot the kernel 1 in NAND and then if not successful, it will try kernel 2.

This also serves as a rescue system. Whenever the rootfs on HDD has problem and cannot boot (the effect is just like the HDD drive is not plugged in), the NAS326 will fall back to booting the kernel 1 or 2 in NAND. When this occurs, the u-boot envs in step 4 must be reentered at Debian command line again to allow booting back to HDD rootfs.

C4. Reverse to stock OS permanently

To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at the Debian command line:

fw_setenv kernel_addr_1 0x00E00000
fw_setenv bootargs 'console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2'
and then reboot
sync
shutdown -r now

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 2 time(s). Last edit at 08/21/2019 01:58PM by bodhi.
Re: Zyxel NAS326 Installation
September 09, 2019 07:14AM
Hi bodhi,

in the Linux Kernel 5.2.9 MVEBU package and Debian armhf rootfs installation instructions, you state:
Quote

Remove flash-kernel first to avoid potential problem.
Is this still valid?
I use flash-kernel to simplify/automate the uboot image creation.
I installed flash-kernel from the Debian buster archives and added /etc/flash-kernel/db like this:
Machine: Zyxel NAS326
U-Boot-Kernel-Address: 0x8000
U-Boot-Kernel-Entry-Point: 0x8000
U-Boot-Initrd-Address: 0x0
Boot-Kernel-Path: /boot/uImage
Boot-Initrd-Path: /boot/uInitrd
Required-Packages: u-boot-tools
DTB-Id: armada-380-zyxel-nas326.dtb
DTB-Append: yes
It worked well for kernels 4.20.6-mvebu-tld-1 and 5.2.9-mvebu-tld-1, the images were created automatically as part of installing the kernel deb package.

regards
kralan
Re: Zyxel NAS326 Installation
September 09, 2019 05:18PM
Hi kralan,

Quote

Remove flash-kernel first to avoid
> potential problem.

> Is this still valid?

> I use flash-kernel to simplify/automate the uboot
> image creation.
> I installed flash-kernel from the Debian buster
> archives and added /etc/flash-kernel/db like
> this:
>
> Machine: Zyxel NAS326
> U-Boot-Kernel-Address: 0x8000
> U-Boot-Kernel-Entry-Point: 0x8000
> U-Boot-Initrd-Address: 0x0
> Boot-Kernel-Path: /boot/uImage
> Boot-Initrd-Path: /boot/uInitrd
> Required-Packages: u-boot-tools
> DTB-Id: armada-380-zyxel-nas326.dtb
> DTB-Append: yes
>
> It worked well for kernels 4.20.6-mvebu-tld-1 and
> 5.2.9-mvebu-tld-1, the images were created
> automatically as part of installing the kernel deb
> package.

The instruction is still valid for a good reason.

To be clear, there is no problem with flash-kernel. That's the Debian way to do installation automatically while we run the mainline Debian kernel. For experienced users like you, usually you would do a cursory check for the /boot directory after upgrading kernel or apt-get upgrade to see everything is normal. So it is OK to use flash-kernel if you know the /boot files well and see problems right away. So you would want to automate the installation process like what you did above.

The potential problem with using flash-kernel is for less eperienced users. If the rootfs was not created by using my release rootfs, then it is possible that the user is installing my customed build kernel from a mainline Debian debootstrap rootfs, therefore there is a mainline Debian kernel on it. This is where the problem potentially will occur if there is a mix of mainline and customed kernels in the rootfs. flash-kernel does not recognize the customed kernel, thus the uImage and uInitrd might be generated from a wrong version. uInitrd problem usually occurs during apt-get upgrade. In the past, I've seen even uImage was not correct sometime (iirc).

So I wanted to prevent all possible pitfalls by instructing users to generate these 2 files manually, not with flash-kernel. And by removing flash-kernel from the rootfs while running a customed kernel, it will prevent future problems, too.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 09/09/2019 05:19PM by bodhi.
Re: Zyxel NAS326 Installation
September 10, 2019 04:36AM
bodhi Wrote:
-------------------------------------------------------

> The potential problem with using flash-kernel is
> for less eperienced users. If the rootfs
> was not created by using my release rootfs, then
> it is possible that the user is installing my
> customed build kernel from a mainline Debian
> debootstrap rootfs, therefore there is a mainline
> Debian kernel on it. This is where the problem
> potentially will occur if there is a mix of
> mainline and customed kernels in the rootfs.
> flash-kernel does not recognize the customed
> kernel, thus the uImage and uInitrd might be
> generated from a wrong version. uInitrd problem
> usually occurs during apt-get upgrade. In the
> past, I've seen even uImage was not correct
> sometime (iirc).
>
> So I wanted to prevent all possible pitfalls by
> instructing users to generate these 2 files
> manually, not with flash-kernel. And by removing
> flash-kernel from the rootfs while running a
> customed kernel, it will prevent future problems,
> too.

If you want to differentiate your custom kernels from Debian's, add
Kernel-Flavors: tld-[1-9] tld-[1-9][0-9]
to /etc/flash-kernel/db.
Flash-kernel will refuse to act on kernels without the right suffix, then.
Admittedly, this will match only the first 99 revisions, because of the limited pattern matching abilities of the shell used.

Flash-kernel is for the lazy guys. I found it tedious and error-prone having to look up the image generation commands on every kernel upgrade.

Nevertheless, I regard sharing the manual process as essential.

kralan



Edited 1 time(s). Last edit at 09/10/2019 04:41AM by kralan.
Re: Zyxel NAS326 Installation
September 10, 2019 07:44AM
kralan Wrote:
-------------------------------------------------------
> bodhi Wrote:
> -------------------------------------------------------
>
> > The potential problem with using flash-kernel
> is
> > for less eperienced users. If the rootfs
> > was not created by using my release rootfs,
> then
> > it is possible that the user is installing my
> > customed build kernel from a mainline Debian
> > debootstrap rootfs, therefore there is a
> mainline
> > Debian kernel on it. This is where the problem
> > potentially will occur if there is a mix of
> > mainline and customed kernels in the rootfs.
> > flash-kernel does not recognize the customed
> > kernel, thus the uImage and uInitrd might be
> > generated from a wrong version. uInitrd problem
> > usually occurs during apt-get upgrade. In the
> > past, I've seen even uImage was not correct
> > sometime (iirc).
> >
> > So I wanted to prevent all possible pitfalls by
> > instructing users to generate these 2 files
> > manually, not with flash-kernel. And by
> removing
> > flash-kernel from the rootfs while running a
> > customed kernel, it will prevent future
> problems,
> > too.
>
> If you want to differentiate your custom kernels
> from Debian's, add
>
> Kernel-Flavors: tld-[1-9] tld-[1-9][0-9]
>
> to /etc/flash-kernel/db.
> Flash-kernel will refuse to act on kernels without
> the right suffix, then.
> Admittedly, this will match only the first 99
> revisions, because of the limited pattern matching
> abilities of the shell used.

Yes. We knew this is possible :) But I chose the simpler and foolproof installation steps. It shows what’s going on behind the scene.

> Flash-kernel is for the lazy guys. I found it
> tedious and error-prone having to look up the
> image generation commands on every kernel
> upgrade.

history command would be useful for this.

-bodhi
===========================
Forum Wiki
bodhi's corner
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: