I managed to get my hands on a HP Media Vault mv2120, a nice ARM based NAS device, a few months ago with the intentions of porting Debian to it. Unfortunately, I have been really busy lately and most of my time was spent on adding support for the QNAP TS-109/TS-209 and TS-409 (which required a lot of generic work to get Marvell Orion support into Debian, a new SoC used in many NAS devices, including the QNAP TS-x09 and HP mv2120). There were a number of things that had to be worked out before Debian would run on the mv2120. The good news is that Marc Singer and Eugene San have done all of the heavy lifting in the last few weeks in figuring out how the mv2120 works and that now it's just a matter of putting everything together for Debian to work. Here are the issues that had to be worked out:

• Figure out how the rescue mode works and how to construct a rescue image that the device can boot: I knew that the mv2120 had a rescue mode that can be activated by keeping the the power and reset buttons pressed when starting that would request a rescue image via the network. This rescue mode can be used to start the Debian installer. Eugene San figured out how to construct a rescue image that the mv2120 would accept. Marc Singer has also written a tool, uphpmvault, to serve such rescue images from Linux.
• Figure out the best way to make one image that contains the kernel and ramdisk: the mv2120 only loads a kernel and no ramdisk, but a ramdisk is needed to start Debian. I discussed some really ugly hacks with Marc Singer to get the mv2120 to accept an image consisting of kernel and ramdisk but Marc wanted to try something else first. u-boot, the boot loader used on the mv2120, can accept something called a multipart image which can consist of a kernel and a ramdisk. When Eugene San heard that we were trying to load a multipart image, he went ahead and figured out how to construct an image that the mv2120 would boot.

Now that these two issues are resolved, I simply need to put everything together and add support for the mv2120 to a number of debian-installer components. We already have Orion kernel images in unstable that support the HP mv2120 (along with a number of other Orion based NAS devices) and the rest shouldn't take too long.

Beta 3 of debian-installer has been released recently and some people are wondering about the status of Debian on Linksys NSLU2. This ARM based device includes an Ethernet chip for which Intel provides a driver (based on some code which only recently became free software and which still requires some microcode which is only distributable together with a click-through license). During the beta 3 development process, I tested the installation on NSLU2 with my USB Ethernet gadget to make sure it works. When beta 3 came out, I wanted to integrate Intel's module and make unofficial images available. Marcus Better did some great work in the last few weeks putting the sources into a Debian packages from which the modules can easily be created. Unfortunately, they don't seem to work. My kernel oopses immediately when I insert them. I spent more than a day compiling the modules myself, trying various things, but to no avail. I have now given up and sent a call for help. What this means is that the unofficial images with the Ethernet driver are unsupported right now, even though Debian on NSLU2 works fine if you have a USB Ethernet adapter. In the long run, I hope to be able to support Ethernet using a driver which is currently being developed. The author has made good progress already and is aiming for mainline inclusion. I hope it will be usable on the NSLU2 in the next few weeks but it's hard to tell. There has also been some development that users may not directly see but which is important maintenance work. The firmware of the NSLU2 has a 1 MB limit for the kernel. So far, we have provided a special kernel for the NSLU2 but it would be better if we could use one generic kernel for all IXP4xx based devices. Together with Marc Singer, the author of APEX, we're now integrating his boot loader as a 2nd stage loader to work around this limit. In summary, NSLU2 development work is still being done, even though the in-built Ethernet is currently not supported. This problem will be addressed in the long run with a proper, mainline driver which will hopfully be usable in the next few weeks. Help with NSLU2 support is welcome because even though I'm still working on it, I now have a number of more interesting devices I'm currently working on (more on this later).