TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Main TiVo Forums > TiVo Series3 HDTV DVRs
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 12-12-2013, 01:37 PM   #1
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Arrow HD GSOD loop - trying to recover

Hi all,

Sorry for starting a new thread for this, but my searches point me to several different threads here.

I've been lurking for a while and researching drive options, but now I'm forced to take some action.

My Tivo HD began acting odd recently when the weather changed. It would "stall" randomly and sometimes selections would "double click" when I knew I had only pressed select once. I had similar issues about a year ago, and running a kickstart 57 seemed to help. So, again without taking precautions, I ran it again. This seemed to have put it in a loop where it "powers up" then is a "few more minutes" then the Green Screen of Death before it reboots and does it all over again.

Initially, I figured it was repairing and just had to reboot to commit the changes or something so I let it loop overnight. The next morning it was still looping.

After seeing the loop was seemingly infinite, I decided to pull the drive and run dd_rescue from the MFSlive CD. Despite having some minor AIX experience, I wasn't able to get the live CD to boot. It would halt right about the time the USB keyboard was detected. Then I saw it doesn't work on AMD procs, so I tried it on an Intel box with the same results.

Now I'm looking at using GNU ddrescue from an Ubuntu live CD in hopes I can clone the flaky drive to a known good new in box WD Blue Caviar.

In summary, I still don't have a grasp on the following:
  1. Has anyone _ever_ recovered from the looping GSOD? I can't find any posts if they did.
  2. How do I use the dd_rescue on the MFSLive CD? Is it my PC hardware that is halting it? Would Ubuntu know how to rescue the drive?

There's two videos on the drive I wanted to salvage if possible and I know it's encrypted. I have checked the capacitors and they look good on the boards. I'm somewhat embarrassed asking for help since I have had Unix experience and I have a background in communications electronics.

Danke,
Jay
oldsyd is offline   Reply With Quote
Old 12-12-2013, 03:18 PM   #2
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by oldsyd View Post
Hi all,

Sorry for starting a new thread for this, but my searches point me to several different threads here.

I've been lurking for a while and researching drive options, but now I'm forced to take some action.

My Tivo HD began acting odd recently when the weather changed. It would "stall" randomly and sometimes selections would "double click" when I knew I had only pressed select once. I had similar issues about a year ago, and running a kickstart 57 seemed to help. So, again without taking precautions, I ran it again. This seemed to have put it in a loop where it "powers up" then is a "few more minutes" then the Green Screen of Death before it reboots and does it all over again.

Initially, I figured it was repairing and just had to reboot to commit the changes or something so I let it loop overnight. The next morning it was still looping.

After seeing the loop was seemingly infinite, I decided to pull the drive and run dd_rescue from the MFSlive CD. Despite having some minor AIX experience, I wasn't able to get the live CD to boot. It would halt right about the time the USB keyboard was detected. Then I saw it doesn't work on AMD procs, so I tried it on an Intel box with the same results.

Now I'm looking at using GNU ddrescue from an Ubuntu live CD in hopes I can clone the flaky drive to a known good new in box WD Blue Caviar.

In summary, I still don't have a grasp on the following:
  1. Has anyone _ever_ recovered from the looping GSOD? I can't find any posts if they did.
  2. How do I use the dd_rescue on the MFSLive CD? Is it my PC hardware that is halting it? Would Ubuntu know how to rescue the drive?

There's two videos on the drive I wanted to salvage if possible and I know it's encrypted. I have checked the capacitors and they look good on the boards. I'm somewhat embarrassed asking for help since I have had Unix experience and I have a background in communications electronics.

Danke,
Jay
Does your background include any experience using a voltmeter?

If I tell you to backprobe the plug to the motherboard socket, do you know what I'm talking about?

You may need to download the MFS Live cd v1.4 .iso again and burn it as an image again--it shouldn't be failing on both boards, unless both boards were already failing themselves, so maybe you got a corrupted download.

And I think it's only on some older AMD CPUs that it has problems, I've run it on Socket A and Socket AM2 boards with no more problems than on boards made for Intel CPUs.

What brand and model is the TiVo's hard drive?

While you're at it, download the free .iso of the Ultimate Boot cd, it may come in handy.

Have you run WD's long test on that Blue yet?

Just because it's new doesn't guarantee nothing bad happened during shipping.

Always test a drive fully before putting it into service.

Are you running XP SP3 or later on either of those PCs?

