view · edit · print · history

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):

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 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.

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

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

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

  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.

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

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.

  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

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

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

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.

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

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

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