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. ggieseke

    ggieseke Active Member

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

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC
    I wouldn't expect

    fdisk -l

    to find the partition table on a TiVo drive.

    That's a job for

    pdisk -l
     
  3. ggieseke

    ggieseke Active Member

    4,031
    12
    May 30, 2008
    Just goes to show what I know about the Unix tools. :eek:

    You're 100% correct as usual.
     
  4. unitron

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC
    It looked like the standard S2 and later "optimized" layout to me, how does spike change it?
     
  5. ggieseke

    ggieseke Active Member

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

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC

    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.
     
  7. ggieseke

    ggieseke Active Member

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

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC
    Does the same thing happen with the .tbk file?

    Are you including -p when you run restore in MFS Live?
     
  9. ggieseke

    ggieseke Active Member

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

    ggieseke Active Member

    4,031
    12
    May 30, 2008
    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:

  11. unitron

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC
    For what it's worth, here's how WinMFS's mfsinfo sees the original 160GB drive from a 652:

    _________________________________________________
    Mfsinfo (Drive 7)

    Boot Page
    Boot Page: root=/dev/hda4
    Active Boot Partition: 3 Active Root Partition: 4
    Backup Boot Partition: 6 Backup Root Partition: 7

    MFS Super Header
    state=0 magic=ebbafeed
    devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13
    zonemap_ptr=1121 total_secs=310728704

    Zone Maps
    Z0: type=0
    map_start=1121 map_size=1 backup_map_start=589822
    next_map_start=263266 next_map_size=6 next_backup_map_start=589816
    zone_first=1122 zone_last=263265 zone_size=262144 min(chunk)=262144
    free=262144 checksum=85e1adbd logstamp=8742226 num_bitmap=1
    Z1: type=2
    map_start=263266 map_size=6 backup_map_start=589816
    next_map_start=263272 next_map_size=34 next_backup_map_start=589782
    zone_first=589824 zone_last=138215423 zone_size=137625600 min(chunk)=20480
    free=136642560 checksum=e6cdcfd0 logstamp=8742253 num_bitmap=14
    Z2: type=1
    map_start=263272 map_size=34 backup_map_start=589782
    next_map_start=138219520 next_map_size=1 next_backup_map_start=138809343
    zone_first=263306 zone_last=589777 zone_size=326472 min(chunk)=8
    free=253672 checksum=8b005ca4 logstamp=8742253 num_bitmap=17
    Z3: type=0
    map_start=138219520 map_size=1 backup_map_start=138809343
    next_map_start=138481665 next_map_size=10 next_backup_map_start=138809333
    zone_first=138219521 zone_last=138481664 zone_size=262144 min(chunk)=262144
    free=262144 checksum=a1a4437d logstamp=8742226 num_bitmap=1
    Z4: type=2
    map_start=138481665 map_size=10 backup_map_start=138809333
    next_map_start=138481675 next_map_size=34 next_backup_map_start=138809299
    zone_first=138809344 zone_last=310718463 zone_size=171909120 min(chunk)=20480
    free=167772160 checksum=22ca713f logstamp=8742253 num_bitmap=15
    Z5: type=1
    map_start=138481675 map_size=34 backup_map_start=138809299
    next_map_start=0 next_map_size=0 next_backup_map_start=-6148914691236517206
    zone_first=138481709 zone_last=138809292 zone_size=327584 min(chunk)=8
    free=320560 checksum=8fea37b logstamp=8742226 num_bitmap=17

    Partition Maps
    #: type name length base ( size )
    1 Apple_partition_map Apple 63@1 ( 31.5K)
    2 Image Bootstrap 1 1@171920054 ( 512.0 )
    3 Image Kernel 1 8192@171920055 ( 4.0M)
    4 Ext2 Root 1 524288@171928247 ( 256.0M)
    5 Image Bootstrap 2 1@172452535 ( 512.0 )
    6 Image Kernel 2 8192@172452536 ( 4.0M)
    7 Ext2 Root 2 524288@172460728 ( 256.0M)
    8 Swap Linux swap 262144@172985016 ( 128.0M)
    9 Ext2 /var 524288@173247160 ( 256.0M)
    10 MFS MFS application region 589824@173771448 ( 288.0M)
    11 MFS MFS media region 137630712@174951096 ( 65.6G)
    12 MFS MFS application region 2 589824@174361272 ( 288.0M)
    13 MFS MFS media region 2 171919990@64 ( 82.0G)

    Total SA SD Hours: 165 Total DTV SD Hours: 144 98 % Free
    Software: 11.0k-01-2-652 Tivo Model: TCD652160


    _________________________________________________

    Partition 1, the partition map, comes first, followed by partition 13, the 2nd MFS media partition, followed by 3, 4, 5, 6, 7, 8, 9, 10, 12, 11.
     
  12. ggieseke

    ggieseke Active Member

    4,031
    12
    May 30, 2008
    That matches the OP's drive and the one I cooked up. Good to know.
     
  13. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    Okay, I was able to use the provided 512 byte header and overwrite the primary and backup headers on my clone drive. I just highlighted the same 512 bytes on the drive and pasted it in there.

    The first bootup, I didn't see a GSOD, but then it rebooted and subsequent boots had GSOD. I let it loop overnight just to make sure it wasn't FSCKing something.

    I'm wondering if maybe replacing the header isn't working because my clone drive isn't exactly like the factory drive? I mean, it's pretty close, but it still has some minor differences, right?

    Other than that I'm out of guesses for today. You guys are operating at a level over and above what I know.

    I'm attaching the two headers that I overwrote with yours. It did look like your good one "fit" into the sector, if that makes any sense.

    ~j
     

    Attached Files:

  14. ggieseke

    ggieseke Active Member

    4,031
    12
    May 30, 2008
    I haven't analyzed your backups fully or run a checksum, but they look OK at first glance. Have you had a chance to run mfsinfo to see if it gets past the previous "volume header not found" error message?

    If necessary we can try to replace all 6 zone headers too. If the data in the actual zones is corrupt it's a lost cause, but if the damage was limited to a few sectors it might work.

    Even if the clone isn't exactly the same it shouldn't matter as long as the cloned drive is at least as big as the original and it's not over 2TB. I haven't proved one way or the other whether Series 3s with a recent OS can break that barrier.
     

Share This Page