Do you have a copy of WinMFS?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-12-2013, 04:26 PM   #3
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Unitron,

Thanks for the reply. Yes, I have a multimeter. Do you want me to check for voltage on the SATA socket or to test for continuity in the SATA cable?

Good idea on the corrupt ISO. I will try that again and verify MD5.

I think it's an AMD K6, but that reminds me that it's a 2 core that I unlocked to 3 cores. I'll disable the core unlocker.

The drive in question is a Western Digital WD1600AVBS-63SVA0. I will run a long test on the blue before I proceed.

I use UBCD for new drives now after seeing my share of DOA drives.

I'm running Windows 7 64-bit, but I still have my XP install disks if needed. I can install WinMFS, but I was afraid to boot into Windows with the drive in question attached for fear it might become "Windowized".

-Jay
oldsyd is offline   Reply With Quote
Old 12-12-2013, 05:06 PM   #4
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by oldsyd View Post
Unitron,

Thanks for the reply. Yes, I have a multimeter. Do you want me to check for voltage on the SATA socket or to test for continuity in the SATA cable?

Good idea on the corrupt ISO. I will try that again and verify MD5.

I think it's an AMD K6, but that reminds me that it's a 2 core that I unlocked to 3 cores. I'll disable the core unlocker.

The drive in question is a Western Digital WD1600AVBS-63SVA0. I will run a long test on the blue before I proceed.

I use UBCD for new drives now after seeing my share of DOA drives.

I'm running Windows 7 64-bit, but I still have my XP install disks if needed. I can install WinMFS, but I was afraid to boot into Windows with the drive in question attached for fear it might become "Windowized".

-Jay
I specified SP3 because by then Windows had quit grabbing every drive it sees and slapping an MBR on it uninvited. Not sure if the change happened after SP2 or before.

What I had in mind with the meter is hooking the negative lead to the chassis somewhere on the other side away from the power supply and then sticking the positive lead down into the holes in the plug that looks kinda like an ATX power supply plug where the power plugs into the TiVo motherboard.

You want the yellow wire to be 12V, the red to be 5, and the orange to be 3.3.

If it's off by very much on any of those, that could mean power supply troubles.

That K6 may be old enough to be the AMD that MFS Live has a problem with.

The UBCD has the WD software, go ahead and test the 160.

Do you have any spare drives laying around that are at least 160 (and SATA)?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-12-2013, 05:34 PM   #5
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Ok, I'll check some volt readings at probe points tonight.

I was wrong about the CPU, it's an AMD Phenom II, it's maybe about 3 years old.

I held off on running the WD tests because, again, I was worried it would change or try to repair some bad sectors.

I have the NIB WD2500AAJS and also an older used (but tested good) WD1600JS.

Jay
oldsyd is offline   Reply With Quote
Old 12-12-2013, 09:58 PM   #6
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Here's the voltage readings with the power supply under load (mobo and the non-TiVo WD1600)

Yellow +12.03VDC
Red +4.93VDC
Orange +3.33VDC
Black 0

I ran a full test on the drive and it found no errors.



And, I was able to get the MFSlive CD to boot after turning off AUTO SATA and turning off the core unlocker.

That's when I saw the dreaded "volume header corrupt" message. Some extensive searching isn't giving me any confidence on how to repair or replace the volume header. It looks like maybe dd_rescue might be the only last thing to try?



Does the MFSlive CD have dd_rescue on it? Can I use GNU dd_rescue?

More importantly, has anyone ever recovered from a corrupt volume header? If nobody else has, I'm betting I won't.
oldsyd is offline   Reply With Quote
Old 12-13-2013, 02:56 AM   #7
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by oldsyd View Post
Here's the voltage readings with the power supply under load (mobo and the non-TiVo WD1600)

Yellow +12.03VDC
Red +4.93VDC
Orange +3.33VDC
Black 0

I ran a full test on the drive and it found no errors.



And, I was able to get the MFSlive CD to boot after turning off AUTO SATA and turning off the core unlocker.

That's when I saw the dreaded "volume header corrupt" message. Some extensive searching isn't giving me any confidence on how to repair or replace the volume header. It looks like maybe dd_rescue might be the only last thing to try?



Does the MFSlive CD have dd_rescue on it? Can I use GNU dd_rescue?

More importantly, has anyone ever recovered from a corrupt volume header? If nobody else has, I'm betting I won't.
Okay send me the NIB WD2500AAJS



