[Announce] NAS-CC: Alternate firmware for NAS200 without any services!

Announcing release of my NAS200 firmware mods


Please read the entire posting before you begin!

Hi, I am pleased to announce a new alternative firmware for the NAS200. Unlike other NAS200 firmware, my firmware actually has the least amount of functionality available from any competing NAS200 firmwares.

It does however allow you to boot other firmwares from a storage device (SATA or USB).


It can be found here:

SourceForge project page

Downlaod page: SourceForge

As usual, use at your own risk! I will not be responsible if your data or configuration disappears, if you brick your box or if you let the Magic Blue Smoke escape. I recommend making a backup or everything (data, configuration, firmware) before you start.

Installation

1. Create and populate a boot share
2. Flash your device with the nascc-boot.bin firmware file
3. Reboot

To create a boot share you must create a share in the root of any of the SATA volumes named either "boot" or "etc". This will work even if your NAS200 is configured as independant drives, JBOD, RAID1 and RAID0. Alternately, you can simply create a "boot" or "etc" directory on a USB drive, or just use the root directory of the USB drive.

In this boot share/directory, you must copy a firmware file. Usually is a file of 8MB size that has a .bin extension.

You must now create a file called: fwboot42.sh with a line:

fwname=NAME_OF_FW.bin

Replace NAME_OF_FW_.bin with the actual name of the firmware file.

To flash yor device, you must download the tar-ball containing the firmware and use the nascc-boot-XXX.bin file.

To do this, simply download it through the Firmware Upgrade webpage of the NAS200 web GUI. You will get a popup saying that your NAS200 will reboot in 30 seconds, and the NAS200 will beep and all lights will go on when it reboots. Click OK on the notification.

At this point you have a NAS200 with a very basic firmware, however this firmware is able to boot a more full-featured firmware either from a USB drive or from your SATA disc.

Make sure you read the included README file for all the options available with the boot firmware.

If you have a serial port connected, you can see what's going on.

Alex

Alex,

Thanks for NAS-CC, this is exactly what I was after!

A couple of bugs to report:

First, I'm using ext3 and if any of the inserted drives were not cleanly unmounted, then the firmware fails to finish booting - it just hangs. To work around this, I'm removing all drives, booting it into failsafe mode, then hotplugging the drives to fsck them. For anyone who ends up needing to do this, echo '- - -' > /sys/class/scsi_host/hostX/scan to rescan for SATA drives and note that the partition labels will probably end up different.

Second, I'm having trouble getting a chroot script to work. It seems to run the script and pivot_root, but fails to exec (my) init. /rc (pid 1) is stuck on pipe_wait (from /proc/1/wchan), there are a ton of zombie mount processes and a zombie /rc (pid > 1). Looking at /rc, I think it has successfully run tryboot, but has not done anything after that point.

It has not unmounted /sys (though incidentally that should be /mnt/sys as this is after the pivot) and its fds (from /proc/1/fd) are connected to /mnt/dev/console, not /dev/console as I would expect.

I've not had to open up and connect a serial cable yet, so that's all the information I have - I had my chroot script run a telnetd so that I could get in.

Any ideas?

I don't know if Alex is supporting NAS-CC anymore. There hasn't been any activity in the project for a few months and the current source no longer builds due to out of date dependencies.

Yes, NAS-CC uses an old version of Buildroot. It is currently broken because one of the library modules included is an old version that is no longer available.

I'm currently working with Buildroot to build a custom NAS200 firmware at the moment. Stay tuned for more soon as well.

Hi,

I haven't have time to do much on my NAS-CC software. I recently moved to a new house and I still don't have Internet at home. I still have a lot of things on my todo list for NAS-CC.

I will take a look at the bugs reported by ribe. However, currently I am very limited with my hacking time.

Similarly, thanking for reporting the build problems, do you care to report which were the out-of-date dependancies? I typically don't test these fully as I usually donload them to my disc and use my offline copy.

If you tell me which old library module is no longer available I should be able to put it up for download.

Some comments, I was using the most recent buildroot at the time. In theory I tried to keep the changes to buildroot as limited (or as unintrusive) as possible, so switching to a newer buildroot shoud work (without much hacking). However, this is not always trivial.

