# Upgrading How to copy existing programmes over?



## merlin (Jul 22, 2002)

I've upgraded my Tivo to a 400Gb Disk and everything is working fine... but I cannot fiind any instructions on how to transfer all of my tv programmes over to the new disk using MFSTools?

Any help would be most greatful......


----------



## blindlemon (May 12, 2002)

*mfsbackup -Tao - /dev/hdX | mfsrestore -s 400 -r4 -xzpi - /dev/hdY*

where hdX is your source and hdY your target drive. Then run copykern to install the LBA48 kernel and initialise the swap


----------



## merlin (Jul 22, 2002)

Thanks.... this seems to be copying now... looking like its going to take a long time!

The command I was using before was

*restore -x -r 4 -s 300 -zpi /mnt/dos/tivo.bak /dev/hdc*

I guess the difference is that this command restores my backup which does not include TV programmes, where your command backups and restores everything...

The only question I have now is I previously restored using *-s 300*, but now I am using *-s 400* is this ok?


----------



## blindlemon (May 12, 2002)

Yes, that's fine. 

Technically you only need 200mb of swap for a 400gb drive, but allowing 400mb gives you the option of adding a 2nd 400gb drive at a later stage without re-imaging or messing about.


----------



## spike2k5 (Feb 21, 2006)

blindlemon said:


> *mfsbackup -Tao - /dev/hdX | mfsrestore -s 400 -r4 -xzpi - /dev/hdY*
> 
> 
> > BTW, -r 4 bug is fixed in the latest MFSLive Boot CD.
> ...


----------



## merlin (Jul 22, 2002)

Ok, I now have a 400Gb Tivo and it all seems to be working etc. thanks blindlemon.

spike2k5, I'm not sure what the *-r* option does except that the instructions told me to do it for drives greater than 274Gb. The *-r 4* option I used seems to have worked.... what is the difference bewteen *-r 4* and *-r 2* ?

Should I be concerned that I used *-r 4* instead of *-r 2* ?

Thanks


----------



## blindlemon (May 12, 2002)

-r4 gives a larger blocksize than -r2 and is used as a workaround for the 274gb bug in MFSTools 2.0 whereby you couldn't have a partition > 274gb. 

Some people also believe that using a bigger blocksize makes your TiVo faster, although I've never noticed any difference either way. 

There's certainly no need to re-do the upgrade with -r2 and the MFSLive CSD if it has worked OK with -r4 and the MFSTools LBA48 CD. 

I assume you ran copykern?


----------



## merlin (Jul 22, 2002)

Yes, I did run the copykern...

But how do I known that the whole 400Gb Drive is being used?

Recording Times Shown:

92 Hrs, 11 Mis (Best) - Mode 0 has been enabled!
413 Hrs, 43 Mins (Basic)

Does the number of hours seem right for a 400Gb Drive?


----------



## AMc (Mar 22, 2002)

Looks right to me, a 40GB Tivo was sold as having 40hours basic recording so a bit over 400 hours on 400GB looks right!
IIRC If you've enabled Mode 0 and the Variable Bit Rate option then you will probably get over 92 hours of Best as this value is calculated from the Maximum bit rate not the average (which obviously varies  )


----------



## blindlemon (May 12, 2002)

merlin said:


> Yes, I did run the copykern...
> 
> But how do I known that the whole 400Gb Drive is being used?


Copykern doesn't affect whether the whole drive is used or not - that depends on doing the upgrade using a LBA48-aware boot CD. COpykern just copies the LBA48 kernel so that _when_ the TiVo OS tries to use part of the drive past 137gb it will actually do so 

If you were only using 137gb then your hours would be around 35 for Best and 150 for Basic.


----------



## merlin (Jul 22, 2002)

Wow, it looks like I may have completed a successful upgrade...

Thanks for everybody's help...


----------



## robmcmahon (Apr 19, 2004)

Hi Guys,

I have added this here rather than start a new thread as I think it is related and hopefully will aid others when searching in the future.

I too am in the process of an upgrade although mine is forced to the failure of my HDD. I have a .bak that I have successfully restored to the new drive.

Is there anyway that I can get my Season Pass info or recoded shows off the old drive?

It currently fails at 56.06% of the mfsbackup leading me to believe that there is a surface issue around that block. My basic understanding is that the recordings are kept in a different partition and the season pass info in /var (not so sure on that)

Is there a process I can follow to try and rescue any of the data?

Can I use the cachecard bootcd to mount the partitions?

Thanks,


----------



## blindlemon (May 12, 2002)

Try doing the backup->restore with the MFSLive CD from www.mfslive.org

That has more robust error handling than MFSTools 2.0 and I have seen it complete successfully despite many surface errors where MFSTools 2.0 could not.

You will need to run copykern from the LBA48 CD afterwards though as MFSLive (although it is LBA48 aware asnd does correctly initialise swapfiles > 127mb) doesn't install the LBA48 kernel.