and we'll use the other 160 for test purposes.


The MFS Live cd v1.4 has

dd_rescue

and the UBCD has

ddrescue

and if either give you a perfect copy of a drive with a corrupt volume header, you'll have another drive with a corrupt volume header.

Whatever a corrupt volume header is.


I'm not sure exactly what it is or if it's fixable, but I've got a bunch of drives with 'em that were in Series 1 TiVos when it happened.


My TiVo wrangling PC is apparently trying to die, so I can't provide the latest version of the 652 image with 11.0m, but these should be 11.0k and can be put on that other 160 to test the motherboard, since your power supply seems to be well within spec.

For use with the MFS Live cd v1.4:

https://dl.dropboxusercontent.com/u/...0/652_gset.bak


For use with WinMFS:

https://dl.dropboxusercontent.com/u/...0/652_gset.tbk


While you're experimenting with my image on your other, spare 160, run WinMFS and see what its version of mfsinfo has to say about the drive that has the shows you want to save, and see if it will let you make a truncated backup.

Then after you go through Guided Setup with the spare 160, we can take it back out and use

dd_rescue

or

ddrescue

to "Xerox" the original drive to the spare 160.

Then you can restore the truncated image with WinMFS to the spare 160, which may overwrite all of the partitions other than the 2 MFS pairs (10,11, 12, 13), but I'm hoping that it will only overwrite the "boundary markers" of the MFS pairs, leaving the already "Xeroxed" shows inside those partitions intact.


You will notice that at no point is the 160 with which you are having problems written to in any way.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-13-2013, 06:51 AM   #8
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
The volume header is what's usually called the MFS "superheader". It's located in the first sector of the MFS application region (partition 10) and there's a backup copy located in the last sector of that partition.

I don't know if mfslive checks for the backup copy or not. If you get a copy of DvrBARS from the Upgrade forum, see if it can make it through a Truncated backup. It checks both copies of the superheader before giving up.

DvrBARS won't fix the corrupted header but if it works we can proceed with a manual fix.

That looks like a standard TCD652160 layout. If I'm correct in that assumption and it hasn't been modified or supersized we should be able to transplant the superheader from a stock image using a hex editor like HxD. I could probably even cook one up from scratch based on the partition table if necessary.

Any version of XP, 7 or 8 is safe for TiVo drives as long as you don't run Disk Manager and answer Yes when it asks if it can initialize it. Windows 2000 was the last OS that did it automatically.
ggieseke is offline   Reply With Quote
Old 12-13-2013, 07:52 AM   #9
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by ggieseke View Post
...
Any version of XP, 7 or 8 is safe for TiVo drives as long as you don't run Disk Manager and don't answer Yes when it asks if it can initialize it. Windows 2000 was the last OS that did it automatically.
Clarified Your Post.


__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-15-2013, 10:29 AM   #10
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Quote:
Originally Posted by unitron View Post
Okay send me the NIB WD2500AAJS



and we'll use the other 160 for test purposes.


The MFS Live cd v1.4 has

dd_rescue

and the UBCD has

ddrescue

and if either give you a perfect copy of a drive with a corrupt volume header, you'll have another drive with a corrupt volume header.

Whatever a corrupt volume header is.


I'm not sure exactly what it is or if it's fixable, but I've got a bunch of drives with 'em that were in Series 1 TiVos when it happened.


My TiVo wrangling PC is apparently trying to die, so I can't provide the latest version of the 652 image with 11.0m, but these should be 11.0k and can be put on that other 160 to test the motherboard, since your power supply seems to be well within spec.

For use with the MFS Live cd v1.4:

https://dl.dropboxusercontent.com/u/...0/652_gset.bak


For use with WinMFS:

https://dl.dropboxusercontent.com/u/...0/652_gset.tbk


While you're experimenting with my image on your other, spare 160,
Thanks for those, I was able to image that spare 160 and it appears to be working fine in my unmodified TCD652160.



Quote:
Originally Posted by unitron View Post
run WinMFS and see what its version of mfsinfo has to say about the drive that has the shows you want to save, and see if it will let you make a truncated backup.


WinMFS does not recognize it.

Quote:
Originally Posted by ggieseke View Post
I don't know if mfslive checks for the backup copy or not. If you get a copy of DvrBARS from the Upgrade forum, see if it can make it through a Truncated backup. It checks both copies of the superheader before giving up.


