Upgrading How to copy existing programmes over?

[merlin]

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]

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]

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]

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]

[QUOTE=blindlemon]mfsbackup -Tao - /dev/hdX | mfsrestore -s 400 -r4 -xzpi - /dev/hdY
[QUOTE]

BTW, -r 4 bug is fixed in the latest MFSLive Boot CD.

You no longer have to use -r 4 value for any partition greater than 274GB and it might be better to use the default value (-r 2) for Series 1.

[merlin]

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]

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

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]

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]

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]

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

Thanks for everybody's help...

[robmcmahon]

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]

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]

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

[ericd121]

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]

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]

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]

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]

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]

You will need to re-run the backup->restore though....Aaarrgh! That is definitely the -F option! :p

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

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]

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]

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]

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]

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]

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?