DNS-323 power button inoperative (Alt-F 0.1RC4.1)

[Omar]

Good day,

First of all: thank you João for all your time & effort on Alt-F - it's very well done, exceedingly useful, and the web interface is excellent! :)

I'm running a DNS-323 ver. B1 with Alt-F-0.1RC4.1 (upgraded from stock D-Link firmware 1.06).

Installation was simple & straightforward. I first did a 'dry run': upgraded the firmware with no drives in the NAS. It all went fine: I adjusted the settings, saved them, and rebooted - all good. When I went to power off though, I found that nothing happened when I held the power button down. So I thought I'd use the 'Poweroff' button under 'System utilities'. This appeared to do the job: the NAS disappeared from the network and I couldn't load the web interface, as expected. But the blue power LED stayed on, blinking rapidly (this is the same state the light was in the entire time the NAS was on, too). And in this powered-off-power-button-blinking state, I found that pressing the power button failed to turn on the NAS. I had to cut power to the device, and once I did that, I was able to to use the power button to turn the NAS on.

I thought perhaps if I put a drive in the NAS this glitch would disappear. I installed a new WD 2TB drive (WD20EZRX) and powered up the NAS - used the web interface to prepare the drive, setup shares, install transmission, everything went flawlessly. (I even verified that transmission was working.) I noticed that the blue power LED stayed on, blinking rapidly, the whole time. Once again, holding the power button down (for any length of time) failed to turn off the NAS. 'Poweroff' button under 'System utilities' seemed to tun off the NAS, but the blue power LED stayed on, blinking rapidly. I left it in this state and retired for the night.

In the morning, it was still in the same state (I noticed that the NAS was warm - not hot - and the fan may have been running at low speed). I had to cut power to the device and then was able to bring it back up. All settings, shares, and services were fine.

I got the NAS up, and tried out the LED control commands you'd provided in another post:

echo 1 > /sys/class/leds/power:blue/brightness # turn off 

echo 0 > /sys/class/leds/power:blue/brightness # turn on

These commands did nothing for me though - even though I was logged in (SSH) as root, I could not change the contents of the 'brightness' file to '0' - it always remained at '1'.

I know the Wiki indicates "Leds on different hardware revision boards might behave in the opposite way, i.e., turn on when then they should turn off and vice-versa." But I thought since I was on a B1 device I'd be OK.

So is there anything I could do to try to get the power on/off to work correctly? Help...? ;)

I had been using D-Link firmware 1.06 with fonz fun_plug (ffp), but I prefer Alt-F and its packages. I may just have to go back to stock though, plus that way the NAS will go to sleep & Wake On Lan, but then I'll be back to ext2 (or maybe ext3 in a newer D-Link firmware). My main reason for switching to Alt-F was the ext4 support, but I found everything about Alt-F to be superb. :)

Thanks again João! :)

[João Cardoso]

On Thursday, 17 December 2015 22:32:55 UTC, Omar wrote:

Good day,

First of all: thank you João for all your time & effort on Alt-F - it's very well done, exceedingly useful, and the web interface is excellent! :)

Thanks.

According to psycros review you are a linux guru. Congratulations :-)

So your issues are:

1-power led is always blinking fast

2-front power button does not start powers off or restart the box

3-the box remains powered even when using the webUI PowerOff

That is odd, as I have a DNS-323-rev-B1 and I don't have such issues. And I don't remember anything similar being ever reported.

