How to recover a Thecus N2100 that has had OpenBSD installed on it

Table of Contents:
0 Background
1 Parts List
2 Verification
3 Exporting Userland
4 Importing Userland to Flash
5 Booting
6 Further Info

WARNING!!!Do not try this unless you know what you are doing. Clearly this could damage your equipment beyond repair. Proceed at your own risk!

0 Background

I purchased a used Thecus N2100 on ebay, that had been altered to run OpenBSD. I BELIEVE the previous owner used this guide to perform the installation. My intent was to install Debian linux overtop of the OpenBSD. Unfortunately, installing the OpenBSD bootloader required deleting userland tools from the flash due to space concerns. This removes the ability to re-install the original factory firmware, and in turn, prevents the installation of Debian. Using these steps, I was able to restore the unit to original factory condition. After this, installing Debian worked as expected.

1 Parts List

Still reading? Anyway, I really didn't use any tools for this project. The only required object is the Thecus N2100, and a second PC of some sort. If you wish to open up the chassis to swap hard drives, etc, a #2 Philips screwdriver will work fine. To perform this recovery, I actually had a second working Thecus available, and was able to use its flash to recover the broken unit. I can provide memory dumps if this data if needed.

2 Verification

The box booted just fine into OpenBSD, but I can see how the following would help a box that can't even do that. Most of the Thecus boxes that have been updated to a fairly recent flash will have Redboot, a bootloader/utility that provides basic functionality to booting and recovering the box. See this guide for more details about accessing Redboot.

To access Redboot requires telnetting to port 9000 during the device's boot process. The easiest way to do this is with the following:

arping -f 192.168.1.100 && telnet 192.168.1.100 9000
WARNING: interface is ignored: Operation not permitted
ARPING 192.168.1.100 from 192.168.1.104 eth0
Unicast reply from 192.168.1.100 [00:14:FD:10:33:8E]  6.473ms
Sent 9 probes (9 broadcast(s))
Received 1 response(s)
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
== Executing boot script in 2.650 seconds - enter ^C to abort
^C
RedBoot>
RedBoot>

On my working Thecus, the following command showed the contents of the flash disk:

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xF0000000  0xF0000000  0x00040000  0x00000000
RedBoot config    0xF0FC0000  0xF0FC0000  0x00001000  0x00000000
FIS directory     0xF0FE0000  0xF0FE0000  0x00020000  0x00000000
ramdisk           0xF0040000  0x00800000  0x00D00000  0x00800000
kernel            0xF0D40000  0x00200000  0x00160000  0x00200000
user              0xF0EA0000  0x00120000  0x00120000  0x00800000
Notice the 'user' directory. This is where the userland Linux tools are stored for the default Thecus firmware. On the broken Thecus, I saw this in flash:
RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xF0000000  0xF0000000  0x00040000  0x00000000
RedBoot config    0xF0FC0000  0xF0FC0000  0x00001000  0x00000000
FIS directory     0xF0FE0000  0xF0FE0000  0x00020000  0x00000000
ramdisk           0xF0040000  0x00800000  0x00D00000  0x00800000
kernel            0xF0D40000  0x00200000  0x00160000  0x00200000
boot              0xF0EA0000  0x00100000  0x00020000  0x00100000
The 'user' directory had been replaced by a 'boot' image of a different length. When I tried to manually load and boot the kernel and ramdisk, they appeared to get started, but once the kernel booted, the lack of userland tools meant no web interface, no network settings, basically a dead system. How do we get this back?

3 Exporting Userland

The working Thecus already had Debian installed on it, and provided all of the tools needed to extract the original Thecus firmware for the transplant. Looking at the forums, I determined that the flash was accessable under /dev/mtd*. To view which partitions housed the various flash images, simply view /proc/mtd. Observe:

debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "RedBoot"
mtd1: 00d00000 00020000 "ramdisk"
mtd2: 00160000 00020000 "kernel"
mtd3: 00120000 00020000 "user"
mtd4: 00001000 00020000 "RedBoot config"
mtd5: 00020000 00020000 "FIS directory"
This looked familiar. I was able to mount these with mount -t jffs /dev/mtd3 /mnt/temp or something similar, but I wanted to extract the filesystem in its entirety. After playing with dd, cat, and /dev/mtd3 and /dev/mtdblock3, I found that a simple
cat /dev/mtdblock3 > user
appeared to do the trick. I now had a file called 'user' which had the contents of mtd3.

4 Importing Userland to Flash

Importing the user image to flash proved to involve a bit of trial and error, and having made a few typos while I figured out which flags on the fis command did what, I was lucky to not blow away any other images ;) From Redboot, I ran the following to erase the 'boot' image:

fis erase -f 0xF0EA0000 -l 0x00020000
Now load the 'user' image via tftp from the server 192.168.1.5 to the correct memory location:
ip -h 192.168.1.5

load -r user -b 0x00120000
Now the moment of truth, flashing the image from RAM to the onboard flash chip. No mistakes!
fis create -b 0x00120000 -l 0x00120000 -f 0xF0EA0000 -e 0x00800000 -r 0x00120000 user
Verify with fis list:
RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xF0000000  0xF0000000  0x00040000  0x00000000
RedBoot config    0xF0FC0000  0xF0FC0000  0x00001000  0x00000000
FIS directory     0xF0FE0000  0xF0FE0000  0x00020000  0x00000000
ramdisk           0xF0040000  0x00800000  0x00D00000  0x00800000
kernel            0xF0D40000  0x00200000  0x00160000  0x00200000
user              0xF0EA0000  0x00120000  0x00120000  0x00800000

5 Booting

RedBoot actually boots the system, so we have to set it to load the kernel and initrd into RAM, then run the userland tools that set the device IP and console access. Recreate the original boot script using fconfig in RedBoot:

RedBoot> fconfig

...contents of the script below...

thecus_setip
fis load ramdisk
fis load kernel
exec -c "console=ttyS0,115200 root=/dev/ram0 initrd=0xa0800000,42M mem=128M@0xa0000000"
Set any IP or other settings that you like. Reset with 'reset'.

At this point, the unit booted into the original Thecus firmware! I upgraded to the Thecus firmware to 2.10, the latest version, then followed the Debian installation guide. The unit installed with no issues, and OpenBSD was gone forever. Eureka!

6 Further Info

Below is a list of most of the articles I used to piece together this procedure. Thanks to the original authors, as without the background information, I would have never recovered this piece of hardware.

http://www.cyrius.com/debian/iop/n2100/
http://www.cyrius.com/debian/iop/n2100/telnet.html
http://www.cyrius.com/debian/iop/n2100/deinstall.html
http://foonas.org/index.php?title=Foonas-iscsi:Install-n2100
http://david.thg.se/n2100/
http://foonas.org/index.php/Platforms:n2100-notes
http://naswebsite.com/wiki/N2100_Recovering_from_a_bad_config_change
ftp://ftp.openbsd.org/pub/OpenBSD/5.1/armish/INSTALL.armish
That about wraps it up. This is a fairly straightforward hack that will allow you to run Debian in all of its glory on hardware that has a limited distro on it. If you have any thoughts/additions, email them to sclebo05 AAATTT gmail.com. Thanks for stopping by!