[LordMcD]

I just got a TurboNet after 3 years of loving my Tivo (HDR31201, 30GB+60GB), and didn't know that XP would kill my drive until *after* I accidentally booted to it with my A drive attatched. Of course the backup I made 3 years ago is long gone.

Now my Tivo is unbootable (and unreadable). MakeTivoBootable (TiVo Partition Tools) looks like it's what I need, but I've only found it on http://pvrhack.sonnik.com which doesn't seem to exist anymore.

My second options is to re-write my boot sector with a known-good copy.

Questions:
1) Does anyone have MakeTivoBootable? I'm willing to host it to make it available to others.
2) Can someone with my model tivo (or one with matching partition table) and either a backup or telnet access *please* help me send me the boot sector? I can help you if need be.

Thanks!

PS: I don't think that TiVo Inc owns the copyright to the HFS partition table of an IDE disk, so this seems within both the spirit and letter of the forum rules. If a moderator feels differently, please let me know.

 

[Cletus]

Enjoy!

Here are the author's comments (dmprantz):

MakeTiVoBootbale -This is a dangerous program! If you're not careful,
you can really break things with this. Basically, it writes a fresh TiVo
block 0 (boot sector) over a hard drive. YOU CANNOT CHANGE THINGS WITH THIS,
ONLY OVERWRITE WHAT'S THERE. Lots of W2K users will need this one. The
syntax is the following:

-d <device> REQUIRED. Device to make bootable
--pk <Partition> Primary Boot Partition
--ak <Partition> Alternate Boot Partition
--bp <Params> Boot Parameters
--host <hostname> Hostname
--ip IP Address
--mac MAC Address

If you wanna create a new boot sector that's supposed to boot from a kernel
on partition 3 and a root that's on partition 4, you would use the following
command:

MakeTiVoBootable -d /dev/hdX --pk 3 --ak 6 --bp root=/dev/hda4

if that doesn't work, try this:

MakeTiVoBootable -d /dev/hdX --pk 6 --ak 3 --bp root=/dev/hda7

contrary to the online help, this program will not automatically swap bytes,
so you must enable that yourself.

HINT: You can (and should) backup your existing block 0 with dd before you
use this program. You can also direct output to a file and verify that it
looks good before you dd that to the hard drive (You can even use dd's swab
option).

 

[LordMcD]

MakeTivoBootable (and the rest of Tivo Partition Tools) are now available at http://www.upl.cs.wisc.edu/~will/tivo/ .

I'll post a follow-up detailing it success.

 

[Cletus]

I have all of the partition tools, but the archive is too big for posting as attachment.

Oh wait.. let me try to recompress it.

Okay, it's smaller now. Remove the extra ".zip" extension, and decompress it with 'tar jxvf rtpt.tar.bz2'. I had to add the extra ".zip" because of the forum software.

 

[LordMcD]

Success!... mostly.

