Major TiVo restore problems..!

[Adlopa]

A failing B drive in my TiVo is causing me all manner of headaches. I can't copy the drive using dd due to its bad sectors and performing a near-complete copy with dd_rescue results in a GSOD loop when I start the TiVo (do I need to MFSADD it to the old A drive again?).

So, what are my options? I have backed-up both drives (or presumably, just the settings) using mfsrestore -l 32 -6so and I have no problem with losing any recordings -- I just want to keep my settings.

The original drives are 2 x 120GB and I have spare 160GB drives that I can use.

Do I perform a 2 x 120Gb to 2 x 160GB upgrade using the Weaknees CD? I have no problem up just using 2 x 137Gb or even 2 x 120Gb and losing the rest of the space, but I'm not sure if previous upgrades now limit my options.

Help!

[blindlemon]

Most of the problems and limitations only kick in if you want to keep your recordings.

As long as the original drives will boot to the main menu and you can get a minimal divorced backup with -l32 -so then you can restore that to any combination of drives and it should be OK.

Use the LBA48 Boot CD (www.tivoheaven.com/download/ptv-mfstools2-large-disk.iso) for the restore, specify a swapsize in mb of half your total capacity in gb and run copykern afterwards to copy the LBA48 kernel and initialise the swap.

If the backup won't divorce and you have bash access then run the DeleteAll script to clear out the MFS before doing the backup.

[Adlopa]

Update. Nope -- GSOD loop.

I have two backups made with the Weaknees CD from 2 x 120GB drives, one each made with the commands:

1. mfsbackup -6so /mnt/dos/tivo.bak /dev/hdc /dev/hdd (per Hinsdale)
2. mfsbackup -f 9999 -1so /mnt/backup.bak /dev/hdc /dev/hdd (per tivo.upgrade-instructions.com)

For the restore to the 2 x 160GB drives, I appear have a choice of two commands:

1. mfsrestore -s 127 -zpi /mnt/dos/tivo.bak /dev/hdc /dev/hdd (Hinsdale)
2. mfsrestore -s 127 -r 4 -zxpi /mnt/backup.bak /dev/hdc /dev/hdd (tivo.upgrade)

Can these be mixed and matched, or should I stick with the pair (which pair??) from the appropriate instructions. Or should I be using something else for backup and restore?

[Rob Nespor Bellis]

For the backup command I would use:

mfsbackup -l 32 -so /mnt/dos/tivo.bak /dev/hdc /dev/hdd

the -l 32 will save various of the moving backgrounds which came with 2.5.5 and is required.

For the restore command I would use:

mfsrestore -zxpi /mnt/dos/tivo.bak /dev/hdc /dev/hdd

Rgds,

R.

[Adlopa]

Thanks Rob, but no joy -- it still goes into a GSOD loop...

Those commands gives the following on mfsbackup:
"mfs_load_zone_map: Primary zone map corrup, loading backup"

mfsrestore gives the following:
"Cleaning up restore :-
mfs_zone_load_map: Primary zone map corrupt, loading backup
mfs_zone_load_map: Primary zone map corrupt, loading backup
mfs_zone_load_map: Secondary zone map corrupt, giving up.
mfs_zone_load_map: Zone map checksum error!"

I should stress that I'm using the large-disk-aware Weaknees CD, which detects the 160GB disks correctly. Does this make a difference? Is the LBA48 CD a better choice?

[blindlemon]

I've not tried the CD you mention but I know the LBA48 CD to be good as that's what I use all the time :)

Rob omitted the swapsize parameter from his command - for 320gb I would suggest

mfsrestore -s 300 -r4 -xzpi /mnt/dos/tivo bak /dev/hdc /dev/hdd

(You could get away with -s 160, but 300 will give you the option to upgrade the B drive to 400gb in future without changing the swapsize.) Then run copykern choosing hdc and kernel option 1.

[Adlopa]

Thanks, but the original B drive looks to be fried -- I can't successfully backup, then restore the pair. So, it looks like I've lost all the recordings at the very least -- that's no big deal, though.

I have successfully restored an old backup using the MFStools LBA48 CD (and updated the kernel, though I need to check the recording time for 2 x 160Gb -- it looks a little low), but that's a backup from 2003, and so isn't that up-to-date.

As a last ditch attempt tomorrow, I may try a two-disk to two-disk copy using:

mfsbackup -Tao - /dev/hda /dev/hdb | restore -s 300 -xzpi - /dev/hdc /dev/hdd

then cross my fingers and hope that that it works, else I'm stuck with the old backup and a factory reset...

[Adlopa]

Bah - scrap that. Old backup it is. Thanks for the input, you two!

[Adlopa]

All up and running now, albeit in a virgin state thanks to the ancient backup. Typically, when I tried a final mfsbackup on the original drives just before I RMA the faulty one, it worked perfectly this time! So I could technically restore my settings, at least. Not that I can be bothered by this stage... Thanks for the input everyone.