40GB DTivo to 120GB DTivo, simple? Or no..?

[wesmoc]

First off, I am embarassed to be posting this, but I *have* to be missing something here.

I have a DirecTivo 40GB version that is happily hacked (with a 40GB drive). I should have just hacked and replaced the 40GB with a 120GB drive to start with when I hacked it 6mos ago, but I didn't.

So, here I am, trying to replace the 40GB drive with a 120GB.

I tried booting off of the MFS Tools disc and performing:
mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -xzpi - /dev/hdc

That seemed to run fine and it ran for about 3 hrs.

I took the drive, put it in the Tivo, booted up, and I get the image that I have attached. I let it sit there for about 20 minutes before I tossed in the towel and rebooted.

After several failed attempts, I gave up and brought everything back over to the PC I was using to do the copy. I figured I would go back and use the same method I tried when I successfully hacked the 40GB drive: Sleeper's TivoScripts Boot CD!

I did that, just going through the backup and restore portion of the monte. Sure, I wasn't going to get the movies I had already recorded, but, hey, I just wanted to see if I could get the 120GB WD drive to boot in this DirecTivo.

I walked it back over to the Tivo, put it in, and booted. Got the same screen again..

I've gone back to using the 40GB hacked drive, but, alas, I'm still fighting with space on this thing... so I am back where I started.

I have checked the jumpers and such. Everything looks OK.

Is it that I should just be waiting *even longer* for that screen to go away? Oh, and that screen comes up right after the "Welcome. Powering up..." screen goes away.

Any pointers in the right direction would be wonderful!

[pmn1]

http://www.dealdatabase.com/forum/sh...14&postcount=3

[wesmoc]

I guess you're saying I've got to "un-sleeper" the drive, eh? Even for this 120GB drive?

My tivo is showing the results of uname -a as:
Linux tivo 2.4.4-TiVo-3.0 #9 Wed Jan 7 10:05:19 PST 2004 mips unknown

And the Tivo itself says I'm running 3.1.1c...

So, I downloaded both the 3.0 and 3.01B ISO's from http://www.ptvupgrade.com/support/bigdisk/index.html

At this point, I guess it would be best to stick with the 3.0 version..

Anyhow, following through the post linked to another post, the procedure looks like:
grab the ISO
use an ISO tool (WinISO works fine) to extract the appropriate kernel
ftp the compressed version over to the tivo
extract it on the tivo itself
Find the right place to put the kernel (crystal ball and a sacrifice of a chicken might help here)
(my results of the bootpage command are : root=/dev/hda4 dsscon=true console=2,115200 BASH_ENV=`mount$IFS-n$IFS/dev/hda14$IFS/mnt;echo$IFS/mnt/runmonte`)
Update the boot params
flip the boot kernel
reboot the tivo

Now, you're saying that once I do all of that, I can finally do the mfsbackup/mfsrestore method in order to utilize the new drive?

Not to sound too paranoid, but this is pretty scary since I would now be mucking with the live drive. If I screw up, I'm hosed... is there no way to back the system up or anything (in such a way that the backup actually works) before I go an kill my tivo (and subsequently get killed by my wife)?

[pmn1]

Originally Posted by wesmoc

I guess you're saying I've got to "un-sleeper" the drive, eh? Even for this 120GB drive?

My tivo is showing the results of uname -a as:
Linux tivo 2.4.4-TiVo-3.0 #9 Wed Jan 7 10:05:19 PST 2004 mips unknown

And the Tivo itself says I'm running 3.1.1c...

So, I downloaded both the 3.0 and 3.01B ISO's from http://www.ptvupgrade.com/support/bigdisk/index.html

At this point, I guess it would be best to stick with the 3.0 version..

Anyhow, following through the post linked to another post, the procedure looks like:
grab the ISO
use an ISO tool (WinISO works fine) to extract the appropriate kernel
ftp the compressed version over to the tivo
extract it on the tivo itself
Find the right place to put the kernel (crystal ball and a sacrifice of a chicken might help here)
(my results of the bootpage command are : root=/dev/hda4 dsscon=true console=2,115200 BASH_ENV=`mount$IFS-n$IFS/dev/hda14$IFS/mnt;echo$IFS/mnt/runmonte`)
Update the boot params
flip the boot kernel
reboot the tivo

Now, you're saying that once I do all of that, I can finally do the mfsbackup/mfsrestore method in order to utilize the new drive?

Not to sound too paranoid, but this is pretty scary since I would now be mucking with the live drive. If I screw up, I'm hosed... is there no way to back the system up or anything (in such a way that the backup actually works) before I go an kill my tivo (and subsequently get killed by my wife)?

It actually sounds much worse than it is. Just read through and understand what you are doing prior to starting and double check your steps.

I had read somewhere that RonnyThunder had enhanced MFS to backup a "classic Monte" drive but he may have pulled it due to killhdinitrd method.

