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

Here is where I believe your source of confusion is.  /dev/sdb refers to the second scsi device that the DNS has found.  When you boot up the device with 1 drive in it, then push in the second drive, /dev/sda will be the one you booted from and /dev/sdb will be the one you inserted.  The system does not know or care which drive it is, or whether it is in the left or right slot.  However, if you boot up the DNS with both drives installed, it will look at the left bay first (drive 0) and the right bay second (drive 1).  The drive in the left bay will be /dev/sda and the drive in the right bay will be /dev/sdb. 

In my scenario above, since the unit is (or should have been) booted from only 1 drive installed, that installed drive will always be /dev/sda.  Once you push the other drive into its slot, it will always be /dev/sdb.  That is why you can fdisk /dev/sdb the second time and it is the other drive.

You are not seeing both disks as Volume_1.  That would only be the case if it was set-up in RAID1.  What you are seeing is 1 disk and not the other.  For a brief summary of the instructions:
1) Install ffp on the 1 working disk, boot up on that disk only, telnet in, pop in the second disk, fdisk and format /dev/sdb (1/2/4)
2) Shut down the unit.
3) Remove the original disk (the one that you booted from and has ffp)
4) Boot up the unit on the freshly formatted disk, install ffp on this disk and reboot (this disk will now be the /dev/sda disk as the unit is booted from it).
5) Telnet in, pop in the disk you removed, fdisk and format this disk (it will be /dev/sdb2 since it was added after the boot)
6) Reboot the unit.  Now you should have 2 individual volumes running on the DNS.

Ok I think I am understanding more now. I will try this out when I get time tonight and see if I can get her rolling...

Between step 3 and 4 though should I move /dev/sdb over to drive 0 before I proceed to fdisking (the now current) /dev/sda?

This makes a bit more sense now that you described it since when I did fdisk etc I was wondering why it woule mess with the drive in  "drive 1"

Last edited by Kdoggwiley (2008-06-09 18:34:44)

Got it, I only did what I saw from your previous posts, so even though I switched positions and fdisk'ed /dev/sdb I was still ok all along.  So just out of pure ignorance last night I was running in circles

Oh well, I will make another attempt at this tonight.

Thanks again bq041

KW

blahsome wrote:

bq041 wrote:

No, it does not reset the information.  I just tested it.

That's rather unfortunate. Is there a command that I can issue via telnet to reset it then?

Not exactlly.  Since it is stored in flash, you first need to mount it and then modify the file.  Here is the command line instructions for it.  It could be written into a scrip, but be very careful as this is modifying the flash.

/ # mount -t minix /dev/mtdblock0 /sys/mtd1   #Mounts flash block 1
/ # mount -t minix /dev/mtdblock1 /sys/mtd2   #Mounts flash block 0
/ # sed -i -e '3,4d' /sys/mtd1/hd_magic_num   # Deletes lines 3 and 4 from file hd_magic_num
/ # sed -i -e '3,4d' /sys/mtd2/hd_magic_num   # see above
/ # umount /sys/mtd1                          # Unmounts flash
/ # umount /sys/mtd2                          # See above
/ #

Very important to not forget to unmount the flash.  If you reboot without unmounting it, you will get errors in your dmesg and will need to run fsck.minix on the flash.  It is better not to have to worry about this.

No frustration here caused from the assistance.  I am just thankful that there are some people willing to walk others through to get what they want when the great little product made failed to deliver.  it has super potential but a shame that the community had to finish Dlinks work!

I was playing around with the limited knowledge that I do have so I would feel more comfortable with it and started to feel more at ease.  I did pull something to do with DOS up and then couldn't figure out what was going on so I ended my session and tried to log back in nad then re-fdisked again...

Oh well...all is good! Hopefully tonight will be more eventful...

I would not trust the windows network drive section.

Anyway, did you want to set up as RAID 1?  If so, I cannot do much for you until Friday.  I am traveling on business and all my stuff is at home.

bq041 wrote:

To format the drive properly after you have done the above fdisk:

Looks like I got lucky when recovering from the 94% issue.  I installed one drive, got it formatted OK, & installed ffp.  Push in 2nd drive. Then I telnetted in and built the partition table on the second drive as described above.  Then I rebooted.  Oops. Forgot to format the 2nd drive.  When it asked to format it for me, I said OK, and it worked fine.  Now I have Volume_1 and Volume_2 which is what I wanted. 

Regards

C

So I finally gave in and called tech support on the 94% freeze issue.  You will never guess what the solution was.

They asked me to remove all the .NET installations (I removed all but the most recent version so as not to screw up all the other applications running on my machine) in add/remove programs.  I asked them how on earth that could be the problem since I am using a web browser and the unit itself handles the formatting.  He claimed that somehow .NET corrupted the information sent to the unit to tell it to format ?????

The only other thing I did was leave the unit unplugged for a few days (since I could not get it to work yet).  The power off may have had nothing to do with it but I am mentioning it anyway in case the previous theory of the unit "remembering" the drives holds water.  I think that it is possible that it does remember the drives perhaps to make sure when replacing a failed drive in RAID1 that it does not think the working drive is the new drive.

So either .NET unistall or a 3 day power off did the trick.

Please try and let the rest of us that still need info know.  For now I am up and running.

DNS-Looped wrote:

The only other thing I did was leave the unit unplugged for a few days (since I could not get it to work yet).  The power off may have had nothing to do with it but I am mentioning it anyway in case the previous theory of the unit "remembering" the drives holds water.  I think that it is possible that it does remember the drives perhaps to make sure when replacing a failed drive in RAID1 that it does not think the working drive is the new drive.

Well - if that was the intent, they need to go back to the drawing board - because the unit, even with fw 1.05 is quite capable of doing exactly that.

DNS-Looped wrote:

SO does anyone think the .NET framework was the actual problem???

nope.. I don't even have .Net installed and it gave me endless 94% errors.

Essentially for me, this is the way to do it.

1. Reset config back to factory. i.e. clear all settings.
2. re-config drives into any other mode.. except that one that you had
3. if successful, reconfig the RAID back to what you actually want.


This is what I did which works for me.

Okay, here it is.  First a couple of things that could cause errors.  First, this is only for F/W 1.04 or 1.05.  I have not have time yet to make one for F/W 1.03.  In the web admin tool, turn off the iTunes, UPNP, and FTP servers.  You can turn them back on after you are done (they lock access on the configuration partitions).

Any data you wish to keep needs to be on drive 1 (left bay usually Volume_2).

1) Copy the attached file to the root of drive 0 (usually Volume_1).
2) Telnet in
3) Run the following command:

/ # /mnt/HD_a2/build_raid1_1.04_1.05.sh

4) Follow the instructions at the end.  I will also put them here.

1) Shutdown the unit using the web admin tool
2) Remove drive 0 (right bay)
3) Start up the unit
4) Telnet in
5) Push in drive 0
6) Run this command:

/# /mnt/HD_a2/raid1.sh

Once this has run, both drive lights should start blinking, indicating that sync is taking place.  You can monitor this in the web admin tool.  Do NOT shutdown, reboot, or interupt the power until sync is finished.

---

Attachments:
build_raid1_1.04_1.05.sh, Size: 3,053 bytes, Downloads: 312

The amber light is normal until you reboot when manually forming the array.  This time as soon as you form the second half of the array (when it starts syncing) enter the command:

do_reboot

Last edited by bq041 (2008-06-21 02:03:59)