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

TiVo Volume Header Format

Discussion in 'TiVo Underground' started by Marconi, Jan 3, 2011.

  1. Jan 3, 2011 #1 of 25
    Marconi

    Marconi TiVo Junkie

    444
    0
    Sep 8, 2001
    Page, AZ USA
    TiVo drives use a "modified Apple partition map." It appears to me that only the volume header block (block zero) is modified from what Apple uses for their APM (Apple Partition Map) format. The rest of the partition map seems indistinguishable from a standard APM format disk. So, I'm trying to figure out block zero.

    Here's what I have been able to figure out about block 0 on TiVo drives:

    TiVo volume header, one block of 512 bytes.
    Bytes 0-1: ("14 92") Unknown. On APM volumes, these bytes are the signature "ER" so perhaps the bytes "14 92" are a TiVo signature. These bytes are the same on all the drives I've checked so far.

    Bytes 2-3: "03 06" or "06 03" indicating the boot partition, either 4 or 7 (zero-based).

    Byte 4 starts the string: "root=/dev/hda7" or "root=/dev/hda4" which is null terminated. This string matches the order indicated by bytes 2-3.

    Byte 19 starts the string: "runfactorydiag=true dsscon=true brev=0x1031" and is null terminated. I've seen other strings including: "runfinaltest=2 brev=0x10 contigmem8=16M=16M" and partially overwritten strings like: "unfinaltest=tru" so I'm not convinced these bytes are all that important.

    Bytes 63 through 131, all nulls

    Byte 132 starts the string: "unnamed" and is null terminated. This seems to be the same on every drive I've checked.

    Bytes 140 through 163, all nulls.

    Bytes 164 through 174 unknown, These vary from one drive to another.

    40 GB drive:
    0A 54 8F 49 B2 32 31 60 75 92 3C

    60 GB drive:
    0A E8 E1 80 8F 9D 03 B0 0B E8 3C

    80 GB drive:
    0A 8D 2F 4C D2 3D 9C 58 7B 16 3C

    another 80 GB drive:
    0A 6E 00 85 01 7A DC 72 7E 4D 3C

    As shown above, byte 164 is always "0A" and byte 174 is always "3C" on each drive I've checked. I have no idea what these bytes indicate.

    Bytes 175 through 511, all nulls.

    If any of you can identify the purpose of bytes 0-1 and/or bytes 164-174, please enlighten me.

    FYI, the reason I'm interested in this is that I have, on multiple occasions, lost all my recordings when a TiVo became unbootable. Subsequent efforts to rescue data using Linux-based tools gave the error that the volume header was corrupted. Hence, I want to know more about the volume header so that I can effect repairs, should I ever have another corrupted volume header.
     
  2. Jan 3, 2011 #2 of 25
    wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    Presumably Linux didn't recognize the format, which is not the same as it actually being corrupted. There's a small kernel patch for Linux that enables it to handle TiVo partition tables, which I used to use back in my DirecTiVo days. I don't know where one might find it now, but there's probably some deal in a database somewhere.

    Alternatively, one can obtain a pre-patched Linux boot disk from (among other places) one of the forum sponsors, I believe.
     
  3. Jan 4, 2011 #3 of 25
    Marconi

    Marconi TiVo Junkie

    444
    0
    Sep 8, 2001
    Page, AZ USA
    When the backup tool (MFSLive boot CD) says it's corrupted, I'll take it at its word. I'm not the only one this has happened to.

    Seems a shame to lose an entire drive of recordings because one 512-byte block is corrupted. I think I'll press on with trying to figure out what those bytes mean.
     
  4. Jan 4, 2011 #4 of 25
    wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    Ah, you didn't say that you'd actually used a TiVo-oriented boot disc, just "Linux". In that case, yes, probably it is.
     
  5. Jan 4, 2011 #5 of 25
    Marconi

    Marconi TiVo Junkie

    444
    0
    Sep 8, 2001
    Page, AZ USA
    I specified "Linux-based tools" so as to differentiate my situation from those using Windows-based TiVo recovery tools. That the tools were for rescue of TiVo data was only implied. I probably should have been more clear.
     
  6. Jan 9, 2011 #6 of 25
    unitron

    unitron Active Member

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

    I feel ya, brother.

    Just to be clear, you are talking about the stuff on the disk that comes before the very first partition, said partition being the Apple Partition Map, said Map being the one which lists itself as the first partition of itself, correct?

    I'm pretty sure that 14 92 is a TiVo-specific thing. Somewhere in the past when booting a Series 1 and watching the process via HyperTerminal and the serial port I think I remember that being what it complained about if the drive wasn't properly byte-swapped (it came up as being read as 92 14 or 41 29 or something like that).

    One of these days I'm going to get enough working machines to be able to devote one to examining old failed TiVo drives with a hex editor and be able to use something else for computer stuff.

    Are you looking at S1 byte swapped drives as well as newer, non-swapped ones?

    You might not want to be so quick to dismiss the importance of the byte 19 string. Apparently it controls, among other stuff, whether the serial port works or not.
     
  7. bsdimp

    bsdimp New Member

    15
    0
    Oct 30, 2009
    I added the necessary glue to FreeBSD's APM definition to make it grok tivo partitions.

    see FreeBSD's src/sys/geom/part/g_part_apm.c for the minimal changes necessary to recognize S1 TiVos. Look at apm_read_ent to see how to read the table in, as well as g_par_apm_probe.
     
  8. Marconi

    Marconi TiVo Junkie

    444
    0
    Sep 8, 2001
    Page, AZ USA
    Correct, though I may be "barking up the wrong tree" as they say. See http://www.tivocommunity.com/tivo-vb/showthread.php?p=4999269#post4999269 There you can see the error messages:
    Primary volume header corrupt, trying backup.
    Secondary volume header corrupt, giving up.
    mfs_load_volume_header: Bad checksum.
    Segmentation fault
    I'm pretty sure that's the same error message I get when my THDs go bad. I suspect that when the TiVo tools, like MFSTools, mention "volume headers" they are not talking about sector zero on the drive, there being no "backup" of that sector (to my knowledge). That and the error message leads me to believe that a routine called "mfs_load_volume_header" is failing.

    So, while corrupted "volume header" is the reason I started investigating this, I don't think I'm investigating the right volume header. Perhaps one of the authors of the tool sets can comment on just what it is that is corrupted when corrupted "volume headers" are reported. Nonetheless, I'm curious to know what all the byte ranges in sector zero of TiVo drives do.

    BTW, to snoop around the drives I'm using iBored: <http://apps.tempel.org/iBored/> iBored (free and available for Mac, Windows, Linux) uses a template system to identify sector types and I'm hoping to contribute a template for TiVo drives. The actual partition map of TiVo drives seems to be just like an Apple Partition Map, with the exception of sector zero. So, figuring out sector zero will allow creation of a template for iBored.

    No, my own S1 is retired and I have only been working with the drives from S2 and THD units.

    I suspect that on the S3 and later units, that part has been deprecated, inasmuch as there are no serial ports. As noted previously, the string beginning there is often partially overwritten. (Probably on S3 and later.)
     
  9. classicsat

    classicsat Astute User

    17,877
    0
    Feb 18, 2004
    Ontario Canada.
    The Series 3s do have a serial console port. It is just not on the back, rather a 4 pin header inside. You need a TTL to RS232 level converter, or USB serial adapter without the level driver (such as a hobbyist FTDI cable), or a Bluetooth serial device.
     
  10. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    Marconi, did you ever find the key to recovering/restoring/repairing the corrupt volume header? I'm asking because I think I'm having the same issue with my TCD652160 and I'm trying to recover the recordings I have which are not replaceable otherwise.

    If you want to see what we have tried, the thread is here:

    http://is.gd/hrILUh

    thx
    jay
     
  11. ejonesss

    ejonesss New Member

    116
    0
    Aug 13, 2007
    is this mean there is a driver that could even make mac read the box?
     
  12. oldsyd

    oldsyd New Member

    20
    0
    Apr 6, 2009
    Iowa
    If you boot from a UNIX based Live CD, you can use Linux based tools on almost any computer.

    I'm still learning on how to repair a damaged superblock.
     
  13. unitron

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC
    If you're looking for a way to take a hard drive out of a TiVo, hook it to a computer, PC or Apple, and see what's on the drive as far as recorded shows and such, much less copy the shows from that hard drive, no one has come up with anything that will do that, and I wouldn't expect anyone to do so any time soon.
     
  14. wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    It's been a long time since I did it, but there are tools that can list and copy individual shows off a connected TiVo drive. However, at the time, there was no way to decrypt them, so it didn't do much good unless you'd disabled encryption before making the recording.
     
  15. unitron

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC
    Could they be copied and saved as .tivo files that Desktop could handle?
     
  16. wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    They're in a different format, and they're encrypted differently. If you disable the encryption, there are tools to convert them to plain MPG files.
     
  17. Marconi

    Marconi TiVo Junkie

    444
    0
    Sep 8, 2001
    Page, AZ USA
    One of my series 3 THDs has just lost all its recordings - again. This is the fourth or fifth time that I can recall. Each time it happens, it goes into a reboot loop and trying to recover anything using the MFSLive CD results in the copy error: "volume header corrupt". Each time it has happened, I have put in a new drive cloned from a 1 TB image of the original factory drive. That is, to create the backup drive/image, I configured the original drive, setting up the CableCARD, etc. then copied and expanded the original drive to a 1 TB drive which became my permanent, bootable backup. I've compared to ensure that the partition sizes are identical between the backup disk and the corrupted one. This is why I thought dd would work.

    Either something in this TiVo is corrupting the volume header of every drive I put in it or there's something wrong with the factory image on my stored 1 TB drive -- something that takes its time to finally manifest after being copied to a new drive. I wish I knew which. Sometimes the new drive works for months before becoming corrupted, sometimes only weeks. Whenever I give up trying to salvage a drive with a corrupted volume header, disk diagnostics always show that the drive is functioning properly. I just erase it and use it elsewhere.

    I also wish I knew what, exactly, the "volume header" is that is being corrupted.

    This most recent time it happened, I decided to try something different. Assuming the "volume header" to be the first block on the drive -- the one before the partition map begins -- I decided to just dd the first block from the 1 TB backup to (a dd clone of) the corrupted drive. No help.

    Then I did a dd copy from the backup drive of everything that is not recordings. That is, I used dd to copy everything starting at the beginning of the disk up to, but not including, the swap partition. All the bootstrap stuff, the OS, etc. was copied to (a dd clone of) the corrupted disk. This did not result in a bootable drive.

    So, what "volume header" is corrupted? It must be in the media areas of the drive as it does not appear to be in the booting /OS areas (even though failure to boot is the primary symptom), which were dd'd but which did not fix the corrupted disk.

    If I knew just what is corrupt, I could dd just that from the backup to the corrupted disk and save my recordings.

    So, where IS this "volume header" that is corrupt?
     
  18. telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    That sounds alot like the MFS header. There are many people here who know more about MFS, so I'll only cover the Linux bases.

    You should view your logs, unless you have already overwrote them. If the only problem is in MFS, that gets configured late in the boot process. The rest of the OS has plenty of opportunity to log complaints about MFS or something else.

    What's the Software version you're using to image from? If it's old, you might be going through a software update at some point. if so, you can NOT go through and recopy pieces from the old image. There's lots of opportunity for mismatch which would make the situation worse.

    If you think this happens consistently, next time it happens, concentrate on analysis rather than fixing it.
    View the logs.
    Binary Compare each of the small partitions.
    (block0 and partitions 1-7 (apm, kernel1, kernel2, root1, root2))

    Someone confirm this (I'm not an S3 person):
    If you have multiple THD, you can reimage then C&DE from another working unit. Then if it happens again, you've isolated it to the hardware instead of the image.

    Is there any hardware modifications or other unusual history to this unit?
     
  19. squint

    squint New Member

    846
    0
    Jun 15, 2008
    I dealt with this before but my memory's hazy. I should have taken better notes...

    I believe it's where the magic number (typically EBBAFEED) is located. I have a 2 tb TiVo HD drive that got stuck in a green screen of death loop and was giving me a corrupt volume header error.

    It should be in partition 10 and a partition map of the drive provided by WinMFS indicates it's in sector 311662658 on my drive. I go to that sector using a hex editor capable of editing drives (iBored or HxD) and see:

    Code:
    00 00 00 00 EB BA FE ED 1C F9 D6 33 00 00 00 10
    00 00 00 01 00 00 00 40 00 00 02 40 00 00 00 01
    00 00 00 01 2F 64 65 76 2F 68 64 61 31 30 20 2F
    64 65 76 2F 68 64 61 31 31 20 2F 64 65 76 2F 68
    64 61 31 32 20 2F 64 65 76 2F 68 64 61 31 33 20
    2F 64 65 76 2F 68 64 61 31 34 20 2F 64 65 76 2F
    68 64 61 31 35 00 00 00 00 00 00 00 00 00 00 00
    When the drive was stuck in a GSOD loop, the EBBAFEED was overwritten with something else. I changed it back (perhaps making some other changes using a working drive's header as reference). Afterwards, I was getting checksum errors which I corrected that using mfs_info -f from the MFSLiveCD.

    If you're losing your recordings anyway you might want to download a fresh image and use that the next time around. That might prevent this problem from reoccurring.
     
  20. telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    There's enough information in the linked threads to check it by hand if not repair it.

    Could you run these commands on the disk you were cloning from and the damaged disk?

    # pdisk -l /dev/sdX
    # dd if=/dev/sdX10 bs=512 count=1 | hexdump -C

    Edit:
    per ggieseke's request add:
    # dd if=/dev/sdX bs=512 count=17 | hexdump -C
    # dd if=/dev/sdX10 bs=512 skip=($TOTAL-1) | hexdump -C
     

Share This Page