OMV on Zyxel NSA320 ?

  • Just got it: my NSA320 runs Kralizec 1.12 on Kernel 3.17.0 booted from the first internal HD. :D

    Now i have to test the performance of the box under OMV - if it's sufficient, it'll become my backup machine...

    If someone (or two ;) ) is(are) interested, i could write a HowTo...


  • @Akeem
    The NSA-325 ist different to the NSA-320. I think you can use dfarnings method described on your linked pages. You'll also find a lot of helpful information and a rootfs on,12096 .

    I wanted the box booting from HD, because a USB-Pen drive will be defective after a week or shorter. The scripted setting of the uboot environment variables for hd-booting was my main challenge.

    A solution for the USB-problem could be the use of a SLC-PenDrive (e.g Mach Xtreme Technology ES SLC USB 3.0 Pen Drive - 8 GB) or an external USB-HD. The latter didn't work for the 320, because the USB-Ports don't deliver enough power for a disk - perhaps it's enough for a 2,5" SSD...

    For the rsync-config we made a HowTo a few weeks ago: Rsync two OMV machines


  • Meanwhile kernel 3.18 is running on my NSA-320, LED are blinking and the powerbutton switches the machine off. Everything seems to run fine thanks to the great work and help from bodhi in the

    As i wrote, i installed Debian and OMV on the first internal HDD, because a USB-flashdrive would be worn out too fast.

    Now i'm thinking about creating a datapartition on the same HDD where the rootfs-partition resides, from that the box boots (with parted while i mount the drive in another Linux system).
    Is it possible to mount a data-partition in OMV, that resides on the system-drive?
    If yes: will that significantly degrade the performance?

    What do you experts think about that?


  • No thoughts?
    Ok, i tried it, and it works: system and data on sda - sda1 (ext3) and sda2 (xfs).
    Testing from Win 8.1 with Helios LanTest over Gigabit LAN: 30 MB/s write, 17 MB/s read.
    h2testw: 34,8 MB/s write, 21,1 MB/s read.
    Test with separate HDDs follows...

    Test with separate Drives: Helios LanTest 20,4 MB/s write, 17,5 MB/s read
    h2testw: 30,1 MB/s write, 16 MB/s read.
    MTU in all tests was default 1500.
    Strange: write ist faster than read and single disk ist faster than separate disks.

    Any ideas where to optimize what settings?


  • I quite like your monologue.
    I can't be of any assistance, but would be interested in a step-by-step to be able to use OMV ánd use both internal HDDs.
    I wouldn't mind to buy a USB-SSD device.

    I'd would love to use btsync on the main OMV box ánd on the NSA325. Btsync does exactly what I wanted to achieve with rsync.

  • Follow the tutorial here,14351
    Use the rootfs linux-3.16.0-kirkwood-tld-2-rootfs-bodhi.tar.bz2from 02 Sept 2014 in the thread,12096 and not the latest as said in the tutorial. Going beyond that rootfs requires you to flash a more advanced bootloader, which is not something for the faint of heart (also because it makes the device unable to boot its own original firmware).

    I have a zyxel nsa325v2 and it works.

    Although I have already flashed a better bootloader and I'm not anymore at the rootfs 3.16.

  • I have a NSA320 and would be very interested in getting it running on my device. Have seen some instructions, also from the NS325. But just only few information on nsa 320. Or can i follow instructions which are given for NSA325?
    Could give me step by step HowTo (if you may do do not have it already)?? or do we have to wait for one more on NSA 320 device ;)

  • Pioneers did it with serial cable to the board or with hacks from the web interface, and that's what is more commonly found in tutorials. Nowadays there are easy installers using a script.

    Here for example there is a nice installer with simple instructions, but works for Arch linux, not for Debian.
    Will modify it a bit to make a version that allows you to boot Debian.
    Just like the tutorial I posted above for the NSA325V2, that is actually using a modified version of the Arch installer for the NSA 325.
    These things are always done AT YOUR OWN RISK. If you don't feel safe enough, DON'T DO IT.

    AFAIK, the u-boot (bootloader, the BIOS of this thing) is too old to be able to boot from USB, can only boot the NAS's original firmware from the flash on its motherboard (too small to install debian in it) or from Sata drives. More updated u-boots with plenty of advanced features are available in the forums of the links above, but it's dangerous to update as if you do it wrong the device can only be restored through the serial cable (IF it can be restored at all), just like updating a BIOS anyway.

    After you followed instructions below and it did its thing, the NAS will be
    set to boot from the left Sata drive, and won't boot again its own
    firmare. (this can be changed easily from inside the Debian system, and
    from a serial connection to the motherboard, but if you don't have
    either working, it's not possible to do anything and you are in trouble)

    So, download the installer zip I modified from here https://dl.dropboxusercontent.…INUX/
    Extract the contents of that zip inside an EMPTY USB flash drive.

    Then download the rootfs (the Debian system for these devices, same as link above)
    The file is Debian-3.16.0-kirkwood-tld-2-rootfs-bodhi.tar.bzip2, so it is compressed with bzip2 and I have no idea if the firmware of the device is able to handle it, so we need to convert the archive to tar.gzip first.
    Download Peazip (it is portable version, will run without installing itself)
    Then extract the archive you downloaded, you should get another archive called Debian-3.16.0-kirkwood-tld-2-rootfs-bodhi.tar
    Now use Peazip to compress it again, but this time select Gzip (it is set to 7z by default, you don't want that, change it to Gzip).
    Now you should get a file called Debian-3.16.0-kirkwood-tld-2-rootfs-bodhi.tar.gzip
    Rename the file into rootfs.tgz
    Very important as the install script will look for this name to install Debian.
    Then place this file in the same USB flash drive you placed the files of the installer zip above.
    Shut down the NAS.
    Place a EMPTY HDD in left slot (the installer WILL ERASE ANYTHING ON THAT DRIVE, so IT MUST BE EMPTY), remove the drive from the other slot, place the USB flash drive into the front USB port, power on the device.
    Wait a bit. It has to unzip the contents of that file (among other things), and that's a weak processor, so it will take some time.
    After it has finished it will reboot on its own, and if all went well it will be running Debian ARM this time.

    If it was connected to ethernet, it will get an IP address automatically when rebooting.
    At this point it's just a headless (no graphical interface) Debian Wheezy system like any other.
    You need to connect to it with SSH (remote terminal), if you don't know how, see this tutorial…om-windows-by-using-putty
    User: root
    Password: root

    (when you have finished the setup it would be a good idea to change the default password of root user)

    Then you follow the instructions here to install OpenMediaVault, (ignore pre-requirements because you have already a running Debian Wheezy in that NAS)
    Howto install OpenMediaVault on Debian 7.x (Wheezy)

    It will take a while because it has to download quite a few things, and its weak processor will slow down the installation process.

    When I did it, something of OMV failed to install and required a manual tweak, if it happens to you too (I think it was fixed but you never know), post the error and I'll see what I can do.

    The installation will take around 10 GB of the drive inside the NAS for system partitions, the rest of the space will become another partition you can use for data (look in Storage ----> Filesystems to set Openmediavault to mount it and use it).

    NEVER EVER install any Kernel or Grub, the Debian running inside these devices has a custom Kernel, if you install another (not from the forums above) it will not boot anymore. Grub is a bootloader, you have already u-boot for that.

    ======Will give you a run down of what happens while you wait and it installs Debian. ===========
    ======Mainly informative purposes, you can skip reading this if you want========
    The installer is a script that exploits the fact that this NAS is set to look inside USB drives when booting.
    If it finds the stuff that you placed into it (some keys plus a script with a peculiar name) it reacts by loading and executing the script.

    The script changes the boot options in the u-boot.

    The script then ERASES EVERYTHING that is currently on the left sata drive, so USE AN EMPTY DISK OR YOU WILL LOSE DATA, also REMOVE ANY OTHER DISK FROM THE NAS while you are doing this.
    Then it makes a couple partitions it needs, using around 10 GB of disk space. The rest of the space becomes a third partition you can use for data.
    Then it unzips the rootfs.tgz (this is the archive with Debian inside) and moves the files where they need to go.
    Since the processor is weak the unzipping will take some time, be patient.

    Then it will reboot, and if everything went well the NAS will boot Debian Wheezy for ARM.

  • Nice guide, tried it already and did everything in same way you describe aboved. BUT seems I chrashed my system, also can not install again via USB Stick.
    Connected with serial cable and got folloing output. any idea what i could do nex?

    | \/ | __ _ _ ____ _____| | |
    | |\/| |/ _` | '__\ \ / / _ \ | |
    | | | | (_| | | \ V / __/ | |
    |_| |_|\__,_|_| \_/ \___|_|_|
    _ _ ____ _
    | | | | | __ ) ___ ___ | |_
    | | | |___| _ \ / _ \ / _ \| __|
    | |_| |___| |_) | (_) | (_) | |_
    \___/ |____/ \___/ \___/ \__|
    ** MARVELL BOARD: RD-88F6281A LE

    U-Boot 1.1.4 (Mar 23 2011 - 16:09:39) Marvell version: 3.4.19

    U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFEE0

    Soc: 88F6281 A1 (DDR2)
    CPU running @ 1200Mhz L2 running @ 400Mhz
    SysClock = 400Mhz , TClock = 200Mhz

    DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
    DRAM CS[0] base 0x00000000 size 256MB
    DRAM CS[1] base 0x10000000 size 256MB
    DRAM Total size 512MB 16bit width
    Addresses 10M - 0M are saved for the U-Boot usage.
    Mem malloc Initialization (10M - 7M): Done
    NAND:128 MB
    Flash: 0 kB

    CPU : Marvell Feroceon (Rev 1)
    //--- stateButtonBit = 3, recovery ---//
    Kernel address is 0x4640000.

    Streaming disabled
    Write allocate disabled

    Module 0 is RGMII
    Module 1 is TDM

    USB 0: host mode
    PEX 0: interface detected no Link.
    Net: egiga0, egiga1 [PRIME]
    Hit any key to stop autoboot: 0

    Reset IDE:
    Marvell Serial ATA Adapter
    Integrated Sata device found
    [0 0 0]: Enable DMA mode (6)
    Device 0 @ 0 0:
    Model: ST2000DM001-9YN164 Firm: CC4B Ser#: Z2F0CCD1
    Type: Hard Disk
    Supports 48-bit addressing
    Capacity: 1907729.0 MB = 1863.0 GB (-387938128 x 512)

    ** Unable to read "/uImage" from ide 0:1 **

    ** Unable to read "/uInitrd" from ide 0:1 **
    ## Booting image at 02000000 ...
    Bad Magic Number

    best wishes

  • Ops, sorry for that. :(
    Since you have the serial connection we can find out where I screwed up and make an installer that actually works next time. :)
    I'm also uploading a rootfs.tgz that I'm sure it works, whenever ready I'm posting the link.
    Also you can fix the issue right away, see below after the ===============

    It seems it does not find the boot partitions.
    this line (and the other similar one)

    Unable to read "/uImage" from ide 0:1

    says it is trying to load Debian from a disk located at address 0, from the partition 1.
    The disk you have is being seen as Disk 0, but what about partitions?

    Power on the device, press a key to stop autobooting

    Then you will see
    Marvell >>
    and a blinking cursor,

    ide partition 0

    then can you post the output here?

    also, can you write


    and post the output here?

    In the forum reply box there is a <> button, select all the text you pasted from the console and press that button. It will add tags so the forum displayes correctly the text and will not look messy.

    If you are in a hurry, you can return to boot its own firmware, see below.

    Power on the device, press a key to stop autobooting

    Then you will see
    Marvell >>
    and a blinking cursor,
    you will need to write

    setenv to_stock

    and then press enter
    then write


    and press enter
    then write


    And press enter again.

    The first command tells the u-boot to go back to booting the NAS's own firmware, the second tells the uboot to save the setting, the last asks it to reboot.

  • I did all these manipulations by hand, not with a script.

    Maybe uboot ist looking for uInitrd and uImage in the root directory, but they are in the boot directory in bodhis rootfs. I made symbolic links in root to the files in /boot to solve this.

    I used another linux machines (my OMV-Microserver) cli for that: just connected the NSA-hdd with an USB-SATA-Adapter and mounted the disk. Mind that the symbolic links must be relative, not absolute.


  • I did all these manipulations by hand, not with a script.

    A script is more user-friendly and saves time when doing mainteneance. Once it is written correctly and it does not fail, anyway.

    I did it by hand in my 325V2 (also because I have Linux Mint Debian on my netbook, so working with Linux paritions and archives is pretty easy as I just need to use Gparted and other standard tools) and also hot-booted the nas with another uboot through the serial (to be sure that in case i screwed up when flashing the newer uboot I could still unbrick the device), so it's not like I'm unable to do everything by hand.


    Maybe uboot ist looking for uInitrd and uImage in the root directory

    if the script ran correctly the contents of boot directory are in first partition (ext2), and the rootfs (parameters passed to kernel) is the partition labeled "rootfs" (the second partition, an ext4 that the uboot itself cannot read, but that's irrelevant as it's stuff that will be done by the kernel).


    I made symbolic links in root to the files in /boot to solve this.

    if your u-boot can read the boot partition (and if it is an ext3 it can) you just need to change any instance of /uInitrd to /boot/uInitrd and the same for the
    /uImage to /boot/uImage in its envs.

    After he posts the results printenv I can make a script that sets the u-boot for multibooting (like I did in my NSA325v2 before I decided to flash the new u-boot), so if booting from Sata fails it will proceed and boot its own firmware again.
    Doing so without looking at his uboot envs would have been too dangerous.

    it is just a line like this (taken from another uboot)

    bootcmd=run bootcmd_uenv; run bootcmd_usb; run bootcmd_sata; reset

    if "bootcmd_uenv" fails it will go on and run "bootcmd_usb", if that fails it will run "bootcmd_sata", if that fails too it will reboot and try again. If any of these commands run, the NAS will boot a kernel, and the uboot sequence stops because the kernel takes over.
    Even if the uboot is dumb and old this trick works.
    The same can be done to make the u-boot able to boot from either Sata drive (theoretically).

    With newer uboots it's a piece of cake (also pre-set in standard envs) as they have decent scripting support like can understand "if-then" loops and so on.


    Strange: write ist faster than read and single disk ist faster than separate disks.
    Any ideas where to optimize what settings?

    You tried using ext4 instead of xfs filesystem? I'm getting higher speeds than yours and I'm using ext4. Even the original firmware uses ext4 for hard drives, but that's faster for unknown reasons (probably better tuned for hardware).
    also someone else that reports the same, for the sake of giving some proofs of what I say.,14351,17328#msg-17328

    Yes, I know that many people say xfs is lighter on CPU.

    Another thing you can try is adding noatime and big_writes in the mount options of the data partitions in /etc/fstab and maybe optimize samba config as explained here.

  • I already got my device back to stock firmware in easy way with serial connection.
    I would like to have an script for it as i´m not too familar with Linux, programming, etc. Glad to see you will go on with it and help me.

    Late afternoon when I´m at hope i will do steps of installing debian again and post my outputs with above points as well.

  • Ty for your patience. Not having the exact device does make this harder than it should.

    I made a rootfs.tgz with linux compression tools for you (just in case Peazip was screwing up, and also because premade is better), if you reinstall can you can use this?
    it is ready to be placed in the USB drive

    Can you post the results of printenv before and after you tried to install with the script?

    Since you are going to reinstall the script anyway to test, now with serial connection attached when installing you can see what is happening when the script runs and any error message that happens will be useful for me.
    You will get a wall of text and random things as the firmware is very chatty, I don't need all that.
    The parts that matter are the text that you get after you see

    Automatic Installation of Arch Linux ARM

    as that means that the NAS is executing the modified install script.

    Did not change the original name and the debug text (there are some typos), but it does not really matter.

    If we get this working, next step is doing something similar for NSA325V2 that can boot from USB too without installing a new uboot, so any brave tester for that is also welcome, a working serial connection is warmly recommended for troubleshooting. (as I'm not going to flash stock uboot into my own NAS just to test this, flashing uboot is dangerous, as long as you have serial connection you can easily fix any issue caused by the script).

    Theoretically also NSA310 (the one-bay nas from zyxel) should be exactly the same as NSA320 (just one less sata), so after this gets fixed this installer can take over a NSA310 too.

    There is also the NSA320S (same as NSA320 but in the same box as the NSA325V2) and NSA310S (box that looks like NSA325v2 but slimmer).
    This is NSA320…wer-media-server-reviewed
    This is NSA320S

  • Ok, i did some new tests and run and also wrote down the infos you asked for. Hope this helps you - for me it´s like chinese - to find where the problem is.

    1. printenv before using script from USB:

    2. printenv after using script from USB:

  • 3. output of printenv after "Automatic Installation of Arch Linux ARM"

  • 4. Info after "ide partition 0"

    NSA320>> ide partition 0
    Partition Map for IDE device 0 -- Partition Type: DOS
    Partition Start Sector Num Sectors Type
    1 63 1028097 8
    2 1028160 -388971391 20

    A lot of codes and words . . . not sure if this really helps you. if i
    have to send more info or should test something else i would do.

  • Yeah, it did help me. Ty. :)
    Old links above are broken now, unnecessary and dangerous.

    All-in-one-installer is here…/
    Download and extract in the zip in the USB, read the README.txt file included in the package for further instructions.

    Tell me if the lights and buttons work well (or at all) in Debian ARM, if they don't I will ask you to post some more things so I can fix manually the rootfs (and give you some quick instructions for your NAS so you don't have to reinstall everything) to get them running properly.

    The NSA325V2's button and lights required manual setup when I installed (a bunch of text copy-pasted into some configuration files, nothing major), this was no more needed in later rootfs releases by bodhi in those forums (that can't be installed without a newer bootloader).
    The NSA320 should work already, being older and all.

    Will now say what it is supposed to do. (anyone tech-savyy enough can go and open up the usb_key_func files with a text editor to see for himself)

    It is now set to multiboot, if it does not find Debian in the Sata disk in left slot it will boot its own firmware again.
    It also checks that partitioning went well and that the extraction went well, before changing the bootloader.
    If the checks detect issues the script aborts and bootloader is not modified, and writes down the error in a log file in the USB drive.

    The checks are also necessary because the bootloader of this device cannot boot from disks bigger than 2TB or so (it can boot only from disks with MBR partition table, MBR partition table has a max size of 2TB for drive capacity, so all disks with more than 2TB capacity have GPT partition table that is newer and does not have this limitation)
    Newer bootloaders for this device can boot from anything, usb, large drives, even from network.

    Bootloader update procedure is much easier if done from inside the Debian ARM system, so getting it to boot Debian this way is the first step anyway.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!