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

I used this link as a good step by step guide to configure my dns to run from usb drive

http://bfg100k.blogspot.com/2008/06/mov … stick.html

amichelf

Inside the scriptfile usbdisk.sh there is a var(iabele) which is called usbdisk_dev, which has the default value sdb1. In the box (and on most Linux boxes) the first harddisk is sda, the second is sdb, 3th sdc, ..., and an usb stick just gets the next value.
So if you've got a 2nd harddisk, you'll have to change the value to sdc1

Last edited by Mijzelf (2009-04-27 13:02:15)

Cirip wrote:

Sorry for anaother lame qustion but where is the usbdisk.sh file?

According to the changelog it's
/ffp/etc/examples/start-usbdisk.sh

does it say sh . ./usbdisk.sh or sh ../usbdisk.sh ? (the latter assuming that the usbdisk.sh script is in the directory *above* the directory that you are currently in), or more likely sh ./usbdisk.sh.  The more common approach would be to cd to the directory with the script and then issue

sh ./usbdisk.sh

note that ./ means current directory and ../ means directory above current

Also make sure that whatever editor you have used to change the usbdisk.sh file recognises and writes unix line endings.  If you are using a windows editor that doesn't (notepad for example) then the script won't run.  This is a general point with editing scripts and configuration files.

I have just checked: . ./scriptname.sh does work, but cd to the directory that the script is in and try sh ./usbdisk.sh and see what happens anyway.

Last edited by luusac (2009-04-28 15:39:48)

just to want to make sure that you know that 'mke2fs' is the command to format disks (ie. to erase all data on it). when playing around with it, you should really be sure that you specify the correct device. are you sure you know what you're doing?

Cirip,
What is your goal in moving the ffp to usb?
I'm running a system that gives some of the advantages, but does not require the usb stick or very much configuration at all.

The short version is that I run ffp off of /dev/sda4.     Compared to a usb setup, the only disadvantage is not being able to run e2fsck on /dev/sda4 without being in some fake-up of single user mode.   The advantages are that it does not require kernel modules, so it can run on the 323 or the 321, it leaves my usb port open for another project that I want to do, it's trivial to set up.

Here's a slightly more detailed version of what I do.
The default partitioning of the drives in the system creates three partitons,   a 512 mb swap partition, typically /dev/sda1, a 512 MB config partition, /dev/sda4, and the main data area, /dev/sda2, for the rest.    The config partition is much too big for the data that the firmware stores there, but just about the right size for ffp, some optware stuff, some log file mirrors and a home directory for root.      So, that's what I set up.   

Here's the procedure I used to get this going starting from a working ffp setup
To get this started, I just had to copy the ffp files to /mnt/HD_a4/ffp
  cp -a /mnt/HD_a2/ffp/ /mnt/HD_a4/ffp
Change the lines in the fun_plug that refer to /mnt/HD_a2
  replace empty line 5 with:
  FFP_MOUNT=/mnt/HD_a4
  replace all occurances of /mnt/HD_a2 with $FFP_MOUNT these are on lines 7,12,15,18 in case you are doing it manually.

Cut over to test the new setup:
  rm /ffp
  /bin/ln -s /mnt/HD_a4/ffp /ffp

Make sure you see a good ffp installation when you say
  /bin/ls ffp

reboot
(Thanks for the forethoughts to modularity Fonz!) 

That gets me a ton of the advantages of running off of usb.
I have:
    a clean /dev/sda2, except for the fun_plug file.  (same as usb)
    the ability to unmount /dev/sda2 and /dev/sdb2 to run fsck without going to a single user fakeup
    good separation between data and program partitions.
    separate backup cycles for data and program partitions.
    the usual powerdown unmounts /dev/sda2 cleanly some of the time (same as usb).

I do not have the advantages of reducing spinup which you get from usb.
I cannot run fsck on /dev/sda2 without going to single user mode fakeup.

To fix the spinup problem, I eliminated the rtc and dhcp crontab entries and replaced them with a single entry that: renews the dhcp; sets the clock using ntp; copies log files; and does a smart check any time that I spin up for a backup anyhow.      My backups run every 6 hours, so I spin up 4 times per day.   When the backups run, they also copy the fun_plug from /dev/sda2 to /dev/sdb2, and they copy /dev/sda4 to /dev/sdb4.   This makes the second drive usable as a first drive in case anything fails.

It's not a bad setup and it has far fewer moving parts than the usb based setups I've seen here.

Cirip,
I think that running off the USB is perfectly reasonable and it sounds like you are close to having that working.

I think that running off of /dev/sda4 would work too.

If you back up /dev/sda4 to /dev/sdb4 and fun_plug from/mnt/HD_a2 to /mnt/HD_b2 on a regular basis, the system will still be bootable as a fun_plug system from the second drive.     This is a bit of trouble, but then again, backing up the USB stick is probably a bit more trouble and is harder to automate.   (USB sticks do fail, but probably not as often as hard drives, but sticking out the back of the box it might look inviting to the cat as a plaything ;-)    )

You do not need to create these partitions yourself.   When you initially formatted the drives, the firmware created them for you, whether you wanted them or not.     It uses them to store some very tiny bookkeeping files in a hidden directory.

Putting data onto these partitions does not change whether /dev/sda2 and /dev/sdb2 are full or not.

I actually think that the coolest setup would be to do the hardware mod to enable the second (internal) usb adapter and do another hardware mod to put a 3rd (2.5 inch) disk into the thing.     I wonder if anyone has tried that yet?   You could use the 3rd disk as a "backup journal" to update an off-site backup, or just as more storage.