MakeTiVoBootable worked (once I read the --bswap option from the command that didn't exist in the documentation), and Tivo boots and works now.

BUT... I can no longer read my partition table using pdisk, or mount any of the partitions (can't read superblock). Any suggestions? Otherwise I might still be able to dd a valid boot sector. Does anyone want to send me a very specific 512 bytes so I can test this theory?

 

[Cletus]

If the TiVo works, that means you have a valid partition table. If you can't read it, you're doing something wrong... like booting in non-byteswapped mode. Which is probably why you needed to use -bswap in the first place (you shouldn't have to, normally). Check again your booting process with the TiVo drive attached to the PC. Make sure it's not on the primary master channel, and that you're not disabling byteswapping when booting the CD.

 

[LordMcD]

Understood and agreed that I'm booting into non-byteswapped mode; I don't know why I didn't approach it from this angle first. As I said it's been a while (2.5 years) since I've done any Tivo hacking. I tried both an old copy of Dylan's BD that I had around and the floppy image from the MFSTools 2.0 CD (the bootable CD wasn't, which is what caused this problem in the first place. I haven't tried burning it again).

Perhaps I should get Dylan's BD again, and I can check the howto's again, but how do I boot into byte-swapped mode? I don't remember LILO waiting for me... Also, wasn't this part of the point of "slightly hacked" HFS support, so you could access both types of disks at the same time? Thanks for you help, BTW.

 

[Cletus]

Use kazymyr's bootable CD v2.6i. It just works. The byteswapped mode is the default.

Or else, use the NoJ version of the MFStools2 CD. The original version was imaged with Joliet extensions on, which caused problems for a LOT of people. Tiger later made available a version with no Joliet ("NoJ"), which is much better, in that it actually boots. For some reason, the correct NoJ version wasn't circulated much, instead the bad first version is what's available all over the place.

 

[LordMcD]

I used kazymyr's CD and as you said, it just worked. Much nicer than DBD (tab completion! command history! decent ramdisk!).

I'm a happy camper now - thanks much.

 

[rbachelor]

So I did the same thing (conveniently forgot that I was running ME the last time I was doing this stuff) and had both my A and B drives attached. I've tried using the MakeTiVoBootable (had to dig up an old DBD -- new Kazy disk has libc.so.6 "issues") however it doesn't appear to have made a difference for me.

So, two questions:

1) Is there something I need to do for my B drive as well?
2) Is there some way to verify that the boot sector is indeed now what it's supposed to be?

Thanks for any help.

Rod Bachelor

 

[rbachelor]

Just re-read my last post and realized that I wasn't clear as to the state my Tivo is in. It doesn't appear to boot off the disk at all, just sits at the "Please wait..." screen.

Rod

 

[Robert S]

I don't think this problem affects to B drive (it affects the boot sector, not the partition table), but if it did, your TiVo would stick at 'almost there'.

Did you have your TiVo drive on primary master when you ran MTB?

 

[rbachelor]

Nope. I was using the original DBD which byteswaps everything but the primary master. The TiVo A disk was on primary slave. Also tried MTB with and without the --bswap mode but it didn't appear to make a difference.

After the last time I tried it (non-byteswapped), I dd'd the first 1024 bytes of the disk. Here's the first 32 bytes:

14 92 03 06 72 6F 6F 74 3D 2F 64 65 76 2F 68 64
61 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00

After the first 4 bytes, it translates to "root=/dev/hda4". The rest are all 00's until it gets to byte 512 where it looks like the partition table starts. I can also read the partition table with no problems with pdisk.

 

[Robert S]

I'm not sure what a TiVo boot block looks like, but I'd agree it probably doesn't look like that!

There are some images in the - ahem - usual place that are gzipped copies of empty TiVo drives. If you got one of those you could unzip the first 512 bytes, which might give you the missing code (you might need to copy partitions 2,3 & 4 to 5, 6 & 7, or vice-versa to get it to boot of the right partitions).

 

[rbachelor]

Hey Robert

I looked back in the previous postings but can't find the one with the ftp site for the images. I've got an old backup, but thought a fresh image might be better. Can you post the location here again or private message it to me?

thanks

 

[Robert S]

Well, linking directly to that site is forbidden on this Forum, so one has to be a little circumspect.

I was thinking of the SVR 1.3 image, which is not an MFS Tools backup, but was produced by piping the output from dd into gzip.

Therefore, the first few bytes of this file are the boot block. I would be surprised if the boot block has changed much between the various versions of the TiVo software - all it does is pull the OS off the disk - so you should be OK if you can figure out how to decompress it.

Look at some of the older TiVo hacking guides for instructions on how to make and restore this type of backup.

I would think that dd with count=1 might do the trick for you.

 

[rbachelor]

Well, the SVR image is quite a bit different than mine. (Phillips 312) so instead, I went ahead and restored an old backup to an old disk and dd'd the first 1024 bytes off and it actually seemed pretty similar. coupla minor changes like a space after the /dev/hda4 and it had the hostname and MAC and IP address but otherwise the same.

So, tried that disk out and it booted. Then, I copied the first 1024 bytes from that disk to my problem disk but still no joy. Same symptoms as before.

I'm really confused here... Any other ideas on what could be preventing the tivo from booting? Any troubleshooting tips? I'm out of ideas...

 

[Robert S]

You seem to have narrowed the problem to the drive itself. Have you run diagnostics on it? Perhaps the XP sig is not the problem?

 

[rbachelor]

Yup. Downloaded the Maxtor diagnostics and it works fine. Very strange. I also went ahead and did a mfstools backup of both drives. I mounted the root and /var partitions as well and they both appear functional. My next step will be to copy the kernel partion from the disk I restored a backup to to the Tivo A disk and see what happens. dd is my new best friend right now...

BTW. copying the 1024 bytes from the working test disk to the A disk screwed up the partition table but I recovered the 1024 bytes I dd'd from the A disk before and the partition table is back and happy again.

Sigh. I'm going to know more about TiVo partitions and such than I ever really wanted to by the time I'm done here...

 

[rbachelor]

Another update. I've tried copying the first 512 bytes of of the boot sector and the partition containing the kernel from the recovered backup disk to my non-booting disk but it still behaves the same (no boot).

Does anyone have any info on the boot sequence of the TiVo and what other differences I could look for between the two disks?

One thing I noticed was that the boot, kernel, root etc. partitions in the disk that works are all contiguous at the beginning of the disk. In the disk that doesn't, the kernel (hda3) and other relevant partitions are about 30GB into the disk. I wouldn't imagine that this would matter considering that the disk used to work and the partition layout hasn't changed but I thought it would be worth mentioning.

Thanks
Rod