Replacing a hard disk drive with a newer/larger one can get complicated, especially since disk geometries can be confusing.

Let's assume first, that your old drive is still operating, and boots up fine.

Since my mythbox is running "headless", I found it just easier to do the rebuild on another workbench machine. In my case, my both of the IDE channels were wide open. The CD ROM drive was setup as a slave, and it is quite bootable. I plugged in both the old disk drive (in the "A" channel) and the new disk drive (in the "B" channel) as Master Drives. This means that the old drive comes up as hdz and the new drives is hdc.

I located and downloaded the ISO image for the gparted "live CD". Most of the work done is from here.. on the booted CD.

Looks like there's a newer version.. I got 0.3.4-4 .. I'm sure that'll work as well. http://sourceforge.net/project/showfiles.php?group_id=115843

With the drives in place, I booted up on the "gparted live cd". It's a bit cranky on my nVidia card.. but Ctrl-Alt-1 gets you into a terminal mode so you can use the "Forcevideo" command and get up the GUI. The default 1024x768 works fine.. but the text is pretty tiny.. and 800x600 works great.

In no time, gparted showed both drives. real easy to click on one partition, hit "copy", click on the new drive, and hit "paste". That's what gui is all about. I setup the "activities" to copy the root, swap and myth partitions, then let it fly. You also can set it to change the partition size (on the fly) to the target drive.

I have used partitionmagic in the past.. and it works very well (under windows).. gparted is quite it's equal under Linux.

Going from my 200 GB drive to my new 500 GB drive took over four hours to complete.. to make matters worse, I screwed up the new drive, so I had to repeat the process. I was in no hurry.

The real trick to this process is betting the MBR (master boot record) to work properly on the new drive. You seriously cannot expect it too just work. .. In other words.. at this point, you got lots of data on a new drive that won't boot.. ouch!

Googling around.. I learned that you want to get "lilo" to fix the MBR for you.

Here's a page with a procedure that works.. http://users.bigpond.net.au/hermanzone/p4.html#Install_Lilo_from_a_Linux_LiveCD .. nice thing.. it works right from your "gparted live cd" session.. so there's nothing else to setup.

There are some things that I don't quite understand.. but here goes..
The procedure suggests "1. Set the boot flag". gparted doesn't show the boot flag on my old disk drive (yet it works).. I used gparted to set it on the root partition on the new drive. (ok, so it works.. doesn't seem to hurt.)

We don't really mind that the procedure is for Ubuntu.. we're all Debian family members.. close enough. In the prcedure, some of the command line items are preceeded with "sudo" .. cute, but we don't care, we don't need it.

"2. chroot into the Ubuntu install and apt-get and install Lilo" .. yeah, yeh, yeah .. sounds all that nice.. but seriusly.. our KnoppMyth drive already has Lilo.. so we don't have to get it or install it.. but the "live CD" doesn't.. and it doens't have apt-get either.. no worries.. we don't need it.. that's why we're doing "chroot". .. but first, we mount the new drive .. if you're the cautuous type.. power it all down and remove your old drive.. this is your backup in case you screw up!

"mkdir /mnt/ubuntu" .. uhh we mean mkdir /mnt/hdcmnt (new drive being hdc)

"mount /dev/hda7 /mnt/ubuntu/" .. uhhh we mean: mount /dev/hdc1 /mnt/hdcmnt/

"mount -t proc none /mnt/ubuntu/proc" >> mount -t proc none /mnt/hdcmnt/proc

"mount -o bind /dev/ /mnt/ubuntu/dev" >> mount -o bind /dev/ /mnt/hdcmnt/dev

OK, now we can "chroot" ...
the procedure says "chroot /mnt/ubuntu /bin/bash" .. our version is: chroot /mnt/hdcmnt /bin/bash

I really can't explain that the last mount commands and the chroot commands really do.. but the bottom line is.. you're logged into the new knoppmyth drive.. and you're good to go.. and set the MBR..

They show "lilo -b /dev/hda7" .. for us that's either lilo -b /dev/hdc1 OR lilo -b /dev/hda1 ... I did both!.. and the second one last.. I'm thinking that it supposed to be "hda1" because, that's what it WILL BE when I boot it back up in my mythbox. (and it works.. so.. so there!)

(last steps in the procedure.. exit.. unmount.. yeah, yeah, yeah.)

Put the new drive back in the mythbox .. and boot... enjoy!

Other reference... http://www.tldp.org/HOWTO/LILO-2.html#ss2.1

Anyone with questions, comments.. why it should work.. why it shouldn't.. I'd be glad to hear.. Just here to learn and share!

_________________
// Brian - Hardware:
ASUS P5P800 - P4 3Ghz, 500 GB PATA HD
ASUS P5K-V - P4 Core2 Duo, 500 GB SATA HD
Hauppauge PVR-350, IR Blaster, Comcast Digital Cable
http://tech.groups.yahoo.com/group/KnoppMyth/
KnoppMyth R5F27 >> R5.5

For my money the procedure above seems fine for replacing the entire disk, but what about those who have a separate drive for recordings, and don't need to replace the boot drive? Here's my experience, including goof-ups. Again in the spirit of BluesBrian, I'm just here to learn and share. Amazinly I did this just yesterday before BluesBrian posted.

In my KnoppMyth setup I have one boot HD and another for Recordings.
my PATA /dev/hda1 had the / (root) and /dev/hda2 Swap partitions.
there is also a /dev/hda3 partition for /myth that holds mythvideo and everything else in /myth that is not recordings. my SATA /dev/sda1 was mounted to /myth/tv