1-After poweron, the box bootloader (u-boot, that Alt-F never touches, so it's still the D-Link shipped one), starts blinking the power blue led fast, and then loads the linux kernel and filesystem; when the kernel turns control, it starts blinking the blue power led at a slow rate. When the Alt-F initscripts start running, the blue power led is set to a solid blue by 'sysctrl', the "the fan/temp/led/buttons control daemon". This is the normal behaviour.

Please attach the "System Configuration log" (System->Utilities, View Logs), that will contain the kernel and system logs, to see if we can figure out anything unusual.

2-'sysctrl' is continuously watching for system and user events, such as the front and reset button, and activates the orange and blue power led accordingly. You must have already read the "About buttons and leds" wiki.

So it seems that 'sysctrl' is not running or is not able to read the power button. Can it read the reset button and activate the orange leds, as the  "About buttons and leds" wiki refers?

Please post the output of the following commands:

ls -la /tmp/sys
echo 1 > /tmp/sys/left_led/brightness # should turn the left orange led on
echo 0 > /tmp/sys/left_led/brightness # should turn the left orange led off
echo 0 > /tmp/sys/power_led/brightness # # should turn the blue power led off
cat /tmp/sys/power_led/trigger # should be "[none] timer heartbeat default-on"
ls -la "/sys/class/leds/power:blue/"
rcsysctrl stop # should display Stopping sysctrl: OK.
hexdump -C /dev/event0 # and press and release the power and reset button, you should see some output. Finish by hitting CTRL-C
rcsysctrl start # restart sysctrl, so the fan will be controlled

3-What happens if you use the 'reboot' command while you are logged in? Will the box reboot? You will at first be kicked off, but after one to two minutes you will be able to login again (and using the 'uptime' command you will know if a reboot has really happened).

You can do all the above without any disk plugged or attached.

I'm running a DNS-323 ver. B1 with Alt-F-0.1RC4.1 (upgraded from stock D-Link firmware 1.06).

Have you ever upgraded the D-Link firmware to 1.07, 1.08. 1.09, or 1.10? I think that your issues are related to the way how the bootloader lets the hardware initialized, and it is possible that some of these D-Link fw versions make an update to the bootloader. Unfortunately to see what your current bootloader version is you would need a serial cable connection to the box, and that involves buying an adapter and soldering; and it is not guaranteed that it will provide clues.

Regarding WOL: I don't remember seeing such feature in any D-Link fw, and Alt-F can't setup WOL.

I remember reading that the the D-Link fw for the DNS-323-rev-C1 had that feature, but no one has discovered/reported how to setup it.

[Omar Hussain]

Hello João,

Thank you for your detailed response, and the summary of the three issues observed in my case.

Since my initial post, I have installed D-Link's firmware 1.08 (1.08b09 to be precise) with ext3 support, and ffp. So this will be a good opportunity to test your intriguing bootloader hypothesis. :)

I will upgrade again to Alt-F, perform the tests indicated, and report back with:

1. System Configuration log

2. sysctrl-test command outputs

3. reboot results

I do recall though, that a reboot via Alt-F's web interface worked perfectly fine.

Regarding WOL: Does this observed behaviour qualify as 'Wake on Lan' -> On stock firmware, the disks in the DNS-323 stop spinning after some extended inactivity (even with ffp installed on /mnt/HD_a2 - provided no torrents were downloading, etc.). Then if I attempt to access a share over my LAN, there is a very slight pause while the disks spin up, and then I can immediately access files on the NAS as usual.

Note: I have since done some reading up on Wake on Lan - it seems I was unclear about what it is. What I'm observing is just the disks going to sleep and waking up... as opposed to the NAS being powered off & then woken up by LAN activity. Which the DNS-323 does not support.

Thanks again, I will report back with the results of my transition from 1.08 -> Alt-F-0.1RC4.1.  :)

Regards,

Omar

[Omar]

Well, I've just upgraded from D-Link 1.08 to Alt-F-0.1RC4.1

Much to my surprise, nothing has changed: blue power LED flashes constantly when device is on. Pressing the power button does nothing - as before the button actions described in the Wiki are non-existent, and the button does not even power off the device.

In the web interface, the reboot button works fine, poweroff appears to power off the device (disappears from network), but the blue power LED remains on, blinks constantly and rapidly.

Will post the test results later. :)

Regards,

Omar

[Omar]

Here are the results after upgrading from stock firmware v1.08 to Alt-F-0.1RC4.1:

1. System configuration log: (attached)

2. sysctrl testing:

[root@bitbucket]# ls -la /tmp/sys

total 0

drwxr-xr-x    2 root     root           160 Dec 18 16:44 .

drwxrwxrwt   10 root     root           260 Dec 18 17:30 ..

lrwxrwxrwx    1 root     root            41 Dec 18 16:44 fan1_input -> /sys/class/hwmon/hwmon0/device/fan1_input

lrwxrwxrwx    1 root     root            26 Dec 18 16:44 left_led -> /sys/class/leds/left:amber

lrwxrwxrwx    1 root     root            26 Dec 18 16:44 power_led -> /sys/class/leds/power:blue

lrwxrwxrwx    1 root     root            35 Dec 18 16:44 pwm1 -> /sys/class/hwmon/hwmon0/device/pwm1

lrwxrwxrwx    1 root     root            27 Dec 18 16:44 right_led -> /sys/class/leds/right:amber

lrwxrwxrwx    1 root     root            42 Dec 18 16:44 temp1_input -> /sys/class/hwmon/hwmon1/device/temp1_input

