TiVo Community Forums Archives - Trouble trying to copy 100 GB drive to 120 GB drive

TiVoCommunity.com
(c)opyright 1995-2005 All rights reserved
indexcheckTC
This area is a static history of posts in the TiVo Community Forum Archive.
This archive history was made for the simple indexing of search sites like Google.

Pages:1

Trouble trying to copy 100 GB drive to 120 GB drive
(Click here to view the original thread with full colors/images)

Posted by: charlieg

I upgraded my Hughes DTivo a few months back by replacing the original 40 GB drive with a 100 GB Maxtor. That upgrade went very smoothly and all my recordings were preserved but in a quest for even more space, I recently purchased a 120 GB Drive to add to the system. Since for my previous upgrade, I did not expand swap, I figured I would simply copy my 100 GB drive to the new 120 GB drive (adding the -s 127 to the piped restore process) and then, after verifying that all was working with the new drive, I would use mfsadd to add the 100 GB drive to the storage pool as drive B. However, I seem to have run into a problem ...

Using the following command:

mfsbackup -Tao - /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdd

where hdb: 100 GB former Tivo A drive
hdd: new 120 GB drive

I get an error to the affect that the target drive does not have enough space for the backup image. Before you ask, yes, I've verified that the system does indeed recognize the drives at their proper sizes so I'm not quite sure why I can't complete the copy (after all, the new drive is 20 GB larger than the current A drive). Any additional insight would be greatly appreciated.

Thanks for your help,

Charlie

Posted by: Tivogre

I had a similar problem recently.

You also need to include the "s" option in the msfbackup command.

The command that will work for you is:

mfsbackup -Taso - /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdd

Let us know how it turns out!

Posted by: charlieg

No joy. I get the same error.

Thanks for responding.

- Charlie

Posted by: Robert S

I think -a and -s are mutually exclusive. (-a says take everything, -s says take only original partitions).

My money would still have to be on a drive recognition issue. Review the Linux boot log with dmesg | more and post the bit where Linux lists the drives it's found.

Are you sure you've got the drives on the right channels? hdb is primary slave, hdd is secondary slave (you would think for A drives you'd have them jumpered as master and so they'd be hda and hdc).

Posted by: charlieg

Ok, here's the deal ... I've tried this every which way, including moving the drives around and could not get it to work with the options specified. However, I did finally get it to work by leaving out the "x" option on mfsrestore. I figure I can take care of this by using mfsadd later on (fingers crossed). In the interests of completeness, here are the details on the configuration:

Using dmesg |grep hd[ab] (I moved the former A drive to primary master and the new A drive to primary slave) I found the following:

HDA: Maxtor 4G100J5, ATA DISK drive
HDB: Maxtor 4G120J6, ATA DISK drive
HDA: 200108160 sectors (102455 MB) w/2048kiB Cache CHS=12456/255/63, UDMA (33)
HDB: 240121728 sectors (122942 MB) w/2048kiB Cache CHS=238216/16/63, UDMA (33)
HDA:Signature 1492, be16 Signarture 9214
HDB:Signature 1492, be16 Signature 9214

and then get the following result when I try to backup/restore:

>mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -xzpi - /dev/hdb
Scanning source drive. Please wait a minute.
Source drive is 39 hours
-Upgraded to 105 hours
Uncompressed backup size: 95307 megabytes
Restore failed: Backup target not large enough for entire backup by itself.

However, as I pointed out above, when I tried without the -x as an mfsrestore option, it did work:

>mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -zpi - /dev/hdb

Now, only time will tell if I end up being able to use the rest of the space on that 120 GB drive ...

Thanks for the help. Any other observations would be appreciated. I'll let you know what happens when the restore completes.

Regards,

Charlie

Posted by: Robert S

Perhaps you've run out of partitions for the expansion? As I understand it -x has the same effect as mfsadd, so mfsadd will fail too. You should be able to use to add the old drive as a B drive and you're only losing 20Gb.

Posted by: charlieg

I sort of figured that might be the case (lose 20 GB) ... I'm not real thrilled about it but I guess it beats losing my recordings. What does surprise me is that I seem to be the first one to run into this. I would have thought there were others who had performed multiple piped restores but I guess not.

In any event, I'll post my final results when the restore completes and I test the new setup (it's about 20% along as I type this).

Thanks again,

Charlie

Posted by: Robert S

It might be interesting to post the output of mfsinfo and the partition table of the A drive.

