Accidentally dd'd my active root OR how do software upgrades work

[dfalso]

Hi all,
I'm running a SAS2, on a drive with a killhdinitrd'd 4.x software I had a 7.1a upgrade pending (with reboots at 2am). I decided the most straightforward way was to let it install the new OS and then try to hack it again (yes, I saw Nutkase's post, but I couldn't find a bootpage that would work on my Tivo). I telnet'd in, ran the installSW file, then let it reboot. The tivo worked fine after than, so I pulled the drive and attemped to zcat a killhdinitrd' 3.1.5 kernel from my PTV LBA48 upgrade CD. Unfortunately, I mistyped, and instead of dd'ing to /dev/hdc4, I wrote to /dev/hdc3.
Now, the Tivo hangs in the welcome screen. I pulled the drive and put it back in my PC, and I can no longer bootpage, tivopart mount, or pdisk it.

Results of bootpage:
Device "/dev/hdc" does not appear to be a TiVo drive!
Signature bytes 0x00 0x52 do not match expected byte values 0x14 0x92

Results of pdisk:
pdisk: No valid block 1 on '/dev/hdc'
Edit /dev/hdc -
Command (? for help):

Results of tivopart.x86 d /dev/hdc:
(null): No valid block 1 on '/dev/hdc'
fatal: invalid drive: /dev/hdc

Now, my questions:
-I've been following the discussion on 3.1.1c vs. 3.1.5, but haven't seen consensus. Either way, I don't think that's the problem. Am I wrong?
-Theoretically, I've only foobar'd my 3 partition; my 6/7 partition should still be okay. Is there a way to revert back to that, rerun the install of the 7.1 software, and try this again?
-I (of course) still have my original tivo drive, sitting in an anti-static bag on my shelf. However, it's still the 4.x software. If I put it back in, I could rebuild the hacked drive like I did originally, but it'd be the 4.x software. How do I tell tivo to resend the 7.1?

Or am I completely screwed?

Thanks for any help.
-Dom

[PlainBill]

Dom, as simply as possible, "You didn't make the mistake you think you did!"