This process should be easily adaptable if the second drive is NOT SATA or is more than just the recordings directory.

1. I found a window where there was several hours before the next upcoming recording.
2. shutdown, connected the NEW harddrive to an open SATA connector. booted the computer and confirmed the drive as /dev/sdb. (this will work for PATA, you'll just get a /dev/hd? device)
3. boot up; login as root.
4. ran fdisk /dev/sdb created a single (primary) partition across the whole drive.
5. formatted the new drive to use the same fs type as the current (xfs)
mkfs.xfs -f /dev/sdb1
If you want to change fstype that's OK, but you'll have to edit /etc/fstab later...
6. mounted the new partition.
mkdir /media/sdb1
mount -t xfs /dev/sdb1 /media/sdb1
7. Copied all my files...
cd /myth/tv
tar -cvf - * | (cd /media/sdb1 ; tar -xf -)
8. Grab a beverege this could take a while. smoke 'em if you got 'em...
9. after the transfer completes. Shutdown and swap the interface cables.
NOTE: before shutting down edit /etc/fstab for the 'new' partitions and or fs type if you are doing anything more complicated than a direct HD replace... ie changing SATA<->PATA or replacing the default /dev/hda3 partition with a new drive...
10. I booted-up and expected to see everything happy but had to clean the following. I'm not sure how to change the process to avoid this.

a. The SATA power cabling was not real secure and bounced off as I was putting the myth box back in the rack. This was more of a panic causer than a real problem.
b. for some reason the /myth/tv mountpoint directory changed ownership to root making the recording directory read-only. Running
chown mythtv:mythtv /myth/tv
as root fixed this. VERIFY everything works before missing a recording!!! watch some live tv or setup a recording of some junk you don't care about...

Your mileage may vary. hope this helps someone...

Very nice.

yeah, "permissions" can be a trap! .. at least you didn't have to worry much about the MBR and booting issues!

Several days before, I had a discussion with a friend that's much more "up on his Linux" than I am. We discussed four different approaches:

1. "dd method". This is best when you're cloning an entire disk drive that has an identical geometry. http://mysettopbox.tv/phpBB2/viewtopic.php?t=12812&highlight=mbr discusses this. This method is "device oriented".

2. "partimage rescue cd" or "gparted live cd" method.. which I describe above. Actually, jmckeown2 could have used this method, as it is oriented around the partition rather than the whole device. (we could have just cloned over the myth partition.. and got it resized in one step) Another advantage.. it works on unmounted partitions, so no worries about getting stuff missed or out of sync 'cuz a file was busy. especially nice for cloning a root partition!

3. "cpio method". basically, create your partitions and use the cpio command to bring over the files. this should be good with permissions.

4. "tar method".. jmckeown2 described this method beautifully. ya gotta love tar's alphabet soup!.. my friend suggested using the -z option that filters the whole event through gzip. presumably to save space on the interim.. although he was showing me using tar with separate commands, rather than your more elegant.. tar in and tar out on one command line. I'm thinking that "z" would slow things down... maybe reduce the I/O workout and increase the cpu pounding. could do some benchmark tests! I'm a little mystified on jmckeown2's permission glitch.

_________________
// Brian - Hardware:
ASUS P5P800 - P4 3Ghz, 500 GB PATA HD
ASUS P5K-V - P4 Core2 Duo, 500 GB SATA HD
Hauppauge PVR-350, IR Blaster, Comcast Digital Cable
http://tech.groups.yahoo.com/group/KnoppMyth/
KnoppMyth R5F27 >> R5.5

Modern Linux/Unix systems generally have a cp -a option which will do the recursive copy with the correct permissions...

Good point.. I would take this into account with a modification to my "3. "cpio method". "

_________________
// Brian - Hardware:
ASUS P5P800 - P4 3Ghz, 500 GB PATA HD
ASUS P5K-V - P4 Core2 Duo, 500 GB SATA HD
Hauppauge PVR-350, IR Blaster, Comcast Digital Cable
http://tech.groups.yahoo.com/group/KnoppMyth/
KnoppMyth R5F27 >> R5.5

I will look into that. I learned the basic commands so long ago I never really looked into updated options...

As for the tar command. (again I'm going to date myself) I learned the format of that command from the examples section of the Solaris 5 tar manpage. (I'm not sure if it has been carried forward or appeared in linux.) The idea is that the first part tar's the files to stdout; the second half untar's from stdin (by specifying dash as the filename) so If you were to add the z option to both sides to compress/decompress you would, as you pointed out, be adding CPU overhead. Depending on how slow the disks are and how fast the cpu(s) are I/O might not get throttled, but I believe it would. It would not get reduced however.

The other gotcha with compressing is that in this case we are moving already compressed files. My gut feel is that the compress flag would make things worse even if you were staging the tar through a real file.

I'm still baffled about the permission thing too, but not enough to do further experimentation directly on my myth box. It almost made me miss a "House" episode I have a desktop that has Ubuntu I may play there. Hopefully the take-away is that someone trying to do the tar-method need only verify/fix the permissions which should only take a few seconds. I got some odd behaviors that were very hard to track down; but make perfect sence knowing the problem. I couldn't open "Live TV" and I couldn't delete shows through "recorded programs" or MythWeb" (they initally disappeared, but came back after a refresh)