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

Sun Sep 10 09:00:08 UTC 2006

On Sun, Sep 10, 2006 at 02:22:52PM +1000, Phill Edwards wrote:
> I'm upgrading my system from FC3 with a 80GB disk to a fresh install
> of FC5 on a brand new 320GB disk. I'm just about there, but I can't
> work out how to transfer the recordings off my old hard disk onto the
> new one. My plan was:
> 
> 1) Put both disks in and boot off the new one with the old disk as a slave.
> 2) Mount the xfs partition on the old disk.
> 3) Copy the recordings frmo there onto the new disk.
> 
> I thought I could boot off the new disk with the old one as a slave
> but whenever I boot with both disks in I get "Read-only file system"
> errors on boot up and then the boot hangs on "Starting system logger".

That's normally the result of moving disks around without updating 
the /etc/fstab entries.

The information you give the boot loader (lilo or grub) is only 
used to find the kernel and tell it which device contains the root 
filesystem.  Once the kernel is running it mounts the specified 
root device read-only and launches init.  The init process starts 
running the boot scripts on the root filesystem.  One of those 
scripts does the fsck of the boot partition and then remounts it 
read-write once it is safe to do so.  It's possible to bypass this 
fsck and remount step by including "rw" as a kernel boot argument, 
but that's inviting disaster.

If you swap hda and hdc and tell the kernel "root=/dev/hdc1" but 
/etc/fstab still says /dev/hda1, then the fsck and remount will 
fail and your system is left running on a read-only filesystem 
(which is a good thing, since a bad "/" entry in /etc/fstab is 
probably a good indication of other problems.

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.

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

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.

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