bootpage fails on original drive?

[m0ondoggy]

Hey all. I'm trying to hack an SD-DVR40 that I bought off of ebay recently, and am having issues.

First off, I tried using the MFStools 2.0 cd to mfsbackup and mfsrestore to a new 160 gig drive. The cd did not have an lba48 kernel, so the drive was not reporting the right size, but would still boot afterwards. I ended up using the free cd from ptv to do the mfsbackup and restore and it sees the whole 160 gigs. I only mention that in case the fact that I initially used a non-lba48 kernel at first screwed something up.

I could never mount the root partitions for the new drive, but i can mount the original ones just fine. The issue that's troubling me the most is this:

If I run bootpage -p /dev/hdc4 on the original unhacked drive, I get this message:

Device "/dev/hdc4" does not appear to be a TiVo drive!
Signature bytes 0x00 0x00 do not match expected byte values 0x14 0x92

I've read about the byte swapping and noswap issues, but that usually involves the byte order above being, well, swapped. This is 0x00 0x00. When I do the mfsbackup and mfsrestore the problem carries over to the new drive.

Here is the command I used:

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -zxpi - /dev/hdd

Both drives boot just fine and work, I just can't mount the new drive partitions on the pc to make the hacks. I also can't install the killhdinitrd'd kernel either:

dd: writing to '/dev/hdd3': No space left on device

I'm at a loss, I've been searching on this forum for a couple of days now, and I'm out of ideas. I have my DSR7000 running perfectly, but I only used a 120G drive on it, so I didn't have these lba48 issues.

Be gentle, I didn't pick up any astroglide at the store :D.

Thanks

[Narf54321]

bootpage -p /dev/hdc4 on the original unhacked drive,

You're trying to look at bootpage on a partition, but bootpage is stored as part of the Master Boot Record.

Try this:
bootpage -p /dev/hdc

[m0ondoggy]

You're trying to look at bootpage on a partition, but bootpage is stored as part of the Master Boot Record.

Try this:
bootpage -p /dev/hdc
Thanks. WOW, stupid me. It's been a while since I hacked my DSR7000. This at least tells me that my original drive is OK and whatever is going wrong is happening with my new drive. It's a Hitachi Deathstar 160G in case that matters.

Any idea why I can't mount my new partitions or dd the kernel to the kernel partitions? I did search on this stuff quite a bit but found nothing definitive. If you have a link to a post that I might have missed that discusses it already that will do just fine.

[m0ondoggy]

So, if I mfsrestore without the -x (uzing -zpi) I can mount the drive. Is -x screwing up the partition map? I read about there being a problem with more than 15 partitions, and my original drive only has 13. When the expand is done, parts 14 and 15 are created. I'm going to take my kid to the park and experiment (and search) more later when he's taking his nap.

I'm wondering if starting out with the non-lba48 disk screwed up the partition table. If I don't have any luck when I get back, I guess I can low-level format the disk and try again with a lba48 boot disk from the onset. This is assuming I don't get any better suggestions here first.

BTW, I did read the lba48 (expand after the fact) thread, maybe I just didn't understand it fully.

[Narf54321]

Its always hard to tell what actually happened when folks are trying to replace drives, especially in the past couple years with the super-large (LBA48 greater than 137GB) drives being so common. You need an LBA48 linux boot CD to boot your PC with, to work on super-large Tivo drives; And you need an LBA48 tivo kernel to boot up your Tivo and "see" all the space on the super-large drive. Series-1 units need a specially-compiled kernel to use super-large drives; Series-2 units need something like the 3.1.5 -or- 6.x -or- 7.x kernels to "see" the larger drives.

The -x option from mfsrestore does an in-place expand while restoring the image to the drive. I usually recommend folks not use the -x option and make sure they get a working system which boots and all that good stuff, first. There's plenty of opportunity to screw up the bootpage, kernel, swap-space and all that without throwing new MFS partitions into the mix.

Once everything actually works, a quick mfsadd is pretty easy to do to add recording space.

A few recommended tools can be found in the tivopart archive (http://www.dealdatabase.com/forum/showthread.php?t=25219) including an lba48chk tool to see if you kernel+drive handles super-large hard disks.

[m0ondoggy]

I'm not sure what the deal was, but everything just went perfectly as I expected it to the first time. I didn't change a THING except I took the x out of the mfsrestore command and just did an mfsadd after I was done hacking. Even after doing the mfsadd, I can still mount the root partition on my pc. I'm up, superpatched and am playing with MRV as I type this.

Way cool.