It also appears that DvrBARS also wants nothing to do with this stinker

Quote:
Originally Posted by unitron View Post
Then after you go through Guided Setup with the spare 160, we can take it back out and use

dd_rescue

or

ddrescue

to "Xerox" the original drive to the spare 160.

Then you can restore the truncated image with WinMFS to the spare 160, which may overwrite all of the partitions other than the 2 MFS pairs (10,11, 12, 13), but I'm hoping that it will only overwrite the "boundary markers" of the MFS pairs, leaving the already "Xeroxed" shows inside those partitions intact.


You will notice that at no point is the 160 with which you are having problems written to in any way.
Okay, I have the updated working spare 160 now, and I've made truncated backups of it on both WinMFS and DvrBARS.

Should I attempt dd_rescue from the corrupt OEM drive to the spare 160? I'm thinking your theory above would apply where if it works, it will just make a byte for byte copy of the nuked volume headers.

I'm thinking the key to recovery is copying everything BESIDES the volume header or copying the whole thing and then overwriting the corrupt volume header (or superheader) with a good one.

Unfortunately, I have no idea how to do that. Reading GNU ddrescue manual has no mention of volume headers or superheaders.

http://www.gnu.org/software/ddrescue...ue_manual.html

And, it looks like GNU ddrescue is a more recent and reliable recovery tool than dd_rescue. But, do any recovery tools need to be run from MFS utilities? I'm still not sure if tools outside the MFS realm would be able to properly recover data? Does the MFS encryption come into play here?

Since the truncated backups of the failed drive did not work, I'm not sure what I should try next that isn't just me making an uneducated guess.

-Jay
oldsyd is offline   Reply With Quote
Old 12-15-2013, 02:52 PM   #11
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
dd

and


ddrescue


and


dd_rescue


don't really take notice of whether it's a TiVo drive or a Windows drive or an anything drive.

They just "Xerox" byte for byte.

If one of those bytes has a zero where it should have a one, or a one where it should have a zero, they won't know and they won't care, they only care about whether they can actually read the part of the drive they're trying to copy.

So use

ddrescue

or

dd_rescue


to "Xerox" the 160 that has the shows you want to save over to the other 160.

(I'm sure DvrBARS is a wonderful piece of software, but I have no experience with it and no way of knowing how it works or what it might do, so I can't be a part of any discussion of using it to deal with your problem.)

Then restore that .tbk truncated backup you just made to that other 160 to which you just "Xeroxed" the first one.

See if that overwrote the stuff that got scrambled without overwriting the stuff you want to save.

Again, all writing is done on the other 160, and none is done on the original.


