LinHES Forums
http://forums.linhes.org/

Replacing a Volume
http://forums.linhes.org/viewtopic.php?f=3&t=16348		 Page 1 of 1
Author:  jmckeown2 [ Fri Sep 07, 2007 1:17 pm ]
Post subject:  Replacing a Volume
Here's my scenario in a nutshell, I am installing a new SATA drive (/dev/sdb), and want to transfer all data from a same-sized PATA drive (/dev/hdb). The mount point is /myth/video. The trick is I don't want to remove the PATA drive. The drives are the same size, if the drives were different sizes I would recommend booting the mythbox with a rescue cd and do all this in gparted.

I had a couple of things go wrong (slightly), so I figure detailing the issues may save someone else some annoyance. I'm pointing out my mess-ups in the order I found them, not the order I committed them.

based on forum posts the command to transfer the data from hdb to sdb is (as root)
Code:
dd if=/dev/hdb of=/dev/sdb bs=2048k

which for my 300Gb drives should have taken 2-3 hrs. My first screw-up was leaving off the 'k' which means the transfer was done with 2kB blocks, not 2MB blocks; the transfer took almost 5 hrs.

Once it was finally finished I wanted to mount the new drive and verify the data. no dice. It wouldn't mount. 'dmesg | tail' pointed out to me that the xfs filesystem had a duplicate UUID, meaning dd made an EXACT copy. googling gave me the fix to this
Code:
xfs_admin -U generate /dev/sdb1

However that gave me a warning that the fs had transactions to replay and doing this without mounting the partition first would screw it up. Which points out my next fault. I probably should have unmounted /myth/video before starting...

So here's the whole fix, I needed to unmount the first drive to get the first copy out of the way, mount the second drive to fix the journal, then unmount it again, fix the dup and remount BOTH:
Code:
umount /myth/video
mount -t xfs /dev/sbd1 /media/sdb1
umount /media/sdb1
xfs_admin -U generate /dev/sdb1
mount /myth/video
mount -t xfs /dev/hdb1 /media/sdb1


I did a bunch of ls commands and satisfied myself that it was finally good and took the step of changing the entry in /etc/fstab. Reboot and I'm done, right? WRONG.
Quote:
LILO:
Error: Duplicated Volume ID

Again with dd being too much of a good thing...
Google to the rescue again. You can confirm the duplicate with
Code:
lilo -T vol-ID

and here's the fix:
Code:
lilo -z -M /dev/hdb
lilo -v
reboot

The lilo -z probably should have been the new drive, but I did the old.
If you don't do the reboot, the fix doesn't appear to have worked.

So I'm guessing the correct procedure is:
    Install the new drive
    ( maybe init s )
    unmount the source partition
    dd to copy the partition
    xfs_admin to correct the dup filesystem id
    lilo -z -M the drive...
    lilo
    reboot
Author:  Girkers [ Fri Sep 07, 2007 5:58 pm ]
Post subject: 
I think you need to add to your steps in your conclusion, to unmount the drive first. This will help as well as it won't let you unmount if there is a file open or locked. Copying a locked or open file is not always a good thing.

Good work figuring this out though, good grab.
Author:  jmckeown2 [ Fri Sep 07, 2007 8:38 pm ]
Post subject: 
Girkers,
Nice catch, I originally meant to have that in there because it also prevents the journaling problem that prevented my first attempt to resolve the UUID problem.

I also added in the thought that this should be done in single user mode. Would it help to keep the system quiet, or is that just overkill?

I also added the reboot at the end. This is required to make the vol-ID fix take effect.

Now here's a question, If I want to dup my entire hda, how do you fix the duplicate vol id without zeroing out the MBR? ie the -z param to lilo -- I need to read up on lilo.
Author:  tjc [ Fri Sep 07, 2007 9:24 pm ]
Post subject: 
Just for the sake of completeness, let me add that you don't need to make a bit for bit copy of the file system to clone it. You can also:

1) Install the new drive.
2) Format it and create the file system.
3) Mount the new file system.
4) Use rsync or the like to copy everything across.
5) Logically swap the drives around (via the cables or jumpers).
6) Boot with the CD as a rescue disk.
7) Make sure the drive is mounted, chroot there, and run lilo.

This may actually be a lot faster if the drive isn't all that full, and works for disparate sized drives (e.g. 250Gb -> 750Gb). It also repacks the file systems ensuring that files are written contiguously and compactly like an old school disk optimizer would.
Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/