[Philly Bill]

This is pretty much what I thought Sergio. Thanks loads. I figured the log was appended to just like most files.. on the bottom. So the bottom-most 'entry' would be the most recent. The timing marks (or whatever they are) are what confused me. They may just be marks to group certain messages together.. who knows?

NOW that THAT is answered... on to the GOOD news....

As you all read previously in this thread, this whole 'grep' 'logs' thing came up because when I replaced my 40GB with a 300GB and did the tpip command I ended up with only a 64MB swap file. I've had various 'freezes' take place 4 times or so over the last month - and I attribute it to this.

Since then I've done the same thing (40GB to 300GB) two more times, and used the --swapped parm in the (version 1.1) tpip command (also discussed above). Both times resulted in a 192MB swap file and so far - no freezes. The machines are performing flawlessly.

After discussing with Sergio last week we decided to try something. When I originally did the 40GB to 300GB (the first one with the bad swap file) I DID specify the -s 192 in the restore command... so Sergio told me to do the tpip command AGAIN correctly this time.

I did that yesterday and the result IS in fact a 192MB swap file now.

So I didn't have to do it over again.

I'll be watching carefully in the coming weeks to be sure I get no more 'freezes'.

Now that we know how to use tpip correctly I don't guess this announcement means much... but I thought you'd like to know how it worked out.

Thanks Sergio.

Bill

 

[slaponte]

I am glad that worked out. You did the hard work.

 

[JamieP]

My question is this. Do the 'clock/timing' numbers to the left mean anything? Or is the 'current' log entry the one on the bottom?

I believe these messages are coming out of the kernel before the clock has been set. So everything is relative to the time of the boot (00:00:00). Later, the clock gets set and log messages begin to have real time stamps (in UTC, IIRC).

 

[Philly Bill]

I believe these messages are coming out of the kernel before the clock has been set. So everything is relative to the time of the boot (00:00:00). Later, the clock gets set and log messages begin to have real time stamps (in UTC, IIRC).

Ah.... so I could get a set of swap messages with 40 seconds on the stamp, then 39 seconds.. then 41 seconds... and so on... depending on how long the thing took to book up.

Makes sense. I'm convince now that I really do have a 192MB swap. I'll just watch it now for the freezings... :fingerscrossed:

 

[jmrwiseguy]

Trying to upgrade to a 400GB Seagate drive on a S2 DirecTivo. I've tried just about every combination I've read in this thread and others. I have another S2 DirecTivo that I previously upgraded to a 200GB drive with 6.2 and it has been running flawless for months. I've backed up this 6.2 with the following:

mount /dev/hde1 /mnt/dos
mfsbackup -f 9999 -6so /mnt/dos/tivo.bak /dev/hdg

Then I tried to restore the image to the new 400GB drive:

mfsrestore -s 192 -r 4 -xzpi /mnt/dos/tivo.bak /dev/hdf

After it finished I ran tpip using the 1.1 version on the ptvupgrade cd:

tpip --swapped -s /dev/hdf


I've tried with the --swapped and without. No matter what I do I get stuck booting the tivo.

Any ideas?

 

[slaponte]

I don't quite understand how you have devices up there in hdg, hde, hdf, etc, but I will assume I just don't know.

If the mfsrestore finished right, btw with 400Gb you should use "-s 200", then the next thing I would try is download the latest tpip (V1.2) and use

tpip -s -1 /dev/hdf

I really don't know the diff between tpip v1.1 and v1.2, but I like to use the latest just in case. Everything else you are doing (besides the hdg, hde, etc) looks fine.

 

[jmrwiseguy]

I don't quite understand how you have devices up there in hdg, hde, hdf, etc, but I will assume I just don't know.

If the mfsrestore finished right, btw with 400Gb you should use "-s 200", then the next thing I would try is download the latest tpip (V1.2) and use

tpip -s -1 /dev/hdf

I really don't know the diff between tpip v1.1 and v1.2, but I like to use the latest just in case. Everything else you are doing (besides the hdg, hde, etc) looks fine.

Not sure why on this computer it doesn't use hda, b, c, or d. It skips over them even though it only has one drive. Either way, it worked fine the last time I did this with a 200GB Seagate drive. BTW, I did try the "-s 200" originally and it didn't help any.

I haven't had a chance to download the 1.2 version. I'll try that and let you know what happens.

thanks...

 

[azitnay]

If a device ends up on /dev/hd[efgh], it's most likely on a secondary IDE controller. The primary IDE controller (typically built into the motherboard) uses /dev/hd[abcd], but some computers have secondary (often on a PCI card) IDE controllers as well.

I've never had the opportunity to use tpip, but I believe I've seen that if you're using 1.1, you need to also add --swapped as a command-line parameter.

Drew

 

[slaponte]

I don't expect that using -s 200 vs -s 192 will change the behaviour above. But if you get it to create 192Mb swap, you still won't have enough when you need it. The point is to be able to recover on a crash. You need 200.

He does have the --swapped param. Since this isn't working, I figure we should try V1.2...

 