echo 1 > /tmp/sys/left_led/brightness # should turn the left orange led on SUCCESS!
echo 0 > /tmp/sys/left_led/brightness # should turn the left orange led off SUCCESS!
echo 0 > /tmp/sys/power_led/brightness # # should turn the blue power led off FAILED

[root@bitbucket]# cat /tmp/sys/power_led/trigger

[none] timer heartbeat default-on

[root@bitbucket]# ls -la /sys/class/leds/power:blue/

total 0

drwxr-xr-x    2 root     root             0 Dec 18 16:44 .

drwxr-xr-x    5 root     root             0 Dec 18 16:44 ..

-rw-r--r--    1 root     root          4096 Dec 18 17:49 brightness

lrwxrwxrwx    1 root     root             0 Dec 18 16:44 device -> ../../../leds-gpio

-r--r--r--    1 root     root          4096 Dec 18 16:44 max_brightness

lrwxrwxrwx    1 root     root             0 Dec 18 16:44 subsystem -> ../../../../../class/leds

-rw-r--r--    1 root     root          4096 Dec 18 17:49 trigger

-rw-r--r--    1 root     root          4096 Dec 18 16:44 uevent

[root@bitbucket]# rcsysctrl stop

Stopping sysctrl: OK.

There was no output when I pressed the power button (tried several times, with varying duration) this is what happened when I pressed the reset button:

Enter code here...[root@bitbucket]# hexdump -C /dev/event0

00000000  91 aa 74 56 0d 3c 02 00  01 00 98 01 01 00 00 00  |..tV.<..........|

00000010  91 aa 74 56 0d 3c 02 00  00 00 00 00 00 00 00 00  |..tV.<..........|

00000020  92 aa 74 56 8b a1 04 00  01 00 98 01 00 00 00 00  |..tV............|

00000030  92 aa 74 56 8b a1 04 00  00 00 00 00 00 00 00 00  |..tV............|

00000040  92 aa 74 56 a5 a4 04 00  01 00 98 01 01 00 00 00  |..tV............|

00000050  92 aa 74 56 a5 a4 04 00  00 00 00 00 00 00 00 00  |..tV............|

00000060  92 aa 74 56 32 aa 04 00  01 00 98 01 00 00 00 00  |..tV2...........|

00000070  92 aa 74 56 32 aa 04 00  00 00 00 00 00 00 00 00  |..tV2...........|

[root@bitbucket]# rcsysctrl start

Starting sysctrl: OK.

3. 'reboot' command testing

[root@bitbucket]# uptime

 17:57:30 up  1:12,  0 users,  load average: 0.00, 0.01, 0.03

[root@bitbucket]# reboot

This successfully rebooted the device, and a few minutes later...
[root@bitbucket]# uptime

 18:00:09 up 2 min,  0 users,  load average: 0.14, 0.08, 0.03

The power LED constantly blinks rapidly at *all* times. The power button does nothing except power up the device after I have cut power to it. When the device is powered, reboot via the web interface works, poweroff via the web interface powers off the device but leaves the power LED on & blinking.

I hope this proves of interest you João. Thanks again! :)

PS I didn't understand your earlier comment:

According to psycros review you are a linux guru. 

But then I read what he wrote - utter nonsense. Some people have no appreciation for other people's time and effort. You (and countless other developers) have given greatly to help others all over the world, and this is not something people should take lightly.

[Omar]

Just in case, I installed D-Link firmware 1.10, and after verifying that was working, installed Alt-F-0.1RC4.1. I observed the same behaviour with the power button & LED as before. Nevertheless, I re-ran the tests.

1. System configuration log: (attached)

2. sysctrl testing:

[root@bitbucket]# ls -la /tmp/sys

total 0

drwxr-xr-x    2 root     root           160 Dec 18 10:53 .

drwxrwxrwt   10 root     root           260 Dec 18 21:09 ..

lrwxrwxrwx    1 root     root            41 Dec 18 10:53 fan1_input -> /sys/class/hwmon/hwmon0/device/fan1_input

lrwxrwxrwx    1 root     root            26 Dec 18 10:53 left_led -> /sys/class/leds/left:amber

lrwxrwxrwx    1 root     root            26 Dec 18 10:53 power_led -> /sys/class/leds/power:blue

lrwxrwxrwx    1 root     root            35 Dec 18 10:53 pwm1 -> /sys/class/hwmon/hwmon0/device/pwm1