(To print the partition table you'd have to use pdisk, which means booting in a byteswapping mode. see the Fixes thread for a magic incantation to boot mfst2 byteswapping (it starts vmlnodma). Then the command would be something like pdisk -p /dev/hdc > /mnt/dos/tivo.txt).

Posted by: charlieg

Here's a preliminary update ... the restore worked but as was speculated, it's 20 GB shy of the entire disk (basically a direct copy of the original 100 GB drive). I ran mfsadd on it and it failed, stating that there were no more partitions that could be added (you were right Robert). Interestingly, when I booted in byteswap mode, mfsinfo said something about being able to upgrade this drive 3 more times. I'll post all of the results (mfsinfo and pdisk) as soon as I get the PC back together and reconnected to the network (may not be until Monday though).

In the mean time, I've got the new drive in the DTivo all by its lonesome (I'll mfsadd the old 100 GB drive tomorrow). I wanted to make sure that the swap expansion worked properly and that the unit was generally functional (with all my previous recordings preserved) before blowing away my former primary drive. All seems to be working properly at this point.

- Charlie

Posted by: charlieg

Here are the details that I promised yesterday. After booting up with MFS Tools 2 in byteswapping mode with my new DTivo A drive connected as primary slave (boot: vmlnodma hdb=bswap) I found the following:

>pdisk -l /dev/hdb

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 4096 @ 197075008 ( 2.0M)
3: Image Kernel 1 4096 @ 197079104 ( 2.0M)
4: Ext2 Root 1 262144 @ 197083200 (128.0M)
5: Image Bootstrap 2 4096 @ 197345344 ( 2.0M)
6: Image Kernel 2 4096 @ 197349440 ( 2.0M)
7: Ext2 Root 2 262144 @ 197353536 (128.0M)
8: Swap Linux swap 260096 @ 197615680 (127.0M)
9: Ext2 /var 262144 @ 197875776 (128.0M)
10: MFS MFS application region 1048576 @ 198137920 (512.0M)
11: MFS MFS media region 32148480 @ 164926528 ( 15.3G)
12: MFS Second MFS application region 1048576 @ 199186496 (512.0M)
13: MFS Second MFS media region 42996736 @ 121929792 ( 20.5G)
14: MFS Third MFS application region 1024 @ 200235072
15: MFS Third MFS media region 121929728 @ 64 ( 58.1G)
16: Apple_Free Extra 39885632 @ 200236096 ( 19.0G)

As you can see, there's 19GB of free space at the end of the disk (slice 16).

>mfsinfo /dev/hdb

MFS volume set for /dev/hdb
The MFS volume set contains 6 partitions
/dev/hdb10
MFS Partition Size: 512MiB
/dev/hdb11
MFS Partition Size: 15697MiB
/dev/hdb12
MFS Partition Size: 512MiB
/dev/hdb13
MFS Partition Size: 20994MiB
/dev/hdb14
MFS Partition Size: 0MiB
/dev/hdb15
MFS Partition Size: 59536MiB
Total MFS volume size: 97252MiB
Estimated hours in a standalone TiVo: 105
This MFS volume may be expanded 3 more times

I'm not quite sure why it says that this MFS volume may be expanded 3 more times but there you have it. It's interesting to note that mfsinfo outputs on stderr as opposed to stdout so you have to modify the standard output redirection slightly in order to capture the data (i.e. mfsinfo /dev/hdb >/mnt/dos/mfsinfo.txt 2>&1).

That's it for now ... the new 120 GB drive has been running since last night without issue. I'm going to mfsadd the 100 GB drive in a short while. I'll let you know if there are any other problems.

Thanks again for the assistance.

- Charlie

Posted by: Robert S

Hopefully mfsadd won't try to expand your A drive (and thus fail again). You may have to use the manually created partition method to avoid this.

Posted by: charlieg

Robert, I just did a quick search and didn't find anyting on the manual partition method. Can you point me in the right direction (just in case I need it)?

Thanks,

Charlie

Posted by: Robert S

It's in the MFS Tools 2.0 README:

mfstool mfsadd /dev/hdc /dev/hdd4 /dev/hdd5

Posted by: charlieg

Great ... thanks a lot. I thought you might be referring to the BlessTiVo routine (which should also work). This way I don't have to download anything else.

- Charlie

Posted by: Robert S

BlessTiVo only works on UNMODIFIED A drives - it blows up horribly if you've got extra partitions on it already!

Posted by: charlieg

As expected, mfsadd -x failed with the same error reported yesterday (too many partitions). Unfortunately, so did the manual addition of partitions (after editing with pdisk in byteswap mode). In the end, I decided that this whole process was chewing up far too much of my weekend and wasn't worth the salvaging of my old recordings so I restored from backup and now have a happy DTiVo with 210 hours of recording time. I'm sure that I'll fill it back up again soon enough :-)

Thanks again for your support.

- Charlie
(guess I've got to update my sig now ...)