[mythtv-users] How do I transfer recordings from old disk to new one?

[Phill Edwards]

Chris - thanks very much for such a detailed reply. I hope it isn't
wasted on me as it's very thorough!

> When copying Linux from one drive to another, the easiest solution
> *by far* is to leave the existing hard drive just where it is and
> install the new drive on a second channel.  You can then partition,
> format and mount the new drive without risking any damage to the
> existing installation.  If the partition assignments will be the
> same on the new device (sizes can be different but names the same)
> then all you have to do is copy all of the filesystems to the new
> drive, make the new drive bootable, and then swap the hardware.
> Since the new drive will occupy the device space previously held by
> the old drive, the /etc/fstab entries will be the same and the
> system should boot just fine.  If the assignments will change then
> you can still just copy everything from hda to hdc (or sda to sdc)
> and then edit the /etc/fstab on hdc/sdc to reflect the new
> assignments, bearing in mind that the drive will be hda/sda after
> the swap.

In hindsight this sounds like a good idea but I couldn't really do a
copy because I wanted the new disk to be running FC5 not FC3.

> > Any ideas how to get around this?
>
> Since you already swapped the drives, you can still salvage the
> situation.  What you need to do is prevent init from running after
> the kernel loads.  You can do that by specifying an alternate
> program.  For example, if your boot command is "linux
> root=/dev/hdc1 init=/bin/sh" then the kernel will mount /dev/hdc1
> read-only and immediately drop you to a shell.  You can then "mount
> /dev/hdc1 / -o remount,rw" and then edit /etc/fstab to fix your
> partitioning so that the init scripts won't bomb.  This isn't the
> best solution, though, particularly if the drives will eventually
> be swapped, because now you are going to have to change every
> reference to /dev/hda in all of the config files so that the
> programs will look on /dev/hdc, and then change them all back again
> after the drives are swapped.  Really, putting the old drive back
> on /dev/hda until after the new drive is ready to boot is a much
> better solution.

This sounded a bit hair-raising to me so what I ended up doing was
booting up with my sysrescuecd and mounting the partitions on the
old/new disks which I wanted to copy from/to.I then copied all the
files and dirs from /mnt/old/video to /mnt/new/video. This seemed to
work fine. I LOVE my sysrescuecd!

> You didn't ask, but I'll offer you this as well: You don't want to
> copy the filesystems of a Linux installation that's running in any
> "user" runlevel as the snapshot will be skewed because changes to
> files that have already been copied will be lost.  While it's
> possible to copy the filesystems while in runlevel 1 or S (the
> system maintenance runlevel), the best solution is to use the
> "init=/bin/sh" trick.  You can then mount the other drive and copy
> the contents of one drive to the other knowing that absolutely
> nothing is writing to the old drive.  Assuming /dev/hda had boot on
> hda1, swap on hda2, root on hda3 and var on hda4, what you would
> want to do is something like:
>
> boot: linux root=/dev/hda3 rw init=/bin/sh
> [Linux kernel boots and drops to shell]
> # swapon /dev/hda2
> # mkdir /target
> # mount /boot
> # mount /var
> #   [partition the new drive]
> # mkswap /dev/hdc2
> #   [mkfs the filesystems for hdc1, hdc3 and hdc4]
> # mount /dev/hdc3 /target
> # find / -mount | cpio -pa /target
> # mount /dev/hdc1 /target/boot
> # find /boot | cpio -pa /target
> # mount /dev/hdc4 /target/var
> # find /var | cpio -pa /target
> # echo -n > /target/etc/mtab
> [See notes 1 & 2]
> # umount /dev/hdc4
> # umount /dev/hdc1
> # umount /dev/hdc3
> # umount /boot
> # umount /var
> # sync
> # mount / -o remount,rw
> Now wait at least 5 seconds (after the drive LEDs stop flashing) and
> then cut the power to the box and swap the drives.
>
> Note 1: blanking out /etc/mtab will prevent the "mount" command from
> showing bad data after you swap the drives.
>
> Note 2: If your BIOS supports booting from hdc then you can get away
> without creating a boot sector or installing the boot loader right
> now.  Instead, swap the drives and tell your BIOS to boot /dev/hdc.
> When the loader gives you the boot prompt, launch using
> "linux boot=/dev/hdc1 root=/dev/hda3 rw init=/bin/sh"
> You can then mount /dev/hda1 as /boot and run the lilo or grub
> installer. Don't forget to make the new hda bootable.  Do the
> unmount, sync and remount and then hit the reset button.  You
> should be booting from hda.
>
> If you don't use a separate /boot partition then the "boot=" and
> "root=" arguments would both point to the same partition.
>
> As always, this information is offered with my best intentions and
> without any warranty. :-)  Read and understand everything before
> starting to make any changes to your system.

It's the understanding bit that's the challenge for me here - but
thank you once again for a very detailed answer. I appreciate it.

> > (Also, an off topic, much less important question - my new disk is
> > 320GB but shows up as 305GB when I do a "df -h". How come? Is it a
> > 1024 vs 1000 thing?)
>
> Yes and no.
>
> Drive manufacturers originally used the terms kilo and mega to
> refer to SI units of 10^3 and 10^6 whereas for binary math a
> kilobyte was 2^10 and megabyte was 2^20.  Had that system been
> carried to 10^9 versus 2^30 then a "320 Gig" drive would actually
> only hold 298 gigabytes.  The discrepancy between "marketing size"
> and "reported size" became more obvious as the drives got larger,
> so they now report drive sizes according to the number of 1024-byte
> blocks.  That means that a "320 Gig" drive today is one that has
> 640,000,000 LBA-addressible sectors of 512 bytes each, or 305
> gigabytes.  The drive capacity multiplication factor is neither
> 10^9 (SI) nor 2^30 (binary), but 10^6*2^10 (new math).
>
> So what does that mean?  When "df -h" reports 305Gb, it means
> 305*2^30 or 327,491,256,320 bytes.  If this was purely a 1000 vs
> 1024 issue then the drive would have been sold to you as having a
> "327 Gig" capacity.  You can check that by doing "df -H" to get the
> sizes in SI units instead of binary units.
>
> Incidentally, if you are using ext2 or ext3 then mkfs reserves 5%
> (by default) of the partition's available space for use by root to
> recover from emergencies like a run-away program that fills the
> drive.  That 5% is not included in the partition size displayed by
> df.  In that case, a "320 gig" drive with all of the space
> allocated to a single partition would be reported by "df -h" as
> having 290 gigabytes free.  Of the original "320 Gigs", you'd lose 15 to
> marketting inaccuracy and another 15 to the ext reservation.
>
> Glad you asked? :-)

Errrm - well..... still, at least I know that my disk is actually
320GB so I got what I paid for and wasn't ripped off!

Regards,
Phill