----------



## robmcmahon (Apr 19, 2004)

Thanks I will try it an let you know how it goes.


----------



## ericd121 (Dec 12, 2002)

blindlemon said:


> *mfsbackup -Tao - /dev/hdX | mfsrestore -s 400 -r4 -xzpi - /dev/hdY*
> 
> where hdX is your source and hdY your target drive. Then run copykern to install the LBA48 kernel and initialise the swap


blindlemon, or anyone.

I'm interested to know why the swap space and the kernel commands are needed. Wouldn't these have been done in the original upgrade?


----------



## blindlemon (May 12, 2002)

For the kernel, that depends whether the original upgrade was to a drive > 137gb or not. The swap initilisation is always required for swaps > 127mb when using MFSTools 2.0. 

MFSLive initiailises the swap OK but doesn't install the LBA48 kernel.


----------



## mikerr (Jun 2, 2005)

A backup doesn't backup the swap, you specifiy the amount you want at restore stage.

If you leave the swap option out (-s 400) then it uses a default value of 64Mb swap,
which is quite small and may stop a tivo being able to recover from a GSOD on a larger drive.

As well as copying the lba48 kernel (which is actually contained in the backup if it was done before), 
the copykern command also initialises the swapfile - mfstools doesn't initialise swap files of over 127Mb properly.

At any rate, running copykern can do no harm.


----------



## ericd121 (Dec 12, 2002)

Thanks for those informative replies. :up:

Having bought a 160GB HDD, and restored my backup image onto it, I'm now copying some programmes over to the new disk using this version of blindlemon's command

*mfsbackup -Tao - /dev/hda | mfsrestore -s 160 -r2 -xzpi - /dev/hdd*

Source disk is on Primary Master plug, 
target disk is on Secondary Slave plug.

It's taking an age, but then I suppose it would.

*[Edit]* It's finished,but with the following message:-
*
Restore done!
Not enough extra space to expand on A drive.*

Any ideas?


----------



## blindlemon (May 12, 2002)

Use the beta version of the MFSLive CD. 

That has the -F option which will force the expansion of the final MFS partition to fill the drive. 

You will need to re-run the backup->restore though....


----------



## ericd121 (Dec 12, 2002)

> You will need to re-run the backup->restore though....


Aaarrgh! That is definitely the -F option! 

<Calms down>

Thanks, blindlemon.

I think I'll redo the restore without copying the progs tonight, and have another go at copying the progs tomorrow.


----------



## blindlemon (May 12, 2002)

Out of interest, what was the size of your original drive and how many partitions were used? 

(run mfsinfo against it to find out)


----------



## ericd121 (Dec 12, 2002)

Ooh! Thought I'd replied to this last night!

I'd already unplugged everything before you posted, BL, but FYI both drives were 160GB Samsungs, and I seem to remember a message at the end of a process along the lines of
*Added hdd12 and hdd13*


----------



## blindlemon (May 12, 2002)

Well, that's fine then.

The reason you're getting the error is because you have specified -x to expand the drive but as you're using the same size it can't expand. So not a problem - and you *don't* need to re-do the upgrade


----------



## madean59 (Dec 30, 2007)

Issue: 2 years ago I added a 2nd hard drive (80GB) to the 40GB that came with my Tivo Series 2. This gave me 120 total drive space. I now have a 250GB Seagate Barracuda and I would like to use it to replace both hard drives. I have the latest MFS Tools 2.0 but when I run the command 
mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdc
I get "Backup Target not large enough for the entire backup itself"
My setup
IDE Primary Master=40gb
IDE Slave=80gb
IDE Secondary Master=250GB
I also tried 
mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -r4 -s 127 -xzpi - /dev/hdc

Newbie: I not to familiar with linux so go easy on me. I checked the report and MSF does see the 250GB not 137GB since I am using the newest CD Boot disk. Any suggestions?


----------



## ericd121 (Dec 12, 2002)

I'm trying to restore a backup image to a Samsung 160MB HDD using this command
*restore -x -s 200 -zpi /mnt/dos/tivo.bak /dev/hdd*

However, after a couple of hours, all the feedback I've had is 
*Starting restore
Uncompressed backup size: 1031 megabytes
*
so I suspect nothing is being written.

I'm fairly certain the HDD hasn't been booted into Windows XP or Vista;
are there any tests I can run on the Samsung to see if it's Tivo-ready?

*[Edit]* I downloaded Hutil from Samsung, which is impossible to find via their new navigation system. Here is the current direct link:-
*http://www.samsung.com/global/business/hdd/support/utilities/Support_HUTIL.html*
Surface scanning as I write.


----------



## ericd121 (Dec 12, 2002)

My Samsung HDD passed all its Hutil tests, but still wouldn't accept a restore. In a fit of peek, I went back into Hutil and deleted the MBR; I suspect this was not wise. 

Can anyone help in telling me how I can format this disk in readiness to accept the Tivo image?


----------

