NSLU2-Linux
view · edit · print · history

HowTo.SwapDrivesOnUnslung History

Hide minor edits - Show changes to markup

August 27, 2008, at 11:13 PM by David Nelson -- Additional suggestion for dd\'s bs= param
Changed lines 120-128 from:

7. restart

to:

7. restart


From linuxquestions.org, re: cloning

"I always add bs=32256 to speed up the process. 32256=63 sector times 512 bytes and is a full track size. Omitting the bs parameter Linux will defaults to copying 512 byte at a time."

worked for me on unslung 5.x


June 12, 2008, at 08:24 PM by choosyg -- added \"the easiest way\"
Changed lines 108-120 from:

I too had problems using Knoppix to "dd" the partitions to new HD, as per the first method above. Same Permission problem. I got around this by using the "Root Shell" found under Program & Configuration on the Desktop rather than the "Konsole" program to run the required commands. The permission problems disappeared, and after running efsck and resize2fs (after Umounting the data partition) the slug booted up fine with the new HD and works fine.

to:

I too had problems using Knoppix to "dd" the partitions to new HD, as per the first method above. Same Permission problem. I got around this by using the "Root Shell" found under Program & Configuration on the Desktop rather than the "Konsole" program to run the required commands. The permission problems disappeared, and after running efsck and resize2fs (after Umounting the data partition) the slug booted up fine with the new HD and works fine.


Unslung 6.8 The easiest way worked fine: 1. plug new HD into the free slug-usb-port 2. format it with the webinterface 3. type "mount" to see the mount point -> remount sdb1 to /mnt/data and sdb2 to /mnt/conf 4. run "rsync --delete -vat /share/flash/data /mnt" (remember to do that as root) 5. run "rsync --delete -vat /share/flash/conf /mnt" 6. shutdown, remove old disk and plug new disk into the other usb port 7. restart

March 09, 2008, at 12:08 PM by Dino T -- using kNOPPIX to copy partitions
Added lines 105-108:

I too had problems using Knoppix to "dd" the partitions to new HD, as per the first method above. Same Permission problem. I got around this by using the "Root Shell" found under Program & Configuration on the Desktop rather than the "Konsole" program to run the required commands. The permission problems disappeared, and after running efsck and resize2fs (after Umounting the data partition) the slug booted up fine with the new HD and works fine.

March 01, 2008, at 01:58 PM by marceln -- Added filecopy for cloning disk
Deleted line 65:
Added lines 67-97:

alternative aproach

It isn't necessary to copy all the disk blocks. You only need a disk with the same disk layout with 3 partitions, the same type of filesystems and all the files which are on the old disk!

  1. Format the disk with the web interface
  2. Mount the disks on a linux system
  3. remove
  4. Mount the filesystems
  5. copy the files of the filesystems

Assume that the root slug disk is "/dev/sda" and the new disk is "/dev/sdb".

# mkdir -p /mnt/data
# mkdir -p /mnt/conf
# mount /dev/sdb1 /mnt/data
# mount /dev/sdb2 /mnt/conf
# rm -rf /mnt/data/* /mnt/conf/*
# cd /mnt/data
# mklost+found
# cd /mnt/conf
# mklost+found
# cd /share/flash/data
# tar cf - . | (cd /mnt/data;tar xf -)
# cd /share/flash/data
# tar cf - . | (cd /mnt/data;tar xf -)
# umount /mnt/data
# umount /mnt/conf

February 21, 2007, at 12:51 AM by snorton -- Clean up formatting. Drive clarification request when dealing with smaller target drive.
Changed lines 23-34 from:

Notes: The error generated because sdb1 is larger than sda1 can be safely ignored

       The parameter "bs=128k" is necessary to accelerate the copy process. As an 
       average 10-15MBytes/s should be reached as a minimum data rate (chipset-integrated
       USB-ports can reach up to 30MBytes/s). Without the "bs=128k" parameter the copy
       data rate is reduced to a fourth of the maximum throughput.

       The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using
       such a kernel might result in very low rates around 700KBytes/s. This means that
       copying a data partition of 250GB would take about 3 days. If you encounter such
       poor throughput use a Linux system with kernel version 2.6.x instead.
to:

Notes:

  The error generated because sdb1 is larger than sda1 can be safely ignored

  The parameter "bs=128k" is necessary to accelerate the copy process. As an 
  average 10-15MBytes/s should be reached as a minimum data rate (chipset-integrated
  USB-ports can reach up to 30MBytes/s). Without the "bs=128k" parameter the copy
  data rate is reduced to a fourth of the maximum throughput.

  The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using
  such a kernel might result in very low rates around 700KBytes/s. This means that
  copying a data partition of 250GB would take about 3 days. If you encounter such
  poor throughput use a Linux system with kernel version 2.6.x instead.
February 21, 2007, at 12:48 AM by snorton --
Changed lines 1-2 from:

I wanted to clone my existing NSLU2 configuration to a larger(see below for a smaller) disk, so I did the following (sda and sdb are used for example only):

to:

I wanted to clone my existing NSLU2 configuration to a larger(see below for a smaller) disk, so I did the following (sda and sdb are used for example only):

Changed lines 21-26 from:
  dd if=/dev/sda1 of=/dev/sdb1 bs=128k (takes considerably longer.  the error generated because sdb1 is larger than sda1 can be safely ignored)

  Note: The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15MBytes/s should be reached as a minimum data rate (chipset-integrated USB-ports can reach up to 30MBytes/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

   The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in very low rates around 700KBytes/s. This means that copying a data partition of 250GB would take about 3 days. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.
to:
  dd if=/dev/sda1 of=/dev/sdb1 bs=128k (takes considerably longer)

Notes: The error generated because sdb1 is larger than sda1 can be safely ignored

       The parameter "bs=128k" is necessary to accelerate the copy process. As an 
       average 10-15MBytes/s should be reached as a minimum data rate (chipset-integrated
       USB-ports can reach up to 30MBytes/s). Without the "bs=128k" parameter the copy
       data rate is reduced to a fourth of the maximum throughput.

       The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using
       such a kernel might result in very low rates around 700KBytes/s. This means that
       copying a data partition of 250GB would take about 3 days. If you encounter such
       poor throughput use a Linux system with kernel version 2.6.x instead.
Changed lines 43-44 from:

6. Plug the new drive back into the NSLU2, boot, and verify the /share/hdd/data file system size.

to:

6. Plug the new drive back into the NSLU2, boot, and verify the /share/hdd/data

    file system size.
Changed lines 50-53 from:

To clone to a smaller disk you have to do the same thing as above, only in the step 3 for the data partition do the following instead:

Fill the empty space on the partition (WHICH DRIVE?) with a file full of zeros and then mark it deleted. It will take some time, depending on how much empty space you have.

to:

To clone to a smaller disk you have to do the same thing as above, only in the step 3 for the data partition do the following instead:

Fill the empty space on the partition (WHICH DRIVE?) with a file full of zeros and then mark it deleted. It will take some time, depending on how much empty space you have.

Changed lines 58-59 from:

Then, run dd to copy the data partition to the new drive, Multiple blocks of zeros will get abbreviated with a string of asterisks saving space

to:

Then, run dd to copy the data partition to the new drive, Multiple blocks of zeros will get abbreviated with a string of asterisks saving space

Changed lines 63-64 from:

dd will exit with an error "not enough space" after it has filled up sdb1 Ignore this error and proceed to the step 4.

to:

dd will exit with an error "not enough space" after it has filled up sdb1 Ignore this error and continue with step 4.

February 21, 2007, at 12:44 AM by snorton -- Asking for clarification. Clean up text a bit.
Changed lines 1-3 from:

I wanted to clone my existing NSLU2 configuration to a larger(see below for a smaller) disk, so I did the following:

to:

I wanted to clone my existing NSLU2 configuration to a larger(see below for a smaller) disk, so I did the following (sda and sdb are used for example only):

Changed lines 10-12 from:

2 (sdb). Please note that if you make a mistake here, you will destroy your data. You might want to read a dd howto before you start. There is also an instruction on how to move files from a bigger partition to a smaller one.

to:

2 (sdb). Please note that if you make a mistake here, you can DESTROY YOUR DATA. You might want to read a dd howto before you start. See below if you are moving files from a bigger partition to a smaller one.

Changed lines 15-17 from:

dd if=/dev/sda2 of=/dev/sdb2 bs=128k (takes a minute or two)

to:
  dd if=/dev/sda2 of=/dev/sdb2 bs=128k  (takes a minute or two)
Changed lines 19-29 from:

dd if=/dev/sda1 of=/dev/sdb1 bs=128k (takes considerably longer, the error generated because sdb1 is larger than sda1 can be safely ignored)

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15MBytes/s should be reached as a minimum data rate (chipset-integrated USB-ports can reach up to 30MBytes/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in very low rates around 700KBytes/s. This means that copying a data partition of 250GB would take about 3 days. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.

to:
  dd if=/dev/sda1 of=/dev/sdb1 bs=128k (takes considerably longer.  the error generated because sdb1 is larger than sda1 can be safely ignored)

  Note: The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15MBytes/s should be reached as a minimum data rate (chipset-integrated USB-ports can reach up to 30MBytes/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

   The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in very low rates around 700KBytes/s. This means that copying a data partition of 250GB would take about 3 days. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.
Changed lines 27-28 from:

fsck.ext3 -y -f /dev/sdb1

to:
  fsck.ext3 -y -f /dev/sdb1
Changed lines 31-35 from:

resize2fs /dev/sdb1

6. Plug the new drive back into the NSLU2, boot, and verify the /share/hdd/data file system size.

to:
  resize2fs /dev/sdb1

6. Plug the new drive back into the NSLU2, boot, and verify the /share/hdd/data file system size.

Changed lines 41-47 from:

fill the empty space on the partition with a file full of zeros and then mark it deleted. It will take some time, depending on how much empty space you have.

cat /dev/zero > zero; rm zero;

Then, run dd and multiple blocks of zeros will get abbreviated with a string of asterisks saving space

dd if=/dev/sda1 skip=1 of=/dev/sdb1 seek=1 bs=4k conv=noerror

to:

Fill the empty space on the partition (WHICH DRIVE?) with a file full of zeros and then mark it deleted. It will take some time, depending on how much empty space you have.

  cat /dev/zero > zero; rm zero;

Then, run dd to copy the data partition to the new drive, Multiple blocks of zeros will get abbreviated with a string of asterisks saving space

  dd if=/dev/sda1 skip=1 of=/dev/sdb1 seek=1 bs=4k conv=noerror
Changed lines 49-50 from:

dd will exit with an error "not enough space" after it has filled up sdb1, just ignore and proceed to the step 4.

to:

dd will exit with an error "not enough space" after it has filled up sdb1 Ignore this error and proceed to the step 4.

January 28, 2007, at 09:53 AM by Lars Bager -- minor correction
Changed lines 26-27 from:

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15MBytes/s should be reached as a minimum data rate (chipset USB-port reach up to 30MBytes/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

to:

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15MBytes/s should be reached as a minimum data rate (chipset-integrated USB-ports can reach up to 30MBytes/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

January 28, 2007, at 09:51 AM by Lars Bager -- corrected syntax errors
Changed lines 26-31 from:

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15 MBytes?/s should be reached as a minimum data rate (chipset USB-port reach up to 30 MBytes?/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in very low rates around 700 KBytes?/s. This means that copying a data partition of 250GB would take about 3 days. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.

to:

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15MBytes/s should be reached as a minimum data rate (chipset USB-port reach up to 30MBytes/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in very low rates around 700KBytes/s. This means that copying a data partition of 250GB would take about 3 days. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.

January 28, 2007, at 09:50 AM by Lars Bager -- corrected syntax errors
Changed lines 26-31 from:

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15 MByte?/s should be reached as a minimum data rate (chipset USB-port reach up to 30 MBytes?/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in rates around 700 KBytes?/s. This means that copying a data partition of 250 MByte? would take about 3 days to copy. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.

to:

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15 MBytes?/s should be reached as a minimum data rate (chipset USB-port reach up to 30 MBytes?/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in very low rates around 700 KBytes?/s. This means that copying a data partition of 250GB would take about 3 days. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.

January 28, 2007, at 09:47 AM by Lars Bager -- added parameter \"bs=128k\". Recommended using kernel 2.6.x
Changed line 16 from:

dd if=/dev/sda2 of=/dev/sdb2

to:

dd if=/dev/sda2 of=/dev/sdb2 bs=128k

Changed line 21 from:

dd if=/dev/sda1 of=/dev/sdb1

to:

dd if=/dev/sda1 of=/dev/sdb1 bs=128k

Added lines 25-31:

The parameter "bs=128k" is necessary to accelerate the copy process. As an average 10-15 MByte?/s should be reached as a minimum data rate (chipset USB-port reach up to 30 MBytes?/s). Without the "bs=128k" parameter the copy data rate is reduced to a fourth of the maximum throughput.

The Unix-Kernel 2.4.x seems to have problems in supporting High-Speed-USB. Using such a kernel might result in rates around 700 KBytes?/s. This means that copying a data partition of 250 MByte? would take about 3 days to copy. If you encounter such poor throughput use a Linux system with kernel version 2.6.x instead.

May 30, 2006, at 09:02 PM by egorATkobylkinDOTcom -- Cloning to a smaller disk
Changed line 1 from:

I wanted to clone my existing NSLU2 configuration to a larger disk, so

to:

I wanted to clone my existing NSLU2 configuration to a larger(see below for a smaller) disk, so

Added lines 40-51:

To clone to a smaller disk you have to do the same thing as above, only in the step 3 for the data partition do the following instead:

fill the empty space on the partition with a file full of zeros and then mark it deleted. It will take some time, depending on how much empty space you have.

cat /dev/zero > zero; rm zero;

Then, run dd and multiple blocks of zeros will get abbreviated with a string of asterisks saving space

dd if=/dev/sda1 skip=1 of=/dev/sdb1 seek=1 bs=4k conv=noerror

dd will exit with an error "not enough space" after it has filled up sdb1, just ignore and proceed to the step 4.

May 28, 2006, at 12:21 PM by egorATkobylkinDOTcom --
Changed lines 12-13 from:

destroy your data. You might want to read a dd howto before you start. There is also an instruction on how to move files from a bigger drive to a smaller one.

to:

destroy your data. You might want to read a dd howto before you start. There is also an instruction on how to move files from a bigger partition to a smaller one.

May 28, 2006, at 11:58 AM by egorATkobylkinDOTcom -- added a link to dd howto
Changed lines 12-13 from:

destroy your data.

to:

destroy your data. You might want to read a dd howto before you start. There is also an instruction on how to move files from a bigger drive to a smaller one.

Deleted line 47:
August 28, 2005, at 04:28 AM by jacek --
Changed lines 38-48 from:

-- Courtesy of polarisdb

to:

-- Courtesy of polarisdb


unslung 5.5; swapping 'Disk 1' (used to unslung) for a bigger one

I tried to use Knoppix, but it complained about permissions, and refused to do anything.

Installed Suse 9.3, and followed the above procedure, but it didn't work. Slug was dead with the new HD.

I noticed that /dev/sdb2 and /dev/sdb3 were smaller than in the old HD (I partitioned that new HD in the slug, as mentioned above), so I used partitioning util on Suse to make them bigger than on the old HD. Instead of using dd for /sdb2 (also didn't work on resized partition), I just connected that new HD to the slug as Disk 2, mounted it (was not mounted by the slug, what could go right at this point), and manually copied 'conf' stuff to the /sdb2. After that fsck was clean, and slug started from the new HD.

August 05, 2005, at 02:34 PM by rwhitby --
Added lines 1-38:

I wanted to clone my existing NSLU2 configuration to a larger disk, so I did the following:

1. Format the new disk as "disk 2" in the NSLU2 (basically because it was the easiest way to get the partitions created).

2. Move both disks from the NSLU2 to a Linux box. Using a boot cd like Knoppix (http://www.knoppix.org/) will work fine.

3. Copy the existing data partitions from NSLU2 disk 1 (sda) to disk 2 (sdb). Please note that if you make a mistake here, you will destroy your data.

Copy the conf partition from the old disk to the new disk:

dd if=/dev/sda2 of=/dev/sdb2 (takes a minute or two)

Copy the data partition from the old disk to the new disk:

dd if=/dev/sda1 of=/dev/sdb1 (takes considerably longer, the error generated because sdb1 is larger than sda1 can be safely ignored)

4. Run a fsck on partition 1 on the new disk

fsck.ext3 -y -f /dev/sdb1

5. Expand the file system on sdb1 to use the entire partition

resize2fs /dev/sdb1

6. Plug the new drive back into the NSLU2, boot, and verify the /share/hdd/data file system size.

7. Done

-- Courtesy of polarisdb

view · edit · print · history · Last edited by David Nelson.
Based on work by choosyg, Dino T, marceln, snorton, Lars Bager, egorATkobylkinDOTcom, and jacek.
Originally by rwhitby.
Page last modified on August 27, 2008, at 11:13 PM