Odd : -s 192 and TPIP not working...

[slaponte]

Lets see. This was an Series 2 with a 40Gb V7.1b.

I made a backup image of this unit. Then added a 300Gb second drive. THe system came up and worked fine. WHat I am tryong to do now is to make swap 192, using a new restore and TPIP to fix the swap header.

Orig 40 is on hda
New 300 is on hdb
FAT32 with image on hdd
Weaknees Boot CD with LBA 48

If I

mfsrestore -s 127 -r 4 -xzpi /mnt/dos/tivobak/eric40.bak /dev/hdc /dev/hdd

Everything works and Tivo comes up.

If I

mfsrestore -s 192 -r 4 -xzpi /mnt/dos/tivobak/eric40.bak /dev/hdc /dev/hdd
tpip -s /dev/hdc

All commands report ok as above but Tivo won't start, gets stuck in "just a few more minutes"... The backup is small, barely any recordings.

Last thing to try is -s 192 -r 3 but for what I know that should not matter...

Ideas?

[Philly Bill]

I don't get it man. You told me what to do and it worked. :)

After the mfsbackup and mfsrestore is done.... and it reports the new drive sizes and returns the Linux prompt I typed in the tpip command just as you specified. Took like a half second. Then I pulled the drive and put it back into the TIVO no problem :confused:

Think it matters that I'm running 6.2 and you're runing 7.x?


Also (I'm sure this has nothing to do with it) I copied recordings over.. :confused:

[slaponte]

Maybe it is the version, who knows. I gave up yesterday. Yeah, tpip runs in a sec and says the 192 swap space is initialized. No errors. mfsinfo reports the partitions properly. It all looks ok.

Weird.

[winders]

Do the restore without expanding or the "-r 4" switch. Then use mfsadd with the "-r 4" switch to expand the drive. Then run tpip and see what happens...

Scott

[Philly Bill]

Maybe it is the version, who knows. I gave up yesterday. Yeah, tpip runs in a sec and says the 192 swap space is initialized. No errors. mfsinfo reports the partitions properly. It all looks ok.

Weird.

So I'm confused. :confused: Did it work? Or no?

[JamieP]

I did some testing with tpip (both version 1.1 from the PTVUpgrade LBA48 disk and version 1.2 from courtesan.com) and it appears that neither one produces a correct v1 swap header for a series 2 tivo when run with the defaults on an x86 PC.

Strangely enough, If you force tpip to think it is working with a byteswapped Series 1 disk, then it does seem to create a good v1 swap header for a Series 2. With the 1.1 version, add the "--swapped" argument (note: that's two dashes). With the 1.2 version, add "-1". "tpip --version" will tell you which version you have.

My guess is that Philly Bill is running with no swap. DTivo's have more memory thatn SAs (64MB verses 32MB) and may be able to run 6.2 with no swap. 7.1 won't run on a SA without at least some swap.

[slaponte]

Jamie, this seems up the right path. When I first started using the PVT CD I noticed that MFSINFO would not work right. I then realized I had to boot with "swap" to make it run right. I wonder if this chages the way the TPIP in there behaves.

Since I always had the Weaknees CD work for me, I copied TPIP to the FAT32 drive to use the Weakness CD. With the Weakness CD everything has worked except TPIP.

Thanks, this looks very good. I will try first thing tonite.

Philly, what he is saying is that your swap might be bad, and the Tivo (6.2) setsup a default swap space and thats why yours comes up. The way to see if it works or not is to check the logs from the Tivo boot, a non trivial exercise in mounting and decoding. Because I am on 7.1, this doesn't work for me and mine gets stuck.

This all makes good sense. Let me try it on mine.

Jamie, since MFSTools and TPIP are on the PVT CD, if I boot with "swap"(for byteswap) so that mfsinfo and all that works, should I then still use the flags for TPIP?

[slaponte]

And, do you know a quick way for Philly to check his swap status?

I think there is a code for older machine that lets you check out the logs on the screen.

[JamieP]

Jamie, since MFSTools and TPIP are on the PVT CD, if I boot with "swap"(for byteswap) so that mfsinfo and all that works, should I then still use the flags for TPIP?I don't know how this interacts with a byte swapped disk. Is possible that with a byte swapped disk it works ok as is. I didn't try it.

On "the other forum", I posted Todd Millers version of mkswap that adds an -S option to generate series 2 compatible v1 swap areas. I've used that, and it definitely works on a non byteswapped disk. Again, I didn't test on a byteswapped disk. I have never actually used tpip, except for my testing last night.

And, do you know a quick way for Philly to check his swap status?It's easy if you have bash running on a hacked tivo: just look at /proc/swaps or /proc/meminfo. I don't know of a way on an unhacked tivo. You might be able to pull the drive right after it was booted, mount it on a PC, and look through /var/log/kernel or messages to see if there is any indication that swap mounted.

[Philly Bill]

<Twilight Zone Music>

Man, I'm lost. :(

It appears to work ok. I had not mentioned this to Slap earlier but yesterday AM the TIVO 'froze up' watching the Today show. I rebooted and its been fine since. I don't know if the swap file is needed for normal viewing or not.

I'll be happy to do whatever anyone else wants to check into this thing. I don't have FTP access to the TIVO its pretty much standard at this point only with a 300GB hard drive. I wouldn't know how to access the logs.

I would prefer to not have to do it again only cause I recorded a few shows over the weekend I'd like to see.. but I can watch 'em first I guess.

I'm gonna be doing this again this weekend on my dad's DTIVO so maybe we can figure out something before then. If not I'll just do his with the -s 127 option and no tpip.

Let me know if I should try/do something to help out.

Bill

PS: Thanks for translating Jamie for me. My head was spinning. :D :D

[slaponte]

No worries, Bill. In your case the only thing is you might be working with a default size swap instead of the 192. Again, in the unlikely event you need the extra swap space, at worst, you might loose your recordings.

Let me try this tonite, I have the drives setup and everything, I just have to boot and run the commands. Seems I can

- Boot the Weakness
- mfsrestore with -s 192
- check the version of tpip
- run it with the proper flag (--swap or -1)

and be ready to go. By later tonite I can have an answer.

Then you can decide if you want to redo or not.

[JamieP]

No worries, Bill. In your case the only thing is you might be working with a default size swap instead of the 192.Actually, this is false, Either he has swap or he doesn't. If he doesn't have swap, he may get unexplained hangs or other weird behavior when the demand for memory is greater than the amount of physical memory available. Or it might just work fine until he hits a GSOD.

The reason it may be working for him without swap, but not for you, is that he has a dtivo, which has twice as much physical memory as a SA. Also, 7.1 has a bunch of extra stuff like HME and a web server that adds additional memory demand.

Now you translate my geek speak for Philly Bill and I'll double check the translation to see if it is still correct :-)

[slaponte]

Philly, swap is used to move stuff out of memory when you need more space than your memory has. So Jamie says you might NOT HAVE A SWAP right now, but because your machine is a dtivo on 6.2, the need for memory is less and you might survive for now.

I in the other hand have a S2 with 7.1, which requires more memory and thus won't come up without a proper swap.

That would explain your ocasional hang. It would be related to how busy (and using memory) the machine is. When the stuff doesn't fit in memory anymore, the Linux will ask for swap, and since it doesnt find any, it hangs.

Answer is the same : let me try it at home. And again, worst case you loose your recordings. Only change is : you need to fix this. It IS an issue.

[Philly Bill]

LOL@Jamie. :)

Thanks.

I agree. Sounds like a fix is in order. A little shuffling of my season pass for Survivor I to my second TIVO is in order...

Sounds like you guys will figure out what I should do by the weekend on dad's upgrade.

Thanks.

BTW I *DO* want to hack this TIVO and learn more about it as I go along. The upgrade was done at this time mainly so my pops would go seamlessly when he gets here and we don't have to spend the entire week I have to visit with him trying to fix a TIVO. :)

Jamie, if I don't have a swap file.. it sounds like some sort of overload of the available memory could cause a problem like I had yester morning? The one time 'freeze' of my TIVO? I'm not sure what could cause the memory stretch just having the TIVO on.. but I imagine it could have been one of a number of things.

Thanks you guys.

[JamieP]

And, do you know a quick way for Philly to check his swap status?Here's a way to check:

Boot the tivo up. Once it is all the way up, pull the plug and pull the drive. Put the drive in your PC and boot with one of the mfstools isos.
Mount the tivo '/var' partition where the logs live:mkdir /mnt/var
mount /dev/hdc9 /mnt/varYou will have to change hdc if your tivo drive is not the primary master.

Now, grep the kernel logs to see if you see any messages about swap. For example, # grep -i swap /mnt/var/log/kernel
Jan 2 00:00:45 (none) kernel: Starting kswapd
Jan 2 00:00:45 (none) kernel: Activating swap partitions
Jan 2 00:00:45 (none) kernel: Adding Swap: 130044k swap-space (priority -1)This indicates that swap was added, and that it was 130044k bytes. In this particular case I had a 127MB swap, but the same method should work to see if a larger swap was added. If you don't see the "Adding Swap:" kernel message, or the size isn't what you think they should be, then something is probably wrong with your swap setup.Jamie, if I don't have a swap file.. it sounds like some sort of overload of the available memory could cause a problem like I had yester morning? The one time 'freeze' of my TIVO? I'm not sure what could cause the memory stretch just having the TIVO on.. but I imagine it could have been one of a number of things.The TiVo software schedules processes to run periodically. These processes might be loading guide data, managing schedules for season passes, collecting garbage in the database, etc. If one of these processes needs more memory than is available, it will fail. The results of that failure are unpredictable (at least by me). So it's hard to know whether the freeze you saw yesterday was related to a swap problem. Checking the logs is the best way to tell.

[Philly Bill]

Thats cool! :)

Thanks for the detailed instructions. I'll pull it tonight, load it to the PC and let you guys know what I find.

Curious. What does 'booting the TIVO up' and pulling the plug do?

By the way, the TIVO is already up and running at home. I can just pull the plug when I get home and pull the drive can't I? I don't have to do a fresh reboot first do I?

[JamieP]

Curious. What does 'booting the TIVO up' and pulling the plug do?You want to see the logs right after the tivo has 'rebooted' (that is, just powered up). So you need to plug it in and let it start up, then immediately after it is all the way started (that is, once you can get to the tivo menus on your tv), unplug it and take out the drive to examine in your PC.By the way, the TIVO is already up and running at home. I can just pull the plug when I get home and pull the drive can't I? I don't have to do a fresh reboot first do I?A fresh reboot is important. The log files 'roll over' periodically, and if it's been a while since it was rebooted, the information about swap space may no longer be in the logs.

[Philly Bill]

LOL. The answer to the first question answered the 2nd. Thanks. I'll reboot tonight after work sometime, pull the drive and post the results.



You want to see the logs right after the tivo has 'rebooted' (that is, just powered up). So you need to plug it in and let it start up, then immediately after it is all the way started (that is, once you can get to the tivo menus on your tv), unplug it and take out the drive to examine in your PC.A fresh reboot is important. The log files 'roll over' periodically, and if it's been a while since it was rebooted, the information about swap space may no longer be in the logs.

[gdavisloop1]

Hello everybody. I'm the "other" person with the same freezing problem using a DirecTiVo running 6.2. NASA launch this morning was a disaster (at least for my TiVo ;-)

I tried grepping the log for clues, but the commands:
mkdir /mnt/var
mount /dev/hdc9 /mnt/var
grep -i swap /mnt/var/kernel

produced a "no such file or directory" message on the grep command.

So I proceeded to try to re-initialize the swap area. tpip reported version 1.1, so I entered:

tpip --swapped -s /dev/hdc

tpip reported that it initialized a 192MB swap.

And put the drive back in the TiVo.

The results are promising but not conclusive. The recordings I made this morning (of the shuttle launch) freeze up instantly when you try to play them (or more specifically, they re-start at the freeze point), but maybe they were corrupted when recording.

But the good news, so far, it looks like a new recording is working, but I've only been up for a few minutes so its hard to say for sure.

>>> Thank you TiVo experts for figuring this out!

Do you think it's safe to delete the "corrupted" recordings? Or is there a chance they'll go into the free space in a corrupt way?

thanks--
--Gary

[JamieP]

mkdir /mnt/var
mount /dev/hdc9 /mnt/var
grep -i swap /mnt/var/kernel

produced a "no such file or directory" message on the grep command.Darn. I'd swear I cut and pasted those commands so I wouldn't screw them up, but I screwed them up anyway. It's /mnt/var/log/kernel
Do you think it's safe to delete the "corrupted" recordings? Or is there a chance they'll go into the free space in a corrupt way?It should be fine.

[Philly Bill]

LOL. I just logged on to report the same. I'll switch back and try again. Stand by for report.

Bill

[Philly Bill]

Ok, here we go Jamie...

After changing the grep command to the proper path, I got the following (I wrote this down and am retyping because I don't know how to copy from a 'command' session if possible at all.

(below is what comes up after the grep -i swap /mnt/var/log/kernel command)


Jan 2 00:00:41 (none) kernel: Starting kswapd
Jan 2 00:00:41 (none) kernel: Activating swap partitions
Jan 2 00:00:41 (none) kernel: Adding Swap: 65532k swap-space (priority -1)
Jan 2 00:00:40 (none) kernel: Starting kswapd
Jan 2 00:00:40 (none) kernel: Activating swap partitions
Jan 2 00:00:40 (none) kernel: Adding Swap: 65532k swap-space (priority -1)
Bus error


Seem's like a lot smaller number than you had.

I got that Bus error every time I tried it too. May be insignificant?

[slaponte]

Well, I got it working. Here is how :

I booted with the Weaknees CD LBA 48

I did my mfsrestore with -s 192 -r 4

I find out my tpip is V1.1

I did the tpip -s --swapped

I then did mfsinfo and it said everything was corrupted. :(

So then I shutdown. Go to my regular PC and download tpip V1.2. I burn a CD, go back to the Tivo PC, load it into it.

Lets try again :

Boot with weakness CD LBA 48

mfsinfo : everything looks fine. :confused:

I do my tpip -1 -s

mfsinfo : everything looks fine

Shutdown. Install on the Tivo, took about 5 minutes, and is UP!!

Pulled the plug, went back to the PC. Mounted and checked the log. It created some 196000K of swap. ~192Mb I guess.

Back to the Tivo. Booted fine. Close the case, start updates from Tivo service.

You know, this is more like a religious experience. You pray and hope for the best.

[slaponte]

Just saw you message Philly. Looks a lot like you are somehow getting 64Mb of swap created somehow. :confused: :confused:

[JamieP]

Just saw you message Philly. Looks a lot like you are somehow getting 64Mb of swap created somehow. :confused: :confused:Yes, that's the way it appears. This is what you get by default if you forget to specify the -s 192 (or whatever) when you restore.

[Philly Bill]

Yeah, I saw 64k. :(

I know I put the option in properly... but I musta done something wrong. I'll have to redo.


I'm pretty certain I used these commands (with hdX as the orig TIVO drive and hdY as the new 300GB drive:

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

after it finished:

tpip -s /dev/hdZ


I've certainly made my mistakes before though :(

So let's see. I could do this again next week if needed (after I watch two shows I recorded that I can't re-record) but I want to nail it down before this weekend so I can do my dad's with no problems.

I have an extra 300GB drive I'll be using later that I could 'redo' with now for testing I guess. :)

So it seems I can still use the commands above (in red) except I need to be sure I have tpip ver. 1.2? I get that from www.courtesan.com? I downloaded it but the tar/zip file had a bunch of files in there.. readmes and c code and such. Do I just need the one file called 'tpip'?

I am not home to try this, but if I D/L the .iso for PTVupgrades CD can I replace the tpip on there with the 'new one' before buring it to a CD?

After the CD is created with the proper tpip program then I can do the same thing (same commands up above in red EXCEPT to add the -1 switch to the tpip command) and it should work?

Like I said I can try this again tonight using a different 300GB drive to see how it works...



BTW, is it possible to just use the current drive and REDO the tpip command with the new version? <wishful thinking> :)

[slaponte]

Jamie, Jamie... you said before it wouldn't create a default swap! Oh, you mean the mfsrestore will assume "-s 64" if you don't state your "-s" flag... humm...

Anyway, as I said, the mfsrestore "-s 192 -r 4" with tpip (V1.2) -1 got mine working with 192Mb. Go for it, Bill!

[slaponte]

Bill, I downloaded also. You only need the one called tpip. No extension. What I did is I created a directory on the FAT32 where the image backup was and I put it there. That way when I mount the FAT32 drive the latest tpip is available.

I only used the V1.2 because mfsinfo stated bad headers when I used the V1.1. After the reboot, mfsinfo stated all was well, but I ran the tpip V1.2 anyway just to be safe. Couldn't hurt.

[JamieP]

Jamie, Jamie... you said before it wouldn't create a default swap! Oh, you mean the mfsrestore will assume "-s 64" if you don't state your "-s" flag... humm...Yes, that's what I meant. I dunno where the 64MB swap came from. I didn't think any of the tivo startup scripts setup a default swap. But I don't have a dtivo and haven't examined the 6.2 startup scripts.

[slaponte]

Me neither. I have a stanalone S2 and a Humax.

Bill, othe readers : I have no proof that the tpip V1.1 didn't work. The only thing I saw isI ran mfsinfo and it gave me bad headers, so I assumed it could be the tpip. So I went through the trouble of getting the V1.2 from the web site, burning a CD, booting the Linux work box into XP, copying the tpip V1.2 into the directory where I keep the tivo images, shutting down, boot to Linux, mount the fat32 drive...

You might want to give tpip V1.1 a try first. Because after all that, BEFORE running V1.2, I ran another mfsinfo and everything looked ok. So I don't know if I needed V1.2 or not. I am just passing on my experience.

Sorry this got so convoluted.

[Philly Bill]

Strangely enough, If you force tpip to think it is working with a byteswapped Series 1 disk, then it does seem to create a good v1 swap header for a Series 2. With the 1.1 version, add the "--swapped" argument (note: that's two dashes).

Since I'm not gonna be able to figure how to get tpip 1.2 onto a CD maybe this will work? The double dashed '--swapped' argument?

It looks like ggdvisloop did that in THIS (http://www.tivocommunity.com/tivo-vb/showthread.php?t=251430) thread and I was thinking of maybe trying it (unless you guys did and it didn't work and I just overlooked it).

Bill

[JamieP]

Since I'm not gonna be able to figure how to get tpip 1.2 onto a CD maybe this will work? The double dashed '--swapped' argument?

It looks like ggdvisloop did that in THIS (http://www.tivocommunity.com/tivo-vb/showthread.php?t=251430) thread and I was thinking of maybe trying it (unless you guys did and it didn't work and I just overlooked it).

BillI think it should work. slaponte thought he had problems with the 1.1 version, but I don't think the results were conclusive.

[Philly Bill]

Ok, here's what I did.

Per slaponte, I tried running tpip 1.2 off a floppy. Worked fine... indicated all ok. It may well have been, but instead of putting the HD into my normal TIVO I put it into another one that the original image didn't come from... long story. Anyway I had to do a Clear & Delete Everything and that may have screwed me up.

When I did a grep after doing a boot in the TIVO and unplugging, it still only showed a 64k swap.

So... I redid everything.... without copying recordings.

(original TIVO drive was hda - hdX & new 300GB drive was hdb - hdZ)

mfsbackup -f 9999 -so - /dev/hdX | mfsrestore -s 192 -r 4 -xzpi - /dev/hdZ

After it finished I kept using the tpip off the PTV CD - which is ver 1.1 I believe...

I issued this command:

tpip --swapped -s /dev/hdZ



The results of the tpip command indicated (as it had in the past) a sucessful 192k swap created.

I put the drive back in the TIVO and rebooted. Then pulled the plug after finished rebooting and put the drive back into the PC. After booting, I followed Jamie's instructions (above somewhere) about doing a 'grep' command on the drive.

Unlike last night, tonight I showed different results:

grep -i swap /mnt/var/log/kernel

produced:

Jan 2 00:00:40 (none) kernel: Starting kswapd
Jan 2 00:00:40 (none) kernel: Activating swap partitions
Jan 2 00:00:40 (none) kernel: Adding Swap: 65532k swap-space (priority -1)
Jan 2 00:00:41 (none) kernel: Starting kswapd
Jan 2 00:00:41 (none) kernel: Activating swap partitions
Jan 2 00:00:41 (none) kernel: Adding Swap: 65532k swap-space (priority -1)
Jan 2 00:00:41 (none) kernel: Starting kswapd
Jan 2 00:00:41 (none) kernel: Activating swap partitions
Jan 2 00:00:41 (none) kernel: Adding Swap: 196600k swap-space (priority -1)

I assume this did it?

[JamieP]

Jan 2 00:00:41 (none) kernel: Starting kswapd
Jan 2 00:00:41 (none) kernel: Activating swap partitions
Jan 2 00:00:41 (none) kernel: Adding Swap: 196600k swap-space (priority -1)

I assume this did it?Looks good. The smaller values are from earlier boots. The last one is the one that counts.

[slaponte]

Woot!!! Woot!!!!

Bill is up on 192!!! You go Bill!!! :up: :up: :up: :up:


Geez, about time! :p :p :p

[slaponte]

Hey man, put both drives on your Dad's and give him a 600hr Tivo!!! :)

Now thats a son to be proud off!!!!!!!!!

[Philly Bill]

Is there anything that will change this? The drive I did it to will not go into a TIVO for real until later when I redo it... but I'll use this method when I do my dad's this weekend. I'll verify with grep again that the swap on that one is the right size. I'll let it run a few days... then pull it again and check it to see if its changed.

Unless that is meaningless. Once the swap is created is there nothing that can change it?

BTW Sergio, I guess you read I used 1.2 on the floppy (which worked great by the way) but I still only ended up with a 64k swap file... so I did it again with 1.1 (on the CD) and the --swapped option which seemed to work.

I have another issue unrelated to swap file but I'll post that in a different thread in this forum to keep this thread on topic.

[slaponte]

It shouldn't change. You mean the Tivo on a boot or reset or something? Nooooo.

[winders]

My HDVR2 with 320GB WD drive had been freezing up every couple of days or so.

When I set my HDVR2 up, I used mfsrestore to create a 192MB partition and "tpip -s" to "fix" the swap header. Well, I pulled the drive today and checked the log file to see if the swap was being initialized properly. It wasn't. So I used "tpip -1 -s" on the drive to fix it. I rebooted my HDVR2 and then pulled the drive again. The swap is now initializing properly.

We'll see if it hangs anymore.....

Scott

[slaponte]

Another satisfied customer! :)

[Philly Bill]

I guess winders had 1.2?

[slaponte]

I would assume so for the -1 flag.

Right now I think either version will work. It migth depend on the machine/OS (6.2 vs 7.1 etc)...

[Philly Bill]

So if I put 192 in my restore line, how come it says my swap file is 196600k? I guess that is 192 * 1024 which = 196608. :)

Funny, when grepping it says something like:

Adding Swap: 196600k swap-space


That would really be 196,600,000 bytes. It SHOULD say: 192k *OR* 196608 bytes.

LOL.

[JamieP]

That would really be 196,600,000 bytes. It SHOULD say: 192k *OR* 196608 bytes.
The swap is 192MB, not KB (MiB, if you want to be pedantic (http://physics.nist.gov/cuu/Units/binary.html).) I believe that a few blocks are used at the beginning for bookkeeping, which is why it is 196600KB rather than 196608KB.

[slaponte]

192 * 1024 * 1024 : 201326592 bytes

196600 * 1024 = 201318400 bytes

8192 bytes diff : 8K : small overhead. :)

[jshorr]

What changed between your failed attempt and this attempt?


Well, I got it working. Here is how :

I booted with the Weaknees CD LBA 48

I did my mfsrestore with -s 192 -r 4

I find out my tpip is V1.1

I did the tpip -s --swapped

I then did mfsinfo and it said everything was corrupted. :(

So then I shutdown. Go to my regular PC and download tpip V1.2. I burn a CD, go back to the Tivo PC, load it into it.

Lets try again :

Boot with weakness CD LBA 48

mfsinfo : everything looks fine. :confused:

I do my tpip -1 -s

mfsinfo : everything looks fine

Shutdown. Install on the Tivo, took about 5 minutes, and is UP!!

Pulled the plug, went back to the PC. Mounted and checked the log. It created some 196000K of swap. ~192Mb I guess.

Back to the Tivo. Booted fine. Close the case, start updates from Tivo service.

You know, this is more like a religious experience. You pray and hope for the best.

[Philly Bill]

I just did dad's last night. Went without a hitch. Same instructions using 192 and when doing tpip command at the end used the --swapped parm.

Grepped the drive and got the 196MB size for swap file message too.

You guys rock

[slaponte]

What changed between your failed attempt and this attempt?

I was trying to use the PVT CD which asks you if you want to boot "swapped" or not and I was making a mess of it. The only reason I was using the PVT CD was because it had tpip in it. So...

I copied the tpip program to my FAT32 drive and then used the Weakness CD which has always worked for me before.

I can probably get the PVT one to work as well if I get organized, but why mess with sucess. :p

[winders]

We'll see if it hangs anymore.....
Good news!

Since I used the the "-1" option of tpip 1.2 to re-fix the swap header and verified that the 192MB of swap was being initialized, my HDVR2 with 320GB WD drive has not frozen up.

I am glad the problem was a lack of swap versus something wrong with the hard drive or unit.

Scott

[jshorr]

I'd also like to thank everyone for their help. I was able to get everything working on a 300GB drive with 192mb of swap!!

[Philly Bill]

:up:

[slaponte]

It's the thread that wouldn't die!!!!!!!!! :p :p :p :p :p

[Jeff_in_Bklyn]

Memory Statistics:
total: used: free: shared: buffers: cached:
Mem: 44937216 43331584 1605632 0 1011712 29265920
Swap: 201318400 8863744 192454656
MemTotal: 43884 kB
MemFree: 1568 kB
MemShared: 0 kB
Buffers: 988 kB
Cached: 26784 kB
SwapCached: 1796 kB
Active: 19776 kB
Inactive: 13316 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 43884 kB
LowFree: 1568 kB
SwapTotal: 196600 kB
SwapFree: 187944 kB

I get this from TWP info.... looks good, right? :confused: Just want to be sure before I close up the box.

[JamieP]

I get this from TWP info.... looks good, right? :confused: Just want to be sure before I close up the box.Looks like a swap of 192MB to me.

[Jeff_in_Bklyn]

Yippie!! :)

thanks everyone

[Philly Bill]

What is TWP info?

[Jeff_in_Bklyn]

What is TWP info?


The Info Screen in TivoWeb Plus :)

[Philly Bill]

Jan 2 00:00:40 (none) kernel: Starting kswapd
Jan 2 00:00:40 (none) kernel: Activating swap partitions
Jan 2 00:00:40 (none) kernel: Adding Swap: 65532k swap-space (priority -1)
Jan 2 00:00:41 (none) kernel: Starting kswapd
Jan 2 00:00:41 (none) kernel: Activating swap partitions
Jan 2 00:00:41 (none) kernel: Adding Swap: 65532k swap-space (priority -1)
Jan 2 00:00:41 (none) kernel: Starting kswapd
Jan 2 00:00:41 (none) kernel: Activating swap partitions
Jan 2 00:00:41 (none) kernel: Adding Swap: 196600k swap-space (priority -1)

First a question. Then a comment after I hear opinions.

I'm addressing this to JamieP because he's the one that brought up how to use grep to verify the swap file size... but if anyone else has an opinion I'm all ears.

In the example (above) there are *two* sets of messages. I know Jamie told us that the first displays were from earlier log entries and that the last one I highlighted was the most recent.

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?

The reason I ask is because I've seen displays of mutiple messages where the 'timing' marks indicated 00:00:41, 00:00:40 & 00:00:39 for the bottom 'set'. And the swap file in each as follows: the top set: 00:00:41 - swap size 64MB; the second set: 00:00:40 - swap size 64MB; the bottom set: 00:00:39 - swap size 192MB.

Now does the :41 indicate the most recent log entry? Or being at the 'top' does that make it an EARLIER log entry?

I'm assuming the timing marks are meaningless (in this instance) and that the most recent log entry would be the last one (on the bottom) - the one that shows 192MB of swap size.

In other words, IF the output looked like THIS, would the bottom display (192MB) be the most recent? Or the top one? (or maybe I read it wrong and this isn't even possible to display this way):


Jan 2 00:00:40 (none) kernel: Starting kswapd
Jan 2 00:00:40 (none) kernel: Activating swap partitions
Jan 2 00:00:40 (none) kernel: Adding Swap: 65532k swap-space (priority -1)
Jan 2 00:00:39 (none) kernel: Starting kswapd
Jan 2 00:00:39 (none) kernel: Activating swap partitions
Jan 2 00:00:39 (none) kernel: Adding Swap: 196600k swap-space (priority -1)

I know this sounds so confusing, but I'm betting you guys will understand what I'm getting at.

Bill

[slaponte]

Here is the thing :

The command grep does a sequential scan of a file, from begining to end, looking for the string you specified. In this particular case, the command "grep -i swap kernel" searches a file called "kernel" for the string "swap" (I think the -i is disregard the upper or lower case).

So the output comes out in the order it is found on the file. Since kernel is a log, the entries in it are in order of writing, every new line added is added, well, at the end. So they should be in chronological order. The last one should be the most recent one.

Because kernel accumulates, doing this after booting ensures there are no further messages added in there to confuse the issue. The last one in the list should be the last swap message since you booted.

There is probably some process that cleans this file out every soo many days or weekly or something so it won't grow forever.

[slaponte]

Re the timing marks : thats kind of weird. If I run the grep command on a Sun machine I have available, the timming marks are not there. Supposedly, in the output line :

Jan 2 00:00:39 (none) kernel: Adding Swap: 196600k swap-space (priority -1)

Everything after "kernel:" is the line from the file that contains the string you were lookign for. So it almost looks like the left time stemp is supplied by the "grep", not in the log file.

Here is another test for the curious : after doing everything the same (mounts, etc), instead of grep type :

tail kernel

This will display the last 25 or so lines of the file. In the output that comes out (the swap line itself might not be there, these are the final lines writen to the file) you can see if there are time stamps in it or not.

[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.... :confused:


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.... :confused:


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!!!

[pgorbas]

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.I am running into almost the same problem, except my sources are a married pair ( 40gb + 120gb ) and my target a 300GB drive.

It looks like your final solution did not use your previous upgrade at all - so you lost all the recordings on that drive correct? I don't want to do that...

[tripmaster]

So the correct command for 1.2 is:

tpip -s -1 /dev/hdc

?



I did some testing with tpip (both version 1.1 from the PTVUpgrade LBA48 disk and version 1.2 from courtesan.com) and it appears that neither one produces a correct v1 swap header for a series 2 tivo when run with the defaults on an x86 PC.

Strangely enough, If you force tpip to think it is working with a byteswapped Series 1 disk, then it does seem to create a good v1 swap header for a Series 2. With the 1.1 version, add the "--swapped" argument (note: that's two dashes). With the 1.2 version, add "-1". "tpip --version" will tell you which version you have.

My guess is that Philly Bill is running with no swap. DTivo's have more memory thatn SAs (64MB verses 32MB) and may be able to run 6.2 with no swap. 7.1 won't run on a SA without at least some swap.

[slaponte]

tpip --version will report the version you have :

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

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

[naiLS1]

tpip --version will report the version you have :

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

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

I'm going to be upgrading my 40 hour to a single 200 gig HD in a couple of weeks. The instructions for Hinsdale and Weaknees both show using a swap of 127. So in this instance I would NOT need to use tpip--is this correct? From what I'm reading here it's only necessary when I attempt to enlarge the swap beyond 127, correct?

[azitnay]

Right, 127MB is plenty of swap for 200GB, so tpip is not necessary.

Drew

[naiLS1]

Right, 127MB is plenty of swap for 200GB, so tpip is not necessary.

Drew

I appreciate the response! Wish me luck!