Another good post that describes the process is http://www.dealdatabase.com/forum/sh...ad.php?t=38970

If you unsure that you can do it, another option is get a second drive and start from scratch. That way no mad wife

[JJBliss]

Or, try the tedious but effective

dd if=/dev/hdc /of=/dev/hdd bs=1024

This command will copy the entire drive sector by sector from the smaller drive (mounted on /dev/hdc) to the larger drive (mounted on /dev/hdd).

Once it has completed, running mfsadd -x /dev/hdd will expand it to the full size of the new larger drive.

[wesmoc]

Much worse than it is, eh.. hehe.. ok..

First off, I think I will try option #2 of dd'ing the drive (I was thinking of originally doing that, but figured the mfstools suite would be the cleanest way to go).

Then, once I have a copy on the 120GB drive that works, I'll try option #1 (un-sleeper'ing the drive and killhdinitrd the drive).

Thanks for the input! I'll let ya know how it goes!

[wesmoc]

Originally Posted by JJBliss

Or, try the tedious but effective

dd if=/dev/hdc /of=/dev/hdd bs=1024

This command will copy the entire drive sector by sector from the smaller drive (mounted on /dev/hdc) to the larger drive (mounted on /dev/hdd).

Once it has completed, running mfsadd -x /dev/hdd will expand it to the full size of the new larger drive.

OK.. dd'ed the drive and went out for the afternoon. When I came back, it was done.

I ran mfsadd -x /dev/hda (which happens to be the 120GB drive), and it came back with

/# mfsadd -x /dev/hda
Current estimated standalone size: 39 hours
Nothing to add!

I checked again, and, yes, /dev/hda is the 120GB drive with the 40GB drive being /dev/hdb.

Any clues? Could it be, perhaps, because of the age of the ISO image I have for MFS Tools (Probably from the August timeframe)?

[wesmoc]

I see where I was going wrong.. I needed to type:
mfsadd -x /dev/hda /dev/hda14 /dev/hda15

(when I tried just /dev/hda14, it complained that the number of partitions had to be even)

However, when I do that, it complains that the filesystem format for /dev/hda14 is "Apple_Free". I looked for a way to change the filesystem type from "Apple_Free" to something else (maybe even delete it all together), but I couldn't...

I'm kind of stumped at this point. I might try putting the 120 in the Tivo just to see if it boots up and acts like the 40GB (it would be good to know if, at the very least, I can safely backup and recover the existing drive!)... But, that's just an excercise in futility if I can't get it to see the rest of the drive..

[JJBliss]

Unsleeper it, and try again.

[PlainBill]

OK, let me see if I can explain this to you.

When you copy a drive using the dd command, it copies the partition table. As a result, mfs tools thinks the new drive is the same size as the old drive. Perhaps there is a version of MFS Tools that will notice the difference; in my limited experience I've never found one.

You cannot use the standard MFS Tools to copy a drive hacked by TiVoScripts because TiVoScripts uses both partition sets for the Monte process. There are several ways to get around this, but by far the easiest way is to 'unsleeper' (unmonte) the drive. The first response to your question gave you all the information you need. If you had followed the advice, you'd be done with this by now!

PlainBill

[wesmoc]

Well, if I had done step one, I would have had to have been home. I was out all day, and the dd'ing process could easily run unattended. In addition, I now have a viable backup copy to work with... If I screw that up, it's no big deal since I have the 40GB drive right here on my desk.

But, I see where you are going... I think I will try to un-sleeper the 120GB drive (since it thinks it is the 40GB drive) and make sure I have the process down right. Once I do that, I'll un-sleeper the original 40GB drive, make sure that one works, then backup the drive via the mfstools.

BTW, I discovered that the way to fix the partition problem is to use pdisk to display the partition table (and write it down), then re-initialize the partition table adding everything back in (not including the Apple_Free partition, of course), and THEN run mfsadd -x /dev/hda /dev/hda14 /dev/hda15

[wesmoc]

OK, ok.. so now that I have the backup of the drive that I know works and it has all of the saved shows, I felt more comfortable mucking around with it to un-sleeper the drive.

I figured that if I screwed up the backup, I was ok.. and wouldn't be lynched by the wife and kids for killing the Tivo a week before the holidays.

So, I unsleepered the drive using the steps in http://dealdatabase.com/forum/showth...t=36693&page=1

I got the ISO image and used the 3.1.1c kernel that was already killinitrd'd
And rebooted.

The unit came up fine.

So, since that worked on the backup drive, I've gone back and done the same steps to the original 40GB drive.

The unit came up fine again. Cool.

So.. I'll go back and use mfstools to copy the drive again since this is now un-sleepered and mfstools should work.

[wesmoc]

Perfect. Simply followed the directions to un-sleeper it, then did mfstools backup/restore to the new drive, and viola! Done.

Thanks for the help!