"volume header corrupt" If you know more than I do, help!

[unitron]

I tried to search for "volume header corrupt" in this Broken TiVos forum and got this:

The following words are either very common, too long, or too short and were not included in your search:
"volume header corrupt"

When I took off the quote marks, it searched for

volume, header, corrupt (i.e., any post with any of those words, apparently)

and returned stuff that gets in way over my head, without necessarily being about what I'm asking about.

Google, of course, returns people asking about it, not offering expanations and solutions.

So I climb to the mountaintop and appeal to the gurus:

When mfsinfo returns "volume header corrupt", is there a somewhat simple explanation of what it means?

Is it talking specifically about one (or more) of the MFS partitions, or just about the other ones, or both, or what?

And just as importantly, is there a fix that might go as far as requiring a hex editor, but not as far as needing an electron microscope to exam the disc surface or 20 years of programming experience?

Thanks for any breadcrumbs you can strew along the trail.

[Jamie]

Refering to the mfstools source, this particular message means that the MFS volume header crc (checksum) isn't correct, and neither is the crc on the backup volume header. With both the primary and backup volume headers corrupt, it may be difficult to get much out of the file system.

The mfs_info utility in mfs-utils has a switch to rewrite the correct checksum -- "-f". This is useful after making manual changes to the volume header, e.g. in a manual partition coalesce procedure. If your volume header really is corrupt, and you didn't make any manual edits to it, this is unlikely to be helpful though. If you try it, I'd suggest you work on a backup copy, not the original.

[unitron]

Wow, now that's fast service.

I'm sort of asking on behalf of someone else I'm handholding over on TCF. I've had it happen to me before, more than once, mostly on S1 (just to add the spice of the byteswapping complication ), and I pretty much put those drives on the shelf and started over. But he's trying to rescue an Hitachi 2TB worth of shows.

Is that the pre-spike MFS Live mfstools by tiger mfstools source?

(you mean I have to break down and read source code? )

Are both that primary and backup volume header on the first MFS partition, partition 10?

Am I hopelessly in over my head here?

[Jamie]

Yes, you'll have to read the source to figure out what is going on.

I found the message in the mfslive-1.4 sources.

The volume header is at block 0 in partition 10. The code seems to think there is a backup copy at a different offset, although I haven't verified that.

It doesn't look like mfstools does much error checking, and if you point it at a disk that is not a tivo disk, but has a partition 10, I think you will get this message.

A good way to check whether you have something that looks like it could be a tivo disk is to hexdump the volume header (aka superblock) and see if it looks reasonable.

Here's a dump from my tivohd:

bash-2.02# hexdump -C -n 512 /dev/hda10
00000000  00 00 00 00 eb ba fe ed  1a 2d 2a bf 00 00 00 10  |.........-*.....|
00000010  00 00 00 01 00 00 00 40  00 00 02 40 00 00 00 01  |.......@...@....|
00000020  00 00 00 01 2f 64 65 76  2f 68 64 61 31 30 20 2f  |..../dev/hda10 /|
00000030  64 65 76 2f 68 64 61 31  31 20 2f 64 65 76 2f 68  |dev/hda11 /dev/h|
00000040  64 61 31 32 20 2f 64 65  76 2f 68 64 61 31 33 00  |da12 /dev/hda13.|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 e8 c6 40 00  |..............@.|
000000b0  00 00 00 00 00 00 00 01  00 00 00 00 00 4a 03 e2  |.............J..|
000000c0  00 00 00 00 00 00 03 e9  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 04 61  00 00 00 00 00 08 ff fe  |.......a........|
000000e0  00 00 00 00 00 00 00 01  00 00 00 00 00 04 00 00  |................|
000000f0  00 00 00 00 00 04 00 00  00 00 00 78 00 00 03 e8  |...........x....|
00000100  00 03 0d 40 00 5c 12 34  00 00 00 99 00 69 13 c6  |...@.\.4.....i..|
00000110  00 00 00 80 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Some things to look for is the magic number at offset 0x4, and the devlist at offset 0x24. The magic number can take several different values, depending on the type and state of MFS. The most common values are 0xabbafeed or 0xebbafeed for a normal mfs32 or mfs64 respectively. On an S1, the value may be byte swapped, depending on what kernel options you used when you booted.

If it looks nothing like this, then either the volume header is corrupt, or the disk isn't in fact a tivo disk.

[unitron]

Darn, you're gonna make me have to think and use my brain and stuff like that, ain't'cha?