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

can you pull the disk(s) out of the unit and it behave okay then? - just to ensure its not a dns-323 hardware fault.
You can then mount the disks on a PC, and manually correct (or remove ) funplug files.

for details of mounting disks on a pc see http://dlink.co.uk/?go=gNTyP9CnptFMIC4A … 7faIa1GdS8

good luck old chap!

Last edited by index monkey (2008-06-02 15:18:45)

Given that he has said his linux knowledge is nil - popping the right disk in with the unit on and mounting it is going to be betond his capabilties (it is beyond mine) - an easier way, again assuming separate disks, would be to swap the disks left for right - which should cause it not to find and start the fun_plug, and then install ffp on the right disk and then restart and use telnet to fix the scripts on what is now the left disk.

If the uint is running RAID1 he can probably pull one drive and insert it into a desktop and remove the fun_plug and then rebuild the RAID array at a later date.

fordem wrote:

swap the disks left for right - which should cause it not to find and start the fun_plug, and then install ffp on the right disk and then restart and use telnet to fix the scripts on what is now the left disk.

What a fantastic forum, what fantastic members !  Thanks to fordem and others who contributed to this thread my issue has been resolved.

Here are the steps I followed to resolve the problem;

1)Power down the DNS323. This is easier said then done when the unit continues to reboot itself. This is were persitance pays. Keep holding that power button and the unit will soon shut itself down.

2)With the unit powered down, the front cover was removed to expose the drives.

3)Prior to removing the drives labels were affixed to both drives and drive bays. Labels reading HD_ax were affixed the right drive and drive bay and labels reading HD_bx were affixed to the left drive and drive bay.

4)With drives and drive bays labeled, the drives wer pulled from the unit then placed in the oposite slots. The drive labeled HD_ax was placed in the slot labeled HD_bx while the drive labeled HD_bx was placed in the slot labeled HD_ax.

5)With both drives in place the unit was powered up. Follwing a few intense minutes of drive activity the unit settled down and remaind operational. Shortly afterward a shout of joy was heard throught the house.

6)With the unit up and running an attempt was made to copy the fun_plug files to drive now know as Volume 1 (Foremerly Volume 2). The first attempt failed with an access error being reported. “Now what”, I thought (And if you believe that's as I said, well....). After giving the issue some thought I launched D-Links Web tool and assigned myself full rights on Volume 1. What do you know, it worked! The fun_plug files were copied to Volume 1.

7)With appropriate files copied to the DNS323, the unit was restarted. Again, following a few minutes of intense disk activity the unit settled down and remaind operational.

8)With fingers crossed a telnet session was started and an attempted to connect to the unit initiated. A few seconds later the command prompt appeared and another shout of joy was heard throught the house.

9)With full access to the unit I made my way to the /mnt/HD_b2/ffp/start directory where the execution bit on a number of files was set off. Specifically the execution bit of the files named cleanboot.sh, lighttpd.sh and crontab_add_scripts.sh were changed using the chmod a-x filename.ext command.

10)While reviewing file status within the /mnt/HD_b2/ffp/start directory I noticed the execution bit of two *.tgz files was set active. The files in question were cleanboot-2.0.2-fp05.tgz and cleanboot-2.0.3-fp05.tgz. Thinking this didn't look right, the executiuon bit was set off.

11)Following these changes the unit was powered down, the left and right drives place back in their respective bays and the unit restarted. Following what seemed like an eternity of intense disk activity the unit settled down and remaind operational.

12)With fingers crossed an attempt was made to access data on Volume 1 (The real volume 1!). Following a brief review and a few tests I concluded that everything was operation and thus began the task of restarting the scripts that were stopped earlier. The first script started was cleanboot. Using the chmod a+x cleanboot.sh command the execution bit was set and the unit rebooted. Following a few minutes of drive activity the unit settled down and remaind powered up.

13)With exception of the file named crontab_add_script.sh, which contians initiates cron jobs associated with rsnapshot and files containing a tgz extension, one by one the execution but of each script was set active, the unit was rebooted and success achieved.

14)The only puzzle remaining is why the unit went south in the first place. I'm guessing that because the execution bit on the files named cleanboot-2.0.2-fp05.tgz and cleanboot-2.0.3-fp05.tgz was set active these files were attempting to execute when the unit started. Failed or conflicting execution of such in turn caused the unit to reboot. Could someone here confirm this was the most likely cause of this problem?

Bob Blackwell
Pickering, ON

Last edited by rcblackwell (2008-06-03 03:46:47)

SilentException wrote:

how did you end up with those two tgz files with +x in start? the package doesnt put them there for sure..

I placed them there in preparation for installation. Based on your comment I'm guessing the /mnt/HD_a2/ffp/start directory is not the correct location for such files. Where should these and other such files be placed?

Bob Blackwell
Picker, ON

marinalink wrote:

Do you encounter the problem now after having fixed everything if you reinstall cleanboot-2.0.3 (with /ffp/start/cleanboot.sh executable)?

cleanboot-2.0.3 reinstalled and the cleanboot.sh file has the x bit set. The unit's been restarted twice without incident. Is there a means by which I can confirm the cleanboot.sh script actually ran?

Bob Blackwell
Pickering, ON

OK, here is a new version (2.0.4) of cleanboot with the cleanboot.sh in /ffp/start not enabled with the execution bit:

http://dns323.kood.org/forum/t2346-smal … nboot.html

marinalink