Problem with S3

[lrhorer]

I finally took the plunge with my S3 and hacked it. Prior to this, I had only hacked my TiVo HD (and of course my S1). The S3 is having a couple of problems, however. In the first place, when I used `tivopart r /dev/sdc` to rescan the partitions, it complained about /dev/sdc16. Since sdc16 is an MFS partition, I really didn't pay too much attention, especially since I was able to mount the root and /var with no apparent trouble. I neutered the kernel, copied all the files over, disabled iptables, and patched tivoapp with the NoCSO hack. I put everything back together and rebooted. I'm able to telnet in, and ftp and TiVoWebPlus are both working. The regular functioning of the TiVo seems fine. When I run ciphercheck, however, I get:

bash-2.02# ciphercheck
crc mismatch len=280 0xbd977fcf 0x8bc08684
WARNING: total sectors doesn't match (total=-389275648 sb=858993459200001)
crc mismatch len=65536 0x00000000 0x569fe985
sector wrong in zone (1125899907104768 10194113466990599)

When I try to start tserver, I get almost exactly the same error:

bash-2.02# /utils/tserver
Doing the Lowest PriorityFix...
crc mismatch len=280 0x991a43d6 0xdf0b9636
WARNING: total sectors doesn't match (total=-389275648 sb=858993459200001)
crc mismatch len=65536 0x00000000 0x569fe985
sector wrong in zone (1125899907104768 10194113466990599)

Can anyone tell me what is going on? Are tserver and ciphercheck different on the S3 versus the THD?

[Jamie]

...
Can anyone tell me what is going on? Are tserver and ciphercheck different on the S3 versus the THD?

Yes. THD is MFS64 while the S3 is the older (legacy) MFS32. You want the 32 bit versions for the S3.

[lrhorer]

Oh, duh! Of course it is. <Sigh> I'm getting old.

Hmm. This is going to complicate maintaining the units just a bit. There are several relatively simple things I can do manually, but as usual I would prefer to automate the process as much as possible. Do you know of a file on the hard drive I can inspect to determine which flavor of TiVo is being modified? If I can get that automatically in the script, then I can easily choose between two archives to dump onto the drive.

[Jamie]

Oh, duh! Of course it is. <Sigh> I'm getting old.

Hmm. This is going to complicate maintaining the units just a bit. There are several relatively simple things I can do manually, but as usual I would prefer to automate the process as much as possible. Do you know of a file on the hard drive I can inspect to determine which flavor of TiVo is being modified? If I can get that automatically in the script, then I can easily choose between two archives to dump onto the drive.

On the tivo, check $SerialNumber or the output of `crypto -gsn`.

Off the tivo, it's a bit harder. The root file systems are identical, except what is in /platform. So you could look in /platform for something that distinguishes the two systems. The kernels are also different, so you could also look for an identifying string there.

Perhaps the best idea would be to check the MFS magic number. For mfs32:

bash-2.02# dd if=/dev/hda10 bs=8 count=1 | hexdump
1+0 records in
1+0 records out
0000000 0000 0000 abba feed
0000008

verses mfs64:

bash-2.02# dd if=/dev/hda10 bs=8 count=1 | hexdump
1+0 records in
1+0 records out
0000000 0000 0000 ebba feed
0000008

[lrhorer]

Yeah, that will work. I can just check for the string value in the hack script and select the appropriate tarball based on the magic number.

[lrhorer]

On the tivo, check $SerialNumber or the output of `crypto -gsn`.

Off the tivo, it's a bit harder. The root file systems are identical, except what is in /platform. So you could look in /platform for something that distinguishes the two systems. The kernels are also different, so you could also look for an identifying string there.

Perhaps the best idea would be to check the MFS magic number. For mfs32:

bash-2.02# dd if=/dev/hda10 bs=8 count=1 | hexdump
1+0 records in
1+0 records out
0000000 0000 0000 abba feed
0000008

verses mfs64:

bash-2.02# dd if=/dev/hda10 bs=8 count=1 | hexdump
1+0 records in
1+0 records out
0000000 0000 0000 ebba feed
0000008

Hmm. I finally (over a year later!!) got around to trying to implement this, having finally gotten tired of manually arranging the hacks. I'm getting something different than you posted, however. From one of my S3 TiVos, I get:

Leslie:/hack# dd if=$dspec"10" bs=8 count=1 | hexdump
1+0 records in
1+0 records out
8 bytes (8 B) copied, 0.00040988 s, 19.5 kB/s
0000000 0000 0000 baab edfe
0000008

Note the byte swapping. Was your output obtained from a live TiVo? I'm doing this from a TiVo drive mounted in a Linux PC. Is that why the bytes are swapped? Telnetting to a live THD and running the command gets the same result you show for the 64 bit.

[Jamie]

....
Note the byte swapping. Was your output obtained from a live TiVo? I'm doing this from a TiVo drive mounted in a Linux PC. Is that why the bytes are swapped? Telnetting to a live THD and running the command gets the same result you show for the 64 bit.

Seems you've answered this on your own, but, yes, it is an endianness issue.

[lrhorer]

Yeah, I figured. I just wanted to make sure I wasn't fooling myself. It's been known to happen.