Replacing failed B drive

[million zillion]

My B drive has failed quite thoroughly (got GSOD that repeats for much longer than 3 hours), and I plan to replace it. I would like to preserve as much of my previous recordings as possible onto the new drive. Failing that, I would like to at least make a reduced backup (as per Hinsdale instructions) and install that to the new drive. I'd appreciate some advice on how to proceed.

The setup:
Series 1 Philips HDR31203 (with Lifetime Sub, so it's worth keeping)
A drive: Quantum 30Gb (original, passes SeaTools diagnostic)
B Drive: Samsung 80Gb (added with MFSTools in 2002, fails diagnostic now)

The B drive seems to have lost its partition table, and the first 20Gb or so contain about 100 block errors according to the Long Test in SeaTools. Also, my PC's BIOS won't auto-ID the drive at power-up. However, the TestDisk tool in Linux does recognize the manufacturer/type/geometry and a short test copy from the drive with dd seemed to work passably well. I've probably lost a big chunk of data already, but I think that if I can get the partition table back with TestDisk, then I stand a chance of retrieving some of the recordings.

My first step should be to make the reduced backup (with "mfsbackup -6so ..."). Does the reduced backup process really require the B drive, or will it work using just the (still-working) A drive?

If the B drive is necessary for the backup, then how well will MFSTools tolerate the block errors on the B drive? Would it help if I dd-copied the old B drive to the new drive first, and restore the partition table there with TestDisk, and use that as the B drive for the backup?

I suppose that if that works, then the whole system would already be nearly restored, with the old A drive and the new B drive. In that case, I could then use mfsadd to expand the new B drive and also run copykern for big drive support. But that all seems potentially destructive to the A drive, so I think I'll need a reliable backup before I commit to using the drives this way.

Incidentally, I do still have the reduced backup from the original 30Gb A drive, from before I added the 80Gb B drive. That's my second-level fallback, in case I can't even save the current state of the A drive.

So, I have a plan, but I'm not sure how well it will work in practice. I don't have the new drive yet, so if anyone has some advice I'd be glad to hear it before I jump into this. Thanks.

[rbtravis]

Better to replace two small drives with 1 large hard drive(say 320 GB) use instantcake to apply image. fast install no hassel's with 6.4a

[million zillion]

Thanks for the ad[vice], but I'm actually looking for some technical information, especially with regard to generating a new reduced backup from my current drives.

Also, I want to at least attempt to recover my recordings. I realize that this may not work, but I'm not ready to give up on them yet. Unless I've misunderstood the documentation, InstantCake will only generate a completely new image without preserving recordings.

[robomeister]

Unfortunately, this is the danger of running with two drives inside the TiVo. One HDD fails, it takes the other HDD with it.

The Hinsdale guide is a good start, but I would recommend looking at www.mfslive.org. This site has the most up to date tools for updates of TiVos.

Some other options would be to get the diagnostics tools for your hard drives and attempt to fix the drives. Or you could get Spinrite from www.grc.com. That might recover the information on the HDD enough so you can copy the contents to another drive.

You could try the Kickstarts (57, 54, 58) too, but that might make the problem worse.

The "reduced" or "truncated" backup will require both drives to be attached. They are "married" and must be together when doing backups.

I would recommend looking for the dd_rescue tool. This tool is tolerant of errors it encounters. dd_copy is not.

Your plan might work, but I'm not sure about the mfsadd after the dd_rescue.

Good luck,
robomeister

[kirkh]

I actually found myself in this same situation recently. I just came home from a weekend away to find the GSoD cycling over and over again.

I have a similar setup to yours - I have a Philips HDR612 with dual drives. I upgraded one of the drives about six years ago now - replacing the 30GB B drive with a 150GB drive.

I haven't popped it open yet to see which of the drives has failed as of yet. It had been acting strange the past few months - freezing a second at a time off and on during live TV and old recordings.

So, I would really appreciate hearing how your process goes, since I'm probably in the exact same situation. I hope to open up the TiVo and start diagnosing the drives in the next day or two.

Looking forward to your updates!

Kirk

[million zillion]

In fact, I was seeing symptoms similar to those that kirkh reported in the months prior to this crash, and worse, including frequent freeze-ups and resets. I wish that I had recognized those as drive failures at the time - I might have been in better shape to recover my data if I had started this earlier.

In the face of such popular demand, here's a status update. I haven't had as much time to work on this as I'd hoped to, so I'm not as far along as I would like to be.

I bought a new Seagate Barracuda 160Gb drive (not the best price/capacity deal, but still cheap and convenient at a local discount PC store). I used dd_rescue to copy the data from the old B drive to the new one. The results were promising - I seem to have lost about 2.5Mb out of 80Gb to bad blocks.

I took a closer look at the new B drive and found that the partition table is actually intact. I wasn't able to see it before since I was using the wrong tool (fdisk instead of pdisk) and no byte-swapping. I'm a little rusty at this, after all.

Then I set about making a truncated backup with the MFSLive CD (thanks for the tip, robomeister). That also seemed to work, but I haven't verified it yet because I don't have another available drive of appropriate size to restore it to (unless I overwrite the new 160Gb, and I don't want to do that just yet).

Then, without making further modifications to the drives, I installed the old A drive and new B drive into the TiVo, just to see if that got me anywhere. Unfortunately, the TiVo now only reaches the first "TiVo lost its marbles" boot screen and no further, not even to the gray "just a few more minutes" screen. And that's as far as I've gotten.

Since the new drive is a copy of the old B drive with the same partitions (which come in at less than 137Gb), I figured that I would have at least gotten back to the GSOD this way. I'll try a few obvious steps next, like re-checking the drive connectors. If that doesn't do it, I'll try mfsadd or something similar, but I'm not sure how else to proceed without losing the recordings.

I'll only go so far with these effort-intensive measures. After that, I'll try restoring the new truncated backup straight to the new drive as a single-drive system. Assuming that the backup is good, that seems much more likely to work.

[million zillion]

I seem to have hit a wall in my plan to preserve recordings. I still can't boot past the marbles screen with the dd_rescued drive (with no other modifications), and it looks like any attempt to expand the drive with mfstools will result in a swap space problem.

My original A drive has a 64Mb swap partition, and the old B drive has no swap. According to the MFSLive FAQ, my old 30Gb+80Gb configuration needed about 1/2 * 110 = 55Mb swap to recover from GSODs (really bad drive failures notwithstanding), so this was ok. But any straight expansion now will take me to at least 30Gb+137Gb (more if I use LBA48 and copykern), which requires at least 84Mb of swap.

I've looked through all the documentation I could find, but I haven't seen a reasonably simple method of expanding a drive in a way that both preserves recordings and increases the swap space. (The Hinsdale HOWTO says as much outright.) I think I saw something in the forum archives about modifying the partition table manually with pdisk, but that seems to be much trickier than anything else I've considered yet.

I'm thinking about adding a small swap partition first (64Mb? 127Mb?), and then running mfsadd to fill the remaining space. copykern on the LBA48 CD is supposed to be able to activate swap, but I haven't found any clear documentation for that yet.

FWIW, here are my current partition tables for both drives.

A drive:
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 @ 64 ( 2.0M)
3: Image Kernel 1 4096 @ 4160 ( 2.0M)
4: Ext2 Root 1 262144 @ 8256 (128.0M)
5: Image Bootstrap 2 4096 @ 270400 ( 2.0M)
6: Image Kernel 2 4096 @ 274496 ( 2.0M)
7: Ext2 Root 2 262144 @ 278592 (128.0M)
8: Swap Linux swap 131072 @ 540736 ( 64.0M)
9: Ext2 /var 262144 @ 671808 (128.0M)
10: MFS MFS application a10 1048576 @ 933952 (512.0M)
11: MFS MFS media a11 56650752 @ 1982528 ( 27.0G)
12: Apple_Free Extra 64 @ 58633280

Device block size=512, Number of Blocks=58633344 (28.0G)
DeviceType=0x0, DeviceId=0x0

B drive:
Partition map (with 512 byte blocks) on '/dev/hdd'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS Second MFS application region 8192 @ 64 ( 4.0M)
3: MFS Second MFS media region 156359760 @ 8256 ( 74.6G)

Device block size=512, Number of Blocks=312581808 (149.1G)
DeviceType=0x0, DeviceId=0x0