lrwxrwxrwx    1 root     root            27 Dec 18 10:53 right_led -> /sys/class/leds/right:amber

lrwxrwxrwx    1 root     root            42 Dec 18 10:53 temp1_input -> /sys/class/hwmon/hwmon1/device/temp1_input

echo 1 > /tmp/sys/left_led/brightness # should turn the left orange led on SUCCESS!
echo 0 > /tmp/sys/left_led/brightness # should turn the left orange led off SUCCESS!

echo 0 > /tmp/sys/power_led/brightness # should turn the blue power led off FAILED

Note: /tmp/sys/power_led/brightness is always 0, observe:

[root@bitbucket]# cat /tmp/sys/power_led/brightness

0

[root@bitbucket]# echo 1 > /tmp/sys/power_led/brightness

[root@bitbucket]# cat /tmp/sys/power_led/brightness

0

[root@bitbucket]# cat /tmp/sys/power_led/trigger

[none] timer heartbeat default-on

[root@bitbucket]# ls -la "/sys/class/leds/power:blue/"

total 0

drwxr-xr-x    2 root     root             0 Dec 18 10:53 .

drwxr-xr-x    5 root     root             0 Dec 18 10:53 ..

-rw-r--r--    1 root     root          4096 Dec 18 21:26 brightness

lrwxrwxrwx    1 root     root             0 Dec 18 10:53 device -> ../../../leds-gpio

-r--r--r--    1 root     root          4096 Dec 18 10:53 max_brightness

lrwxrwxrwx    1 root     root             0 Dec 18 10:53 subsystem -> ../../../../../class/leds

-rw-r--r--    1 root     root          4096 Dec 18 21:26 trigger

-rw-r--r--    1 root     root          4096 Dec 18 10:53 uevent

[root@bitbucket]# rcsysctrl stop

Stopping sysctrl: OK.

Note: this output is from pressing the reset button - the power button did nothing

[root@bitbucket]# hexdump -C /dev/event0

00000000  30 dd 74 56 69 5c 02 00  01 00 98 01 01 00 00 00  |0.tVi\..........|

00000010  30 dd 74 56 69 5c 02 00  00 00 00 00 00 00 00 00  |0.tVi\..........|

00000020  31 dd 74 56 2d 2a 04 00  01 00 98 01 00 00 00 00  |1.tV-*..........|

00000030  31 dd 74 56 2d 2a 04 00  00 00 00 00 00 00 00 00  |1.tV-*..........|

^C

[root@bitbucket]# rcsysctrl start

Starting sysctrl: OK.

3. 'reboot' command testing

[root@bitbucket]# uptime

 21:32:18 up  2:38,  0 users,  load average: 0.00, 0.01, 0.04

[root@bitbucket]# reboot

Reconnected after rebooting:

login as: root

root@bitbucket's password:

COLUMNS=131;LINES=48;export COLUMNS LINES;

[root@bitbucket]# uptime

 21:33:45 up 1 min,  0 users,  load average: 0.28, 0.10, 0.03

I don't even need the power button, really, I rarely shut the NAS down. But I'm just a bit concerned that if this doesn't work, perhaps something else might be amiss, too. And that bright blinking light is disconcerting. ;)

But then on stock firmware I'm not sure how to:

a) cleanly unmount (I've read up on cleanboot)

b) run fsck (I've seen your work on yafsck & chkbutton2)

In any case, thank you for all your contributions João. :D

[João Cardoso]

On Saturday, 19 December 2015 04:44:23 UTC, Omar wrote:

Just in case, I installed D-Link firmware 1.10, and after verifying that was working, installed Alt-F-0.1RC4.1. I observed the same behaviour with the power button & LED as before. Nevertheless, I re-ran the tests.

1. System configuration log: (attached)

Your kernel log is identical to mine, also on a DNS-323-rev-B1 box, so no clues.

Exploring the bootloader hipotesis: My bootloader version is: 

U-Boot 1.1.1 (Oct 12 2007 - 17:19:14) Marvell version: 1.7.3.001

 

You can get yours version even without a serial console be executing (even on the D-Link fw, as long as you have ffp installed):

cat /dev/mtd4 | grep U-Boot

There is definetively an issue with some SoC gpio (General Purpose Input Output).

The power led,  the poweroff hardware and the power button (as all leds and buttons) are controlled by some of these lines, and somehow in your box they are not working as on the other boxes. The SoC has a few tens of such lines, and they are connected differently on different boards, with hardcoded values in the kernel.

I don't know if you can read C code, but here is a small excerpt of the linux kernel code that sets up such things:

pr_info("DNS-321/323: Triggering power-off...\n");

/* Pin has to be changed to 1 and back to 0 to do actual power off. */

gpio_set_value(DNS323_GPIO_POWER_OFF, 1);

mdelay(100); # this is 100 milliseconds, can it be that your box needs a longer time?

gpio_set_value(DNS323_GPIO_POWER_OFF, 0);

...

/* The DNS323 rev B1 has flag to indicate the system is up.

* Without this flag set, power LED will flash and cannot be

* controlled via leds-gpio.

*/

if (gpio_request(DNS323_GPIO_SYSTEM_UP, "SYS_READY") == 0)

gpio_direction_output(DNS323_GPIO_SYSTEM_UP, 1);

/* Poweroff GPIO */

if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||

   gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)

