1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

HD GSOD loop - trying to recover

Discussion in 'TiVo Series3 HDTV DVRs' started by oldsyd, Dec 12, 2013.

  1. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    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
     
  2. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    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?
     
  3. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    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
     
  4. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    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)?
     
  5. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    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
     
  6. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    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.

    [​IMG]

    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? :confused:

    [​IMG]

    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. :(
     
  7. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    Okay send me the NIB WD2500AAJS

    :D

    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/49887720/652_gset.bak


    For use with WinMFS:

    https://dl.dropboxusercontent.com/u/49887720/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.
     
  8. ggieseke

    ggieseke Active Member

    4,031
    12
    May 30, 2008
    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.
     
  9. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    Clarified Your Post.

    ;)
     
  10. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    Thanks for those, I was able to image that spare 160 and it appears to be working fine in my unmodified TCD652160.

    [​IMG]

    [​IMG]

    WinMFS does not recognize it.

    [​IMG]

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

    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/manual/ddrescue_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
     
  11. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    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)
     
  12. ggieseke

    ggieseke Active Member

    4,031
    12
    May 30, 2008
    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.
     
  13. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    As long as you know exactly what numbers to use,

    dd

    and its more sophisticated relatives will copy over part of a partition.
     
  14. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    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. :rolleyes:

    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
     
  15. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    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.
     
  16. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    Thanks for correcting that, I flip flopped those.

    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 ;)

    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.
     
  17. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    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.
     
  18. ggieseke

    ggieseke Active Member

    4,031
    12
    May 30, 2008
    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?
     
  19. unitron

    unitron Active Member

    16,390
    2
    Apr 28, 2006
    semi-coastal NC
    Especially if you're smart enough to make a "Xerox" of the problem drive and do that experiment on the copy.
     
  20. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    Ok, I've verified that the cloned drive also does have the GSOD loop.

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

    [​IMG]
    [​IMG]

    How would one proceed and replace the damaged 512 bytes on the cloned drive?
     

Share This Page