The kernel is written to either partition 3 or 6; if you wrote it to the opposite one it would NOT give the 'not a TiVo drive error'; even if you wrote it to the root partition (4 or 7), it would not give the error (but it WOULD have trashed the software.

I can think of two possibilities - you accidentally booted the computer with the drive attached and are running either Windows 2000 or XP. If that happened, 'maketivobootable' will fix it for you (you'll have to search for it here).

The other possiblity that comes to mind is you wrote the kernel to partition 1 by specifying /dev/hdc1 (or I think can also be done by specifying /dev/hdc). In that case, I know of no way to recover.

[NutKase]

(yes, I saw Nutkase's post, but I couldn't find a bootpage that would work on my Tivo).

Every tivo includes a mips bootpage in /sbin/bootpage and this will work as advertised via telnet when working from your tivo.

If you're working on your tivo drive while it's in your computer, use the bootpage that's included on most boot disks or the alldeadhomiez updated version available on this board.

-Theoretically, I've only foobar'd my 3 partition; my 6/7 partition should still be okay. Is there a way to revert back to that, rerun the install of the 7.1 software, and try this again?

Just set the bootpage back and flip it and you'll be fine unless you did something else.

How do I tell tivo to resend the 7.1?

Tivo will resend 7.1 if you force a connect with an old software version installed.

That said, the hacked killhdinitrd'd kernel GOES on either /dev/hdc3 or /dev/hdc6, depending on which is the active partition pair. This means that where you put it is not the source of your problems.

Did you boot into windows (XP or 2000) with your tivo drive attached to your pc? Have you changed boot disks (to one that may be byteswapped)? Are your jumpers correct (don't use cable select)?


NutKase

[dfalso]

Wow, you guys are awesomely fast. If nothing else, thanks for that...

I'll answer as many as possible. First off, I lent my serial cable to a friend, and I should get it back tomorrow. I don't see that clearing things up, but JIC...

Oh, and I backed up my rc.sysinit.authors, my /var/hack directories, and my recordings before I started this, so starting over from scratch isn't that catastrophic.

PlainBill and Nutkase:
Whenever I attach the drive to my PC, I boot into knoppix and disconnect my SATA drives (where windows lives). I'm 99% sure that's not it.
I will look for maketivobootable, and see if that fixes things.

PlainBill:
I'm also pretty sure I didn't trash the 1 partition. I did dd to 3 and 4, but that's (I think) it. Now you see why I'm confused...

Nutkase:
I *thought* that bootpage should already be there (its a tivo developer tool, right?), but when I ran a locate (I think it was locate - find wasn't installed in the utils I had up there), I couldn't find it . Too late now.
Like I wrote above, using bootpage (I downloaded the one here: http://www.dealdatabase.com/forum/sh...ad.php?t=39244) with any parameter (even -b) produces an error. So I don't think I can flip back.
I'm pretty sure the jumpers aren't an issue; the drive is on an ide channel by itself. The CDR (actually, DVDR) is on the primary.

Nutkase:
In my situation, I'm using a USB-ethernet adaptor supported by the stock SAS2 config. In this instance, does the call to redownload the new OS happen automatically? Otherwise, how do I force a connect?

The byteswapping issue is the one I don't understand well, and was doing some reasearch on. I used the 3.1.5 kernel (under s2_kernels) on the PTV upgrade LBA-48 ISO v3.0. That could be the problem as well. I confess, I'm still researching byteswapping as well, but I *think* that it applies to Series1 (I have a SAS2).

Nutkase, thanks for clarifying the upgrade distribution issue. The way I see it, if I can't recover this drive, I should:
-Restart tivo with the old drive.
-Wait for it to upgrade to 7.1 (or not)
-remake the new drive again, as before.
-attempt to swap the kernel.

Guys, again thanks for all your help. You all rock.

-Dom

[dfalso]

One more thing:
it was suggested in some other helpme threads that the first 128 bytes of the drive are useful. I grabbed 'em for you:

dd if=/dev/hdc bs=1 count=128 > /home/knoppix/Desktop/tivoheader.hx

hexedit reveals:
00000000 00 52 50 4F 80 00 20 00 00 00 0F 71 00 00 00 00 .RPO.. ....q....
00000010 80 1E 4B 84 00 1E E1 47 00 1E E1 47 00 00 00 00 ..K....G...G....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 80 15 09 04 00 00 00 00 00 00 00 00 FF FF FF FF ................
00000040 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 FF FF FF FF FF FF FF FF 80 00 20 3C .............. <
00000060 80 00 20 3C 00 00 00 00 80 00 20 00 80 00 20 00 .. <...... ... .
00000070 80 14 B0 90 00 00 00 00 00 00 00 00 00 00 00 00 ................

As suspected, it doesn't look good. Maybe if I had dd'd to /dev/hdc instead of /dev/hdc3, that could do it?

-Dom

[alldeadhomiez]

As suspected, it doesn't look good. Maybe if I had dd'd to /dev/hdc instead of /dev/hdc3, that could do it?

Yep, that was it. Don't do that next time.

Moved to Newbie.

[eastwind]

One more thing:
it was suggested in some other helpme threads that the first 128 bytes of the drive are useful. I grabbed 'em for you:

dd if=/dev/hdc bs=1 count=128 > /home/knoppix/Desktop/tivoheader.hx

hexedit reveals:
00000000 00 52 50 4F 80 00 20 00 00 00 0F 71 00 00 00 00 .RPO.. ....q....
00000010 80 1E 4B 84 00 1E E1 47 00 1E E1 47 00 00 00 00 ..K....G...G....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 80 15 09 04 00 00 00 00 00 00 00 00 FF FF FF FF ................
00000040 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 FF FF FF FF FF FF FF FF 80 00 20 3C .............. <
00000060 80 00 20 3C 00 00 00 00 80 00 20 00 80 00 20 00 .. <...... ... .
00000070 80 14 B0 90 00 00 00 00 00 00 00 00 00 00 00 00 ................

As suspected, it doesn't look good. Maybe if I had dd'd to /dev/hdc instead of /dev/hdc3, that could do it?

-Dom

Yeah, that looks a lot like the hexdump of my hda3--not exactly the same because my kernel is from 3.1.1c (2.4.4 Linux kernel). But similar enough to make me believe that's what you did.

[bash DTiVo(4): ~] $dd if=/dev/hda3 bs=1 count=128 | hexdump
128+0 records in
128+0 records out
0000000 0052 504f 8000 2000 0000 0db1 0000 0000
0000010 8019 f380 001b 605d 001b 605d 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 8011 b700 0000 0000 0000 0000 ffff ffff
0000040 0000 000a 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 ffff ffff 8000 203c
0000060 8000 203c 0000 0000 8000 2000 8000 2000
0000070 8011 5cc0 0000 0000 0000 0000 0000 0000
0000080

ew