TiVo Community Forums Archives - HELP! Am I missing something here

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

HELP! Am I missing something here
(Click here to view the original thread with full colors/images)

Posted by: TiVoBob

Hi, been awhile since I posted, but I"m running into problems doing an upgrade of my upgrade......

I've got an upgraded Phlips model with (2) 60 gig drives. I want to put (2) 120 gigs in there....

I downloaded the floppy version of the boot disk, hooked up the existing Tivo drives as primary master/slave, hooked up the new drives as secondary master/slave

The boot disk sees the drives as the correct sizes, ran this command

mfsbackup -Tao - /dev/hda /dev/hdb | msfrestore -s 127 -xzpi - /dev/hdc /dev hdd

It went slow, but it went...after about 60% complete, the process stopped and I got a long output of data that ended with something about "not syncing" and "AIEE!, KILLING INTERRUPT HANDLER"

I jumped back on here and read a post about turning dma on, so I went back and did the following for each drive...

hdparm -d1 -c3 -m16 /dev/hda

Things went a heckuva lot faster, but I came back (at what I'd estimate wouldve been around 40%) and saw the same error message and the process stopped...

What am I missing here?

Any help would be greatly appreciated. Thanks.

Posted by: Robert S

The obvious explanation is that you've got a bad block on the disk - run PowerMax on the drives (assuming they're Maxtor/Quantum, other mfrs have similar diagnostics) to verify this. The OS can't handle the bad blocks and kills the process trying to read it.

As far as I'm aware, this is a real killer and there's no way to carry your recordings across to the new drives.

Posted by: TiVoBob

Man, that's not something I was hoping to hear, but might explain some of the stopple problems I was having. I thought I had that fixed by redownloading the guide data a coupla weeks ago.

I'll give it a go and post the results. Thanks for the quick response

Posted by: TiVoBob

Well, I just ran Powermax and both of the original drives came out as error-free. The new drives are WD 120 gigger's just out of the box, didnt test these yet, but I"m presuming they're ok.....

Any other suggestions?

Posted by: Robert S

Try doing dd from the source drive to /dev/null (of=/dev/null) and see if it completes. Perhaps the bad blocks are on the target drive?

Posted by: TiVoBob

Had a concept and figured I'd see if it'd work.....

I tried using the "new A or B drive" method from Hinsdale. I figured if I could run both drive copies seperately, then I could marry and expand the copied drives when I was done (am I correct here?)

I had my original drives on primary and my new drives on secondary

so I typed dd if=/dev/hda of=/dev/hdc and it worked, files in=files out

When I tried it for the "B" drives, I got the same error message, so I'm presuming my original "B" drive has some error that Powermax doesnt recognize. (As I said, I had some severe stoppling and pixelization problems a few weeks back, so this lends some credence to the bad drive theory).

So, assuming my "B" drive is toast, is it possible to "divorce" my new "A" drive from the "B" drive it thinks it has and then marry my new "B" drive?
That way I'd still have some of my recordings?

Posted by: Robert S

Some people have managed to save a few recordings that way, but only recordings that are entirely on the A drive. If you've been running as a twin for a while, all your recordings are scattered across both drives.

Posted by: TiVoBob

Whoopsie, I knew it was too good to be true.

But you're telling me I can type "dd if=/dev/hda of=/dev/null" and that will just try to read all the info off of the original drive and wont write it anywhere?

Guess that's the only way to test this theary of a bad original B drive.

Thanks for all the help Robert, I do appreciate it.

Posted by: Robert S

Yes, /dev/null is a special device that just consumes any data sent to it and returns 'End of File' if you read from it. It's there as a 'bit bucket' to send data that you can't avoid producing but want to get rid of.

The idea is that if dd is crashing on a bad block it'll crash using that command, but if the problem is something else that command will complete.