pr_err("DNS-321/323: failed to setup power-off GPIO\n");

pm_power_off = dns323b_power_off;

There are other segments of related C code (arch/arm/mach-orion5x/dns323-setup.c)

So, I'm afraid that I can't help without being able to reproduce it.

Thanks

PS: what you described previously as WOL is not really WOL. For WOL power is removed from all electronics components except the network interface; then when receiving a special packet, the NIC will awaken the box.

[Omar]

I'm running D-link firmware v1.08 with ffp 0.7, this is what I got when I tried to check the bootloader:

root@bitbucket:~# cat /dev/mtd4 | grep U-Boot

Binary file (standard input) matches

root@bitbucket:~# ls /dev/mt*

crw-r--r-- 1 root root 90,  0 Dec 27  2005 /dev/mtd0

crw-r--r-- 1 root root 90,  2 Dec 27  2005 /dev/mtd1

crw-r--r-- 1 root root 90, 32 Dec 27  2005 /dev/mtd16

crw-r--r-- 1 root root 90,  4 Dec 27  2005 /dev/mtd2

crw-r--r-- 1 root root 90,  6 Dec 27  2005 /dev/mtd3

crw-r--r-- 1 root root 90,  8 Dec 27  2005 /dev/mtd4

crw-r--r-- 1 root root 90, 10 Dec 27  2005 /dev/mtd5

brw-r--r-- 1 root root 31,  0 Dec 27  2005 /dev/mtdblock0

(truncated)

Incidentally, I did find another user (with a rev. B unit) who has experienced this issue: alternative way to power off the DNS 323 under alt-f? Don't worry - I don't expect you to solve this mystery. I appreciate the time you've spent considering the problem. :)

On a related note, do you have any thoughts on other good NAS devices?

- The DNS-325 is appealing, but a bit old and no longer officially supported (as of 2015-02-01)

- The DNS-320L seems pretty good and Alt-F should work well with it. They've removed fun_plug support from firmware 1.06 onwards though, so no more ffp on stock. :(

My needs for a NAS are basic: good data handling is the first priority (clean unmounting, ext4 support would be nice), good transmission client, good SAMBA support, and that's about it. SSH is handy.

I'm very happy with the DNS-323 and it fulfils all my needs, but I'd like to know what I could use if/when the DNS-323 goes down for good.

Thanks again, and happy holidays. :)

-------------------------------------------------------------------------------------

Footnote

I've been running the DNS-323 since approx. mid-2011 on firmware v1.06 & ffp, with 2 x 750GB HD (WD7500AACS) in standard format. I only ever used one of the drives, the other one remained empty. I always intended to back up the data from one drive to the other, but never got around to it. :|