My plan was to take a frozen version of buildroot, use it for a few months and then upgrade to a newer version. (buildroot gets updated nearly daily).

Like Jac did, I also took a look at OpenWRT (but not OpenEmbed). The thing I did not like about OpenWRT is that it pulls in quite a lot of hardware dependant stuff which was very complex for me to understand and I was not going to be able to use. So I chose buildroot instead (which starts of more generic) and added the NAS200 dependant bit.

Adding new software to buildroot is not too complicated.

Is there any activity at all in this project? If so, could you provide the latest tree you got? I'd like to make some changes and upgrade it to more recent versions but it could be useless if you already got a new tree

Or do you have anything new already dsc68?

buildroot is preparing a new stable version at the moment. When their stable version comes out I'll look at building a NAS200 version.

From what I have been able to determine, the sequence to build the firmware is:

1. Unpack the nascc tarball
2. Copy the buildroot tarball to the nascc directory
3. Edit the line in the Makefile which specifies what release of buildroot you are going to use
4. Clone one of the packaged profiles to your new <profile> with ./mk clone std <profile>
5. Unpack the build directory with ./mk unpack <profile>
6. Modify the profile config with ./mk <profile> menuconfig
./mk <profile> busybox-menuconfig
./mk <profile> uclibc-menuconfig
./mk <profile> linux26-menuconfig
7. Build the firmware with ./mk <profile>
8. Package the firmware with ./mk <profile> firmware


However, I haven't been able to get a successful build. The included buildroot is out of date and one of the included packages is no longer available (I can't remember which off the top of my head). Using a more recent buildroot runs into problems with the various patch files not working - though as far as I can determine most of them are no longer required particularly with the RDC support now included in the kernel. buildroot is also has been a bit unstable recently as they are working towards a stable release.

I've also had problems with Alex's binaries not work as intended. The boot firmware doesn't seem to run all of the initialisation scripts of the replacement environment properly.

dsc68 got it allmost right.

First you must unpack the nascc tarball and place the buildroot tarball in there.

There are three profiles, boot, bare and std. Only boot is meant to be flashed into the NAS flash. To get a new boot firmware the steps are:

1. ./mk unpack boot
2. ./mk boot
3. ./mk firmware boot

The other profiles tend to be too large to fit in the flash. To create your own profile (that will be chainloaded by the boot profile)

1. ./mk clone std <profile>
2. ./mk unpack <profile>
3. ./mk <profile>

This will create a kernel and a root file system in binaries/<profile>, these need to be put in a boot partition.

Unfortunately I am still without Internet so I can't check which package is out of date still.

Once I do, I will either post the missing dependancy or a new patch.

On the boot firmware not running all of the initialisation scripts, that could be, as I did not test the chroot stuff fully.

I've traced the problem with the init scripts to sysinit failing because it tries to fsck the mounted root volume. Adding -r to the fsckoptions fixes the problem.

Hi dsc68,

What does -r do? According to the man page it says:

-r

This option does nothing at all; it is provided only for backwards compatibility.

Sorry, my wrong - I meant -R