[Philly Bill]

Well on the three I did to 300GB I made backups but just put 'em away... then didn't restore my IMAGE to the new drive.. just did a straight drive to drive.

mfsbackup -Tao - /dev/hdX | mfsrestore -s 192 -r 4 -xzpi - /dev/hdZ

after it finished:

tpip --swapped /dev/hdZ/ <--- I THINK this is right....

Why not try it with the double command and the 'pipe' between...? Skip the restore from your image. See how that goes.

(don't forget to use the -9999 instead of -Tao if you don't want to backup recordings.

 

[azitnay]

(don't forget to use the -9999 instead of -Tao if you don't want to backup recordings.

-f 9999, rather.

Drew

 

[Philly Bill]

Yea.

 

[slaponte]

V1.1 : tpip --swapped -s /dev/<drive>

V1.2 : tpip -1 -s /dev/<drive>

 

[Philly Bill]

Can always count on the pros that have this stuff memorized. LOL.

 

[jmrwiseguy]

Well on the three I did to 300GB I made backups but just put 'em away... then didn't restore my IMAGE to the new drive.. just did a straight drive to drive.

mfsbackup -Tao - /dev/hdX | mfsrestore -s 192 -r 4 -xzpi - /dev/hdZ

after it finished:

tpip --swapped /dev/hdZ/ <--- I THINK this is right....

Why not try it with the double command and the 'pipe' between...? Skip the restore from your image. See how that goes.

(don't forget to use the -9999 instead of -Tao if you don't want to backup recordings.

I tried the following:

mfsbackup -f 9999 -6so - /dev/hdh | mfsrestore -s 200 -r 4 -xzpi - /dev/hdf
tpip --swapped /dev/hdf

When put into my DirecTivo it just hangs when booting.

Then I tried:

mfsbackup -Tao - /dev/hdh | mfsrestore -s 200 -r 4 -xzpi - /dev/hdf

Scanning source drive. Please wait a moment.
Source drive size is 40 hours
- Upgraded to 222 hours
Backup image will be 222 hours
Uncompressed backup size: 177627 megabytes
Backup failed: Backup target not large enough for entire backup by itself.

The uncompressed backup size should easily fit on a 400GB drive. I don't understand what it is complaining about.

When I boot, this is what shows up regarding drives:
hde : 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=15505/240/63
hdf : 781422768 sectors (400088 MB) w/8192iB Cache, CHS=51681/240/63
hdh : 390721968 sectors (200050 MB) w/8192KiB Cache, CHS=387621/16/63
hdg : ATAPI 40X DVD-ROM CD-R/RW drive, 2048kB Cache

hde is the WinXP boot drive
hdf is the 400GB target drive I'm trying to copy from drive h
hdh is the 200GB source drive that works fine now in a DirecTivo

Any other ideas?

 

[jmrwiseguy]

Ok, I think I know partly what is wrong. The error message I received about not enough space got me searching and I found a posting that said you can't expand twice. Thus, If I had a 40GB drive that I backed-up and expanded to a 200GB drive, is it true that I can't backup the 200GB drive and expand it onto a 400GB drive?

I'm going to go back and try to use the original backed-up image to see if that helps any.

 

[jmrwiseguy]

Ok, I finally got it to work. I had to use the original backup from the original drive instead of a backup of a expanded/hacked drive. The reason I didn't want to use the original was because it wasn't hacked so I'm going to have to do that all over again on this drive. BTW, the "tpip --swapped -s /dev/hdxx" worked fine with tpip 1.1.

Thanks everyone.

 

[Philly Bill]

Cool :up: Glad you figured it out.

 

[AllAboutJeeps]

All in this thread! You guys Rock! :up: :up:

Just upgraded my SA S2 40hour with a single 300gig Seagate. Between Weaknees interactive guide and this thread, everything seemed to have gone excellent! I did a -s 210 with the thought that more swap space can't hurt. Used tpip 1.2 and everything seems to be running just peachy.

Thanks again all! You guys are the best!

...danny

 

[RaGINaR]

OK, well I finally got it to work. First you need to get the PVT Upgrade CDROM.

Second: You can use the usual Weaknees Guide information to conduct your backup/transfer of data. The only value that will change is swap space and is based upon your drive. It comes out to be like 1mb for every 2 gigs of hard drive space. For myself I used "-s 300", though I'm sure you don't need that much.

Second, I used the tpip --swap -s /dev/hdY command.

hdX is your Tivo drive.
hdY is your new (bigger) Tivo drive.
This will initialize your swap space so it is usuable.

So I did:

mfsbackup -f 9999 -so - /dev/hdX | mfsrestore -s 300 -zxpi /dev/hdY
tpip --swapped -s /dev/hdY

This basically did a direct copy of my Tivo drive (I'd already made a backup image earlier using the new, bigger drive since I didn't have a FAT32 drive previously) to the new, bigger Western Digital JB300gig drive.

I gave it a 300mb swap drive. and used tpip to initialize it. Works!!!