Over the years, there were rare occasions when the power went out (the NAS isn't plugged into a UPS or even surge protection), but I never observed any issues. On Dec. 13 a breaker tripped & killed power to the area the NAS was in. When I tried to turn the NAS on, it wouldn't boot up. I quickly realised the issue was with the HD I'd been storing data on, since the NAS powered up once I removed the drive. I felt awful when I thought I might have lost all the family pictures & movies I'd archived. :(

I installed the (ext2-formatted) HD from my NAS directly in my PC, and to my horror, found that the drive could not be mounted: not in linux, and not in Windows via 'Ext2Fsd'. I soon discovered that with 'Ext2Read' & (the superior) 'DiskInternals Linux Reader', I could see and copy files off the drive. I settled on using testdisk to recover all my data (attempted to repair the partition table with testdisk, but ultimately used it simply to copy all files). It was at this point that I started looking into Alt-F and learned about the importance of cleanly unmounting the drives, and running fsck...

I've always known I should have at least one backup - I was very fortunate, and won't risk losing my data again. I've got a secondary backup of the pictures & videos archive now, plus I'll upload them to Google Photos (the more current material is already on there).

[João Cardoso]

On Monday, 21 December 2015 07:19:31 UTC, Omar wrote:

I'm running D-link firmware v1.08 with ffp 0.7, this is what I got when I tried to check the bootloader:

root@bitbucket:~# cat /dev/mtd4 | grep U-Boot

Binary file (standard input) matches

Sorry, my mistake, it should be  'cat /dev/mtd4 | strings | grep U-Boot'

 

Incidentally, I did find another user (with a rev. B unit) who has experienced this issue: alternative way to power off the DNS 323 under alt-f? 

You gave two additional details: the power led is non-controllable and is always blinking fast and the power button does not generate events. That pointed me to the code of the board initial setup. I could setup an experimental kernel image for you to test, but I'm leaving home till next year. If you are still running Alt-F you might want to test it next year?

 

Don't worry - I don't expect you to solve this mystery. I appreciate the time you've spent considering the problem. :)

On a related note, do you have any thoughts on other good NAS devices?

- The DNS-325 is appealing, but a bit old and no longer officially supported (as of 2015-02-01)

That is the box I use for my home backups. Sturdy construction (identical to the DNS-323)  and fast enough for my needs.

 

- The DNS-320L seems pretty good and Alt-F should work well with it. They've removed fun_plug support from firmware 1.06 onwards though, so no more ffp on stock. :(

Didn't knew that... no ffp... that box is as fast as the 325 and has the same amount of memory (256MB) but suffers from several problems: noisy fan, bad thermal design, not easily swappable disks, fragile case. Alt-F works fine with it.

I also have a 327L. I have installed a slightly modified ffp on it (just changed the mount points); its a rev-A1 with fw 1.0. It is faster then the 320L, has 512MB of memory, USB-3, a bigger ans silenter fan, but it has the same kind of construction as the 320L. The (single core) CPU has a hardware accelerator unity (VPF), that Alt-F will not (yet) handle and should be able to do transcoding. Alt-F will fully support it for the next (to be released?) release. 

Have a nice new year!

My needs for a NAS are basic: good data handling is the first priority (clean unmounting, ext4 support would be nice), good transmission client, good SAMBA support, and that's about it. SSH is handy.

I'm very happy with the DNS-323 and it fulfils all my needs, but I'd like to know what I could use if/when the DNS-323 goes down for good.

Thanks again, and happy holidays. :)

-------------------------------------------------------------------------------------

Footnote

I've been running the DNS-323 since 2011 on firmware v1.06 & ffp, with 2x 750GB HD (WD7500AACS) in standard format. I only used one of the drives, the other one was always empty. I always meant to back up the data from one drive to the other, but never did. :|

Over the years, there have been a few (rare) occasions when the power has gone out (the NAS isn't plugged into a UPS or even surge protection), but I never observed any issues. On Dec. 13 a breaker tripped & killed power to the area the NAS was in. When I tried to turn the NAS on, it wouldn't boot up. I realised the issue was with the HD I'd been storing data on, since it powered up once I removed the drive. I felt awful when I thought I might have lost all the family pictures & movies I'd archived. :(

Fortunately using testdisk, I was able to recover all my data. It was at this point that I started looking into Alt-F and learned about the importance of cleanly unmounting the drives, and running fsck...

[Omar]

When I ran 'cat /dev/mtd4 | strings | grep U-Boot', it led to the error message 'strings: command not found'. With Google as my guide, I installed binutils. ;)

root@bitbucket:~# cat /dev/mtd4 | strings | grep U-Boot

U-Boot 1.1.1 (Nov 27 2006 - 14:25:52) Marvell version: 1.7.3

Addresses %dM - 0M are saved for the U-Boot usage.

U-Boot

It appears that the Marvell CPU in my DNS-323 may be a year older than yours (if that's what the date in brackets represents)...

I don't wish to trouble you at all - if you would like to prepare a test kernel or anything else next year whenever you have the time, I'd be happy to try it out. I am happily running ffp 0.7 on the stock firmware - Alt-F would be better, but I've gotten more than my money's worth out of this little box as it is. :P

Thank you for insight on the other NAS devices, it's invaluable.

Thanks again for everything João. :)

Happy New Year! :D