DSM-G600, DNS-3xx and NSA-220 Hack Forum

You have to change the init script in initramfs. You *can't* change anything in the firmware. It's readonly.

black-tiger wrote:

root@NSA-220:~/initramfs.d# ls *
init  linuxrc

You also need the nsa220_check_file in the root of the stick. You can read a wiki page about usb_key_func.sh here.

Ah yes, a checksum file is also needed. It's probably called nsa220_checksum. The real name is inside nsa220_check_file, as you could have read in the wiki page I provided.

Last edited by Mijzelf (2010-11-29 18:07:06)

The checksum is a checksum of the provided usb_key_func.sh. So the ffp checksumfile won't work with the Debian usb_key_func.sh.

No I don't have anything like that. But you can PM me the login data, than I'll look tonight (west European time) what I can do for you.

I understand it still doesn't work?

I do not like the line 'sed: bad option in substitution expression'. It indicates that ROOTDIR has a strange value. The line 'Usage: switch_root bladibla' could be caused because you're not running this from process 0, but it could also mean that INIT has a strange value.

You can change the last lines of the script:

# copy mtab
cat /etc/mtab | sed "s/${ROOTDIR}//g" > /mnt/etc/mtab

echo ROOTDIR: \"${ROOTDIR}\"
echo INIT: \"${INIT}\"

# do the real action
cd ${ROOTDIR}
exec switch_root -c /dev/ttyS0 . ${INIT}

emergency_shell "Failed"

to show these values, and re-chroot the script.

When somebody writes the required code to boot it.

Depends. It took me a few weeks to get it going on the NSA-220, but after knowing the tricks, the same implementation for the EdMini v2 costed only one weekend.
On the other hand, these implementations rely heavily on fonz' reloaded.ko to boot another kernel/rootfs, and I couldn't get that module working for the Iomega Home Media Network Disk, which has the same cpu (OXE810DSE) and kernel (2.6.24.4) as the 210.
But the Iomega kernel is compiled with gcc version 4.3.2, while the ZyXEL kernel is compiled with gcc version 3.4.3, the same one which is used for the 220. Don't know if that matters. Maybe fonz knows.

When your 210 is available for testing, then I want to spend some hours on this problem.

With testing I mean that I send to software (scripts, modules, kernel) to test, and maybe I'll need rootaccess.

I *think* this is all harmless for your device (it was harmless for the DNS-323, NSA-220 and the EdMini v2), but of course I don't guarantee anything.

I don't know what to say. The disclaimer is actually the same as the one in the startpost of this thread. Yet I have the idea that you would have installed it on your NAS, if it was supported.
I really can't give you percentages. I just look at what the code is supposed to do, and what it might do if it fails. For reloading a kernel I *think* it will just work, or freeze the box. In the latter case a powercycle should resolve it. But I can't discard the possibility that it would overwrite the flashrom, bricking the box. I *think* it won't happen, and so far it hasn't happened. None of my own NASses have been bricked,
My 'Debian for NSA-220' package has been downloaded 369 times, but I hardly haven't had any feedback. Maybe 10 times. These 10 times there were problems, but nothing serious. And the other 359? I don't know. Assuming that all these downloads are actually installed, I can say that at least 3% of the installs didn't brick the box.

Last edited by Mijzelf (2010-12-19 22:12:47)

its weird that people dont post feedbacks even though if they are posistive

With a score of 96% non-responding downloaders, I'd conclude it is standard human behavior. Unless you argue that someone who cares about installing Debian on his NAS is weird by definition

is it possible to secure the flashrom so ...

The only way I know is desoldering the chips, but I suppose that is more risky than just hoping it won't be erased (unless you have extraordinary soldering skills).
You must take in mind that when the flashrom is overwritten, something has gone out of control. So it's not possible to control that anyway.
And yes, it is possible to backup the flashrom contents. If it is possible to put it back depends on the degree of damage. When the box still boots normal, you can write it back (but why would you?). As long as the bootloader isn't damaged it might be possible to use a serial cable to put it back, but AFAIK nobody has done this yet. (It has been done with the 220, but on the 210 it's not necessarily the same). When the bootloader is damaged it might be possible to reprogram the flash by using a JTAG cable. Again, AFAIK nobody has done this yet.
BTW, a damaged flashrom was only an example. If I had to brick a NAS softwarematically, I'd erase the flashrom. Easy and effective. I suppose it is also possible to brick it by turning off the fan and let the processor and disk work as hard as possible. And maybe there are other ways which need a more in-depth knowledge of the specific NAS.

as far i know the firmware is installed on the hdd

At least the bootloader and the kernel are in flash, and a rootfs. (See the flash mapping here). I don't know if that rootfs is temporary and exchanged on boot by a rootfs on disk, or that only /usr and maybe /sbin are added from disk, but the box boots initially only from flash.

Last edited by Mijzelf (2010-12-21 12:07:50)

It's my aim to build something that runs completely from stick. So removing the stick will remove every trace of Debian. It will be loaded instead of the firmware, so the firmware services will not be running. (I will try to get the fancontrol running, but all other services have a better Debian equivalent)