-R When checking all file systems with the -A flag, skip the root file system (in case it's already mounted read-write).

rc.sysinit fails without the option because the root partition is already mounted r/w

Alternatively it could be that the root partition is mounted as r/w at this stage when it should be r/o

Hi,

Finally got my Internet so I posted a new version of my firmware 0.1.3rc1. Contains bug fixes to all the bugs listed in this thread. i.e. chroot script bug, the -R flag for fsckoptions, the ONE URL that was out of date was corrected, etc.

So this one is buildable. It still uses an old buildroot snapshot. I am waiting for Jac to finish his gentoo work before I move to the current buildroot release.

Finally, I compiled an AoE server. However, this feature has not been tested.

You can download this from: sourceforge.net

Thanks Alex,

I suspect the -R flag issue is actually a work around for a different problem. The root partition should really be mounted as R/O up until after the the fsck section of the rc.sysinit script, after which it should be remount as R/W. As it is now, the root partition will never be fsck'ed.

Another issue I have encountered is that if you use a hard coded IP address instead of DHCP, there is no where to set a default gateway. rc.d/network just needs a route command included after the ifcfg.

Hi Alex,

Im curious, which AoE server did you compile? vblade? which version?
I was working on this the last three days and a I managed to compile and run successfully "vblade-16". But that is the last version that works for me.
I started with 19 (last one) that didn´t work an from that point I started to downgrade until I get 16 up and running.

I transfer a few files but the performance is really poor that´s why I´m planning to try other implementations (mostly kernel modules instead of userspace apps) in the quest of better performance.
It seems to me that iSCSI is a lot lot faster.
Anyway if anybody is interested in benchmarking vblade, let me know and I will upload the binaries.

Keep improving! :thumbup:

Fernando

PS: I couldn´t format an AoE device from my Windows Vista workstation with NTFS. It keeps failing but I didn´t have problems with FAT32. Weird don´t you think? With iSCSI I didn´t have any problems.

I also noted that Jac but I couldn´t understand why.
I disable the promiscuous mode on the network adapter but everything is still OK.
I though that by doing that maybe the NIC or the system was going to have a little better performance. Silly me.... :frown:
I couldn´t think of a way yet to get 2 or 3 more MB/s from this little friend.
iSCSI didn´t do the trick and AoE was a lot more dissapointing.
Anyway I will keep searching, reading and thinking, at least is a good exercise. :tongue:

Hi,

As usual, documentation is always lacking...

1. 1. The default root install would configure the root partition to mount read-only, however this can be changed in the boot script file. Actually, root is designed to ALWAYS run read-only. You only need to mount your /etc and /var read-write and mount exported filesystems under /data (again rw)
2. If you want to configure to use static IP address you need to create a file /etc/config.d/network and in there place the following:
   
   Code:

   bootproto=static
   ipaddr=static-ip-address
   snmask=255.255.255.0
   gw=ip-address-of-gateway
   domain=domain-to-search-dns
   ns=ip-address-of-nameserver
   

   You can specified more than one name server if you surrond them with quotes and separate with spaces.
   
   For example:
   
   Code:

   bootproto=static
   ipaddr=10.0.0.20
   snmask=255.255.25.0
   gw=10.0.0.1
   domain=example.net
   ns="10.0.0.1 10.0.0.2"
   

The AoE server that I compiled was qaoed v0.81 from http://pi.nxs.se/~wowie/. I picked that one because it is multithreaded and can be configured from a file.

The kernel that I compile 2.6.20.4 does not set the interface to PROMISC. On the other hand I did not have that much time to work on the NAS200... This post was just a collection of a bunch of stuff that I did for the 4 months that it took my Internet to get connected (don't ask!)

One SAN protocol that sounds interesting would probably be NBD. I found that qemu comes with a qemu-nbd server. While this will not make things faster, it is supposed to support COW images (Copy-on-write).

Hi Alex, did you test/benchmark qaoed?

I compile it for jac2b and also vblade (I´m working on a kernel module AoE target know which seems to be a little more harder to compile but maybe a little bit faster when running). Anyway a test both of them with very laaaaame results. No more than 1050KByte/s (aprox 1 MB/s) for writings and even worst for reading, a little bit more than half the speed of writing, around 750KB/s.
I´m using a regular file for export with both of them and also with iSCSI. And in my experience iSCSI is more than 4-5 times faster than AoE in opposition to the theory.

Yup, nothing better than practical testing to prove/disprove theory.

I think the conclusion can be made. NAS200 is just slooow...

Finally I´m getting convince of that frustration after frustration.... :frown:

Hi,

I uploaded a new NASCC firmware version. As always, it can be found here:

https://sourceforge.net/projects/nascc/files/

This version goes back to basics. Essentially means that NASCC is 1st stage boot firmware. Most of the functionality is meant to be provided by the 2nd stage environment.

This version is more compatible with the vendor supplied firmwares in the sens that now you can put your boot scripts in the DISK_1 or PUBLIC_DISK shares of your NAS200. (It can be either on the root or on a /boot or /etc folders).

I am currently using this version to boot into CentOS.