(you really ought to make a copy of the MFS Live cd v1.4, just to have it in your arsenal, even if you aren't going to make .bak backups)
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-16-2013, 06:16 AM   #12
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
Quote:
Originally Posted by unitron View Post
(I'm sure DvrBARS is a wonderful piece of software, but I have no experience with it and no way of knowing how it works or what it might do, so I can't be a part of any discussion of using it to deal with your problem.)
Well, now we know for sure that the primary and backup superheaders are both corrupt.

I don't know the tools like pdisk etc well enough to know if you can just copy part of a partition. If you can replace the first 512-byte sector of partition 10 with the same sector from a healthy 652 with the same partition table that should fix the superheader. Replacing the last sector of partition 10 at the same time would be nice, but as long as the primary superheader is intact, KS57 should be able to fix the backup copy later.
ggieseke is offline   Reply With Quote
Old 12-16-2013, 12:03 PM   #13
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by ggieseke View Post
Well, now we know for sure that the primary and backup superheaders are both corrupt.

I don't know the tools like pdisk etc well enough to know if you can just copy part of a partition. If you can replace the first 512-byte sector of partition 10 with the same sector from a healthy 652 with the same partition table that should fix the superheader. Replacing the last sector of partition 10 at the same time would be nice, but as long as the primary superheader is intact, KS57 should be able to fix the backup copy later.
As long as you know exactly what numbers to use,

dd

and its more sophisticated relatives will copy over part of a partition.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-20-2013, 11:11 AM   #14
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Lightbulb Update

Sorry for the delayed reply, in addition to the usual holiday time gobblers I've also had another unrelated crisis pop up that I'm working on fixing. I'm blaming it on the unluckiness of the year 2013 and that stuff will stop breaking once 2014 rolls around.

I was able last night to run dd_rescue from the Ubuntu-Rescue-Remix live CD, and it completed. The drives look nearly identical in Linux, so I had to use another tool that pulled the actual drive model number so I could verify what /dev/ was what. I used this live CD because the UNIX folks seem to think GNU dd_rescue is better and more current than the entirely different ddrescue that the MFSlive CD has.

It also threw me an error complaining about the damaged superblocks, but I was able to force it.

I still need to power the newly cloned drive up in the HD, but I'm guessing it might still loop.

Jay
oldsyd is offline   Reply With Quote
Old 12-20-2013, 12:53 PM   #15
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by oldsyd View Post
Sorry for the delayed reply, in addition to the usual holiday time gobblers I've also had another unrelated crisis pop up that I'm working on fixing. I'm blaming it on the unluckiness of the year 2013 and that stuff will stop breaking once 2014 rolls around.

I was able last night to run dd_rescue from the Ubuntu-Rescue-Remix live CD, and it completed. The drives look nearly identical in Linux, so I had to use another tool that pulled the actual drive model number so I could verify what /dev/ was what. I used this live CD because the UNIX folks seem to think GNU dd_rescue is better and more current than the entirely different ddrescue that the MFSlive CD has.

It also threw me an error complaining about the damaged superblocks, but I was able to force it.

I still need to power the newly cloned drive up in the HD, but I'm guessing it might still loop.

Jay
Actually, the MFS Live cd v1.4 has

dd_rescue

and the other program is

ddrescue

or more properly

Gnu ddrescue

As for telling drives apart, when using a Linux based bootable cd,

fdisk -l

should list the drives detected as /dev/hd? for the PATA/IDE drives and /dev/sd? for the SATA drives.

Armed with that info

hdparm -i /dev/?d?

(where the first ? is an "s" if it's a SATA drive and the second ? is "a" or "b" or "c" or whatever depending on exactly which drive you want to know about)

should give you size, brand, model, and serial number.

If it doesn't give serial number, then do the same thing, but with the uppercase "I" instead, like this:

hdparm -I /dev/?d?

I"m pretty sure that SHIFT+PAGE UP and SHIFT+PAGE DOWN will let you go up and down what's on the screen since their will be too much info to fit.

If that doesn't work, substitute CTRL for SHIFT.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-20-2013, 01:19 PM   #16
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Quote:
Originally Posted by unitron View Post
Actually, the MFS Live cd v1.4 has

dd_rescue

and the other program is

ddrescue

or more properly

Gnu ddrescue
Thanks for correcting that, I flip flopped those.

Quote:
Originally Posted by unitron View Post
As for telling drives apart, when using a Linux based bootable cd,

fdisk -l

should list the drives detected as /dev/hd? for the PATA/IDE drives and /dev/sd? for the SATA drives.
I did use fdisk, and the geometry of the two 160GB drives were identical. There was no way to distinguish them. I think I used TestDisk and that showed the model numbers. Apparently I chose a good drive for cloning the TiVo drive

Quote:
Originally Posted by unitron View Post

Armed with that info

hdparm -i /dev/?d?

(where the first ? is an "s" if it's a SATA drive and the second ? is "a" or "b" or "c" or whatever depending on exactly which drive you want to know about)

should give you size, brand, model, and serial number.

If it doesn't give serial number, then do the same thing, but with the uppercase "I" instead, like this:

hdparm -I /dev/?d?

I"m pretty sure that SHIFT+PAGE UP and SHIFT+PAGE DOWN will let you go up and down what's on the screen since their will be too much info to fit.

If that doesn't work, substitute CTRL for SHIFT.
I'll bet TestDisk issues the same hdparm utility for it's results. I'll try that next time. Thanks for the additional tips.

I was thinking if the cloned disk loops, then I was looking into using mke2fs or e2fsck to recover or copy a known good superblock.

From what I've been reading, the superblock is a catalog of every file on the drive, so even if I had a good superblock from a generic image, that still would not work. It sounds like I'll need a backup of the superblock from the failed drive to restore or else find some way to rewrite the superblock based on the data that is there. And, of course I could be dead wrong.
oldsyd is offline   Reply With Quote
Old 12-20-2013, 02:39 PM   #17
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
If you had two 160GB drives hooked up as well as the drive from which the PC usually boots, then

fdisk -l

would show you which drive you want to be sure not to mess with (unless the boot drive was also a 160GB)

And it confirms that all the drives connected were detected.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-20-2013, 04:45 PM   #18
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
From the error messages you've been getting I still think we're dealing with the MFS "superblock", not the superblock in one of the Ext2 partitions. In fact, I'd bet a case of beer on it based on the DvrBARS screenshot you provided.

In MFS, the volume header is a fairly simple critter. All it does is describe the total MFS volume size, the logical devices that comprise it, like "/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13", and it contains the first MFS zone descriptor. After that the zone descriptors daisy-chain.

If nothing else was damaged, replacing those 512 bytes on the ddrescued disk with the correct header from an undamaged drive should work. That's still a big "if", but what do you have to lose by trying?
ggieseke is offline   Reply With Quote
Old 12-20-2013, 08:02 PM   #19
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by ggieseke View Post
...

If nothing else was damaged, replacing those 512 bytes on the ddrescued disk with the correct header from an undamaged drive should work. That's still a big "if", but what do you have to lose by trying?
Especially if you're smart enough to make a "Xerox" of the problem drive and do that experiment on the copy.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-20-2013, 10:32 PM   #20
oldsyd
Registered User
 
Join Date: Apr 2009
Location: Iowa
Posts: 20
Ok, I've verified that the cloned drive also does have the GSOD loop.

Here's what I'm seeing for drive info:




How would one proceed and replace the damaged 512 bytes on the cloned drive?
oldsyd is offline   Reply With Quote
Old 12-21-2013, 11:56 AM   #21
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
That latest fdisk -l doesn't look promising if it can't even find the partition table. The one you posted earlier was OK.

I need to whip up a factory drive as a donor. I tried this morning with WinMFS, but Spike actually changes the partition layout in that tool even if you don't change the swap space. I'll try again with MFSLive and see if I can get a partition table that matches your original.
ggieseke is offline   Reply With Quote
Old 12-21-2013, 12:32 PM   #22
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by ggieseke View Post
That latest fdisk -l doesn't look promising if it can't even find the partition table. The one you posted earlier was OK.

I need to whip up a factory drive as a donor. I tried this morning with WinMFS, but Spike actually changes the partition layout in that tool even if you don't change the swap space. I'll try again with MFSLive and see if I can get a partition table that matches your original.
I wouldn't expect

fdisk -l

to find the partition table on a TiVo drive.

That's a job for

pdisk -l
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-21-2013, 02:39 PM   #23
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
Quote:
Originally Posted by unitron View Post
I wouldn't expect

fdisk -l

to find the partition table on a TiVo drive.

That's a job for

pdisk -l
Just goes to show what I know about the Unix tools.

You're 100% correct as usual.
ggieseke is offline   Reply With Quote
Old 12-21-2013, 03:37 PM   #24
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by ggieseke View Post
That latest fdisk -l doesn't look promising if it can't even find the partition table. The one you posted earlier was OK.

I need to whip up a factory drive as a donor. I tried this morning with WinMFS, but Spike actually changes the partition layout in that tool even if you don't change the swap space. I'll try again with MFSLive and see if I can get a partition table that matches your original.
It looked like the standard S2 and later "optimized" layout to me, how does spike change it?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-21-2013, 05:30 PM   #25
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
This is the partition map that I got from restoring 652_gset.tbk.

Partition Maps
#: type name length base ( size )
1 Apple_partition_map Apple 63@1 ( 31.5K)
2 Image Bootstrap 1 1@309550766 ( 512.0 )
3 Image Kernel 1 8192@309550767 ( 4.0M)
4 Ext2 Root 1 524288@309558959 ( 256.0M)
5 Image Bootstrap 2 1@310083247 ( 512.0 )
6 Image Kernel 2 8192@310083248 ( 4.0M)
7 Ext2 Root 2 524288@310091440 ( 256.0M)
8 Swap Linux swap 262144@310615728 ( 128.0M)
9 Ext2 /var 524288@310877872 ( 256.0M)
10 MFS MFS application region 589824@311402160 ( 288.0M)
11 MFS MFS media region 137630712@171920054 ( 65.6G)
12 MFS MFS application region 2 589824@311991984 ( 288.0M)
13 MFS MFS media region 2 171919990@64 ( 82.0G)

The sector start numbers don't even seem close to oldsyd's original layout. "MFS application region" starts at sector 311402160 instead of sector 173771448. Maybe I'm missing something stupid.
ggieseke is offline   Reply With Quote
Old 12-21-2013, 07:14 PM   #26
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by ggieseke View Post
This is the partition map that I got from restoring 652_gset.tbk.

Partition Maps
#: type name length base ( size )
1 Apple_partition_map Apple 63@1 ( 31.5K)
2 Image Bootstrap 1 1@309550766 ( 512.0 )
3 Image Kernel 1 8192@309550767 ( 4.0M)
4 Ext2 Root 1 524288@309558959 ( 256.0M)
5 Image Bootstrap 2 1@310083247 ( 512.0 )
6 Image Kernel 2 8192@310083248 ( 4.0M)
7 Ext2 Root 2 524288@310091440 ( 256.0M)
8 Swap Linux swap 262144@310615728 ( 128.0M)
9 Ext2 /var 524288@310877872 ( 256.0M)
10 MFS MFS application region 589824@311402160 ( 288.0M)
11 MFS MFS media region 137630712@171920054 ( 65.6G)
12 MFS MFS application region 2 589824@311991984 ( 288.0M)
13 MFS MFS media region 2 171919990@64 ( 82.0G)

The sector start numbers don't even seem close to oldsyd's original layout. "MFS application region" starts at sector 311402160 instead of sector 173771448. Maybe I'm missing something stupid.

Yeah, on closer inspection he gets partition 1 and partition 13 where they're supposed to be, but seems to have taken it upon himself to monkey with the rest.

Let me pull out one of my original 652 drives and see if I can find a PC around here that'll work long enough to let me boot with MFS Live and take a look via pdisk.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-22-2013, 10:51 AM   #27
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
I have been trying all morning to get MFSLive to recreate a factory layout from your 652_gset.bak file. No matter what I try it always moves stuff around and the resulting partition table isn't even close.

It may not matter anyway, but I'd like to introduce as few variables as possible. IIRC, once you have the start sectors of the MFS partitions and the device list from the superheader everything within the rest of the MFS file system is relative and has nothing to do with the physical placement on the disk. The trouble is that it's been almost a year since I dove into the really deep end of MFS and my memory stinks.
ggieseke is offline   Reply With Quote
Old 12-22-2013, 03:53 PM   #28
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,323
Quote:
Originally Posted by ggieseke View Post
I have been trying all morning to get MFSLive to recreate a factory layout from your 652_gset.bak file. No matter what I try it always moves stuff around and the resulting partition table isn't even close.

It may not matter anyway, but I'd like to introduce as few variables as possible. IIRC, once you have the start sectors of the MFS partitions and the device list from the superheader everything within the rest of the MFS file system is relative and has nothing to do with the physical placement on the disk. The trouble is that it's been almost a year since I dove into the really deep end of MFS and my memory stinks.
Does the same thing happen with the .tbk file?

Are you including -p when you run restore in MFS Live?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 12-22-2013, 04:30 PM   #29
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
I stripped it down to just -i (no -p or -z) and even tried to convince it that my 500GB drive had exactly 312581808 sectors like oldsyd's original drive with hdparm -N.

With -p it dumped all of the Root, Boot & Kernel sectors at the end of the drive and without it, it just wrote them in order of the partition table. Nothing seemed to convince it to write them in TiVo order, which means that partition 13 starts at sector 64 and everything else except the final MFS media partition gets shoved downhill.

I know that Spike is a bloody genius, but there's too much "I know better than TiVo" in both MFSLive and WinMFS for my taste. All 4 of my S2s were built with those tools and they still work great, but in this case I just want a factory layout.

Where did I f*** up?
ggieseke is offline   Reply With Quote
Old 12-24-2013, 07:10 AM   #30
ggieseke
Registered User
 
Join Date: May 2008
Posts: 2,962
oldsyd,

I managed to come up with a healthy 652 image exactly like yours and extracted the attached MFS volume header. Once you unzip it we need to write those 512 bytes to the COPY of your original drive.

The primary volume header on your drive should be located at byte offset 88970981376 (14B7157000 in hex), and for good measure we should also fix the backup copy located at offset 89272970752 (14C9156E00 in hex).

It should only take a few minutes with a hex editor like HxD, and with any luck there won't be any additional damage in the zone headers or zones. Let me know if you need step-by-step instructions.

Greg
Attached Files
File Type: zip MfsVolumeHeader.zip (334 Bytes, 4 views)
File Type: txt mfsinfo.txt (3.3 KB, 4 views)
ggieseke is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVoŽ is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 03:26 AM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |