# Fixes for MFSTools 2.0 swap problems



## Robert S

You have probably heard MFS Tools 2.0 has some problems associated with it. We now believe we have solutions for those problems.

The core problem is swap space. To get a safe upgrade with MFS Tools 2.0, make sure you use include the option '-s 127' on your restore - do not go higher than 127 or you'll get no swap at all! Avoid dd + mfsadd profiles if possible (useful for saving recordings), a pipe backup|restore with -s 127 is actually safer.

If you upgraded your TiVo with MFS Tools 2.0, you can use the backdoor codes to check your kernel log for swap error messages. See below for a detailed explanation of how to do this by Cpen.

The MFS Tools 2.0 documentation claims that 64Mb is enough for any TiVo to recover from a 'green screen' filesystem corruption error. This is not true. If you go over about 140Gb total storage space, TiVo will need more than 64Mb of swap to recover from a green screen, 127Mb appears to be enough for a 274Gb (largest possible capacity) TiVo to recover.

If your TiVo gets stuck in green screen - reboot loop, you may be able to save it by temporarily using your inactive root partition as emergency swap.

See the next post from me below for detailed instructions on how to do this.

If you are upgrading the A drive on a twin drive TiVo and keeping recordings, you may not be able to use MFS Tools 2.0 to increase swap. See the next post from me for details of how to manually add a swap partition.

If you used MFS Tools with -s 128, and therefore got no swap at all, below are some methods that you can use to activate your swap without reinstalling. Choose the one that suits your circumstances best:

The Linux kernel on the TiVo can only use the first 127Mb of a swap partition, even if you've used -s 512 to try and get 512Mb swap.

*Ways to fix the problem*

There are several ways to fix this problem, pick the one that works best for you.

*1. Use shell access to TiVo to run mkswap directly.*
If you can get a shell on your TiVo, this is the easiest general solution.

*2. Use dd to duplicate existing swap partition*
Simple method, but doesn't increase size of swap available, so doesn't fix green screen issue. Will get you working fast.

*3. Use copy of mkswap on tools CD*
Must have bootable CD.

*4. Modify boot scripts to make TiVo run mkswap itself*
Quite tricky, especially if you don't know Linux, but will work when other methods are unavailable. Won't work on DTiVoes or Series|2.

For the remainder of this guide we shall assume that your new TiVo drive is on Secondary Master and your old TiVo drive (if required) is on Primary Slave.

Some of these methods require access to the TiVo partitions and/or filing systems. You must use a byteswapping boot disk to do this. Byteswapping mode on the MFS Tools 2.0 boot disk
is broken. You can make it work by typing *vmlnodma hdb=bswap hdc=bswap hdd=bswap* at the boot prompt. You may prefer to use a different TiVo boot floppy or CD instead.

*1. Use shell access to TiVo to run mkswap directly.*

Use the shell to type

*mkswap /dev/hda8
swapon -a*

*2. Use dd to duplicate existing swap partition*

From TiVo boot disk do

*dd if=/dev/hdb8 of=/dev/hdc8*

This will only take a few seconds.

This will work even if you used -s to get a larger swap partition, but it will only give you 64Mb of swap, which will be enough to get your TiVo working properly.

*3. Use copy of mkswap on tools CD*

Boot a TiVo boot CD (but not the MFS Tools 2.0 CD) and do

*/sbin/mkswap -v0 /dev/hdc8*

Thanks to Merle Corey for getting this working. This is now a verified method.

(It has been suggested that under certain circumstances

*/sbin/mkswap -v0 /dev/hdc8 130048*

may be required to get working swap).

Options 2 and 3 are probably the only options for DTiVos as you can't get a shell or modify boot scripts on those.

*4. Modify boot scripts to make TiVo run mkswap itself*

[This is a condensed version of the original description.]

You will need both TiVoMad and Dylan's Boot disk.

On boot TiVo (and indeed all Unix systems) runs a script called /etc/rc.d/rc.sysinit (this is broadly equivalent to C:\AUTOEXEC.BAT on a DOS/Windows system). If we add our mkswap command to this file, the swap file will be initialized when the TiVo boots.

The file we want is in the _active_ root partition.

Boot TiVoMad, use Ctrl-C to break out of the upgrade script.

Do

*/mad/edit_bootparms hdc -r*

It will reply 'root=/dev/hda4' (or hda7)

Boot Dylan's boot disk. Mount active root partition

*mount /dev/hdc7 /mnt*

or

*mount /dev/hdc4 /mnt*

edit sysinit

*joe /mnt/etc/rc.d/rc.sysinit*

add the following line on a line on its own somewhere near the top.



Code:


mkswap /dev/hda8

 Save (Ctrl-K then X).
Unmount

*umount /mnt*

Power down, boot TiVo, check logs, return drive to PC, boot TiVoMad's utility disk (Ctrl-C to get command prompt)

Traverse to rc directory

*cd /mnt/etc/rc.d*

delete modified sysinit

*rm rc.sysinit*

replace original version from joe backup

*mv rc.sysinit~ rc.sysinit*

unmount partition

*cd /
umount /mnt*

Power down and replace drive in TiVo.

Most of the credit for the fixes in this thread goes to the contributors below, especially Merle Corey for his work on characterising the mfsfix/green screen problem and identifying -s 127 as the solution.


----------



## mtg101

I just need to clarify something for my upcoming upgrade...

I'm planning to take my single 40GB drive system and add a second drive to it (120GB). If I use MFSTools 2.0 and leave the swap space alone, I should be OK - right?


----------



## Robert S

If you have more than 140Gb of hard drive space in your TiVo, the original 64Mb of swap space does not provide enough memory for the filesystem checker (mfsfix) to repair corruption to the filesystem. If you get corruption, your screen will turn green as mfsfix runs, but rather than fixing the problem, your TiVo will just reboot endlessly. If you get this problem, this post explains how to fix it.

If you are upgrading the A drive on a twin drive TiVo, see the end of this post for important details.

(Note that mfsfix can't fix everything, so you might get stuck like this for other reasons. If you know you increased swap, or you know your TiVo is smaller than 140Gb, these instructions won't help.)

*The Plan*

TiVo has two partitions for storing the system software, these are referred to as 'root partitions'. Only one is active at a time. The other is used when a software upgrade comes in. The inactive root partition is formatted and the new software load copied on to it. The boot block is then rewritten and the TiVo reboots to the new active partition.

Most of the time therefore, the inactive root partition is unused. We will format it as a swap partition and recofigure the TiVo to use it instead of the normal swap partition. Once TiVo has repaired itself, we will return things to the way they were to leave the inactive root partition available for the next software upgrade.

*Do not forget to reverse the partition changes once your TiVo is working again! Terrible things will happen at the next software upgrade if the partitions are not reset!*

We will:


Boot so we can read the TiVo partitions
Identify the inactive root partition
Prepare the inactive partition as a swap partiton
Renumber the partitions
Allow the TiVo to repair itself
Restore the original partition numbers

A. Booting so we can read the TiVo disk

Connect your TiVo's A drive as primary master.

TiVo disks can not be read by a PC because the bytes are written in a different order to that expected by the PC's processor. TiVo boot disks are patched to boot in a 'byteswapped' mode that allows the TiVo data to be read.

Most people these days seem to be using the MFS Tools 2.0 CD. MFS Tools 2.0 has internal support for byteswapping so that CD boots in non-byteswapped mode by default. It offers you the option to boot byteswapped, but this doesn't work. To boot the MFS Tools 2.0 CD byteswapped at the 'boot:' prompt you must type

*vmlnodma hda=bswap*

If you can't get this to work, try Kazymyr's boot CD or TiVoMad's boot CD. If use a different boot disk, hda will be left unswapped. Use one of the other connectors and adjust the commands below accordingly. (We don't currently know how to do this from a floppy, one of the tools we need is only on the CDs).

Series|2 TiVoes are NOT byteswapped. You should be able to boot the MFS Tools 2.0 as normal.

B. Identifying the Inactive Root Partition

The easiest way is to read the boot block.

*edit_bootparms hda -r*

(If you're using TiVoMad, the command is:
/mad/edit_bootparms hda -r )

It will reply with the name of the active root partition, which will be either /dev/hda4 or /dev/hda7 - the inactive root partition will be the other one.

If edit_bootparms is unavailable, you can try to mount the root partitions:

*mount /dev/hda4 /mnt* or *mount /dev/hda7 /mnt*

If you get an error saying 'Must specify filesystem type', you're trying to mount an empty partition, if the prompt comes back with no message, the filesystem has mounted.

You need to confirm that one root partition mounts and the other doesn't. You unmount partitions with:

*umount /mnt* (note umount, not unmount).

If both partitions mount, look at the dates on the files with:

*ls -l /mnt*

The active partition will have newer files.

If neither partition mounts, you haven't booted correctly.

C. Prepare the inactive partition as a swap partition.

Do

*mkswap v0 /dev/hda4*

or

*mkswap v0 /dev/hda7*

D. Renumber the partitions.

*pdisk /dev/hda*

On TiVoMad, pdisk is /mad/pdiska.

If your inactive root partition is 4, type:

*r 8 4
r 5 9*

If your inactive root partition is 7, type:

*r 8 7*

*w* (write partition table)
*y* (confirm, returns you to command prompt)

E. Restore drive to TiVo

Let the TiVo run, it may take a long time, and may reboot occasionally, but it should eventually boot up properly. *Remember, you must complete this sequence, your TiVo is not safe when it recovers from the green screen.*

F. Restore the original partition numbers

Repeat step D above.

You can now safely replace the drive in the TiVo.

Notes

If you want to backup the partition you're about to take over, boot in a byteswapped mode, with a FAT drive attached (the way backups were done before MFS T2), mount the FAT parition as in Old Hinsdale and do:

*dd if=/dev/hdX4 of=/mnt/dos/tivopart.bak*

Similarly, you can backup the partition table with

*dd if=/dev/hdX1 of=/mnt/dos/tivotbl.bak*

This has been tested and verified on all types of TiVo.

Thanks to *gigageek* for working through this properly to document it and proving it works on DTiVoes. See page 10 of this thread for his write-ups, which include so details I've omitted. Thanks also to *dougdmy* for being the first to try the emergency swap idea and reporting that it works.

*Upgrading Twin-drive TiVoes*

There is one case that isn't covered by all the previous discussion: What do you do if you've got a TiVo with the original A drive and a large B drive? If you're on a twin with the original drives, you can just pipe both drives onto the new drive, but you're stuck if the old B drive is to be retained.

You can upgrade by using dd to copy the A drive and then using mfsadd to expand it. This gets you a working TiVo, but doesn't expand your swap. You can just wait for it to green screen (may well never happen) and use the rescue procedure above, but if this is the sort of thing that would worry you, you can manually add a swap partition.

The procedure is very similar to the rescue. Start by dd'ing the A drive on to the new drive. Then reboot into a byteswapping mode (you'll probably want to disconnect the old A drive) as above.

Run pdisk and create a new partition:

*pdisk /dev/hda*

*C
12p
128m*

You'll also be asked for the partition label and partition type. "Linux Swap" and "Swap", WITH the quotes, are the 'official' answers, but TiVo doesn't check this detail.

Swap the partition labels around

*r 12 8
r 9 13*

The TiVoes currently on sale have 13 partitions on their A drives. The commands will be different - C 14p 128m <Return> r 14 8 <Ret> r 9 15 <Ret>.

If pdisk complains 'invalid partition' when you try to create the new partition, see post #7 for a laborious work-around.

Write and exit:

*w
y
q*

Then prepare your new swap partiton

*mkswap -v0 /dev/hda8*

and you can now complete the upgrade with mfsadd as normal:

*mfsadd -x /dev/hdX /dev/hdY*

You should now find your TiVo boots to give you extra space and report a 130 million byte swap partition in the logs.

Thanks to *angra* for working through this one.


----------



## mtg101

> _Originally posted by Robert S _
> Yes, swap file issues only affect changes to the A drive, but this is not the same as having a perfect upgrade.
> 
> You will be vulnerable to mfsfix problems however you do it,


Thanks for your help. However...

You've lost me there I'm afraid - what's mfsfix? I assume it's a daemon that monitors the file system and fixes it?

And MFSTools 2.0 will stop that from running will it? Is there way to avoid MFSTools 2.0 stopping mfsfix, or will I have to use the older tools to avoid this problem?


----------



## Robert S

If you're wondering what this 'swap' that everyone's going on about in this thread is, here's a quick explanation. This post was originally a reply to mtg101's question, but that answer is out of date now anyway.

Virtual memory is a technique used by most modern operating systems including Windows, Windows NT and all versions of Unix including the Linux variant used by TiVo. Basically it allows you to substitute cheap (but slow) hard drive space for expensive (but fast) DRAM by tracking which parts of DRAM are currently in use and copying the unused bits to the disk, allowing that space to be used for something else. When the bit that was copied out needs to be used again, it's copied back into DRAM, possibly causing something else to be copied out to disk.

The most common VM system is called 'paging' where blocks of memory (typically 4kb each) are considered individually. This requires fairly sophisticated hardware so earlier systems used a 'swapping' model where entire processes would be copied to disk to enable other processes to run. All modern systems page rather than swap, but the term 'swapping' is used where 'paging' would be more correct.

The other salient point is exactly how the stuff being swapped out it handled. Windows, for example uses an ordinary file. Yours is called c:\windows\win386.swp if you're running Windows 9x with the default settings. Unfortunately there's a lot of housekeeping associated with accessing a file in a filing system (updating dates and file sizes etc) that isn't really useful for a swap file. So Linux also supports swap partitions, which give the VM module direct access to a linear chunk of drive space without having to go through a filing system.

Series 1 stand alone TiVoes ship with 16Mb of DRAM and a 64Mb swap partition, all other TiVoes have 32Mb or RAM. The 'green screen of death' is a filesystem repair utility (broadly equivalent to ScanDisk) called mfsfix. mfsfix requires 1/2Mb of memory for every (binary) gigabyte of disk space that it needs to check. Therefore as shipped, Series 1 stand alones have enough swap for mfsfix to complete with 150Gb of disk space, other TiVoes have enough for 180Gb. It takes about 4 minutes for the TiVo to realise that it doesn't have enough swap for mfsfix and at that point the TiVo reboots.

If you run mfsrestore with -s 127 you'll get 127Mb of swap, which is enough for at least 274Gb of disk space, which is the most the original kernel can handle. If you use Todd Miller's patched kernel you can go well beyond that. This will require more swap, which is possible, but not straight-forward


----------



## ADent

If you use the older tools, when you run tivomad you can tell it to build a bigger swap parition (it asks if the total drive space is going to be over 140GB). 

If I am not mistaken the old method (MFSTOOLS 1.x & TiVoMad) has been proven to work up to 256GiB (or at least 240GB). 

S2 users of course are limited to just adding a second drive with MFSTools 1.x and you can not reupgrade a unit w/o losing all of the recordings.

There were arguments that a S2 with an added 120GB drive might be OK since they ship with more memory.


----------



## Robert S

Very rarely when you try to use pdisk to create a swap partition manually or try to use mfsadd to expand your TiVo image, you'll get an error suggesting that the disk is full. The solution to this is to use pdisk to rebuild the partition table. Doing this will make the partition table represent the full size of the new disk and will allow pdisk or mfsadd to work.

Normally both pdisk and mfsadd will recognise that the drive is larger than the partition table indicates and this process will be unnecessary.

What you need to do is print out the drive's partition table and then use pdisk to create a blank partition table and then reenter all the partitions with exactly the same parameters as before. The reinitialised disk will show the full capacity of the drive, so the Apple_Free partition at the end will be much larger than it was before.

For a Series 1 TiVo you will need to boot in byteswapping mode to get into the partition table. For Series 2 TiVoes, the MFS Tools 2.0 CD will boot in the correct mode anyway.

We're using Kazymyr's boot CD with the hard drive on primary slave. If you force byteswapping mode (see the first post of this thread), the MFS Tools 2.0 disk should work just as well.

Hit the enter key when you see Boot: This will boot Kazymyr's CD in default mode.

You will be prompted to login as "Root" Type root and hit enter.

If you want want to make a backup of your partition table so you can recover if things go wrong, proceed as follows:

You'll need a mountable partition to write the backup files to. This is the same process you use to mount a partition for writing an MFS Tools backup during an upgrade.

At the linux shell prompt (/#) type *mount /dev/hda1 /mnt*

You can make a text file by typing *pdisk -l /dev/hdb > pdisk.txt*. If you go back to Windows, this file will be C:\pdisk.txt. You can use WordPad to print it out if you wish (Notepad will be confused by the Unix style line terminations).

You can make a backup of the partition table: *dd if=/dev/hdb of=/mnt/tivopart.raw count=32*. If you dd this file back onto the drive it will restore the partition table to its original condition.

Disconnect from the partition with *umount /mnt*

This completes the optional backup phase.

At the next linux shell prompt type *pdisk /dev/hdb*. This gets you into pdisk which is the program used to change your partitions. It will say: Edit /dev/hdb and take you to a Command (? for help):

Type *p* and hit Enter. This will show you the partition table for your drive. WRITE THIS DOWN EXACTLY AS IT APPEARS (At least make sure you have all the numbers correct). If you're working on an A drive, you may have 13 partitions to deal with. If you're working on a B drive, there may be as few as three.

At the command:, give an *i* (Enter) command to initialize the partition table. You will have to confirm that you want to do this by typing *y* (Enter)

Next, give a *C* (capital C) command which will allow you to enter the information you wrote down previously.

Partition 1 is the partition table. pdisk has already set that up for you, so you start with partition 2.

First block: (This number will be the number under "base" for partition 2)

Length in blocks: (This number will be the number under "length" for partition 2)

Name: For an A drive this will be "Bootstrap 1", for a B drive, this will be "New MFS Application". You need to type the quotes.

Type: "Image" (A drive) or "MFS" (B drive)

Do a p command to check the partition you just added, make sure it matches what you wrote down.

Repeat the C command and enter the information for partiton the remaining partitions. The last partition - Apple_Free/Extra is just a placeholder for the unallocated space on the drive, you don't create it yourself.

Do a p command to check the partitions again. The table should look just like what you wrote down. The size of the Apple_Free partition should be much bigger - the difference between the old and new drives, infact. pdisk lists the partition sizes in 512-byte blocks, so if you divide by 2 you get the size of the partition in kilobytes.

After confirming that your newly created partitions look exactly like what you wrote down, do a *w* command. This writes your new partitions into the file. You will have to confirm that you want to do this step by typing *y* and hitting enter.

You will need to quit pdisk and get back to a linux shell prompt by typing *q* and hitting enter.

At the next linux shell prompt, do a pdisk -l /dev/hdb command. That is a lower case "L", not a one. You should find that the partition table looks as it did, except for the enlarged Extra partition.

At this point the partition table reflects the true size of the disk. You should find that pdisk now allows you to create your new partition or that mfsadd expands the image as expected.

Thanks to *mutant* for suggesting the rebuild as a work-around for the problem with creating a new swap partition and outlining the procedure, to *someone whose nick I've forgotten* for suggesting mutant's rebuild would work for the mfsadd problem too and to *at4tivo* for slogging through the rebuild and writing it up in enough detail to be usable by people who've never used pdisk before.


----------



## Cpen

I upgraded my TiVo over the weekend and just checked the (kernel) log files using backdoors.

It read:

"activating swap partitions"
"adding swap:65532 swap-space (priority-1)"

Wohoo! Looks good!

Those that are having problems have reported the following message:

"activating swap space"
"unable to find swap-space signature"
"swapon: Invalid argument" 

I used MFS Tools 2.0 and Hinsdale's "Upgrade Configuration #6" to take my A & B drive from my Phillips 312 and move/expand them (and my stored recordings/content - 3 hours worth recorded on "high") to a brand new (unused) 120 gig hard drive. This debunks an earlier theory by Hi8 stating that "it appears that the problems appear when trying to copy a FULL TiVo".

From what I've seen so far, it appears that anyone that attempted to use the -s 128 to increase their swap size is a good candidate for this swap problem. 

I used the command (from Hisdale's upgrade configuration #6): mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -xzpi - /dev/hdc 

My Hard Drive was a virgin 120MB 5400rpm Maxtor (no prior image on the drive). I followed Hinsdale's instructions, using the MFS Tools 2.0 to boot from a CD that I made with the ISO image (Edit: I was asked by Robert S if I booted into a swapping or non-swapping mode - to the tell the truth, I don't know - whatever Hindale's default instructions said to do, I followed).


Superman (Tiger) where are you!?

P

PS: To check your log file to see if your swap is working:

1. Reboot/Restart your TiVo (It's important to do this, as this is when the swap gets activated. The sucess or failure of the swap activation gets written to a log file that you can review - keep reading)

2. Enable back doors - The Backdoor mode can be entered using the remote. This is done by doing a "Browse By Name" or "Search by Title" or wherever you can get to the Ouija screen... Currently, the only easy way to exit backdoor mode is to reboot the Tivo. After entering this code, you will see "Backdoors Enabled!" appear briefly, and it will return to Tivo Central. You can verify that backdoors are on in the System Information screen. 

1.3 systems: Enter "0V1T" and press Thumbs Up. 

2.0 systems: Enter "2 0 TCD" and press Thumbs Up. 

2.5 systems: Enter "B D 2 5" and press Thumbs Up. 

3.0 systems: Enter "3 0 BC" and press Thumbs Up. 

2.5.2 systems (DirecTivo Only): Enter "B M U S 1" and press Thumbs Up. 

1.5.2 UK systems: Enter "10J0M" and press Thumbs Up. 

3. With backdoors enabled press (on your remote) Clear-Enter-Clear-Thumbsup.

4. You're now in the TiVo Log files. Use the right arrow (the right side of the circular pad on your remote) to get to the "var/log/kernel" page

5. Use page up (channel up on your remote) to jump a page at a time and get to the beginning of the log file(you'll have to press channel up many times).

6. Now - Use page down (channel down on your remote) to review the lines of your log file page by page - the "activating swap" line should appear about 3-5 pages down.

7. To get out of the log file view, press the Tivo button or the left arrow on the circle pad.

8. To then disable the backdoors, reboot/restart your Tivo.

What did you find? What type of Tivo did you upgrade? How did you upgrade (configuration upgrade # from Hinsdale's guide)? What command did you use (did you use -s 128?)?


----------



## Bill Reeves

> _Originally posted by Cpen _
> From what I've seen so far, it appears that anyone that attempted to use the -s 128 to increase their swap size is a good candidate for this swap problem.


Another data point to support this theory. I performed my upgrade last week with the following command:

mfsbackup -Tao - /dev/hdc | mfsrestore -s 128 -xzpi - /dev/hda /dev/hdb

(from the Hinsdale How-To guide, step 10, Upgrade Configuration #3, from a Single-Drive TiVo to New A and New B Drives)

and I just checked my kernel log file and sure enough, the "bad" messages were there.

-- Bill


----------



## mtg101

> _Originally posted by Robert S _
> *AFAIK mfsfix just fixes file system problems. There has been no word of the scope of this problem or possible fixes, but a few MFS Tools 2.0 have been stuck in a green screen (mfsfix running) -> reboot (mfsfix crashed) loop, suggesting it is real (presumably these cases have faulty backups or faulty drives leading to problems that mfsfix tries to fix).
> 
> The only totally safe option at the moment is to use older tools, but there if you go over about 140Gb mfsfix runs out of swap and crashes so you can't safely bless your 120Gb drive and add it to your A drive without increasing swap. *


Thanks for the info. As it's my first upgrade I'll stick to the old tools I think. And I'll leave the original drive alone. Just backup and put on new 120GB drive and expand that. Thus I'll always have the original to do upgrades from in the future. That all sounds about as safe as it's getting to me


----------



## hinsdale

> _Originally posted by Bill Reeves _
> *
> 
> Another data point to support this theory. I performed my upgrade last week with the following command:
> 
> mfsbackup -Tao - /dev/hdc | mfsrestore -s 128 -xzpi - /dev/hda /dev/hdb
> 
> (from the Hinsdale How-To guide, step 10, Upgrade Configuration #3, from a Single-Drive TiVo to New A and New B Drives)
> 
> and I just checked my kernel log file and sure enough, the "bad" messages were there.
> 
> -- Bill *


Realizing the problems with the -s swap file creation in Mfs 2.0, I thought I removed all instances of the -s 128 in the 2.0 How-To several weeks ago. Apparently I missed one, and have removed it. The problem with this parameter was that it not only did not increase the swap to 128, it actually resulted in error with no swapfile.

Having witnessed hundreds of upgraders adding large B drives (since the new 120-160 drives were released at end of last year) without increasing swap and no subsequent pattern of reported unrecoverable GSODS, and also having personally experienced several >140GB machines (standalone and directivo) with unmodified swap file recover from GSOD, I would not be overly concerned about swapfile creation larger than 64MB. Although larger swap certainly doesn hurt, I am not convinced that the swap file limitations for mfsfix to function exist any longer and may have been addressed during TiVo software upgrades above 2.0.


----------



## muchmore44

Hinsdale,

Do you mean that you feel that using Mfs 2.0 and the most recently updated instructions will successfuly allow upgrades WITHOUT any problems related to the swapfile? Sorry if this is a lame question, but befor I complete a TIVO upgrade, I want to be sure.

Thanks,
Muchmore44



> _Originally posted by hinsdale _
> *
> 
> Realizing the problems with the -s swap file creation in Mfs 2.0, I thought I removed all instances of the -s 128 in the 2.0 How-To several weeks ago. Apparently I missed one, and have removed it. The problem with this parameter was that it not only did not increase the swap to 128, it actually resulted in error with no swapfile.
> 
> Having witnessed hundreds of upgraders adding large B drives (since the new 120-160 drives were released at end of last year) without increasing swap and no subsequent pattern of reported unrecoverable GSODS, and also having personally experienced several >140GB machines (standalone and directivo) with unmodified swap file recover from GSOD, I would not be overly concerned about swapfile creation larger than 64MB. Although larger swap certainly doesn hurt, I am not convinced that the swap file limitations for mfsfix to function exist any longer and may have been addressed during TiVo software upgrades above 2.0. *


----------



## Robert S

Please do the upgrade and let us know what happens. We need people to try this and report so that we have a good basis to answer questions like this from. At the absolute worst you'll end up having to redo the upgrade with the older tools, which doesn't take very long.

My prediction is that if you use MFS Tools 2.0 to restore to a brand new hard drive it will not give you a working swap partition no matter what options you choose.


----------



## DCIFRTHS

> _Originally posted by Robert S _
> *
> 
> My prediction is that if you use MFS Tools 2.0 to restore to a brand new hard drive it will not give you a working swap partition no matter what options you choose. *


For example, do you mean two 120 GIG drives?


----------



## Robert S

_Originally posted by DCIFRTHS _
*
For example, do you mean two 120 GIG drives? *

I don't think drive size has anything to do with it. Only the A drive has a swap partition, so it doesn't matter if you use one or two drives.

('Options' is a Unix-ism for command line switches (usually preceded by a - ), and I use it in that rather limited sense.)

People have been talking about whether it's the -s option that causes the problem (and earlier speculation on the role of -p and -z).

I have not seen a report where it can be unequivocably stated that MFS Tools 2.0 has correctly initialised a swap partition.

There have been cases where people have upgraded with MFST2 and got working swap, but so far in all those cases the swap was either copied from another TiVo drive or inherited from an earlier TiVo image on the same drive.

Cpen appeared to state that MFST2 had correctly initialised his swap, but he hasn't replied to my request for more details.


----------



## Cpen

Robert - 

Let me know what else you're looking for and I'll post it here - I'm very interested in figuring out what combinations of hardware and upgrade configurations are leading to problems.

Note - I made changes to my earlier post to clarify where you had questions.

P


----------



## Robert S

I posted the following on the MFS 2.0 Swap Problem?? thread where you first mentioned your upgrade, sorry if you missed it:

_Can you tell us more precisely what you did, specifically:

Was the target disk completely blank or did it have an earlier image on it already?

Did you boot into a swapping or non-swapping mode? _

Ideally you'd write up your whole upgrade process and they we'd see if it worked for other people too. In the mean time, the two questions address two specific possibilities: 
The swap partition may have been inherited from an earlier install (restoring with MFST1.1 and then restoring over that with MFST2 does seem a valid (if slightly boneheaded) way of getting a working swap partition.

The swap bug may be caused by byte-swapping. Most people do their MFST2 upgrades unswapped because that's the default, perhaps the swap initialiser isn't swap aware (and yes, the turn swap does mean several different things in that sentence!)


----------



## Robert S

_Originally posted by Cpen _
*Note - I made changes to my earlier post to clarify where you had questions. *

I see now, too subtle for me, I'm afraid. Sorry about that. Well, I'm completely stumped, I have seen posts from people who appear to have done exactly and got no swap.


----------



## mtg101

As mentioned above, I'm planning on replacing my drive with a single 120GB A drive. Would it be useful to people if I tried it first with MFSTools 2.0 to see if I get the swap problem?


----------



## lemketron

> _Originally posted by Robert S _
> *...I have not seen a report where it can be unequivocably stated that MFS Tools 2.0 has correctly initialised a swap partition.
> 
> There have been cases where people have upgraded with MFST2 and got working swap, but so far in all those cases the swap was either copied from another TiVo drive or inherited from an earlier TiVo image on the same drive.
> 
> Cpen appeared to state that MFST2 had correctly initialised his swap, but he hasn't replied to my request for more details. *


That may well be true. Tonight we re-did the DirecTiVo that I upgrade the other night. The first time we did backup to file, then restore with -s 128 and the swap was bad. Tonight we did another restore without the -s 128. However, since I lack a DSS dish, there was no way to get to the log so to eliminate another lost day of use we also did a "dd" copy of the swap partition from the original 30gig drive.

I heard back later that the machine is working fine now, and has a valid swap.

Sorry this doesn't help figure out whether MFST2 can restore a valid swap or not, but it does establish (for me anway) that -s 128 is bad.

Now if someone can try a backup | restore without the -s 128 to see if MFST2 can make a valid 64MB swap, that would be great.

One other note Robert: We also tried to boot MFST2 with the "swap" option (in order to try the /sbin/mkswap suggestion) but MFST2 wouldn't boot with "swap" on my system. Don't now if this is a known problem or not, but if refused to boot all the way.
--Steve


----------



## Robert S

_Originally posted by mtg101 _
*As mentioned above, I'm planning on replacing my drive with a single 120GB A drive. Would it be useful to people if I tried it first with MFSTools 2.0 to see if I get the swap problem? *

Yes please! Start by trying to replicate Cpen's upgrade, if that works reliably I'll have to rewrite the top post in this thread.

To be a worthwhile test you must ensure that hdx8 doesn't contain a valid swap partition. Obviously the first time the disk will be blank, but on subsequent attempts, dd hdx9 onto hdx8 to make sure it's corrupt.

I'm sure you really just want to get your TiVo working, but if you want to try some variation, I would be interested to see if it makes a difference if MFS Tools runs in a byteswapping environment.


----------



## BareMetal

> Now if someone can try a backup | restore without the -s 128 to see if MFST2 can make a valid 64MB swap, that would be great.


I've worked on three series 2 standalone systems. Two of them i used the -s 128 option on the third one I didn't. The first two have no swap, but the third one does.


----------



## sdunne

I've just moved from a single drive UK model Tivo (Thompson 6020 series) to dual 160Gb Maxtors. I followed the Hinsdale guide, in particular:
Step 7 Option 1) (but backing up to a linux partition) via "mfsbackup -l 32 -6so /mnt/rh73/TivoBackup /dev/hdc"
Step 8 via "mfsrestore -zpi /mnt/rh73/TivoBackup /dev/hdb
Step 10 Upgrade Configuration #3 via "mfsbackup -Tao /dev/hdc | mfsrestore -xzpi - /dev/hda /dev/hdb"

It all seems to have gone ok. System Info is reporting 94 hours 27 mins best quality (330 hours 19 mins in basic). 

I checked my kernel logs and it looks like a new 64Mb swap partition was created, one message in there "Adding Swap 65532k swap-space (priority -1)" suggests.

It's since been rebooted without any apparent problems.

Fingers crossed, but leaving out the -s 128 seems to have worked out OK

Stephen


----------



## klincoln

On Thursday, I successfully upgraded a previously upgraded SA Sony SVR-2000 with MFSTools 2.0. This TiVo began life as a 30hr single drive unit running 1.3 with a locked Quantum 30GB drive. During the "1.3 era", BlessTiVo was used to add a 60GB Maxtor B drive and expand the unit to roughly 100 hours. It ran in this configuration, with OS upgrades along the way to 3.0, until I saw MFSTools 2.0 and 160GB Maxtor drives for $169 at a local computer show.

The upgrade scenario was Hinsdale's UPGRADE CONFIGURATION #5: Any Dual Drive TiVo to New A and New B Drive (replacing both drives), Option #1 MFSTools single step method using four IDE ports and the MFSTools 2.0 boot floppy. The existing drive pair were reasonably full, using 81GB out of an available 91GB. The two 160GB Maxtor upgrade drives were virgin, fresh out of the shrink wrap. No byteswapping was used. The anecdotal evidence so far seems to point towards the -s option being the root of the swap partition problems. Based on this, the -s option was omitted from the MFSTools command line. The following command was used:

mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -xzpi - /dev/hdc /dev/hdd

81GB and 21 HOURS LATER (!), after successful completion of the backup/restore, the new 160GB A and B drives were installed in the TiVo. The unit booted and operated properly. Backdoor inspection of the kernel log confirms that a properly initialized 64MB swap partition is activated:

"activating swap partitions" 
"adding swap:65532 swap-space (priority-1)" 

Since Thursday, I've booted the unit about a half-dozen times, with the swap partition successfully activating each time. All TiVo functions work properly and reasonably promptly. All menus are properly populated and all migrated recordings play correctly. New recordings work fine at all compression levels. Recording capacities are as expected, ranging from 94.5 hours at best quality to 344.5 hours at basic quality. "Save Disk Space" (VBR) is disabled.

My experience would seem to lend support to the growing evidence that MFSTools 2.0 can create a working swap partition provided you don't try and grow the swap partition via use of the -s option (64MB swap partition correctly created on a virgin drive in this case with the -s option omitted). My gut feeling is that this unit would also successfully complete an mfsfix if it suffered file system corruption and a GSOD. I feel that those MFSTools 2.0 upgraded units that are suffering signal 11 exceptions during mfsfix also don't have a properly initialized swap partition because they used the -s option during their upgrades. If someone can supply more info on using mfsassert to trigger mfsfix, I'd be more than happy to test this hypothesis.

Kevin


----------



## DCIFRTHS

klincoln: Very nice report. It's easy to read with great attention to details. Welcome to the forum.


----------



## jhburke

I just spent the last few hours trying to fix the swap on my DirecTiVo 2.5.2 which I upgraded about 5 weeks ago using MFStools 2.0 and the 128M swap option (which of course resulted in an unusable swap partition). I have an old 2 drive Philips DTivo and I upgraded to 2 new Maxtor 120GB drives, preserving all the old recordings. I really haven't noticed any problems despite the lack of swap, but I thought I would try to fix it anyway to try to avoid GSOD...

1. I first tried using the MFStools 2.0 boot CD to run mkswap. The byteswapping option on boot is bad; you have to manually type in "vmlnodma hdb=bswap hdc=bswap hdd=bswap" at the boot prompt to use byteswapping. I ran mkswap /dev/hdc8 without errors ("131xxxK bytes"). I ran swapon /dev/hdc8 and checked /var/log/messages ("Adding swap-space 131064K (priority -1)"). However, when I put it back into the DTiVo, the swap was not used with the same errors.

2. Then I tried using the DTiVoMad boot CD (which does byteswapping by default). Same process, same results - swap partition works in the computer, but not back in the DTiVo.

3. Now I tried to copy the swap partition from my original TiVo A drive to the upgrade drive ("dd if=/dev/hdd8 of=/dev/hdc8"). I know this is only a 64M swap file copied to a 128M swap partition, but I figured "why not?!" since I couldn't think of anything else except to reupgrade and wipe out the last 5 weeks of recordings. It showed no errors, and swapon /dev/hdc8 gave a successful message in /var/log/messages (Adding swap-space 65332K (priority -1)). Now, back in the DTiVo and voila!, I now have a functioning 64M swap file, according to both /var/log/kernel and /var/log/messages via backdoors.

Now, what to think?

Will having a 64M swap file in a 128M swap partition cause problems down the road? So far, so good. I can't tell any difference with the speed of menus or Now Playing list, however.

Maybe MFStools 2.0 initializes the swap file correctly (I never tried to mount it from the computer before running mkswap the first time) but DTiVo cannot use a 128M swap file. This doesn't seem entirely true since in an older swap problem thread someone was able to initialize a 128M swap file by running mkswap from the rc.sysinit file in a stand alone TiVo.

Anyway, just posting my results. I'll let everyone know if I find any problems with my current fix.

John


----------



## klincoln

Thanks DCIFRTHS. I've been a long time lurker who has sponged volumes of valuable information from the generous folks around here each time I've gone thru one of my flurries of TiVo upgrade madness.

To add to yesterday's post, I supposed that an MFSTools 2.0 upgraded TiVo that had a confirmed working swap partition would subsequently complete an mfsfix/GSOD. I was seeking advice on mfsassert to test the theory. Well, I can now report that theory is ONE HUNDRED PERCENT WRONG! After yesterday's post, I put a bash shell up on the serial port via rc.sysinit.author, fired up tivosh, and executed "mfsassert -please" out of /tvbin. The shell console confirmed "MFS filesystem has been marked inconsistent" among the spew from several unhappy threads as the system rebooted...to the desired (?) GSOD. After roughly three or four minutes, it once again rebooted back to the GSOD. While watching this second reboot sequence I was already taking the side off of the PC, and rummaging for the previous A and B drives and my spare IDE cables. I allowed it to continue this reboot/GSOD cycle for roughly an hour before putting it out of its misery. Upon mounting the "dirty" A drive on the PC, the kernel logs confirm repeated signal 11 failures in mfsfix.

So, in my case, even though the swapfile was properly created, the MFS partitions/data were layed down by MFSTools 2.0 in some fashion that indeed gives mfsfix heartburn.

Deciding to copy my original 100 hour configuration back to the new pair of drives again with MFSTools 2.0 and keep recordings, rather than revert to MFSTools 1.1, I looked a little more closely at the MFSTools 2.0 boot floppy environment. My first (21 Hour!) backup/restore was done with byteswapping enabled/DMA disabled (duh)! My comment of yesterday regarding the original backup/restore being done without byteswapping was wrong. My limited Linux skills get lightly sharpened during my TiVo flurries, but then WAY too many sleep periods elapse between uses. After using "hdparm -d1 /dev/hdx" to enable DMA on all four drives, the 81GB backup/restore takes about 90 minutes! This new configuration also worked correctly in all operational respects. And, since this configuration really did result from a non-byteswapped backup/restore environment, I executed the mfsassert command again for the sake of posterity. Been there, done that, same story. The problem with MFSTools 2.0 MFS partitions and mfsfix is not influenced, in my case, by whether the backup/restore environment is byteswapped or not.

Knowing that I can restore it in less than two hours, I'll continue to run this MFSTools 2.0 config with migrated recordings while I wait for a solution to the mfsfix issue. I'll take my chances against a legitimate GSOD until then. Like most of us, I'd be nowhere without these superb tools that are created by people like Tiger. They've MADE my TiVo experience. I'm confident the problem will be corrected.

A TiVo weekend in the A/C from a blistering Washington, DC...

Thanks,
Kevin


----------



## Robert S

klincoln, if you're in the mood to experiment, would you like to try MFS Tools 2.0 with -r 0 (1 Mb block size)? Some people have expressed the hope that this might create a recoverable TiVo, but no-one's tested it.


----------



## jhburke

I had an additional thought about the bad swap files:

I never used TiVoMad to upgrade before, but I understand there is an option to expand the swap file when the combined hard drives are greater than 140 GB to help prevent GSOD from mfsfix. I wonder if someone could provide an image of a good 128MB swap file, which I (and others) could dd onto our mfstools 2.0 expanded swap partition to get a good 128MB swap file. This will be even more important if the 1 MB block size mfs partitions (which might not break mfsfix) is the answer to prevent mfsfix errors, because with the small block size and only 64MB swap, mfsfix will run out of memory. My understanding is that it is not possible to get a bash prompt or to edit rc.sysinit on a DTiVo, so this might be the only way to get a good 128 MB swap. Unless, of course, we fall back to mfstools 1.1. Of course, I guess I could get another blank drive, use the old tools, get a good 128MB swap file, and then dd it to my current upgrade. I just might try that next time I have time (maybe next weekend).

John


----------



## Robert S

That's not a bad idea. If you start with a blank disk, or zero the partition out (use dd to copy /dev/zero over the partition) before running mkswap then a gzipped copy would be tiny. It may well be that any 128Mb swap partition would be a suitable source (subject to byte-swapping considerations).


----------



## klincoln

> klincoln, if you're in the mood to experiment, would you like to try MFS Tools 2.0 with -r 0 (1 Mb block size)? Some people have expressed the hope that this might create a recoverable TiVo, but no-one's tested it.


Robert S, trying the -r 0 crossed my mind as, under the circumstances, MFST2's default larger block size is a strong suspect in my mind for the cause of mfsfix's heartburn. However, given that I want to confine my testing to a 2x137GB target with preserved recordings, I'm hesitant to invest the time to test -r 0 without the known ability to lay down a valid 128MB swap partition to accompany -r 0's smaller block size on this >140GB configuration. Just as jhburke is creatively mulling the same dilemma, I'm in search of a solution. Without a valid 128MB swap partition, I don't hold out much hope for -r 0.

I'll see what comes up between now and next weekend, and maybe give it another whirl then.

Kevin


----------



## Robert S

Hmm, swap partitions, it really shouldn't be that hard to make them, you know?

I think the swap partition on a TiVo is just the same as any swap partition on any Linux system. If this is true, then the following should work:

Boot any normal Linux install (I used Tom's Root and Boot Disk as it's a convenient single-disk Linux.

Create a blank file of the right size. I did

*dd if=/dev/zero of=/mnt/swapfile bs=1024k count=128*

(obviously you'll need something mounted on /mnt to take the file).

swapfile is 134,217,728 bytes long. Is this the right size for a 128Mb swap partition?

Then

*mkswap /mnt/swapfile*

I then did

*gzip /mnt/swapfile*

and it created swapfile.gz at 131kb.

Now, I'm not sure that file is the right size to copy onto your swap partition, so you might want to try the following:

From a swapping environment:

*dd if=/dev/hdx8 of=/mnt/swapfile*

From an environment where you have a *mkswap* command available (Tom's would do nicely)

*mkswap /mnt/swapfile*

and then from a swapping environment

*dd if=/mnt/swapfile of=/dev/hdx8*

If this works (I have no easy way to test it) you could *gzip swapfile* and post it for others to use. If swapfile doesn't compress well, once you know the size of the swap partition you could use dd as above to create a file the same size made of zeros (*bs=1 count=<filesize>*), run mkswap on that and then gzip it.

This is not a risky procedure, as long as the swap file is no larger than the swap partition you won't overwrite anything - the worst than can happen is that the swap won't activate at boot.


----------



## rswift

I, too, am suffering the invalid swap file after using the -s 128 option in the MFSTools 2.0 boot CD. I have a Sony T60 with a Maxtor 160G A drive + Maxtor 80G B drive. Reported recording time is 204 hours, and has been working fine for a couple of weeks. After checking the threads here, noticed the swapfile issue, enabled back doors, and discovered the problem.
My quandry/question is whether to do anything now, or wait until:
A) My DirecTiVo crashes, then I take the original 40G Quantum and re-upgrade, or
B) Some genius figures out how to create a 128Mb swapfile usable by TiVo with support for fsfix.

Is it worth trying to copy the 64Mb swap file from my original drive onto the new A drive into the 128Mb partition?
I'm not sure I understand the risk of running without a swapfile, vs using a 64Mb swapfile in my 204 hour TiVo. Can 64Mb swap handle a TiVo with less than 140Gb? If so, maybe I should downgrade to just the single 160G Maxtor. I haven't read anything so far that pinpoints the cause of the fsfix, sigma 11 error, but something gave me the impression that may be related to having insufficient swapfile space for large capacity TiVos.

Thanks to all who've made the upgrades possible. The added capacity is well worth any hassles in opening the box and copying the drives.

rswift


----------



## Robert S

The swapfile issue and green screen recovery aren't linked in your case. It is true that increased swap space is necessary for earlier versions of MFS Tools and earlier versions of TiVo OS, that no longer applies.

There is currently no known way to make a TiVo that can recover from green screen if it's been upgraded with MFS Tools 2.0.

Copying your 64Mb swap partition from your old drive is a good solution for now. (Unless you'd like to try the swap file method I posted just above you, that post was written with some Linux knowledge assumed, I can explain it more carefully if you're interested.)

If you want a 'safe' TiVo (ie, green screen recovers) you will have to repeat the whole upgrade with pre-MFST2 tools - or wait for a fix for MFST2 problems.


----------



## rswift

Any guess as to the issues with running without ANY swapfile?? Everything seems to be working with no issues right now. Maybe it's because I haven't let the new drives start getting really full yet. My assumption would be that the swapfile might become very important as the lists of Now Playing, Season Passes, etc. start growing very large, and TiVo needs more memory space to play with the lists?? 
Thanks for the offer. I've not played with Linux at all, and have limited knowledge of UNIX, mostly Solaris. My first inclination is to dd the old swapfile into the new swap partition.
One thought I had is that if the new swap partition created with the -s 128 option is just slightly too small, even by a byte or so, will a properly created 128 Mb swapfile necessarily fit into the space? Not knowing exactly what the -s option really did, it's hard to predict. In my gut, I fully expect to have to re-upgrade using my old 40Gb original TiVo disk, so I've been copying to VCR most of my "must save" shows. YUK!~
Thanks for the help.
~rswift


----------



## Robert S

It appears that the problem with the missing swap relates to the program guide functions rather than the recording/playback functions (which are mostly handled in hardware). On UK TiVo's the missing swap prevents TiVo from making daily calls, on US machines it just seems to slow everything down (~24hour indexer runs).

On the space issue, my suggestion above was to dd the current swap partition to a file on your hard drive, therefore when you copy it back it will be precisely the right size. It would be nice if you could validate that, but copying your 64Mb swap partition over would make your problems go away very safely.


----------



## rswift

I may have to wait until next weekend to play with any of these new ideas. I took the day off work today, but can't do that again for a bit. Let's hope a real fix to this, and the GSOD problem are discovered and posted soon. I'm a bit nervous now.
On an unrelated note, I've had smoke coming out of my TiVo on two occasions, yet the thing still lives on! I fried the original TiVo Quantum drive while copying it the very first time. One of the IC's on the IDE circuit board glowed white hot and smoked out. Thought it was toast, but replaced the little circuit board on the back of the drive with one off of a new spare Quantum, and darned if it didn't come back to life. Then, I smoked the motherboard while replacing the internal fan (trying to make TiVo run cooler) and while the fan supply got fried (I now use power from the 4pin hard drive connectors) the TiVo still lives. 
Needless to say I open the cover of my T60 with much trepidation...


----------



## BareMetal

> _Originally posted by rswift _
> *Any guess as to the issues with running without ANY swapfile?? Everything seems to be working with no issues right now. Maybe it's because I haven't let the new drives start getting really full yet. My assumption would be that the swapfile might become very important as the lists of Now Playing, Season Passes, etc. start growing very large, and TiVo needs more memory space to play with the lists?? =*


My experience with no swap, is a series 2 tivo that starts shutting down services and leaves me with a grey screen every other day. I just need to find some time to fix it..


----------



## Ivor

Robert S said:

"swapfile is 134,217,728 bytes long. Is this the right size for a 128Mb swap partition?"

From http://www.mcc.ac.uk/Documentation/linux-doc/LDP/sag/x1762.html:

"The Linux memory manager limits the size of each swap space to about 127 MB (for various technical reasons, the actual limit is (4096-10) * 8 * 4096 = 133890048$ bytes, or 127.6875 megabytes). You can, however, use up to 8 swap spaces simultaneously, for a total of almost 1 GB.

With newer kernels and versions of the mkswap command the actual limit depends on architecture."

Could this be the cause of the problem, i.e. MFS2 *is* creating a 128Mb swap file/partition, but TiVo is unable to recognize it because of kernel/hardware limitations?


----------



## enigma2175

From the mkswap man page:


> It is roughly 2GiB on i386, PPC, m68k, ARM, 1GiB on sparc, 512MiB on mips, 128GiB on alpha and 3TiB on sparc64.
> Note that before 2.1.117 the kernel allocated one byte for each page, while it now allocates two bytes, so that taking a swap area of 2 GiB in use might require 2 MiB of kernel memory.


It sounds like the tivo kernel is new enough to use 2 bytes per page, and that swap partitions can be up to 2 GiB. Maybe I'm wrong, and who knows what TiVo did to the kernel, but I think we're safe in that regard. However, it might be wise to create 2 64MB swap partitions and use them both (or even better, have one on your second disk, better performance.)


----------



## Robert S

I don't know if this applies to the version of Linux running on TiVo. It certainly might apply to the version on the Tom's Root and Boot Disk I used (quite an old one, something like 1.7 (of TR&B)).

mkswap did say something like 'truncating swap file to ' and gave a number that I think did start with 133. That was what got me paranoid about file lengths, wondering if dd had created a file that was too large for the TiVo's swap partition.

TiVo are unlikely to have fiddled with the VM on their kernel. I would think a swap partition create the way I suggest would work.

It's not easy to create another swap partition on your B drive as that drive will be full of MFS partitions. TiVo doesn't need the speed of multiple swap partition.

I do wonder, though, if you needed emergency swap for a mfsfix whether you could set up a swap file on /var.

However, it does seem that 64Mb of swap is plenty for TiVo running later than TiVo OS 2.0 and it's only when you get no swap at all that people seem to have real problems.


----------



## enigma2175

Yeah, a swap file in /var/ might come in super-handy. However, I generally don't have much room in /var and it is getting smaller all the time. But a simple swap file rather than a partition might make it easier for some people to get their TiVos running again.


----------



## Ivor

I have a Thompson (UK) TiVo with factory fitted 30Gb and 15Gb drives which I want to upgrade to 2 x 120Gb, probably this weekend. Since I'd prefer to have partitions with 1Mb blocks and an increased swap file (to avoid repercussions with fsfix), I don't mind experimenting a bit. I'll try MFStools with the -r 0 and -s 128 options, followed by Robert's procedure above, and let you know what happens.


----------



## Robert S

Unfortunately we don't know that -r 0 fixes the GSOD problem and I don't know how to run mfsassert without a shell on the TiVo. Can you add *mfsassert -please* to the start up script the same way I added mkswap? The system should then reboot and green screen. (Does that sound right klincoln?)


----------



## Ivor

OK - Once I've confirmed I've got a working 128Mb Swap file, I'll add *mfsassert -please* to rc.sysinit and see if it recovers.

Question - when fsfix finishes repairing a partition successfully, does it usually reboot the box or just continue with startup? If it reboots, I'd need to interrupt the process at some point to prevent getting into a perpetual loop <break - fix - reboot - break - fix - reboot ...>.


----------



## Brad Bishop

I went back last night and checked my DirecTiVo which I had upgraded with a 80GB drive. It looked fine as far as the swap file goes. I did notice, though, that it was at 64MB instead of what I had been reading here (128MB). I understand what swap files do but I am left wondering if there's some great increase in performance or need for a 128MB swap file.

Also, I'm thinking about taking out the 80GB drive and giving it to my daughter (she's building a PC) and putting a 120GB drive inside it. I remember reading a while ago that TiVo would slow down noticably with drives over 100GB. Is this still an issue or is it related to the swap file size or it being corrupted?

Thanks,

Brad


----------



## Robert S

Ivor, you'd probably need to catch it on that first reboot and reset the sysinit before letting it green screen.

Brad, I don't think swap size affects the user speed I upgraded with TiVoMad and went to 128Mb and that was noticably slower than the original 40Gb config. That drive then died and MFS Tools 2.0 came out while the drive was being replaced. With MFS Tools 2.0 the TiVo feels very similar to how it did with the 40GB despite now being a 120 and having 11 pages in NP, even with no swap at all! The problem with no swap was that the indexer got stuck, not that the TiVo was unresponsive.

I think you should be find with 64Mb of swap, but there are several methods in this thread for fixing any swap problems you may have.


----------



## Cpen

I upgraded to a single 120GB Hard drive. I've noticed no change in speed - more importantly, neither has my wife (beleive me, when she knows I've been monkeying with something, she's quick to let me know if I broke it or made it worse).

In the absence of the swap file problem (I don't have the swap problem - did not use -s 128), I think the only real slowdown you will see is in some "live" calculations made by TiVo - For example, the Season Pass manager - it may take much longer to calculate changes/additions as it has many more scenarios and data to sort through to calculate available space, potential conflicts, priorities, etc. It's this kind of live calculation that will get slower with more available/stored information to take into account! (I don't have enought season passes, wish lists, etc to have this get noticably slower, but with the new hard drive, I'm well on my way).

One live process that probably wont be effected is searching for programs to record. You're still working with the same amount of guide data (2 weeks). 

I'm guessing that the swap file problem caused MAJOR slow downs because TiVo's indexing engine used the swap file to speed up indexing. Without the ability to index, a bunch of stuff probably get hosed - Program Guide, searching for programs to record, etc.


----------



## deek_man

I upgraded my Phillips HD112 about three weeks ago and just checked the (kernel) log files using backdoors. 

It read: 

"activating swap partitions" 
"adding swap:65532 swap-space (priority-1)" 

I guess that means everything is ok.

I used MFS Tools 2.0 and Hinsdale's Upgrade Configuration #2 (dated July 8, 2002) to restore my original 14 hour drive backup on to a virgin 100 gb Maxtor and I also added a second virgin 100 gb Maxtor.

The restore command I used is as follows: 

mfsrestore -zpi /mnt/dos/tivo.bak /dev/hdb 

My original backup was made using: 

mfsbackup -6so /mnt/dos/tivo.bak /dev/hdc 

I used the following command to expand the two drives:

mfsadd -x /dev/hdc /dev/hdb (note: no -s command)

I now have a 250 hour machine and have had no problems that I'm aware of over the past several weeks of use. Hope this helps.


----------



## Robert S

It's actually the mfsrestore command that affects swap, by the time you get to the mfsadd stage, your swap is already set up.

Anyway, thanks for the input.


----------



## deek_man

Sorry about that. I know where to plug in the cables but my understanding is a little superficial The restore command I used is as follows:

mfsrestore -zpi /mnt/dos/tivo.bak /dev/hdb

My original backup was made using:

mfsbackup -6so /mnt/dos/tivo.bak /dev/hdc

Swap is ok and box works great (see previous post). Hope that's a little more helpful.


----------



## Ivor

Update:

I started my upgrade yesterday, having first made and tested a divorced backup of my original drives.

*mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -r 0 -s 128 -xzpi - /dev/hdc /dev/hdd * was used to copy my original a and b drives to the new ones using standard sized blocks and an expanded 128Mb Swap partition.

As expected the swap partition signature was not recognized by TiVo, and when the new drives were placed in the system this resulted in a perpetual reboot/GSOD/pause/reboot loop.

The disks were returned the disks to my PC to try and fix the swap partition which was expected to be found on /dev/hdc8.

TiVoMad disagreed, however, giving the following:


Code:


Partition check:
 hda: hda1

 {my Windows hdd}


Code:


 hdc:Signature 9214, be16 Signature 1492
Blocks in Map - 10
 mac st=1 sz=3f name='Apple' t='Apple_partition_map' bim=10
 hdc1 mac st 51ff040 sz=1000 name='Bootstrap 1' t='Image' bim=10
 hdc2 mac st=5200040 sz=1000 name='Kernel 1' t='Image' bim=10
 hdc3 mac st=5201040 sz=40000 name='Root 1' t='Ext2' bim=10
 hdc4 mac st=5241040 sz=1000 name='Bootstrap 2' t='Image' bim=10
 hdc5 mac st=5242040 sz=1000 name='Kernel 2' t='Image' bim=10
 hdc6 mac st=5243040 sz=40000 name='Root 2' t='Ext2' bim=10
 hdc7 mac st=5283040 sz=40000 name='Linux swap' t=Swap' bim=10
 hdc8 mac st=52c3040 sz=40000 name='/var' t='Ext2' bim=10

 hdc9   } various MFS regions
 hdc10  }
 hdc11  }
 hdc12  }
 hdc13  }
 hdc14  }

 hdc15 ... name='Extra' t='Apple_Free' bim=10
 hdc16

 {blank}

I haven't had a chance to look at my original drives again, but it would seem that the partition labels do not match their contents. The log files I expected to have found in '/var' were all on hdc9; hdc8 was unmountable and hdc7 appeared to contain a root directory rather than a swap file. This is about as far as I got before I had to stop.

Any ideas why the partition names appear to have changed?

Ivor.


----------



## Robert S

I think this is just the rather confusing layout of the boot-up partition table list. If you use pdisk you'll see the labels are correct, and your experiments with mount also verified it. (7 is root, 8 is unmountable because it's swap and 9 is var.)

If you look closely you'll see that the first partition (Apple_partition_map) doesn't have a number and hdc16 doesn't point at anything. Perhaps on this list the partition names are at the end of the lines and wrap around to the beginning of the next line on an 80 col screen?


----------



## Ivor

That would make most sense - in fact it seems quite obvious now that you've pointed it out, I'm surprised I didn't think of it! 

In any case, I'm about to revisit fixing the swap file shortly. Wish me luck!


----------



## Ivor

Robert was right - pdisk displays the partitions correctly, the version shown at boot up was what confused me! Anyways...

The new A disk was removed from my Tivo and rc.sysinit was modified to add mkswap /dev/hda8 at the start of the file. The disk was then returned to the TiVo and the box rebooted.

Mkswap ran and the swap file was created successfully (from the kernel log at next reboot):
_
mkswap: warning: truncating swap area to 130752kB
Setting up swapspace, size = 133885952 bytes
...
Activating swap partitions
Adding Swap: 130684k swap-space (priority -1)
_

So far so good, but then after a while it continued with:
_
Time set to: Thu Aug 8 22:58:36 2002 
Have a nice day. 
Checking for additional disk... 
hdb: Generic ATA management 
Starting EventSwitcher... 
Filesystem is inconsistent - cannot mount!	
Writing 207040 bytes to OSD at address 0	
Filesystem assert: cbMap >= sBucket at fszone.C line 170 in FsZone::FsZone(bool, enum FsZoneOwner, long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, bool = false)
Filesystem flagged as inconsistent! 
Tmk Assertion Failure: cbMap >= sBucket	
FsZone::FsZone(bool, enum FsZoneOwner, long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, bool = false), line 170 (fszone.C)
Tmk Fatal Error: Thread main <78> died due to signal -2	
_

at which point, following a few seconds of GSOD, the box reboots...

Back to the drawing board.


----------



## kingmiwok

I upgraded a series 2 AT&Tivo 40 G to a 120/120 with MFS2.0 about a 5 days ago. Unfortunately I used the dreaded -s 128 option and did not discover the swap problems discussed here untill afterward. Dang.

Symptoms: It boots OK and will run for about a day, then I get a UI lockup. It keeps recording though, I just can't get menu control. After reboot it runs fine for another 24hr or so.

I have every reason to believe I have the swapfile problem, but when I access the logs with the backdoor, I do not actually find the....

"activating swap space" 
"unable to find swap-space signature" 
"swapon: Invalid argument" 

....entry. Actually, I can't find anything listed on the swap file activation? Am I looking in the wrong place? var/log/kernel, right? 

Is it significant that I can not find this in the log file? I should find it within the time-area for the most recent boot, correct? What other activity in in the log in the same general area?

Any input would be apreciated.

Note: I did find, in another log file, a line that stated (something like) "swap file size 0000000". All the other files/partitions listed had significant file sizes.

Thanks.


----------



## Robert S

You'll see it fairly early on in the boot sequence, the date will be in January because the clock has not been set at that point. There will be three lines of error messages if it fails, but just one logging success.


----------



## Ivor

kingmiwok - if you are going to take the drives out anyway to fix the swap file, you might find it quickest to use the TivoMad or Dylan's Boot disk to mount the /var partition (number 9 on the Tivo A drive), load the kernel log into an editor and then search for 'swap'. As Robert says, it should be a few lines before the box corrects the date and time.

The swap file is easy enough to fix by putting


Code:


mkswap /dev/hda8

 at the start of the */dev/hda*X*/etc/rc.d/rc.sysinit file* (where X is either 4 or 7 depending on your config). See Robert's post at the start of this thread for full details.

--oo0oo--

I completed my second rebuild earlier this morning after running
*mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -s 256 -xzpi - /dev/hdc /dev/hdd*
to create a drive with a 256Mb Swap partition but leaving out the -r 0 parameter [standard block sizes]. I then got TiVo to recreate it's own swap partiton by adding *mkswap /dev/hda8* to rc.sysinit as above and tested it by running a full program call. This seems to be working fine [no GSOD] I'm not going to tempt fate by running *mfsassert -please * on this system despite the larger swap file, since I'm fairly certain this would fail.

Interestingly mkswap did use the full 256Mb allocated to it, although the partition is definitely 256Mb and the MFST2 readme suggests it could use up to 511Mb. Regardless, it is still using the same 133885952 bytes as before, just short of the original 133890048 bytes limitation for early versions of linux...

*Thanks to everyone involved for all their help!* 

Ivor.


----------



## kingmiwok

Thanks for the replies/advise. Much appreciated. I'll tackle it this weekend and report anything out of the ordinary. 

Slightly OT... I noticed you guys are from the UK. Many of the posts here are, which leads me to believe (incorrectly?) that Tivo may be more of a phenomenon in the UK than in the US. 

In the US there is somewhat of a name recognition for Tivo, but it is hardly a household term. Among my closer friends (mostly computer geek types here in Silicon Valley), NONE have a Tivo. And even though you can't get me to shut up about the virtues of Tivo if asked, I can't get them to take the plunge and get one. It's almost as though they don't get why it's better than their VCR, or don't care. They seem to prefer to watch DVDs they have bought/rented. 

I think maybe they see it as just another unwanted distraction competing for their time. We are all in our 30s+. Maybe it's more popular with a younger crowd, but I don't believe so.

Is Tivo huge in the UK? Lots of name recognition with the general population? (I have a fascination with why some products take off and others flop, or never get broad acceptance. Yet will be very popular elsewhere.) 

Again, thanks for the tech help.


----------



## Ivor

> Slightly OT... I noticed you guys are from the UK. Many of the posts here are, which leads me to believe (incorrectly?) that Tivo may be more of a phenomenon in the UK than in the US.


This thread http://www.tivocommunity.com/tivo-vb/showthread.php?s=&threadid=70772 suggests there are about 35000 TiVo users in the UK and about 422000 worldwide. That's maybe just over 1 box per 800 households here which would explain why I don't know anyone else who has one... The UK board can probably account for this better than I can.


----------



## kingmiwok

Hmmm, something is not working. 

I tried fixes 2 and 4 with (I think) no luck. Tivo is up and running again, but I think my swap file is in the same condition as beforehand and I'll have a lockup in a day or so.

Note: I am not Linux savvy at all, but I do understand what the commands are supposed to do. I'm vcomfortable with DOS so working from a prompt does not bother me.

In a nutshell, 
I boot on MadTivo disk and try to run edit_bootparms /dev/hdc -r 
I get "file not found" (or whatever it says exactly)

If I try to mount a drive from a Dylan boot, I get a variety of responses, none completely positive. It often wants to know the file system type. 

I tried to dd over the 64M swap from the orig Tivo drive and the reply I got back was
0+0
0+0
That seemed wrong.

I notice during boot that it does not read the partitions and can not identify the file system type. It finds the drives OK though.

Question: At the beginning of this thread, for repair method 2, is the dd command correct? States going from hdb8 to hdc9. Should be hdb8 to hdc8, yes?

So if it's possible to guide me a bit... what am I doing wrong? Thanks.


----------



## Robert S

Yes, well spotted, the swap partition is number 8, of course. You can stare at these things for ages and not see them, you know?

Assuming your working drive is on hdb and your new drive is on hdc your *dd* command would be

*dd if=/dev/hdb8 of=/dev/hdc8*

It should say something like 128 records transferred.

edit_bootparms is in the mad directory on TiVoMad, so you need to do

*/mad/edit_bootparms ... *

(I've fixed this in the top post too).

*mount* should give no response if it completes. If it asks for a filesystem type you can take it you're either mounting the wrong partition or a byte-swapped one, Linux can auto-detect FAT, Ext2 and NTFS partitions.

Thankyou for your comments, hope things start working for you soon.


----------



## rswift

> _Originally posted by kingmiwok _
> *
> I tried to dd over the 64M swap from the orig Tivo drive and the reply I got back was
> 0+0
> 0+0
> That seemed wrong.
> *


Kingmiwok, that is exactly what happened to me yesterday. I dug out my original TiVo A drive and slammed in my 2 new TiVo drives, expecting to do a 5 minute dump of the old swap onto the new partition, but got the 0+0 in and 0+0 out message just like you did.
I had all the drives on a second controller card , and used 
dd if=/dev/hde8 of=/dev/hdg8, where I connected the original TiVo disk to the primary master on the second controller, and the new TiVo drive (with the bad 128M swap partition) as the secondary master (and the new TiVo B drive on the secondary slave ). 
I used the MFSTools 2 boot CD, and all drives were recognized on bootup, so I have no idea what the problem was.
I'm not familiar with Linux, either, so rather than risk doing something bad to my original disk (I have no backup image), I just bailed out, hoping for some help or suggestions online.
My TiVo started acting wierd on Saturday am, rebooting 6 times in fairly rapid succession. It would work for about 5-20 minutes between reboots, then go again. It seems to have fixed itself, or at least settled down for a bit. Its been up for about 36 hours without any issues.

Any new info or suggestions appreciated. 
rswift


----------



## kingmiwok

Robert S:
Thanks for the reply. Based on your comments and what has happened, I have the general feeling that my drives are not being detected correctly when I boot Linux. I'm thinking its not running the commands, mount or dd, etc because it is not seeing the drives in their complete form to begin with. 

For example, cd'ed around a bit and spotted the edit_bootparms in the mad dir. It still blew me off when I tried to run it! 

I'm not sure why, but maybe my motherboard settings are confusing things.
I think I'll retry with everything dummied down, or do it on another computer where I'm not afraid of messing up the BIOS settings. (I'm always anxious about changing settings on a computer I need for other "real" work.)

rswift:
I feel your pain. I'm doing more rapid reboots now after trying to fix it. Nice. I'm backed though, so I feel a fairly safe in trying things without paying too bad of a price.

My only recommendation it to do what I mentioned above. Maybe try it again with a very simple computer setup. No add-on second controller card, no cards in the slots, the absolute minimum. I think you want HD detection turned off in the BIOS as well. Look at your boot sequence very closely too. Even though my boot was detecting the drives as a physical device, it had lots of comments that indicated that it was not reading the FATS and partitions completely. See if you're getting those too.

I'll post up any success/failure. I'll try to get to it within the next couple days

If it does not work for me, I'm going give up the programs I have recorded since the upgrade and redo the whole process. I was interested in learning a little bit more about the inner workings and fixing the swap directly, but it's becoming a drag. My limited linux skill are really beginning to show.


----------



## rswift

thanks, kingmiwok. I probably won't crack the cover again until the weekend rolls around, or at least Thursday. I looked at the boot sequence very carefully and didn't see anything that I thought was troublesome. I used the exact same configuration when I copied and expanded my original TiVo drive that I'm trying to use now to repair swap, so I'd think that I would have run into problems the first time around.
I'm also curious as to when it's necessary to boot into byteswapped mode. I tried that with the MFSTools CD and got an error and freeze. Had to reset the PC.
Thanks again for the response.

rswift


----------



## jhburke

Rswift:

I had success copying the swap file by booting into byteswapping mode. The easiest way to do this is to boot from the older MFSTools disk (i.e. Kazymir's Boot Disk). Byteswapping mode is broken on the new MFSTools 2.0 disk (you can read the thread at the top of this forum) but it can be done if you type "vmlnodma hdb=bswap hdc=bswap hdd=bswap" at the "Boot:" prompt. The error in the boot disk is that the wrong kernel is invoked if you type "boot: swap" . It loads the dma kernel which doesn't work for byteswapping, which causes the lockup. Read the isolinux.cfg file on the cd if you want to see. I think it will work for you in byteswapping mode. 

John


----------



## Merle Corey

So, being the curious sort, and having an extra 40gb drive, I just finished running a proof of concept.

Summary: mfsrestore -r 0 works.

Anyway, here's what I did:

My TiVo: Philips HDR-212, with TurboNet and 100GB HD (TiVoMad style expansion performed Aug '01).

Booted with the MFST2 CD (default/dma enabled mode). Backed up my current TiVo drive with:

mfstools backup -6s -o /mnt/bak/mybackup /dev/hdb

Shutdown, disconnected good drive, installed test drive.

Restored with:

mfstools restore -x -p -s 128 -r 0 /dev/hdb -i /mnt/bak/mybackup

After completion, I rebooted with the TurboNet 3.0 install CD and installed (for tnlited, primarily).

Slapped the drive in the TiVo. Booted. Telneted in, ran:

mkswap /dev/hda8
swapon -a

Rebooted. Swap was accepted.

Ran:

mfsassert -please

Waited nervously through the green screen. It didn't green screen loop - once through the green screen, then back to the happy TiVo intro vid and life as usual.

So MFSTools 2.0 can (apparently, in my case) be made to work completely with a little finagling and not using the defaults.

Anybody else want to make a test run and either confirm or refute?

MC


----------



## Ivor

That's restoring using a minimal backup, right? i.e. no programs saved?

My attempt at using -r 0 (whilst expanding drives and saving programs) broke even before I had a chance to run _mfsassert -please_, and didn't recover (see earlier in thread). If I can get hold of a suitable disk I'll try restoring my emergency backup with _mfstools restore -x -p -s 128 -r 0_ etc. and let you know what happens. It would also be interesting to see how this works on a >140Gb total setup (which requires the larger swap file).


----------



## Merle Corey

> _Originally posted by Ivor _
> *That's restoring using a minimal backup, right? i.e. no programs saved?*


Correct. Time (not being patient enough to leave my TiVo down that long for a proof of concept) and space (going from 100gb to 40gb, only having a 2.5gb partition for holding any backup images) were my primary reasons for not attempting the complete backup/restore.

Besides, that's the best kind of backup to test -r 0 from, the way I figure - it guarantees all MFS partitions are MFSTools 2.0 created.



> *
> It would also be interesting to see how this works on a >140Gb total setup (which requires the larger swap file). *


Theoretically, it should make no difference - having repaired the swap and gotten it recognized at 128mb, it shouldn't matter what size the overall setup is... But you're absolutely right, it'll be interesting to see if it works regardless.

MC


----------



## rswift

Any thoughts on a repair solution for a DTiVo? Doing the mkswap after the drive is back in TiVo isn't really a viable option. I've read elsewhere in this post of doing a mkswap while the drive is out of TiVo, then after the drive is returned to TiVo, the swap isn't readable.

I'm still curious about which copy, backup, restore type commands need to be done in byteswap mode vs. non-byteswap.

Thanks.
rs


----------



## sbourgeo

So what's the consensus on new expansions?

I have an HDR-312 where I had previously replaced the 30G drive with an 80G drive with TiVoMad/mfstools 1.1.

Based on the Hinsdale directions, I can just put the 80G and my new 160G drive in my PC, boot with the mfstools 2.0 cdrom and run "mfsadd -x" to recognize the new drive.

According to a post from hinsdale in this thread and in tiger's original mfstools 2.0 announcement, the 64M of swap that I currently have should be sufficient. Is that a fair assumption?

I just want to make sure I have enough swap to recover from GSOD, if necessary.



Steve


----------



## Robert S

The reason Tiger thinks MFS Tools 2 doesn't need enlarged swap is that MFS Tools 2 uses larger blocks sizes, so mfsfix needs less space to run. However, MFS Tools 2.0 breaks mfsfix anyway, so this is hard to verify.

You should be OK if you use mfsadd with -r 0, but this hasn't really been verified. This doesn't use the larger block size, so mfsfix should complete, but you'll have to trust that both Hinsdale's and Merle Corey's upgrades are representative of your situation.


----------



## dobbie1

I have been following the discussion with much interest, hoping to confirm that the lockups I am receiving on a daily basis now are the result of not having created a swap space when I upgraded my Series2 unit. I don't know if MFS Tools 2 has been updated but I used the version first released. I checked my log files and it does not appear that I have any swap space on the unit. I plan on trying to use the option 2 to fix but since I am not familiar with Linux, but do follow directions very well, are the commands listed for the option 2 fix all I will need execute in order to create a swap? Any comments, suggestions will be appreciated.

Regards,
dobbie1


----------



## Robert S

First make sure you really do have a swap problem. You should see three lines giving a clear error message about problems activating swap.

Method 2 should work for you, although I don't think anyone's actually tried it on a Series 2. S2's don't need byteswapping, so you should just boot the MFST2 CD as normal.


----------



## Merle Corey

> _Originally posted by Robert S _
> *You should be OK if you use mfsadd with -r 0, but this hasn't really been verified.*


Not thoroughly, anyway. More datapoints are definitely better.

Of course, Steve's also looking at a >140GB capacity, so he has a choice between playing guinea pig or playing it safe.

Specifically, while -r 0 works (at least some of the time), you (Steve) will theoretically need the expanded swap space as well, and will need to do the song and dance to expand it (Robert nailed a good summary of the possible methods in the first message in this thread).

The guinea pig aspect comes in with not expanding the swap - according to one of Hinsdale's comments somewhere in all of this, the 64MB swap "limitation" may have been resolved in later versions of the TiVo software. If you're the gambling type, you can try not expanding and see what happens.

Of course, failure would essentially result in loss of whatever you've got on the drive, requiring you to reimage... 

Me, I think I'm going to get myself a new drive and play a little more - I'll run another test scenario and see exactly what happens with >140GB capacity, 64MB swap, and that ever so enjoyable mfsassert -please.

I'll post my results when I've got them, but nobody hold off anything on my account - I haven't even _ordered_ the new drive yet. I'm at least a week or two away from being able to sit down and play again.

And on a not-unrelated note, does anybody have any idea what's become of Tiger in the last few months?

MC


----------



## Robert S

Steve's in a rather sticky situation already. He can't just expand swap because his A drive is already full. He just wants to add a B drive. This should work, there's even a chance it might survive a green screen, but there's no easy way to guarantee it.

It might be safer to do a pipe transfer saving all recordings (see MFS Tools README, RESTORE section) and using the -xp, -r 0 and -s 128 options to move everything onto the new drive, expanding swap (will need to use one of the repair methods at the top) and then, once the new drive is verified, mfsadd the old drive as the B drive.

By the way, Merle, what size was your backup image? Did MFS Tools create a new pair of MFS partitions in addition to the original TiVo-created pair?


----------



## sbourgeo

> _Originally posted by Robert S _
> *Steve's in a rather sticky situation already. He can't just expand swap because his A drive is already full. He just wants to add a B drive. This should work, there's even a chance it might survive a green screen, but there's no easy way to guarantee it.
> 
> It might be safer to do a pipe transfer saving all recordings (see MFS Tools README, RESTORE section) and using the -xp, -r 0 and -s 128 options to move everything onto the new drive, expanding swap (will need to use one of the repair methods at the top) and then, once the new drive is verified, mfsadd the old drive as the B drive.
> *


Actually, I thought about doing that...

If I just run mfsadd to partition the 160G drive, then I really don't have the ability to create another swap partition before (since mfsadd would wipe it out) or after (no space left on new drive) I run it. I wish I had selected 128M swap size when I upgraded the first time, but didn't see the need to at that time... 

I may just hold off on adding the 160G for a little while. I have a bunch of recordings that I'd prefer to keep, so that is my top priority at the moment.

Maybe by then Tiger will get back from vacation or from doing REAL work and can look into this stuff. 

Steve


----------



## Merle Corey

The backup image is a stripped down, formerly upgraded, 20 hour image. (The original upgrade was to 100gb - my understanding is that the -s was required in order to destroy the expanded partitions and let everything be done over). When I restored via -x, it created a new pair of MFS partitions to fit the 40gb drive I was dropping back on to.

If you like, I can re-run the process tonight without -x in the restore and confirm that only a base 20 hour image is restored, and rerun afterwards with mfsadd -x -r 0 /dev/hdb. (Running mfsinfo in between to get the particulars.)

You're exactly right regarding adding the B drive, and making the new drive into the A being the safest route; I knew I was missing an obvious problem there.

MC


----------



## Merle Corey

> _Originally posted by sbourgeo _
> *If I just run mfsadd to partition the 160G drive, then I really don't have the ability to create another swap partition before (since mfsadd would wipe it out) or after (no space left on new drive) I run it.*


You can do it during - if you do the piped transfer Robert refers to, you'll preserve all your shows, plus create a new swap on the fly, in the process of migrating everything from the 80GB to the 160GB. You can do the expansion at the same time, and even use -p to optimize the layout.

After that's done (and tested, and the swap fixed), you would run mfsadd to make your 80GB the B drive to your new 160GB A drive.

It's a slow process, mind you, but it's definitely the safest route, and accomplishes everything you need to do.

MC


----------



## Robert S

That's fine, Merle. I just wanted to be sure you hadn't put a 40Gb image on a 40Gb drive, which would've meant no MFS Tools 2.0-created partitions and rendered your success with mfsfix meaningless.

The two new partitions mean this was a valid test.

I suppose showing the same upgrade fails with -r 2 would mean something, but we're pretty sure that's the case. A test on a big drive is the really interesting case, particularly if -r 0 doesn't slow things down too much (keep the -p partition layout changes).

(Just paranoid, really.)


----------



## Merle Corey

> _Originally posted by Robert S _
> *I suppose showing the same upgrade fails with -r 2 would mean something, but we're pretty sure that's the case. A test on a big drive is the really interesting case, particularly if -r 0 doesn't slow things down too much (keep the -p partition layout changes).*


Hey, I can aim for failure, too. I'll run with -r 2 tonight just to prove the point (probably).

How big is big? I was planning on just going to 120GB for my new purchase, and merging it with the 40GB for large testing. That's more than a single 160GB, but it's way smaller than any dual-large config.

(I'll freely admit that my curiosity and testing aren't entirely selfless - my 100GB drive has started making the kachunk-kachunk-kachunk of doom, and I'd rather get it out of my TiVo before it's dead. Gotta make sure I've got a clean upgrade path. )

MC


----------



## Robert S

If you can get a 120 + 40 to recover from a green screen, I'd be convinced (already close to convinced). You'd then have a two-drive configuration, much larger than any standard TiVo, which would cover most of the potential problems your current experiments haven't.


----------



## Merle Corey

Ok, so my current laundry list is:

40 w/ -r 2: Proof of failure

120+40 w/128MB swap & -r 0: Proof of success in large setups.

120+40 w/64MB swap & -r 0: Proof of possible mfsfix swap requirement resolution (in 3.0 at least).

Am I missing anything? Any requests? I'm limited by hardware to SA series 1 only, so I can't do any DTiVo experimentation.

MC


----------



## dobbie1

> _Originally posted by Robert S _
> *First make sure you really do have a swap problem. You should see three lines giving a clear error message about problems activating swap.
> 
> If the swap is okay, would I not expect to see some message indicating the swap was activated?
> 
> Regards,
> dobbie1*


----------



## sbourgeo

> _Originally posted by Merle Corey _
> *
> 
> You can do it during - if you do the piped transfer Robert refers to, you'll preserve all your shows, plus create a new swap on the fly, in the process of migrating everything from the 80GB to the 160GB. You can do the expansion at the same time, and even use -p to optimize the layout.
> 
> After that's done (and tested, and the swap fixed), you would run mfsadd to make your 80GB the B drive to your new 160GB A drive.
> 
> It's a slow process, mind you, but it's definitely the safest route, and accomplishes everything you need to do.
> 
> MC *


I'd rather hold off on the klugey stuff (like the swap workarounds) until the process is ironed out a little.

The TiVo I want to add it to is currently our "production" model and I want to minimize the risk as much as possible.

Steve


----------



## Robert S

If your swap is OK you'll see one line (very easy to miss) saying something like 'Activating swap <size>, priority -1'.


----------



## dobbie1

I rebooted, then activated backdoors, went to /var/log/kernel and did not see any entry as described above. The only entry close was "Initialize with 1 live caches."

Thanks for your responses.


----------



## Merle Corey

> _Originally posted by dobbie1 _
> *I rebooted, then activated backdoors, went to /var/log/kernel and did not see any entry as described above. The only entry close was "Initialize with 1 live caches."*


Straight from my kernel log:

Jan 1 00:00:15 (none) kernel: Activating swap partitions 
Jan 1 00:00:15 (none) kernel: Adding Swap: 130684k swap-space (priority -1)

It's very early in the boot process (you can tell because the date/time isn't set yet), but it's pretty easy to miss. The line you're looking at is around (ballpark number, YMMV) 100 lines too far down. (Or, an unknown number too soon, depending on where your logfile starts.)

Hope that helps!

MC


----------



## horwitz

So what is the latest "best idea" for upgrading? I am going from a factory HDR312 (13.6+13.6) to 120. MFSTools 2.0 a la Hinsdale's page (what about all these flags people are talking about? -xp, -r 0, -s 128, etc.)? Will the old 1.1 solution on Hinsdale's page work; what disadvantages are there to the old procedure (aside from it taking longer)? BTW, I hope to upgrade to 120+120 sometime in the not-too-distant future.


----------



## Robert S

As you might guess, this is still a matter for debate, however, I think we can say the following:

If you want to be absolutely safe, stay away from MFS Tools 2.0! Use the older, proven tools in the original Hinsdale.

If you have to use MFS Tools 2.0 (there are some upgrades that can not be done with the old tools), avoid the -s option (increase swap partition file) and use -r 0 to force 1Mb block size.

The -x and -p options (you've combined them as -xp) cause MFS Tools to fill the hard drive with Tivo partitions and use an alternate partition layout that's believed to be faster.

If you want the fastest possible TiVo and are prepared to accept the risk that your TiVo might lose all its recordings without warning (if you get filesystem corruption), use MFS Tools 2.0 as described in new Hinsdale, but check your swap as described in the first post in this thread.


----------



## SAFW

So does anyone know of a method to get MFStools 1.0 working with devices recognized as hdf, hdg, hdh, and hdi (the Promise RAID controller takes up hda, hdb, hdc, and hde)? How about TiVoMad? Is there an integrated restore/expand option like -zxpi in MFStools 2.0?

MFStools 2.0 worked like a charm for me with -zxpi, but now I'm concerned that I'll get the GSOD somewhere down the line.

SAFW


----------



## Merle Corey

I ran several tests tonight, and here are the results:

First up, swap space tests. (All tests are to the same 40GB drive.) First with:

mfsrestore -p -x -r 2 -i /mnt/bak/mybackup /dev/hdb

I can confirm that the "default" swap works fine out of the gate. As expected, a 64mb swap partition was found on first boot; it's not a restored swap either, as the swap on my old drive was 128MB. So we have a little more confirmation on that front.

A little weirder: I ran the experiment again, this time with the 128MB swap (-s 128), and rebuilt the swap (mkswap /dev/hda8 ; swapon -a) via telnet. The swap definitely mounted on the command, and remounted after rebooting, but no further log messages were generated by it. So everyone who couldn't find any message at all? You may not be crazy, and your swap may be fine. Don't ask me, I can't explain this one.

A third time through, and I tried another swap prep mechanism: Building the swapfile with the mkswap on the bootdisk. I used: mkswap -v0 /dev/hdb8

This worked. Flawlessly. Tricks involved were having byteswapping enabled and forcing the old style (-v0) swapfile. The default was to a new style swap - I knew something was up as soon as that happened because the messages were completely different. Forcing -v0 generated the same messages as doing mkswap via telnet to TiVo, and worked immediately on insertion.

I'd love to hear from someone with a DTiVo who's willing to try this. rswift? I believe you were looking for a mechanism to fix your swap?

Now for the really weird part: It successfully ran through mfsassert -please with -r 2. This surprised me so much that I ran it again after zeroing out the drive - and it worked again. So just for giggles, I ran it through a third time, this time without specifying any -r value (theoretically defaulting to -r 2, but I wasn't taking it for granted). It worked yet again.

The only conclusions I can draw are either:

1) -r works for all values and drive sizes, and any mfsassert/fsfix issues are unrelated

2) -r works for all values of drives under a certain size, but fails for drives/combos over a certain size

3) -r works with a stripped out backup (-s) but not for modifying "existing" data - preservation of programs, adding a B drive to an already expanded A drive, etc

I'd love to prove #1 is true, but I suspect the reality is #2 or #3. It may be that only "native" MFST2 mods work, and that piggybacking with other expansion mods doesn't. It may be yet another space issue. I can't work any further on most of these until my new drive arrives (some time early next week, best guess).

If anybody has anything further they'd like me to try, let me know. I plan to try again, this time to do a combo of:

mfsrestore -p -r 0 -i /mnt/bak/mybackup /dev/hdb

and

mfsadd -r 2 -X /dev/hdb

to simulate item #3 (as if the data had been dd'd over) and see if that makes anything break, but I'm not going to have time to do that until some time this weekend.

MC


----------



## stormsweeper

I think I was one of the first to report this on my SVR-2000. One part of the problem is that the older swap version is limited to 127MB. So you should get a message that the space was truncated to 133890048 or so when you run mkswap from the tivo.

Since then it's been happy.


----------



## dougdmy

I posted this in another thread, but thought that it was more appropriate to this thread.
__________

I used mfstools-2.0 and ran well for a couple of months. Then a few days ago, I had the GSOD/reboot loop problem. I had so many recordings on there, too. But I was very concerned about my Season Passes and Wishlists. Here's what I did: 

I took out the two 120GB drives from my TiVo and used mfstools-1.1 to create a backup image. I got a message stating something about an inode problem and that it was trying to read the backup table (or something to that effect). The backup successfully completed. Then I restored the image using mfstools-1.1 to a new 80GB drive. I put the 80GB drive in my TiVo. On power-up, I got the GSOD and much to my delight, it did not reboot. It spent about 20 minutes fixing itself and then it rebooted and all seemed well. I deleted what was listed in my Now Showing list, powered down, and TiVoMadded the 80GB drive to utilize the whole thing. 

So far (one day later) all seems well. 

This got me thinking. Can I use mfstools-1.1 to create a backup image of my original 120GB+120GB configuration (streams and all) and then use mfstools-1.1 to restore it? Hopefully during the restore process mfstools-1.1 will create the mfs partitions in a way that will allow mfsfix to do its job and I'll have minimal programming loss. 

Has anyone else tried this? It's an expensive thing for me to try because I would have to go out and buy enough disk space to store the huge backup file. 

I appreciate any and all suggestions or ideas. 

Doug (who is very sad because he lost the entire season of The Shield that he hasn't watched yet)


----------



## Robert S

I think this has been tried, without success. One obvious question would be whether MFST1 can read the larger blocks created by MFST2 (your minimal backup only captures the original TiVo partitions (1Mb blocks, even on an MFST2 restore) and doesn't touch the new partitions).


----------



## Merle Corey

For what it's worth, I'm starting to suspect that the block size problem isn't.

This morning's test run involved making a fresh backup of my original 100GB (20 hour image, TiVoMad expanded) drive with MFST1:

mfstools backup -6so /mnt/bak/mybackup /dev/hdb

I restored with MFST1 to a 40GB drive:

mfstools restore -zi /mnt/bak/mybackup /dev/hdb

This gave me a 20 hour, unexpanded image on my 40GB drive. Booted, confirmed functionality, and even ran mfsassert -please for kicks (fsfix was successful). I then went back and expanded with MFST2:

mfsadd -r 2 -x /dev/hdb

Booted again, confirmed everything was golden, mfsassert -please, and yet another successful run of fsfix.

I'm starting to nurse a pet theory, and that theory is that the decreased swap needed by the larger block size may not be directly proportional to the increase in MFS block size.

To put it differently: Kevin (klincoln) is the only other person to test MFST2 via mfsassert with a known good swap. He tested with dual 160's and a 64MB swap - if I'm right, he may need 128MB swap to make it work, even with the default (-r 2) MFST2 block size. Kevin? You still watching this? Wanna take a crack at it?

Meanwhile, I can't find a way to break things with a 40GB drive, so there's nothing more I can do for now. My new drive is arriving Wednesday, and I should be done with burning it in by Friday. As an added bonus, I may be able to lay my hands (temporarily) on another 120GB drive, allowing me to test an extremely large (though 34GB shy of maxed out) config.

MC


----------



## Robert S

How about reducing your swap? You could try *swapoff* to turn off all swap. You could also try manufacturing a smaller swap file and using that. If you could find a threshold below which mfsfix wouldn't complete, that would be an interesting find.

However, if you look at embeem's post on Tiger's MFS Tools 2 thread, it looks like he understands the swap issue.


----------



## Merle Corey

> _Originally posted by Robert S _
> *How about reducing your swap?*


I'm a little confused now. We already know that swap plays a critical role in successfully running fsfix. Or are you suggesting the establishment of multiple data points, whereby we can determine the minimum amount of swap required by, say, 40GB at -r 0 vs -r 2, and by extension determine whether the the swap size is directly proportional to the block size?

Heck, I think I may go do that anyway now, just for kicks.  The real testing may once again have to wait for me to get the new drive, though, as I'm going to be playing with really small partitions to scale it down for 40GB (ballpark "minimum" at -r 0 should be around 18MB, meaning a theoretical 9MB for -r 2).


> *However, if you look at embeem's post on Tiger's MFS Tools 2 thread, it looks like he understands the swap issue.*



I didn't get that out of it. He just asserted that there was a problem that prevented fsfix from running. He wasn't even certain that it was a MFST2 problem, and said he didn't have the resources to check.

It may be that we're flogging a dead horse at this stage, but I'm not going to be satisfied without definitive success either.

MC


----------



## Robert S

Yes, exactly. If reducing the swap breaks mfsfix on a 40Gb (and it may well be it's too small, but you don't have a bigger drive ATM), you should be able to find a threshold that separates sufficient from insufficient swap. It might then be possible to estimate how much swap a given configuration requires, and to test the theory that higher -r numbers require less swap for mfsfix.

To some extent you can't add much more to our knowledge because we need more data from other TiVoes (there are enough people reporting GSOD loops to suggest it's a real problem). On the other hand, if you're enjoying the investigation I'm happy to suggest new experiments. You've certainly shown that saying 'MFST2 breaks mfsfix' is an over-simplification.

I've PM'd embeem to ask what his config was - there's no earthly point in arguing what someone else meant


----------



## jhburke

I just wanted to post my confirmation of Merle Corey's findings about running mkswap from the boot disk. I had previously tried to run mkswap from the MFSTools 2.0 cd boot disk, and ended up with a swap file which I could mount from the boot disk, but would not mount from the TiVo. Now, thanks to Merle, I ran "mkswap -v0 /dev/hdc8" from a byteswapped boot cd, and my kernel logs now show "Adding Swap: 130744k swap-space (priority -1)". I also received the error message from the boot disk about truncating the swap file from 133xxxK to 130xxxK as Merle also noted. I don't notice anything running any faster on the TiVo, however.

I'd be willing to try mfsassert -please, but since I have a DTiVo, I can't easily get a prompt. I guess I'll just have to wait for the green screen!

BTW, I've had 2 TiVos now for greater than 2 and 1 years, and have never seen the green screen, either before or after upgrading. Are they common or am I just having good luck?

John


----------



## Robert S

*I ran "mkswap -v0 /dev/hdc8" from a byteswapped boot CD*

What does -v0 do? (Sorry, too lazy to look at mkswap manpage  )

As for mfsassert, unless mfsfix completes it will blow away your current TiVo install, forcing you to restore from backup - so not recommended unless you've got a spare disk like Merle.


----------



## horwitz

I did an upgrade last night (thanks to Tiger and Hinsdale, of course and to all the folks who answered recent questions (e.g., Robert S)) of an HDR312 from 13.6+13.6 to a single 120. Everything seems to working fine. I tried to look through the log file for "activating swap" (just after a reboot), but never found that text. Will it always be there? (I never even found "swap".) TIA


----------



## Robert S

It should be there. The error messages from a failed swap activation are much easier to see. If you're not having problems with indexing, I think it's safe to assume you're OK.


----------



## Merle Corey

Ok, so I flubbed my guesstimate before. The magic number for getting fsfix to fail under -r 0 on a 40GB drive is 12MB of swap or less. 13MB works.

Useful trivia: If you have a TiVo that's greenscreen looping due to bad swapfile, but is otherwise of sufficient size, you can run mkswap -v0 /dev/hdX8 from the (byteswapped) boot disk and the TiVo will recognize the corrected swap, allowing fsfix to complete.

In other words, anyone who is up the creek because of having used -s 128...? It's fixable, without reimaging, even if the greenscreen loop has already begun.

Not-as-useful trivia: mkswap accepts a size argument, as long as the size isn't larger than the target partition. Very useful for, say, playing with swap sizes. 

Useful datapoint: fsfix fails with signal 11 when there's not enough swap space. This is the same signal Kevin got with his dual 160's and a 64MB swap.

Robert, the short answer your question: -v0 sets an old style swap, the same variety TiVo uses. The mkswap included in the bootdisks defaults to the new style, which is incompatible. (Of course, the newer version is also more efficient, on those systems that recognize it...)

John, glad to hear it worked for you. I can't really answer your question about greenscreens - I've had my TiVo's (2) for a year, and never had one that I hadn't caused. Others aren't as lucky. The swap shouldn't make any performance difference - having run *top* on my TiVo a few times, I can confirm that the swap doesn't get touched in normal use, and even most abnormal use. I'm not an authority on the subject, but it may only really get utilized when fsfix is running.

I'm off to generate a magic number for -r 2. I'm not certain that I'm going to be able to determine a scale based on these results alone, so I may redo this process when the new drive arrives.

MC

(Edit: Typo fix)


----------



## Robert S

So, your theory at the moment is that TiVoes caught in a green screen loop are just running out of swap afterall?

Two suggestions for making more swap for emergencies:

Create a swap file on /var (hda9 is 64Mb, of which most is probably rubbish).

Create a swap partition on your inactive root partition. hda4/7 is 128Mb, you can have multiple swap partitions/file active even if no single swap entity can be more than 128Mb.

Both of those are fairly heavy duty Unix hacks (and wouldn't work on DTiVoes), but they might provide an emergency rescue option.

I was beginning to wonder if you were a special case, but being able to break/fix mfsfix by tweaking the swap size suggests these results will apply to all TiVoes. You may very well have found a fix for the second MFS Tools 2.0 problem.


----------



## Merle Corey

Yep, that's my working theory.

Oh, and a note on the emergency swap suggestions: If you need to implement one of these, you'll also need to update /etc/fstab in the active root partition to include the added swap space(s). Theoretically speaking, if you have a single drive config, you could also put a second drive in place with a swap partition or two on it. Again, caveats regarding fstab and hackable TiVo's apply.

I finished the second phase of testing, and got some interesting results. The magic swap number for -r 2? 13MiB.

Either the improvement is subtle and beyond my measurement (I moved in increments of 1MiB, so theoretically, there could be up to 1023KiB difference) or the improvement isn't significant on a 40GB drive (a possibility, since only about 18GB is providing "new" space). Either way, it looks like the swap requirements for MFST2 may be almost exactly the same as they were for all previous methods.

It wouldn't be a bug in MFST2 as much as a serious misconception as to how fsfix works. On top of that, it seems to indicate that 64MiB of swap probably isn't enough for the larger drive configs.

For what it's worth, I hacked out some estimates of swap requirements and system RAM utilization. Specifically, about 6MiB of system RAM is used in the fsfix process, and the total RAM (system & swap) needed for a capacity is about 512KiB per GiB of total drive capacity.

It can be approximated as:

(SwapMiB + 6MiB) = (DriveCapacityGiB*(512KiB/GiB))/(1024KiB/MiB)

Or more simply:

.5*DriveCapacityGiB = TotalSwapMiB

If I'm right, this means that people with dual 160's should have enough swap at 128MiB, regardless of the method used. Of course, this is on a SA w/16MiB RAM - people with 32MiB are probably in slightly better shape.

(For the pedantically inclined, I specified the difference between binary GiB/MiB/KiB and decimal GB/MB/KB. This isn't something I usually pay much attention to, but it plays a significant role here - DriveCapacity in GiB vs GB is the difference between "just enough" and "not enough" swap at the 256GiB/274GB mark.)

I'll run these tests again when I've got a 120GB drive in place - it should at least tell me how significant the difference is between -r 0 and -r 2, but I'm not expecting big changes in the results.

Meanwhile, I think we've definitely got some food for thought. 

MC

(Edited to clean up some phrasing)


----------



## dougdmy

> _Originally posted by Merle Corey _
> 
> *Useful trivia: If you have a TiVo that's greenscreen looping due to bad swapfile, but is otherwise of sufficient size, you can run mkswap -v0 /dev/hdX8 from the (byteswapped) boot disk and the TiVo will recognize the corrected swap, allowing fsfix to complete.
> 
> In other words, anyone who is up the creek because of having used -s 128...? It's fixable, without reimaging, even if the greenscreen loop has already begun.
> *


I'm still getting my feet wet with this and I don't want to do anything irreversible. So I'd just like to clarify this before I do it.

First my history---

I used mfstools-2.0 to expand a 80+80 DTiVo to a 120+120 DTiVo by using this command:

 mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -xzpi - /dev/hdc /dev/hdd

According to the README with mfstools-2.0, -s 64 is the default for the swap file size. I verified this by looking at the partition table, which has the following entry for /dev/hdc8:

 8: Swap Linux swap 131072 @ 23894080 ( 64.0M)

So now on to my question: If I run

 mkswap -v0 /dev/hdc8

and put the drives back in my DTiVo, there's a good chance that the reboot loop will be history and that fsfix will be able to complete. Am I correct?

Thanks in advance for your comments. I'm probably being a bit overly cautious, but I just want to be sure.

Doug


----------



## mrtickle

> _Originally posted by Merle Corey _
> *
> John, glad to hear it worked for you. I can't really answer your question about greenscreens - I've had my TiVo's (2) for a year, and never had one that I hadn't caused. Others aren't as lucky. The swap shouldn't make any performance difference - having run top on my TiVo a few times, I can confirm that the swap doesn't get touched in normal use, and even most abnormal use. I'm not an authority on the subject, but it may only really get utilized when fsfix is running.
> *


Here in the UK there is so much guide data that the swap is needed for indexing after the daily call. You may have seen some reports of people's tivos crashing after two days...


----------



## Merle Corey

> _Originally posted by dougdmy _
> *So now on to my question: If I run
> 
> mkswap -v0 /dev/hdc8
> 
> and put the drives back in my DTiVo, there's a good chance that the reboot loop will be history and that fsfix will be able to complete. Am I correct?*


Unfortunately, if I'm right, no.

You have a 64MB swap, which may not be enough for your dual 120's - _if_ my findings are correct. More to the point, a 64MB swap (probably) won't be helped by rerunning mkswap, simply because MFST2 seems to know how to make a 64MB swap without breaking.

You would fall into the category of needing emergency swap space, but that would only be possible if you've hacked your DTiVo's prom to allow modifications. How to do that is beyond the scope of this particular thread - try a search on "DTiVo" and "bash" either here or on google, but it's definitely not for the faint of heart, and goes way past just adding drive space. Even if you do go that route, you'll still need to eventually redo your TiVo drives to permanently expand the swap to 128MB.

Ultimately, you may be better off restoring from backup and writing off what you've got recorded. 

MC

(Edited for clarification.)


----------



## Merle Corey

I never said it explicitly last night, so I'll say it now for the sake of clarity: If I'm right, the ">140GB needs 128MB of swap" rule of thumb is still true under MFST2.

That would mean - *in theory* - that anyone with 64MB of swap and >140GB could be subject to greenscreen looping, and may want to redo their TiVo expansion to use 128MB of swap.

Keep in mind, though, that right now this is a _theory_. Just because it was true once doesn't mean it'll be true always, but it's certainly disturbing news. I hope to add further confirmation to this once my new drive arrives, but it ultimately needs to be tested by more people.

Oh, and thanks to mrtickle for the swap info - now we know two things it's used for. 

MC


----------



## dougdmy

> _Originally posted by Merle Corey _
> *
> 
> You would fall into the category of needing emergency swap space.....
> 
> *


Thanks for your helpful information. Currently hda4 is my active partition and hda7 is unused. I did mkswap on hda7 and edited /etc/fstab. I put the drives back into the TiVo and I got the green screen and no reboot! It seems to be working.

Of course I realize that this is a temporary fix and if fsfix successfully completes, I will have to rebuild (soon) from my backup. But at least I can watch some of my more important shows. I feel like I'm sitting on a TiVo TiMe BoMb!

Doug


----------



## dobbie1

> _Originally posted by Merle Corey _
> *
> 
> Straight from my kernel log:
> 
> Jan 1 00:00:15 (none) kernel: Activating swap partitions
> Jan 1 00:00:15 (none) kernel: Adding Swap: 130684k swap-space (priority -1)
> 
> It's very early in the boot process (you can tell because the date/time isn't set yet), but it's pretty easy to miss.
> 
> I know I probably keep missing the entry, but for the life of me I cannot find an activating swap partitions in my Series 2 standalone. The only indication I can find of swap is in \var\log\messages.
> 
> However, yesterday I took the upgraded drive A out and tried to run the option 3, mkswap. It did not work. I rebooted, activated backdoors and in the log \var\log\messages, Swap Total = 0, and Swap Free = 0.
> 
> Today I took both of the upgraded drives out and replaced with the original 60G TiVo drive. When I rebooted and activated backdoors then checked \var\log\messages, Swap Total = 65532, Swap Free = 65520. I still could not find anywhere in any of the logs where the swap partition was activated.
> 
> For the last month or so, the TiVo had been experiencing random lockups, normally after the daily call when the data load had finished processing. I intend to run the original drive for a week to see if I begin experiencing lockups, if not then I will put a second drive in and bless with MFSTools 1.1.
> 
> Hopefully, this info will help.
> 
> Regards,
> dobbie1*


----------



## Robert S

Why don't you just dd the original swap partition over? (Method 2 on the top post.) Remember Series 2's are not byteswapped, so use the MFS Tools 2.0 CD and you should be able to see the partition table. I don't think this method has been verified on an S2, so let us know how you get on.


----------



## kingmiwok

doobie1:
Just for your sanity... I have a series 2 AT&Tivo and can find no mention of activating the swaps either. (This is after upgrading to a 120/120 config using the -s 128 option and tools v.2.0.) My swap reads 0 and 0 in the \var\log\messages as well. I'm thinking now that series 1 and 2 behave differently in this way

I'm locking up every 24 hrs or so and I'm patiently waiting for a sure fire fix. I have not had success dd-ing the old swap over, or running mkswap, but I may have had unrelated linux problems while trying to do the fix, so YMMV. 

I hope to get a chance to try again in the next week, so I'll post up results.


----------



## dobbie1

> _Originally posted by kingmiwok _
> *doobie1:
> Just for your sanity... I have a series 2 AT&Tivo and can find no mention of activating the swaps either. *


Thanks! At least I'm not in the boat alone.

It maybe the weekend before I have the opportunity to try and "dd" the backup and see if that works. Will post the results.

Regards,
dobbie1


----------



## Agent86

I'm confused. Someone throw me a lifejacket 

I have an AT&T Series 2. It came with a 40GB drive. When I got it, I used MFSTools 1.1 to add a 120GB drive to it.

When MFSTools 2.0 arrived, I wanted to expand my A drive, but not lose recordings. I DDed the 40GB drive to a 120GB drive, and then expanded the DDed image on the 120GB drive.

I assume, based on what I have read, that this means my swap partition is indeed intact. So my question is pretty simple:

Do I have to do anything (i.e. bump swap to 128MB), or am I all set as is?

If I need to do anything, what do I need to do (comands to run, etc).

Someone save me! 

- Agent 86


----------



## Robert S

You're OK for now. You carried your original swap over with dd, so that's fine (you will experience serious problems within hours if you have no swap at all). However, if you get a file system corruption problem - a green screen - you'll lose everything and have to restore from backup. The swap extending hacks we've been proposing require some fairly heavy Unix hacking and Series 2's are locked against that sort of thing.

If you do have to restore that TiVo's hard drives for whatever reason, it's probably best to use -s 128 to expand your swap. We don't seem to have figured out a reliable way to fix the swap problem that causes on S2's yet, so don't do that just yet.


----------



## Merle Corey

dobbie1, kingmiwok:

Just another confirmed sanity check - series 1 also displays the swap info you found in /var/log/messages - it's as valid a confirmation as the one in /var/log/kernel.

What steps, exactly, did you follow when using mkswap? What boot disk, byteswapping or no, and did you use any command line parameters?

Theoretically speaking (I haven't been able to talk a friend into letting me dissect his S2 for some reason, so I can't say for sure...), you should use a non-byteswapping boot mode, but the command you use should still be:

mkswap -v0 /dev/hdX8

Where X is the drive letter assigned by linux.

For the record, has _anyone_ with a series 2 been able to successfully build a 128MB swap?

I've been hooked up with an image now; I'll post if I learn anything new from it.

MC

(edited to remove image request)


----------



## Agent86

Robert:

Thanks for the lifejacket .

I'm pretty familiar with Linux, so command lines here and there don't scare me too much. I'm no low-level programmer or anything, but I can handle dd, cfdisk, and all their friends .

Hopefully we'll find a solution soon.

- Agent 86


----------



## dobbie1

> _Originally posted by Merle Corey _
> *dobbie1, kingmiwok:
> 
> What steps, exactly, did you follow when using mkswap? What boot disk, byteswapping or no, and did you use any command line parameters?
> MC *


I used the mkswap parameters listed under option 3, but I belive they were different that what is shown now. I used noswap, but after looking at my boot cd's today, I may have inadvertenly used the MFSTools2 disk. However, I did find time today to try and "dd" the swap file with the commands listed under option2, only to find that I had no space left on the upgraded drive and when I tried to reboot with that drive to delete some programs, I ended up with a very "green" screen. I assumed my file structure was now corrupt and went back to the original drive with a blessed drive b.

I will be happy to try and ftp you a copy of my original Series2 image, with the 30 software. I am not sure why there isn't one on the ftp site. I ftp'd Stan Simmons (?) the image over a month ago.

Regards,
dobbie1


----------



## Robert S

Sorry dobbie, the original mkswap parameters were wrong, the current ones have been tested on a Series 1.

Is there something odd about the S2 partition structure?


----------



## Merle Corey

> _Originally posted by Robert S _
> *Is there something odd about the S2 partition structure? *


I was wondering that myself; that's why I wanted the image - so I could see if there's anything unusual about it.

Right now the only noteworthy thing is that it's a 13 partition structure, similar to the S1 Sony... But I'm pretty sure we knew that already.

Other than that, the layout appears to be exactly the same - /var on 9, roots on 4 and 7, swap on 8. I'm going to take a closer look at the swap and confirm that it's still the old version, but that's also fairly likely to be the case.

MC


----------



## Merle Corey

And it's confirmed, series 2 still utilizes the old style swap - in other words, -v0 is required or mkswap will create something that the TiVo can't read.

(PM me if you really wanna know how to find out - it's easy - everything you need to know is in the man page for mkswap. )

I don't think there's much more to fiddle with at this point - what we need now is someone with a series 2 to try it out with the -v0 parameter.

MC


----------



## Agent86

So what has to be done? You know, the usual newbie stuff - commands to run, switch options, and option values (like swap size).

If it helps, I'm running dual 120gb drives in this unit.

Is it possible to do this without losing my programs, or do I have to start from scratch?

I have a feeling I might not like the answer to this one, based on prior posts in the thread .

- Agent 86


----------



## Robert S

Not at all, we just want you to do method #3 from the top post with the new options. It shouldn't affect the rest of your setup.

Seeing as you already have working swap, perhaps Merle can suggest a sequence of commands to reduce your swap slightly and then increase it back to 64Mb so we can be sure it's working.


----------



## Agent86

I think I can handle that .

But don't I need to get MORE then 64 to make my TiVo happy when things go sour?

So ideally we'd drop it to some lower number, and then boost it to some higher number (i.e. 128, or whatever is needed for dual 120s).

Just feed me the proper command lines, and I'll make sure my fingers get them right .

Also, does Kazymyr's boot cd (v2.6i) have this tool on it? Do I boot in byteswapped or non-byteswapped mode?

- Agent 86


----------



## Robert S

Well, you only have room for 64Mb of swap, which is not enough for your system to recover from a GSOD. You should have done a pipe transfer, which would have saved your recordings and left you with a 128Mb hole where your swap partition should be.

What we're trying to figure out is that last step - repairing swap partition on an S2. I don't think there's any reason to think it's impossible, but people have been having problems.

DTiVoes and S2's are locked down, so you can't do the hacking required to add additional swap for emergencies. I think DTiVoes can be unlocked by hacking the boot PROM, but S2's are currently unhackable, so the only way to make your TiVo safe is to repeat the upgrade and this time expand swap to 128Mb (there's no point in going beyond 128Mb, even though MFS Tools 2.0 allows it, as the Linux kernel TiVo uses can only use 128MB per partition or file).

128Mb should be enough for any TiVo to recover from a green screen, subject to confirmation when Merle's stocked up on big drives


----------



## dobbie1

I will give it a try with the 80G drive that had been expanded. Listed below are the steps, I think I should take.

1. Low level format the drive to get back to a clean drive. 
2. Restore the backup with MFSTools2 using the default parameters as I used originally.
3. Expand drive with MFSTools2.
4. Return to TiVo and check swap file, there should not be any.
5. Remove drive from TiVo and with MFSTools 1 run mkswap with -v0 parameters.

Will this verify what is required. My system is a Series2 Standalone.

Regards,
dobbie1


----------



## Agent86

Well balls! 

So, since its the off season its probably the best time to get this fix out of the way. It stinks that I'll lose all my season's passes, thumb ratings, and recordings, but if its the only option its the only option. I suppose that's why its called "hacking".

I'll just watch the few "new" shows I have (like Monk) over the next couple of days and then prep for surgery.

My backup image is a virgin image made with MFSTools 1.1. So what do I have to do to restore it to the 120GB drive, expand it, and make 128MB of swap properly?

My parents also have a Series 2 with the stock 40GB and a 120GB B drive - which means they fall victim to the same plague. Where is this piped procedure I can follow so that I can upgrade their A drive and extend the swap as well?

I really don't want to have to do all this ever again .

- Agent 86


----------



## stormsweeper

You could just make a new backup image and keep all your settings, but not recordings.


----------



## Merle Corey

Agent86:

You don't have to lose anything (other than recordings). Make a new backup of your TiVo in its current state with:

mfsbackup -6so /mnt/bak/tivoagain.bak /dev/hdX

You'll preserve the season passes, etc, but flush the recordings.

When you go to do the 'mkswap', you'll need to do it in non-byteswapped mode, as that's how S2's work.

And thank you again for setting me up with the S2 image - it was a big help.

---

dobbie1:

Depending on what the "default parameters (you) used originally" are, yes, that's the process in a nutshell. If you used -s 128, then yes, you should have no swap. If you didn't specify, or used -s 64, you should have a working 64MB swap.

Technically, you don't need to low-level format the drive either, if you're looking to save a little time.

MC


----------



## Agent86

What command do I use to properly restore the backup? 

Do I still use the -s 128, and then use mkswap -v0 to initialize it properly?

- Agent 86


----------



## Merle Corey

Today's quote of the day is: "A foolish consistency is the hobgoblin of small minds." --Ralph Waldo Emerson

So I got curious as to why, exactly, -s 128 failed. It didn't make much sense - I did a little digging, and it turns out that -s 128 fails to produce working swap because it initializes it improperly. It tries to do the right swap type (version 0), but munges the format.

This, however, triggered a suspicion and I just proved it true: We're (mostly) familiar with the "truncating to 130048kB" message that mkswap produces when making a version 0 swap of 128MB. The reason for that message is simple - that's the largest swap size supported by version 0 in a single partition/file.

130048kB/1024 = 127MB.

Oops.

The bug in MFST2 is that it _fails to adjust for improper swap sizes fed to it on the command line_. This is compounded by the README claiming that all swap sizes up to 512MB are valid.

So, I ran another test, this time using -s 127. It worked just fine.

In other words, the following produces a working restore with a maxed out swap partition:

mfsrestore -zxp -s 127 -i backupfile /dev/hdX

Well, Robert, we were looking for a simpler way to explain how to get working swap... I think I found it. 

MC

(edit for typos)


----------



## Robert S

A86, you might want to wait until we have a verified method for doing swap on an S2. If you want to keep your SP's etc a new backup will preserve those (won't even have to make a guide call).

Restore with

mfstool restore -s 128 -xpi /mnt/dos/tivo.bak /dev/hdc

Which will restore the backup, increase swap size (broken), expand your partitions to fill the drive and optimise your partition layout for extra speed.

Whatever scheme we settle on for fixing swap, you should be able to do it from the MFS Tools 2.0 CD without rebooting because Series 2's aren't byteswapped.

dobbie, you don't particularly need to clear the disk first, I was slightly concerned earlier that you might inherit working swap from your previous install, but I don't think that applies here. Rather than a format, which is very slow, you could dd from /dev/zero over your drive. Set bsize and count to write 1Gb of data and you'll trash all the relevant stuff.

As I said, S2's aren't byteswapped, so MFS Tools 2.0 CD is the one to use, S1's must not use MFST2 CD because they are byteswapped. I would be quite happy for you to do mkswap before you test the restore, as long as you can verify that it worked.


----------



## Agent86

Sweet!

So all I have to do is boot up with MFSTools 2.0, and run

mfsbackup -6so /mnt/bak/tivoagain.bak /dev/hdX

and then follow that up with

restore -s 127 -zxpi /mnt/bak/tivoagain.bak /dev/hdX

and I'll be golden?

(The above is a combo of your restore and Merle's fix)

- Agent 86


----------



## Merle Corey

> _Originally posted by Robert S _
> *
> Whatever scheme we settle on for fixing swap, you should be able to do it from the MFS Tools 2.0 CD without rebooting because Series 2's aren't byteswapped.
> *


Actually, a reboot is required between the restore and running mkswap. I don't know _why_, but mkswap won't recognize the new partition until a reboot has taken place.

Of course, we may not need mkswap any more... 

MC


----------



## Merle Corey

> _Originally posted by Agent86 _
> *
> and I'll be golden?
> *


Yeah, that's the way it looks. I just re-confirmed again.

On the one hand, it's nice to finally have the kinks in MFST2 resolved. On the other, I feel pretty silly about that 127MB vs 128MB thing.

Ah well. Live and learn.

MC


----------



## Robert S

Merle, 90% of discoveries are things that people, having heard them, say 'I could've thought of that'. Trust me, the 127Mb thing is not something you should feel ashamed of, quite the reverse, be proud. In fact I feel proud just for giving you a bit of prodding to help you on your way.

So, to finish up, we need to get this into the right places, obviously Hinsdale would be a good place to start. We'll have to wait for Tiger to resurface before we can get his MFS Tools docs changed, but we should probably try and get a mod to change his top post on the MFS Tools 2.0 announce thread.

Also, we need to get the emergency swap strategy worked out so people who come here with 64Mb swap and a green screen loop can learn how to save their TiVoes. It would obviously be good if someone who's actually done this could write it up.

Anyway, I'll get on rewriting the top post on this thread.


----------



## Merle Corey

Oh, I'm not ashamed of it at all - I'm pretty puffed, truth be told. I just had a very large "D'oh!" moment when I realized what was going on, especially in light of that "128MB is such a nice, round number" post that I made elsewhere yesterday. 

(And in all fairness, the limit is actually 133890048 bytes - about .3MB less than 128MB. 127MB just has the distinction of being the largest whole number within the limit. Theoretically speaking, Tiger should probably just have -s just be a toggle to activate the larger swap rather than a configurable value.)

I'll go ahead and confirm the swap requirements for very large configs (and I've made arrangements to get that second 120GB), but I really don't think there are any big surprises left for us to find.

I pm'd Hinsdale yesterday with regard to still needing *ahem* 128MB swap for larger configs. I haven't heard anything back yet, nor has there been an update to the How-To, but I assume he's just busy.

Beyond that, it looks like we're finally putting a wrap on this thing.

(Can I get a "woohoo!"?)

MC


----------



## stormsweeper

> _Originally posted by Merle Corey _
> *The bug in MFST2 is that it fails to adjust for improper swap sizes fed to it on the command line. This is compounded by the README claiming that all swap sizes up to 512MB are valid.
> 
> So, I ran another test, this time using -s 127. It worked just fine.
> *


Yeah, I had that suspicion, as well. I even asked if anyone had tried specifying a swap more than 64MB and less than 128 but didn't get a response then. ( http://www.tivocommunity.com/tivo-v...page=20&highlight=127&pagenumber=2#post595529 ) At the time I had fixed my problem and didn't have a suitable spare drive for testing anymore.

As to why you're having to reboot between restoring and running mkswap - the drive's partition map needs to be reread. I'm not enough of a linux guru to know how to do that from the command line, unless forcing a reread in pdisk will do it.


----------



## hinsdale

Merle and Robert, I received your emails and thank you for the updates and good work on narrowing down the cause. I had mentioned to several people that emailed me over the last few weeks to try -s 127 and report their results as a possible solution to the swap file failure (apparently no one did this or reported their results). As stormsweeper mentioned this was one of the first theories floated as to the failure of the -s 128 creation. I hadnt had time to test this myself and wasnt following the thread closely enough to realize that this had not yet been tested.

I will be updating the How-To to incorporate the larger swap partition creation.


----------



## Robert S

Alternative suggestion for emergency swap for green screen recovery:

Use pdisk to transpose the labels on hdx8 and hdx4/7, run mkswap on hdx8.

Avoids problem with hacking fstab or rc.sysinit to activate swap - so may even work on DTiVoes and Series|2's. Would have to execute it just perfectly and back out correctly too.


----------



## DCIFRTHS

> *
> (Can I get a "woohoo!"?)
> 
> MC *


*woohoo* 

I haven't contributed anything technical to this discussion, but I have been following it VERY closely. This is really good news. You guys invested a lot, and I want to say - Thanks.

I really hope that everything is okay with Tiger. Hopefully he just has a new job, and hasn't had time to check in here....


----------



## stormsweeper

> _Originally posted by Robert S _
> *Alternative suggestion for emergency swap for green screen recovery:
> 
> Use pdisk to transpose the labels on hdx8 and hdx4/7, run mkswap on hdx8.
> 
> Avoids problem with hacking fstab or rc.sysinit to activate swap - so may even work on DTiVoes and Series|2's. Would have to execute it just perfectly and back out correctly too. *


Eek, and this would probably break a future upgrade too. I wouldn't recommend keeping this config for any longer than absolutely necessary. Be sure to change the partition map before you make a new backup.


----------



## BobCamp1

I have been watching this thread with interest, as I want to upgrade my Tivo but I'm waiting for the problems with MFSTools to get resolved. (Thanks to everyone for all that work, I wish I had that much spare time!)

Hinsdale has already updated the instructions (man that was fast!) and has put in the -s 127 parameter.

However, isn't there a problem with swap file size when adding a very large B drive? I thought Merle's research (and other people's information) indicated that if the combined capacity was greater than 140GB, then you needed a 127 MB swap file. However, Hinsdale's instructions for adding a larger B drive don't mention this.

So, if I have a single 30GB A drive and add a 120GB B drive, that equals 150 GB. But according to Hinsdale's instructions (step 10, config #1), I'm just typing in: 

mfsadd -x /dev/hdc /dev/hdb (Boot CD and Floppy users command)

Doesn't this just use my original 64MB swap file? Isn't that too small to avoid the GSOD/reboot problem with my new 150 GB capacity?

I'm thinking of copying my old A drive to the new 120 GB drive (using the -s 127 parameter to create a larger swap file), then using my old A drive as the new B drive. Unless there is something in MFSTools that lets me expand my swap file on the old A drive while preserving recordings.

Besides, when you have a small amount of RAM you generally need a bigger swap file. All series 1 units with upgraded hard drives should probably use a 127 MB swap file since they only have 16MB of RAM. What's an extra 63 MB for a swap file when you're adding a 120 GB hard drive?

Am I just being paranoid, or should I use the 127 MB swap file for my upgrade?


----------



## Robert S

I would definitely recommend upgrading swap if at all possible. If you do a pipe transfer (will take several hours) to the new drive, you can save all your recordings, expand swap and stay in a single-drive configuration for now and add a large B drive later with mfsadd.

Alternatively if you just use mfsadd to add a B drive as long as your machine is a Series 1 standalone, you can add extra swap if your machine gets caught in a green screen loop. At 150Gb you're right on the limit for mfsfix, the true limit is believe to be between 150 and 155Gb, so you may or may not have problems.


----------



## mrtickle

> _Originally posted by hinsdale _
> *Merle and Robert, I received your emails and thank you for the updates and good work on narrowing down the cause. I had mentioned to several people that emailed me over the last few weeks to try -s 127 and report their results as a possible solution to the swap file failure (apparently no one did this or reported their results). As stormsweeper mentioned this was one of the first theories floated as to the failure of the -s 128 creation. I hadnt had time to test this myself and wasnt following the thread closely enough to realize that this had not yet been tested.
> 
> I will be updating the How-To to incorporate the larger swap partition creation. *


I see it's now changed to 127 in the guide, thanks. I can't find any mention though of the fact that you have to make the big drive the A drive, because otherwise the bigger swap won't fit. Or does MFStools2 create the swap on the B drive?


----------



## Robert S

No, MFS Tools can't put a swap partition on the B drive (although this is possible in principle, it's probably not desirable and you would have to modify TiVo system files after a software update).

It's quite tricky to explain, but it's important to explain to be people that they need to choose upgrade profiles that allow MFS Tools 2 to increase swap for them. So things like dd + mfsadd and using mfsadd to add a B drive to an unmodified A drive should be deprecated in favour of pipe transfers, which have the same effect in almost all cases with only a little more pain.


----------



## Cpen

Robert:

So - When I upgraded my Philips 312 (2-drive) TiVo to 120 MB, I did not use the -s command (at all). As a result, my upgrade used the default 64MB swap file (confirmed by looking at var logs). Should I not be concerned because my total hard drive size is under 140MB?

or

Do I need to re-run my upgrade and use -s 127 

I think I'm good to go, as I did not use -s128 (I have a working 64MB swap) and my hard drive space is under 140 MB (which I beleive means a 64MB swap will work just fine). If this is true, then I was just lucky - go figure.

P


----------



## Robert S

That's our current belief. Merle is planning to do some more experiments on big drives, so we may get really solid answers to these questions.

If we can get my partition relabeling idea proved out (and I think we're still waiting on an S2 owner successfully using mkswap), then our advice to people with working TiVoes over the limit would be to wait for the green screen to happen and then use emergency swap, rather than trash a perfectly good system.

Assuming no-one pops up in the next few days pointing out a major problem we've missed, I think we can say that MFS Tools 2.0 is a safe and effective upgrade tools when used within our guidelines.


----------



## Cpen

Robert:

Thanks. I was hoping that this thread would drive resolution/closure to the outstanding issues w/regard to use of MFSTools 2.0.

Hopefully this will close out the chapter of uncertainty for MFSTools 2.0 and allow people to upgrade w/greater confidence!

Thank you for (doggedly) pursuing the solution(s). It's very much appreciated.

P


----------



## Merle Corey

A little more swap confirmation:

Got both my new drive and my borrowed drive today - both 120GB.

Random details:

I ran short on time, so didn't fine tune the results beyond general range.

A 120GB requires somewhere between 45MB and 50MB of swap to successfully run fsfix.

A 240GB config requires between 100MB and 110MB to successfully run fsfix.

Expected results: 

.5 * CapacityGiB = 6MB RAM + N swap

120GB capacity --> 50MB swap
240GB capacity --> 105MB swap

This makes the formula good enough for government work.  More to the point, it stands up for at least moderate accuracy.

Most importantly, of course, is the fact that we have (more) proof that very large configs require more swap than smaller configs.

Cpen - this also means that you should be fine with your config.

MC


----------



## SAFW

By the proposed formula a dual 137 GB system will require ~121 MB swap, or 6 MB shy of the current swap limitation. If that 6 MB of hard RAM weren't there, it would put the swap size at 127 MB. Are the hard drive limitation issue and the swap limitation issue connected in some way?


----------



## Robert S

I suppose the connection is powers of 2 - both the 128GiB disk limit and the 128MiB swap limit arise from the number of bits allocated to an address lookup. The 1/2 MiB per 1 GiB is balanced by the 2 drives. 

So the fact it lines up so precisely isn't coincidental, but one more or fewer bit on either one would mess it up or make it well clear.


----------



## Merle Corey

I'll tackle this with more depth.

The swap limitation is because of the age of the TiVo kernel - I'm not sure when that limitation was broken, but it's been obsolete for at least four years or so. It probably also happens to have been current when the TiVo was undergoing initial development.

The drive limitation (128GiB) conforms to the ATA spec. Up until late last year, 128GiB was the defined maximum addressable space supported by an EIDE drive, using 28 bits of address space. The new ATA/ATAPI-6 spec provides for 48 bits of address space - a nominal maximum of 144 petabytes, or around 150,000 hours of basic recording time. That's quite a ways off, though - right now we know these as the 160GB, 180GB, and 200GB drives, of which TiVo can currently only utilize 137GB/128GiB.

But back to your original question: No, they're not really connected in any meaningful way - they're two independent standards, the only common factor being fsfix.

It may be that TiVo saw this coming in one form or another, and optimized fsfix so that it would run within the limitations of the platform, even though a "stock" TiVo doesn't even come close to pushing those limitations. Honestly though, I tend to suspect coincidence on this one, a serendipitous arrangement of two different base 2 numbers and the memory requirements of a filesystem repair tool. 

You know, what Robert said. 

The other thing worth noting is that's the formula for a 16MB SA TiVo - the 32MB TiVo's are going to be in better shape. 

If somebody with either upgraded RAM in an S1 SA or a hacked PROM in their DTiVo would like to determine the usage in a 32MB TiVo, it's pretty easy. Find the breaking point - the minimum amount of swap needed for fsfix to run given a specific capacity in GiB. Using the formula:

R + S = m*C

Where R is the system RAM utilized in MiB, S is the minimum working swap space in MiB, m is the multiplier in (MiB per GiB), and C is the capacity in GiB. You'll know values for m (.5), C, and S, so solve for R. Basic algebra.

MC

(Correcting typos and reminding myself that getting my hands on an S2 won't help generate the 32MB equation.)


----------



## Robert S

Recovering a TiVo that's GSOD'd and sticks



> _Originally posted by brentf in another thread_
> *How can I determine which is the inactive partition? Also does pdisk need any parameters or be executed from a particular location? Once I doe this should I expect a green screen and wait for mfsfix to run or should it boot normally?*


See the top post in this thread for tips on how to detect the active partition. If you haven't had a software update since the upgrade, one of them will mount and the other won't.

You need to tell pdisk the device node for the drive you want to work on.

Once you're done, yes, restart the TiVo and let the green screen complete. The TiVo should reboot and come up as normal.

Then go back and reverse the renaming of the partitions, if you forget this you'll be in real trouble at the next software update!

pdisk's internal help is probably good enough for you to figure out what to do. If you could take notes of what you do and post them it would really help get this down.

You'll need a byteswapped boot disk to see the partitions on a Series 1 TiVo. Therefore you can't use the MFS Tools 2.0 bootdisk. If you use a TiVoMad boot disk, note that pdisk is actually /mad/pdiska on his disks.


----------



## brentf

Thanks Robert. I'll read this thread to get up to speed and report the results. To orient this thread I'm getting GSOD reboots after adding a 120GB Maxtor to an already expanded 80GB "A" drive. So the plan is as follows:

mkswap -v0 (on inactive root partition)
use pdisk to swap partition ID's on the inactive root and swap paritions
Boot Tivo and allow to repair
pdisk the partitions back again to ready for next software update.

Let me know if I've missed something.


----------



## BobCamp1

Using Merle's data points of (120GB, 50MB) and (240GB,110 MB), and assuming a linear relationship, I get the equations:

swap needed in series 1 Tivo (in MB) = (0.5*total capacity (in GB)) - 10

and

total capacity (GB) = (S1 swap size (MB) + 10) * 2

So a 64k swap file allows you to have up to 148 GB in capacity.

A 127 MB swap file would allow a capacity of up to 274 GB, or two 137 GB drives.

These numbers are a little conservative, which means it should be safe to put two maximum capacity hard drives in your Tivo as long as you use a 127 MB swap file. It also means the critical "capacity" is probably around 150 GB. (My planned upgrade puts me right at 150 GB, so I'll increase my swap file size).

Note that a series 1 Tivo seems to be using around 10 MB of RAM to run mfsfix, instead of 6 MB as was posted eariler.

Series 2 is currently a guess. Worst case says no additional RAM is used, so the series 1 equation holds (max. capacity of 150GB w/64MB swap). Best case is all additional 16MB of RAM are used for mfsfix, which makes the max. capacity (64+10+16) *2 = 180 GB w/64 MB swap file. That assumes that almost everything else for series 2 Tivo's is the same as in series 1, which is a pretty weak assumption. But if you want to play it safe, I'd treat the series 2 just like a series 1 and increase the swap file for capacities over 150 GB.

Hopefully, the equations can be tweaked as more data comes in.


----------



## Robert S

Actually given the 'common code base' of 3.0, I think it's entirely probably that S2's give an extra 16Mb of RAM to mfsfix and even if extra network stuff is added later, the chances are that most of that won't load until after mfsfix is called.

I would recommend increasing swap whatever else you're doing - it only costs you 63Mb of disk space. Even if you're under the limit, hard drives will continue to fall in price and if you want to go up to a bigger drive having extra swap makes it safer.

What we really need, of course is confirmation that the partition swapping technique works on DTiVo and S2.


----------



## Merle Corey

> _Originally posted by BobCamp1 _
> *Using Merle's data points of (120GB, 50MB) and (240GB,110 MB), and assuming a linear relationship, I get the equations:*


Two important factors here:

1) The 120GB/50MiB and 240GB/110MiB were *NOT* minimum known good values. Rather, they were semi-arbitrary values chosen because they fell on the "good" side of the equation. I didn't have enough time to generate specific minimum good swap values through guess-and-check, and I'm not going to for a while - my TiVo died a fiery death yesterday thanks to the electrical storms in the area.

2) You're flip-flopping between GiB and GB - the former is base-2 and is how the computer reports drive space, while the latter is base-10 and is how hard drive companies refer to disk space.

50MiB + 6MiB = 56MiB.
56MiB * 2 GiB/MiB = 112GiB
112GiB is roughly equal to 120GB

110MiB + 6MiB = 116MiB
116MiB * 2 GiB/MiB = 232MiB
232GiB is roughly equal to 249GB.

So the 50MiB of swap may be the exactly-right number for a 120GB drive, but 110MiB is more than is strictly needed for 240GB.

(For reference, the known "exactly right" values we've currently got are 13MiB for 40GB and 64MiB for 140GiB. Note the different GB and GiB suffixes for those.)

Finally, the reason we cared about this at all was to establish two things - that, contrary to the MFST2 docs, 64MiB swap wasn't sufficient for all capacities, and that 127MiB of swap was sufficient for all currently possible capacities.

MC


----------



## gigageek

> _Originally posted by Robert S _
> *What we really need, of course is confirmation that the partition swapping technique works on DTiVo and S2. *


Ask and ye shall receive. I just purchased 3 Seagate ATA IV 80GB drives to upgrade my Sony SVR-2000 (SA) and my Sony SAT-T60 (DTiVo).

The SVR-2000 currently has a Maxtor 40GB A-drive and Maxtor 80GB B-drive. Two of the Seagate drives will ultimately end up here. The T60 is currently unmodified, and the remaining Seagate drive will replace the factory A-drive (which will be placed in safe storage - you can never have too many backups).

Before I get to the permanent configurations, however, I will upgrade the DTiVo with a pair of 80GB drives using -s 127. I plan to start later this evening, and post my results when I'm done. Hopefully, this will provide some small measure of payback to the forum for the outstanding support I've received here over the years.

So someone please refresh my memory about what I'm looking for after the upgrade?

Greg

P.S. This is a little bit off-topic, but in case you were wondering why I'm replacing two perfectly functional Maxtor drives in my SVR-2000 with only 2x80GB disks (as opposed to 2x120GB, which would obviously be for the increased capacity)... Mostly, it's because the Maxtors are too noisy for my taste. It's not head-seeking noise, it's the whine of the drive motors, and it's always been just a little bit annoying. It's always been the same volume (for well over a year), so I don't think either drive is failing, but both of my TiVos are in the great room and I'd like them to be quiter. (Silent would be my first choice, but I'll settle for "quiet enough to not be heard in the breakfast nook 30 feet away".)


----------



## Robert S

That's not what we want to test. We are absolutely confident that you will get a safe upgrade with working swap.

What we want to test is putting a swap partition on your inactive root partition and transpose the partition labels for the main swap partition and the inactive root parition. This breaks lots of important things on the TiVo, but gives it 128Mb of swap, which would allow a TiVo that was stuck on a green screen for lack of swap to recover.

We are pretty sure this will work on stand alone series 1's, but DTiVoes and Series|2 are locked down to prevent modifications to the root filing system. We therefore don't know if the partition table is also checked.

If you would like to test this on the SVR, that would be very helpful. All we really need to know is that the DTiVo boots and recognises the swap partition in this configuration, we're pretty sure that the green screen will complete if that happens.

This is a fairly heavy Unix hack, which we haven't got written down yet, but there are a couple of outlines further up this thread.


----------



## gigageek

> _Originally posted by Robert S _
> *This is a fairly heavy Unix hack, which we haven't got written down yet, but there are a couple of outlines further up this thread. *


I may be your guy, but I might need a little bit of help. I've got 5 years experience as a sysadmin on SGI boxes, so I'm pretty familiar with Unix (the SGI flavor, anyway). I've also got a functioning 2-drive SVR-2000 (hacked with Dylan's Boot Disk & BlessTiVo), an unmodified T-60, three 80GB disk drives, and a willingness to hack. Heaven forbid, I've even got the time to do it this weekend. The best part is that, even if the swap hack fails on my new configuration, I've still got the fully-functional drives to start over with. 

If you give me instructions, I'll be happy to test-drive your theories. Just keep in mind my inexperience with the Linux flavor of Unix when giving me the instructions. And do I need to preserve the recordings, or can I do the speedy upgrade?

In the meantime, I'm re-reading the earlier posts in this thread that mention the heavy-duty swap hack.


----------



## Robert S

It shouldn't be destructive, but you might prefer to play it safe. 

We don't care about the recordings on the drive, or the total drive size, we already have that sorted. You might want to do a quick restore to one of your as yet unused drives to sacrifice for this test.

You should find Linux fairly comfortable if you know Irix. You'll probably need a TiVoMad or Kazymyr boot CD.

What you need to do is

Identify your inactive root partition (see the top post on this thread for detailed methods, but one will mount and the other won't).

Turn your inactive root partition into a swap partition by using mkswap. You'll need to use the -v0 option to create an 'old style' swap partition. (This is documented quite well in the top post, although the target will be hda4 or 7 instead of 8)

It might be a good idea to hose the original swap partition with 'dd -if=/dev/zero of=/dev/hdx8' to be sure the substitution is real. (If you restore with -s 128 you can be sure you've got no 'real' swap without doing this step.)

Use pdisk (TiVoMad calls it pdiska and puts it in /mad) to transpose the partition numbers on the normal swap partitions and the inactive root partition. pdisk's help should be enough to figure this out.

Boot the TiVo and report what happens, in particular, check the kernel logs and verify the swap activation.

Use pdisk to reverse the transposition and release the inactive root partition for its intended purpose. If you intend to use this disk you'll need to recreate the hosed swap partition, otherwise forget about it and do whatever the drive was intended for.

Obviously the more detail you can report on what you did and what happened, the better.


----------



## brentf

Robert, I'm about to give this a shot, but based on what I can gather, this is just a "get it back up" procedure. If this is true, is there any approach to enlarge the permanent swap file? Just a hairbrain, but what would happen if I restored my 80 Gig "A" drive to my 120 Gig "B", then did an expansion building the 128Meg swap space? It would obviously truncate any data that was on the old "B" but would it recover?


----------



## Robert S

It depends on whether you want to keep your recordings. The -s option only works on restore rather than mfsadd, so if you do a standard backup/restore to your current drive set with -s 127, you'll increase the swap partition size, but lose all your recordings.

The only way to do this and keep your recordings would be to do a pipe transfer to two new 120Gb drives (would take several days!).

Your TiVo should be fine if it recovers from the green screen. If it green screens again it probably means one of your hard drives is going, so you'll want to make arrangements to move to new drives anyway.


----------



## kyoto

Hi!

I just completed the upgrade using MFS Tools 2.0. It took a couple of hours as I chose to copy over my recordings. The only oddity I noticed was that the TiVo Suggestions were cleared. I intiated a daily call and some appeared.

I really appreciate the work you did to figure out the swap issue. I had read the article on upgrading the TiVo in the Sept 2002 Home Theater magazine and ordered 2 120 gb drives and a drive bracket from 9th Tee. As they arrived, I saw the post on the swap problems and started to sweat. I was very relieved and thankful when I saw you work out the resolution to this problem.

Now the arguments with my wife over her year old recordings can end  !

Thanks!!!

kyoto
ready for the new TV and college football seasons


----------



## gigageek

> _Originally posted by Robert S _
> *Use pdisk (TiVoMad calls it pdiska and puts it in /mad) to transpose the partition numbers on the normal swap partitions and the inactive root partition.
> 
> >>> pdisk's help should be enough to figure this out. <<<
> 
> *


I'm trying to get all my ducks in a row before I get started, but I'm stumbling over the pdisk step. The closest relative to pdisk tha I'm ware of in IRIX is "fx", but it operates very differently from pdisk. I'm still guessing that a mis-step here will render parts (or all) of the drive (and my efforts to help) unusable.

I ran pdisk -i and issued "?" for help, but this "help" was pretty thin, even by Unix standards. I don't have a "real" version of Linux on which to read the pdisk man page, so I'd be grateful for some extra help. Can you post (or PM) either the whole pdisk man page, or at least the relevant sections of it? MTIA.


----------



## Robert S

Don't read the man page, do pdisk /dev/hdc (or whatever) and look at the help available there. I seem to recall it was plenty. pdisk won't trash your disk unless you save the changes - you can mess about as much as you like.


----------



## gigageek

> _Originally posted by Robert S _
> *Don't read the man page, do pdisk /dev/hdc (or whatever) and look at the help available there. I seem to recall it was plenty. pdisk won't trash your disk unless you save the changes - you can mess about as much as you like. *


I started with the DirecTiVo (previously unmodified single-disk SAT-T60). I physically removed my XP system drive from the system (all those years of paranoid sysadmin training tought me that you can't destroy what isn't installed) and connected my TiVo A-drive to primary master, and a spare 850MB FAT32 drive to primary slave. I mounted the FAT32 drive as /mnt/dos, made my backup (mfsbackup -6so /mnt/dos/tivo.bak /dev/hda), rebooted to XP, burned the backup to CD, rebooted to linux (mfstools2 boot floppy), mounted the CD as /mnt/dos, and restored the image to an 80GB Seagate drive (mfsrestore -s 128 -zpi /mnt/dos/tivo.bak /dev/hda).

I ran pdisk /dev/hda and was told:
pdisk: No valid block 1 on '/dev/hda'

Before I started, I had tried to format the Seagate drive as FAT32 under XP - until I relized that XP only allows you to format NTFS. (I was going to dump the backup to the Seagate drive instead of cannibalizing the other FAT32 drive from another system.) Since the Seagate drive was connected to the system while XP was running, even though that was before I made/restored the TiVo images, does this mean that I've got the dreaded XP contamination mentioned at the end of Hinsdale's how-to? If so, how can I get rid of it?


----------



## Robert S

As you have a Series 1 machine, you will need to boot in a byteswapping mode. Byteswapping is broken on the MFS Tools 2.0 CD (someone want to post the boot parameters to fix it?), so you'll have to use a TiVoMad or Kazymyr CD.

Primary Master is left unswapped so you can access a FAT drive for backup. (This is mostly irrelevant as MFS Tools 2.0 has internal support for byteswapping, but you need to understand it you want to access the partitions yourself.)

XP probably has rendered that Seagate unusable, you'll probably have to restore the backup to that drive again. It is possible to reverse this change, but there's nothing special on that disk yet anyway.

You can format FAT partitions from Tom's Root and Boot Disk with fdisk (you want a type 0c partition) and mkdosfs - it's more flexible and faster than using the equivalent DOS tools.


----------



## Gomer Pyle

Robert S.:

I feel like an idiot, but the fact is, I am Linux illiterate, and need some hand holding...

I upgraded from a 40GB+80GB (created with Dylan's boot disk + BlessTiVo) to a 120GB+80GB (using the dd command, per Hinsdales guide, preserving recordings, on a Series 1 Sony, with the boot floppy off of MFS2 CD [which will NOT boot on my machine...]). I knew there was a swap file issue circling around, but went ahead and did the upgrade anyway (sounds like not such a good idea, now).

From my understanding of reading this thread the past few hours, my current set-up will run fine until something goes wrong that would require the TiVo to try to repair itself. At that point, it will be dead, since it has the original 64 MB swap file, which is not large enough to support a rebuild of a 200 GB system. I could in theory, at that point, make an emergency swap file that could get me out of the immediate jam, but not solve the problem permanently - is that close to a correct description?

Your solution in the first post, which sounds like the solution for a Series 1 SA unit, is to:
_
1. Use shell access to TiVo to run mkswap directly.

Use the shell to type

mkswap /dev/hda8 
swapon -a 
_
Is this understanding correct? Where does this command sequence specify swap file size? Is a -127 modifier not required for this command? Is this a permanent fix that will survive future upgrades (as currently understood), or is this an emergency fix?

Thanks for any reply.


----------



## gigageek

> _Originally posted by Robert S _
> *As you have a Series 1 machine, you will need to boot in a byteswapping mode. Byteswapping is broken on the MFS Tools 2.0 CD (someone want to post the boot parameters to fix it?), so you'll have to use a TiVoMad or Kazymyr CD.
> *


I get more confused the farther I get into this... That Seagate drive that pdisk didn't like after the upgrade booted just fine in my DTiVo. All my "stuff" was still there (except the actual recordings, obviously).

I re-installed my original DTiVo drive in my PC (primary slave), with the FAT32 drive as primary master & CD-ROM as secondary master. I booted the TiVomad floppy, interrupted the upgrade script, and executed:
#/mad/edit_bootparms /dev/hdb -r

All I got was the usage screen telling me what the parameters are (but no useful information).

I booted the MFSTools2.0 CD and (later) Kazymyr's Boot CD. With both boot CDs, I (alternately) specified the following boot parameters:
vmlinuz hdb=bswap
vmnodma hbdswap
<accept defaults>

(I picked up the kernel boot parameters from jhburke on the 2nd and 4th pages of this thread. Is there a functional difference between vmlinuz and vmnodma, other than display colors?)

I could get pdisk to give me a partition map, but only when accepting the default kernel boot parameters. If I specified hdb=bswap during boot, pdisk protested about "No valid block 1 on '/dev/hdb/" on my original (unhacked) DTiVo A-drive.

Under no circumstances could I get edit_bootparms to tell me anything other than the usage information (in either mad31 or mad32 on tivomad disk).


----------



## Robert S

Gomer, those instructions are for creating a normal swap partition on a machine which MFS Tools 2.0 left with no swap at all (we now know how to avoid this, but until a revised version comes out it remains a trap for the unwary and I want people to know they can fix it without running MFS Tools again).

The 'emergency swap' routine is still being worked out, but it will be /much/ more involved.

You were in the 'nightmare scenario' anyway - there's no way you could have increased your swap without losing your recordings or buying another big drive.


----------



## Robert S

GG, you're just running into byteswapping problems.

The Seagate drive is byteswapped, the way TiVo likes it, so your PC won't be able to see it unless you boot into a byteswapped environment. That means all the tools - edit_bootparm, pdisk, mount - require you to get byteswapping right. If you get it right, Linux will print the TiVo partition table as it boots. (MFS Tools 2.0 has internal support for byteswapping, so you don't normally need to worry).

Byteswapping on MFS Tools 2.0 is broken unless you use that special boot line. The reason is that it uses the vmlinuz kernel instead of vmnodma when it boots in byteswapping mode. The difference is that vmnodma has no DMA. DMA is incompatible with the byteswapping patch - if you activate them both you get DMA, but not byteswapping.

Kazymyr by default boots with swapping on hdb,c and d.

If you can't get edit_bootparms to work, try mounting the two root partitions. The one that fails to mount is your inactive root (given your current issues, make sure that the other one does mount).


----------



## BRENT

What is the difference between the swapon entries? Do they each provide the same result?

mkswap /dev/hda8 
swapon /dev/hda8

mkswap /dev/hda8
swapon -a /dev/hda8

mkswap /dev/hda8 
swapon -a


----------



## Robert S

I think swapon -a activates all the swap partitions listed in /etc/fstab whereas swapon <filename> activates the swap partition or swap file pointed to by filename. swapon -a <filename> probably produces an error.


----------



## BRENT

I used the first entry to correct my swap. The first and second entry were posted as the fix in another thread. The last one listed is in this thread. Just to clarify, which is the correct or best entry?


----------



## Robert S

The first and third are essentially equivalent as /dev/hda8 is in fstab on a TiVo, the middle one is probably a mistake.

It doesn't really matter as long as mkswap succeeds - you'll get your swap on the next reboot anyway.


----------



## gigageek

Robert S,

I appreciate all your help, but it's still a little bit unclear to me exactly which tools I'm using/testing, and in which order. I would be really grateful for some EXPLICIT instructions (at least as far as the general steps, if not the actual syntax). What I think you want me to do is:

1. Boot MFSTools 2.0 with 'vmlnodma hdb=bswap' (where hdb is my DTiVo A-drive).
2. Use MFStools2 to backup to a new drive:
#mfsbackup -6so /mnt/dos/tivo.bak /dev/hdb
3. Stop here to burn a CD-R of the backup. I know this step isn't really necessary, but I'm pretty anal about having multiple backups (you can never have too many). 
4. Boot MFSTools 2.0 with 'vmlnodma hdb=bswap' (where hdb is now the new Seagate 80GB drive).
5. Restore from the backup with -s128:
#mfsrestore -s 128 -zpi /mnt/dos/tivo.bak /dev/hdb
6. Boot the restored Seagate drive in my DTiVo, verify that I get the swap errors in /var/log/kernel:
kernel: Activating swap partitions
kernel: Unable to find swap-space signature
kernet: swapon: /dev/hda8: Invalid argument

All of the above steps will get me the "swap-hosed" upgrade that everyone who used mfsrestore -s 128 has, correct?

From this point, I'm not terribly clear what EXACTLY you want me to test. I've burned up most of the weekend groping around blindly, and the wife is getting irritated about not having TiVo while I'm working this out. Pretty soon I'm going to have to abandon ship & give her back a functional TiVO.

What I think you're asking me to do is:

7. Put the upgraded Seagate 80GB drive back in the PC (hdb), boot Kazymyr's Boot CD (with defaul boot parameters). 
8. Determine the active root partitiion:
#/mad32/edit_bootparms hdb -r
If this doesn't work (which it hasn't for me thus far), try mounting /dev/hdb4; if hdb4 mounts, this is my INACTIVE root partition (but still verify /hdb7 DOES mount).
(Assume for the rest of this discussion that 'root=/dev/hda4', so the INACTIVE root is /dev/hdb7.)
9. Create a swap file on INACTIVE partition from previous step:
#mkswap -v0 /dev/hdb7
10. Swap the partition label of the original TiVo swap partition (/dev/hdb8) and the inactive root partition (hdb7) using pdisk.
11. Put the swapped-partition drive back in the TiVo and see if it boots. If it does, check /var/logs/kernel for relevant messages.

Is this was you've got in mind? If not, please give EXPLICIT instructions.


----------



## Gomer Pyle

Robert S.

Thanks for the reply. It certainly was not clear to me that the initial post in this thread regarded units only with no swap at all. Sounds like I will be much better off in the long run if I just scrap my recordings and restore with a defined 127 MB swap. Guess I'll do that now. There really isn't much on there other than suggestions right now, so now is a good time to kill it.

You assistance is greatly appreciated.


----------



## Robert S

Step 1 is unnecessary, MFS Tools 2.0 has internal support for byte-swapping, so you can just boot normally if all you want to do is a backup/restore/expand.

I'm not quite sure where you are at the moment, if you already have a TiVo backup, restore that to the new drive. If you don't have a suitable backup, then making one is a good idea.

'-s 128' will /definitely/ get you no swap, only check it if your really paranoid. You can go straight on to the rescue procedure.

Now is the time to boot MFS Tools 2.0 with the magic incantation. If you have a Kazymyr or TiVoMad CD, that will work just as well (they're all basically variations on Kazymyr's original). You probably will have to reboot, even if you booted in a byte-swapped mode for the restore.

Step 8, if a partition mounts it's probably the active partition. I'll assume this is a typo. Make sure you get one mounting and one not mounting. If neither mount your boot environment is wrong, if both mount you'll have to look at the file dates with 'ls -l', the newer files will be on the active partition.

Other than those incidental point, that's exactly what we want. If you can write up a similar list from what you actually do, I can write that up into a How-To. I have a list of how to do it right - the beta testers' job is to work out what might go wrong.


----------



## gigageek

Robert S, thanks for the guidance. I think we have a solution here, although I'm not sure what else it might break. I have performed the following steps on my previously unhacked Sony SAT-T60 DTiVo:

1. Install FAT32 drive on hda, DTiVo A-drive on hdb. Verify the BIOS recognizes both drives before booting MFSTools 2.0 CD with default boot parameters. (Note: I think this is where most of my early problems were. Well, this and CDD: Clue Deficit Disorder.)

2. Create backup of the DTiVo A-drive:
# mkdir /mnt/dos
# mount /dev/hda1 /mnt/dos
# mfsbackup -6so /mnt/dos/dtivo.bak /dev/hdb

3. Stop here to burn a CD-R of the backup. I know this step isn't really necessary, but I'm pretty anal-retentive about having multiple backups (you can never have too many). Plus, by restoring from the CD-R backup, this verifies that the CD copy of that backup will indeed create a usable drive.

4. Remove XP drive from PC. Install FAT32 drive on hda, new Seagate 80GB drive on hdb, CD-ROM on hdc. Verify the BIOS recognizes all drives before booting MFSTools 2.0 CD with default boot parameters.

5. Restore from the CD-R backup:
# mkdir /mnt/dos
# mount /dev/hdc /mnt/dos
# mfsrestore s 128 zpi /mnt/dos/dtivot60.bak /dev/hdb

6. Boot the restored Seagate drive in my DTiVo, verify that I get the swap errors in /var/log/kernel: 
kernel: Activating swap partitions 
kernel: Unable to find swap-space signature 
kernel: swapon: /dev/hda8: Invalid argument

7. Reinstall new Seagate 80GB drive on hdb (FAT32 drive on hda, CD-ROM on hdc). Verify the BIOS recognizes all drives before booting MFSTools 2.0 CD with "vmlnodma hdb=bswap".

8. Determine active root partition:
# cd 
# mkdir /mnt/tivo/4
# mount /dev/hdb4 /mnt/tivo/4
# ls l /mnt/tivo/4
<most-recent date was June 14, slightly more than 2 months ago>

Per Robert S, this suggests that hdb4 is the active partition. To verify, I did:
# umount /dev/hdb4
# mkdir /mnt/tivo/7
# mount /dev/hdb7 /mnt/tivo/7
mount protested with "mount: you must specify the filesystem type."
From this, I concluded that root=/dev/hdb4, and hdb7 is the INACTIVE partition.

I suppose that if I were slightly more clever (or more familiar with TiVo disk partitions), I could have drawn the same conclusions from the partition map:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
4: Ext2 Root 1 262144 @ 75153472 (128.0M)
7: Ext2 Root 2 262144 @ 75423808 (128.0M)
8: Swap Linux swap 262144 @ 75685952 (128.0M)

9. Create a swap file on the INACTIVE root partition (hdb7):
# mkswap v0 /dev/hdb7
output from the above command was:
mkswap: warning: truncating swap area to 130752kB
Setting up swapspace version 0, size = 133885952 bytes

10. Reorder the original TiVo swap partition (hdb8) and the inactive root partition with newly-created swap (hdb7):
# pdisk /dev/hdb
Command (? For help): r <for reorder partition entry in map>
Partition number: 8
New number: 7
Command (? For help): w <for write the partition table>
Writing the map destroys what was there before. Is that okay? [n/y]: y

This reordered the partition table as shown:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
7: Swap Linux swap 262144 @ 75685952 (128.0M)
8: Ext2 Root 2 262144 @ 75423808 (128.0M)

11. Install pdisk-modified A-drive back into DTiVo, power up, enable back doors, search /var/log/kernel:
kernel: Activating swap partitions
kernel: Adding Swap: 130744k swap-space (priority -1)

12. Does this warrant a WOOHOO!?


----------



## gigageek

Since I don't know whether TiVo cares about the partition names and types (it seems unlikely to me, but what do I know?), I used pdisk to delete & recreate partition names to match what they looked like before I reordered them in step 10 (previous post). Continuing where I left off:

13. Use pdisk to delete/recreate partitions 7 and 8.
# pdisk /dev/hdb
Command (? For help): d (for "delete partition")
Partition number: 7
Command (? For help): C (for "create with type specified")
Partition number: 7
First block: 75685952 Use the number shown for partition 8 for *YOUR DRIVE* in Step 8 above.
Length in blocks: 262144
Name of partition: "Root 2" (quotes are required)
Type of partition: Ext2
Command (? For help): d (for "delete partition")
Partition number: 8
Command (? For help): C (for "create with type specified")
Partition number: 8
First block: 75423808 Use the number shown for partition 7 for *YOUR DRIVE* in Step 8 above.
Length in blocks: 262144
Name of partition: "Linux swap" (quotes are required)
Type of partition: Swap
Command (? For help): w (for "write the partition table")
Writing the map destroys what was there before. Is that okay? [n/y]: y

This reordered the partition table as shown:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
7: Ext2 Root 2 262144 @ 75685952 (128.0M)
8: Swap Linux swap 262144 @ 75423808 (128.0M)

I didn't even have to recreate the swap space on partition 8. (Actually, I tried, but mkswap correctly pointed out that there was already swap space on that partition: I didn't really modify the *contents* of the various partitions, I just moved entries around in the partition table.)

14. Install pdisk-modified A-drive back into DTiVo, power up, enable back doors, search /var/log/kernel:
kernel: Activating swap partitions
kernel: Adding Swap: 130744k swap-space (priority -1)

Robert S: Will this fix the GSOD/reboot loop that some people have?


----------



## gigageek

After working out the steps that (I hope) will repair the swap partition and end the GSOD/reboot cycle on boxes that previously upgraded with -s 128, I upgraded my Sony SAT-T60 DTiVo using -s 127. A quick check of /var/log/kernel revealed:

kernel: Activating swap partitions
kernel: Adding Swap: 130044k swap-space (priority -1)

So, just as Robert S stated (ever so clearly) a few pages back, *-s 127 definitely will give you a good backup with active swap* .   

All my recordings are present & play (resuming from exactly where I left off prior to upgrading). System Information says my recording capacity is now "Variable, up to 67 hours" (single 80GB drive). So, according to SI, I doubled the size of the drive and got LESS than double the recording capacity (despite the fact that there's no OS on the extra 40GB of space I added). Does this seem right to people? 

Prior to upgrade, SI said "Variable, up to 35 hours" but stuff started getting deleted when the drive got between 25 & 30 hours of stuff recorded. Was the 35 hours hard-coded on the unhacked boxes because that's what they were marketed as? In any case, an extra 30 hours will carry me long enough for my local computer store to get another Seagate 80GB drive in stock  (I bought the last 3 they had on Friday, and 2 of them are slated for my SA).

Next up: Back up my Sony SVR-2000 with -s 128 and verify the fix I posted earlier this morning will repair the swap partition. What's the little emoticon for "gesture of fingers crossed for luck"?


----------



## Robert S

Outstanding work giga!

The only bit I didn't quite follow was the back-out. It didn't apply to you because you already had a partition large enough to be the inactive root, but everyone else will want to revert to exactly the partition table they had before they changed it so their TiVoes will take the next software upgrade.

If you repeat the procedure, could you jot down the precise pdisk sequence needed to get back to where you were. I think it's obvious, but I'd like to write 'this has been tested'.

Also, how could you tell from the partition table which is the active root partition? I don't think a software upgrade changes the partition names, so either Root 1 or Root 2 could be active depending on how many updates you've had.


----------



## gigageek

> _Originally posted by Robert S _
> *1. If you repeat the procedure, could you jot down the precise pdisk sequence needed to get back to where you were.
> 
> 2, Also, how could you tell from the partition table which is the active root partition? I don't think a software upgrade changes the partition names, so either Root 1 or Root 2 could be active depending on how many updates you've had. *


Thanks, Robert. It's nice to give back to the TiVo community that has helped me before. People should probably take that approach IRL more often...

1. The precise pdisk sequence needed to get back to where I was WHEN? I think I understand that you're saying it was fortuitous (for me) that I used -s 128 because that meant the inactive root & swap partitions were the same size & I could just swap them. I'm pretty sure this won't work if someone did -s 512 (or any number greater than 128). Do you now want me to delete & recreate partitions 7 and 8 to look like they did in Step 8 (before I swapped them)?

2. DOH!!! I guess I'm not so clever as I thought I was when I posted that. I thought "Root 1" meant active, "Root 2" meant inactive. (This is why I always reserve the right to be wrong.)


----------



## Robert S

If you have a 128Mb hole, like you did, you can just make a swap partition on that. The people who will need this hack have a full disk with a 64Mb swap partition, but they can take over their inactive root partition to be a larger swap partition until their TiVo fixes itself, but they'll need their original, 128Mb root partition for the next upgrade.

So we need the pdisk sequence to get back to how the partitions were _before you changed them with pdisk_.


----------



## gigageek

I restored the A-drive to its original partitions, although I stumbled at one step (I forgot to do mkswap after switching partitions back).

15. Reinstall new Seagate 80GB drive on hdb (FAT32 drive on hda, CD-ROM on hdc). Verify the BIOS recognizes all drives before booting MFSTools 2.0 CD with "vmlnomda hdb=bswap".

16. Use pdisk to delete/recreate partitions 7 and 8.
# pdisk /dev/hdb
Command (? For help): d (for "delete partition")
Partition number: 7
Command (? For help): C (for "create with type specified")
Partition number: 7
First block: 75685952 Use the number shown for partition 8 for *YOUR DRIVE* in Step 8 above.
Length in blocks: 262144
Name of partition: "Linux swap" (quotes are required)
Type of partition: Swap
Command (? For help): d (for "delete partition")
Partition number: 8
Command (? For help): C (for "create with type specified")
Partition number: 8
First block: 75423808 Use the number shown for partition 7 for *YOUR DRIVE* in Step 8 above.
Length in blocks: 262144
Name of partition: "Root 2" (quotes are required)
Type of partition: Ext2
Command (? For help): w (for "write the partition table")
Writing the map destroys what was there before. Is that okay? [n/y]: y

This reordered the partition table back to the way it was in Step 8 (before I swapped partitions) as shown:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
7: Ext2 Root 2 262144 @ 75423808 (128.0M)
8: Swap Linux swap 262144 @ 75685952 (128.0M)


At this point, I re-installed the drive back in the DTiVo, but it couldn't mount the swap because I had forgotten to create it. (DOH!!) Back to the PC, again boot MFSTools 2.0 CD with "vmlnomda hdb=bswap", then:
# mkswap -v0 /dev/deb8

17. Install pdisk-modified A-drive back into DTiVo, power up, enable back doors, search /var/log/kernel:
kernel: Activating swap partitions
kernel: Adding Swap: 130744k swap-space (priority -1)

Once I figured out what is was that I was supposed to be doing, this whole process wasn't that painful (except for my occasional ineptness, e.g., forgetting to run mkswap at end of Step 16). I'm pretty certain that the difficulties I had getting started were related to one of two things:

*A. Forgetting to make certain the BIOS recognized all devices connected to the system.* This step doesn't exist on the SGI boxes I'm most familiar with, and I don't upgrade PCs often enough for this to become an ingrained habit. I'm pretty certain I've developed this habit now, although I'm equally certain it will wear off after about 5 or 6 sleep cycles.

*B. Getting byte-swapping hosed up on the different boot floppies/CDs that I used.* As with all things Unix, the learning curve was pretty steep here. To be clear, any how-to for fixing the swap issue should include the following statement (or similar): Accept the default boot parameters when booting the MFSTools 2.0 CD for running mfsbackup/mfsrestore/mfsexpand, but be advised that pdisk will not run properly; when booting this CD to run pdisk, use "vmlnomda hdX=bswap" boot parameters (where X is the TiVo drive ID), but be advised that mfsbackup/mfsrestore/mfsexpand will not work properly.

NOTE: I never did figure out how to make pdisk work with TiVomad floppy or Kazymyr's Boot CD, mostly because I stopped trying once I got pdisk to work with MFSTools 2.0 CD. I'm certain it was just operator malfunction.

Robert: I assume the process for repairing a 64MB swap partition that locks on GSOD/reboot loop would be exactly the same, but the block numbers would be different. I'd rather not spend the time verifying this if you concur, and I'm going to need that drive soon. (I'm currently working the same hack on my SVR-2000.) Are we done with the DTiVo swap-fix hack?


----------



## Robert S

Brilliant!

You're quite right, once you've done it, everything that seemed so difficult seems trivial - I'm sure if you boot Kazymyr now, everything will work perfectly. That's mainly why I wanted someone else to do it - I knew you'd fall into any hole I left I my explanations, so I can now be sure everything is covered.

Can you not use r to renumber the partitions back the way they were? Doesn't r 8 7 do the trick? Or do the labels get mucked up?


----------



## gigageek

> _Originally posted by Robert S _
> *Can you not use r to renumber the partitions back the way they were? Doesn't r 8 7 do the trick? Or do the labels get mucked up? *


I'm pretty sure you could do that, but I had hosed up the labels in Step 13 (operator malfunction).

Rather than re-label the partitions when I do my SVR-2000, I'll just swap them, do mkswap, verify swap activation in tivo, and then swap them back. I'll post how it works out.


----------



## Robert S

OK, I've written your work up and posted it as the second post on this thread (fortunately I have several posts on the first page, and that post contained outdated info).

If you'd like to read it through and point out mistakes/improvements...


----------



## gigageek

This hack was performed on a Sony SVR-2000 that was hacked in March or April 2001 with Dylans Boot Disk. This SA TiVo had a 30GB (Maxtor 33073H3) A-drive and an 80GB (Maxtor 98196H8) B-drive.

1. Install the drives in the following order:
hda: 30GB TiVo A-drive (Maxtor 33073H3)
hdb: 80GB TiVo B-drive (Maxtor 98196H8) 
hdc: CD-ROM
hdd: FAT32 drive
Verify the BIOS recognizes all drives before booting MFSTools 2.0 CD with default boot parameters.

2. Create backup of the TiVo A-drive:
# mkdir /mnt/dos
# mount /dev/hdd1 /mnt/dos
# mfsbackup -6so /mnt/dos/svr2000.bak /dev/hda /dev/hdb

3. Stop here to burn a CD-R of the backup. I know this step isn't really necessary, but I'm pretty anal-retentive about having multiple backups (you can never have too many). Plus, by restoring from the CD-R backup, this verifies that the CD copy of that backup will indeed create a usable drive.

4. Install the drives in the following order:
hda: FAT32 drive
hdb: new 80GB (Seagate ST380021A) drive
hdc: CD-ROM
Verify the BIOS recognizes all drives before booting MFSTools 2.0 CD with default boot parameters.

5. Restore from the CD-R backup:
# mkdir /mnt/dos
# mount /dev/hdc /mnt/dos
# mfsrestore s 128 zpi /mnt/dos/svr2000.bak /dev/hdb
The -s 128 hoses up the swap partition (intentionally), as documented earlier in this post.

6. Boot the restored Seagate drive in my TiVo, verify that I get the swap errors in /var/log/kernel: 
kernel: Activating swap partitions 
kernel: Unable to find swap-space signature 
kernel: swapon: /dev/hda8: Invalid argument

7. Reinstall new Seagate 80GB drive on hdb (FAT32 drive on hda, CD-ROM on hdc). Verify the BIOS recognizes all drives before booting MFSTools 2.0 CD with vmlnodma hdb=bswap.

8. Determine active root partition:
# cd 
# mkdir /mnt/tivo/4
# mount /dev/hdb4 /mnt/tivo/4
# ls l /mnt/tivo/4
<most-recent date was June 11, slightly more than 2 months ago>

Per Robert S, this suggests that hdb4 is the active partition. To verify, I did:
# umount /dev/hdb4
# mkdir /mnt/tivo/7
# mount /dev/hdb7 /mnt/tivo/7
mount protested with mount: you must specify the filesystem type.
From this, I concluded that ACTIVE root=/dev/hdb4, and hdb7 is the INACTIVE partition.

9. Create a swap file on the INACTIVE root partition (hdb7):
# mkswap v0 /dev/hdb7
output from the above command was:
mkswap: warning: truncating swap area to 130752kB
Setting up swapspace version 0, size = 133885952 bytes

10. Reorder the original TiVo swap partition (hdb8) and the inactive root partition with newly-created swap (hdb7). The original partition table was:
Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
7: Ext2 Root 2 262144 @ 56929344 (128.0M)
8: Swap Linux swap 262144 @ 57191488 (128.0M)
# pdisk /dev/hdb
Command (? For help): r <for reorder partition entry in map>
Partition number: 8
New number: 7
Command (? For help): w <for write the partition table>
Writing the map destroys what was there before. Is that okay? [n/y]: y

This reordered the partition table as shown:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
7: Swap Linux swap 262144 @ 57191488 (128.0M)
8: Ext2 Root 2 262144 @ 56929344 (128.0M)

11. Install pdisk-modified A-drive back into TiVo, power up, enable back doors, search /var/log/kernel:
kernel: Activating swap partitions
kernel: Adding Swap: 130744k swap-space (priority -1)

12. Reinstall new Seagate 80GB drive on hdb (FAT32 drive on hda, CD-ROM on hdc). Verify the BIOS recognizes all drives before booting MFSTools 2.0 CD with vmlnodma hdb=bswap.

13. Reorder swap and inactive root partitions back to their original conditions:
# pdisk /dev/hdb
Command (? For help): r <for reorder partition entry in map>
Partition number: 8
New number: 7
Command (? For help): w <for write the partition table>
Writing the map destroys what was there before. Is that okay? [n/y]: y

This reordered the partition table back to the way we started, as shown:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
7: Ext2 Root 2 262144 @ 56929344 (128.0M)
8: Swap Linux swap 262144 @ 57191488 (128.0M)

14. Create swap space on TiVo swap partition (hdb8). This was never created if upgrade was performed with s 128.
# mkswap v0 /dev/hdb8
output from the above command was:
mkswap: warning: truncating swap area to 130752kB
Setting up swapspace version 0, size = 133885952 bytes

15. Install pdisk-modified A-drive back into TiVo, power up, enable back doors, search /var/log/kernel:
kernel: Activating swap partitions
kernel: Adding Swap: 130744k swap-space (priority -1)

Another satisfied TiVo box.


----------



## gigageek

Boy, I wish I had your instructions when *I* started on this. 

My suggestions (and they are for MINOR changes):
1. Rename section C to "Prepare the *inactive* partition as a swap partition." (Change in 2 places.) I think this makes it just a little bit clearer for someone unfamiliar with TiVo disk partitions.
2. Include in section B the alternate method of attempting to mount partitions 4 and 7: the active partition mounts, the inactive partition will not. This allows the whole process to be run from MFSTools 2.0 CD. People with low-bandwidth connections will appreciate not having to download another large boot image if all they have is the MFSTools 2.0 CD.
3. The title for section D didn't get underlined properly due to a vB Code typo.

One other typo that's in your first post: The synatx for edit_bootparms is
# /mad/edit_bootparms hdb -r
(not /dev/hdb).

And the reason why I could never get edit_bootparms to work was because I was using MFSTools or (plain) TiVomad, not DTiVomad.

"It's all become clear to me now."
--Dave Bowman


----------



## Robert S

Thanks for that. If anyone else spots something that's wrong, unclear or out-of-date with those top posts, do say. The intention is to summarise the current info that's in this thread without people having to read down to here to get it.


----------



## deek_man

First, thanks to all the folks who have worked so hard to solve the swap problem. I have a couple of quick questions about fixing this problem when/if it occurs and about the instructions for a fix in Robert S's second post on the first page of this thread.

A couple of months back, I upgraded a Philips series 1 standalone using two 100gb Maxtor drives for a total of 200 gigs. I used MFSTools 2.0 but did not specify a swap partition. I checked the log files and I have 64 mb of swap. I understand this could be problematic if mfsfix runs to repair corrupted files. This has not happened yet and the box appears to be operating normally. Here's the questions:

1) Do you still believe we should not fix the swap if the box is operating normally and only initiate a fix if the green screen freeze occurs?

2) Regarding the fix directions: Do you type "vmlnodma hda=bswap" after booting normally with the MFSTools 2.0 CD? (I think that's what step A. is saying.)

3) In step D. of the directions, you renumber the partitions and then in step F. you restore the original partition numbers. Does this mean that the inactive root partition (4 or 7) is the opposite partition for Step F compared to what it was in Step D?

Again, thanks for all the help.


----------



## Robert S

64Mb of swap will only cause a problem if you green screen. There's no way to increase swap without losing your recordings, so if you want to keep them you don't have much choice. The emergency fix should work well enough for you to feel safe with 64Mb of swap.

You type the magic incantation at the boot: prompt - it changes the way it boots. Would you like to try it and suggest a clearer form of words?

You want to get the partition table back the way it was before you started. Thus the partition numbers are the same as in step D.

Thankyou for you comments.


----------



## drewba

I'm thinking that there is still a hole in the Hinsdale-How-To. In step 8 it directs us to mfsrestore the image to the new larger upgrade drive using an -s 127 switch to test the backup. However, assuming the backup works, those adding a B drive use their original A drive and run an mfsadd to add the new B drive. Thus the swap has never been actually been increased. Am I looking at that correctly?


----------



## Robert S

That's not how I read it, he's telling you to restore to the new drive, expanding swap. If you want to use your old A drive too you should add it as a B drive.

If you want to keep your recordings, it's better to do a pipe transfer rather than just blessing a B drive.


----------



## drewba

> _Originally posted by Robert S _
> *That's not how I read it, he's telling you to restore to the new drive, expanding swap. If you want to use your old A drive too you should add it as a B drive.
> 
> If you want to keep your recordings, it's better to do a pipe transfer rather than just blessing a B drive. *


But Upgrade Configuration #1 in step 10 is adding a new B drive to any Single Drive TiVo and keeps your recordings. I would hazard a guess that this is the most common upgrade, but it seems to me that doing this upgrade following the directions will result in a swap file that isn't increased to 127MB.


----------



## Robert S

The only way to save your recordings and increase swap is to do a pipe transfer (basically MFS Tools 2.0 can only increase swap if it's doing its restore function). It makes sense to do this instead of blessing, even if you're not going over the limit. 

Despite the simplicity of blessing, if you don't increase swap it's very difficult to increase swap if you want to upgrade further and keep your recordings (adding swap would be a very similar process to the 'rescue' hack at the top of this thread, but you'd use pdisk to create a partition to relabel, rather than using the root partition).

The trouble is, to explain this properly would add at least a page to Hinsdale. Unfortunately, if you don't understand this, you might conclude that a TiVo stuck in a green screen loop is unrecoverable, whereas infact it can be recovered with a clever hack.

It would be nice to say to everyone who upgrades, 'if you go over 140Gb and you didn't expand your swap, tape a note with the address of the Upgrade Forum inside the lid - you'll know when you need it'.


----------



## deek_man

Thanks for the help, Robert. But if one wanted to save their recordings before a green screen freeze AND repair the swap partition for a 200gb system with only 64 mb of swap, could one use:

mfsbackup -Tao - /dev/hdx | mfsrestore -s 127 -xpi - /dev/hdy /dev/hdz


----------



## Robert S

That's what I mean by 'a pipe transfer' - the '|' character is pronounced 'pipe'.

It's not always possible to do this - if you want to upgrade the A drive of a twin drive machine without losing recordings, for example. You can increase swap between running dd and mfsadd, but the process is just as complex as the 'rescue' procedure.

I agree that Hinsdale skates over an important issue by not mentioning swap issues. Advising everyone to use -s 127 is a good start, but to cover it properly you'd have to explain:

What swap is
You need more swap >140Gb
Most upgrades can increase swap by using -s 127
Most of the rest can increase swap by using a pipe transfer instead of blessing or dd + mfsadd. And that despite the extra pain this causes, it's well worth it.
A drive expansions on twin drive machines can not expand swap without losing recordings, but there is a hack you can use if you want.
If you go over >140Gb without expanding swap your TiVo will get stuck in a green screen loop if it gets filesystem corruption. If this happens, there's a hack to recover your TiVo without losing your data or recordings.
As there's already so much in Hinsdale, I can appreciate he's reluctant to add more. New Hinsdale was written from Tiger's documentation, which claims that you don't need more swap if you use MFS Tools 2. This has since been proved false. One could argue that in the light of that discovery, it needs a major overhaul.


----------



## mrtickle

The last bullet point is the single most important omission IMHO. It should be screamed in huge letters at the start of the document!

I bet there are thousands of people out there with machines >140GB and only the default size swap. Not just MFStools2 upgrades, but older ones too. I only found out by a fluke chance just in time before I did my own upgrade.


----------



## BobCamp1

Also, upgrade kits should be avoided! Ordering a large pre-blessed drive and installing it will make your Tivo unstable. The full upgrade service has to be used (where you ship the entire Tivo), and you have to be smart enough to insist the service also increase the swap file size using MFSTools 2.0. 

This could put Hindsdale and others who have performed upgrades in trouble, since they have been unintentionally screwing up some (but not all) of the Tivos. And people who were too scared to do the upgrade themselves are surely not going to want to run the emergency fix procedure. Some of these people will demand a free fix or demand to be reimbursed the $100 they had to pay Tivo to have them fix it.

Without Hindsale's instructions, I would have never attempted the upgrade in the first place. My guess is that around 70% of the people simply want to add a new drive. Those instructions are incomplete. It's not his fault (it's actually Tiger's), but he needs to fix them.


----------



## jhburke

I have been following this thread with a lot of interest, and I am impressed with the clever work of the contributors in figuring out the swap problems. However, I'm not so sure that the old "BlessTiVo" method is necessarily bad.

It seems that large upgrades (ie 30 + 120) have been performed for a while, using the old tools, but no problems reported until MFSTools 2.0 was released. Then, shortly after MFSTools 2.0, there was a torrent of reports about GSOD and failures from inadequate swap. It doesn't seem possible to me that sudden drive failures causing GSOD should suddenly start occuring once 2.0 tools are used - perhaps the problem doesn't occur with mfstools 1.1 or BlessTivo. PTVupgrade stated in an earlier post in this thread that he's never had this type of problem despite never increasing swap. Perhaps mfstools 2.0 increases the swap requirement rather than decreasing it, and perhaps a 30 +120 upgrade with BlessTiVo can recover from GSOD with 64M swap.

Of course, I don't know the answer, but it might be interesting if someone could test this theory (hint-hint anyone?). Then all the people with older upgrades and default swap may not need to panic yet.

John


----------



## mrtickle

Systems >140GB have always needed more swap. Always! This is unfortunately not made clear in the guides - that was my point and is my only criticism of the guides. *Everyone who has >140GB and only default swap has a TiVo which WILL crash and go into an infinite reboot loop if it ever gets a GSOD!* The only get-out is to pull the drives and perform the procedure to give emergency extra swap as detailed earlier in the thread.

There was a separate problem whereby anyone following the instructions (-s 128) ended up with no swap at all. People who then had GSODs (for whatever reason) then found themselves in trouble. Initially it was thought that less swap would be needed for mfsfix with the bigger blocksize that MFStools uses by default. The complete lack of swap may have induced many of the GSODs. This happened to lots of people at the same time so that's why the issue got a lot of attention.


----------



## Robert S

A 150Gb TiVo might just squeak through a GSOD. Merle Corey published his best estimate of the formula needed to estimate the precise amount of swap needed. Above about 155Gb there's no possibility of recovering. The swap requirements for MFS Tools 2.0 are exactly the same as for any other tool, despite the MFST2 docs repeatedly saying it's more efficient.

I don't think there was a flood of people getting green screens - in fact quite the reverse, there was a nasty gap between embeem pointing out there was a problem and reports coming in from others confirming it.

I don't think the absence of swap causes any real problems for the media side of TiVo - the guide and indexer get gummed up, but the video side is fine.

There were a lot of people talking about the _risk_ of a GSOD, but only a few actually experience one.

This problem has always existed - TiVoMad will increase your swap for exactly the same reason - but larger drives and inaccurate claims of MFS Tools 2's powers make it more visible.


----------



## muchmore44

I just want to say thanks to Hinsdale and Tiger for giving us TiVo users a way to maximize a terrific technology, as well as to Robert S. and Merle C. for refining the swap expansion/correction process. 

Last night, I upgraded my Hughes DirectTiVo from 35 hours to 106 hours (went from 40 GB to 120 GB) and it couldn't have gone better! It took approximately 1 hour, 30 min, mostly because I was very, very careful - I could have done it faster, but I didn't want to take any chances. MFSTools 2.0 are the best! 

I am the happiest guy in the world right now (at least until the next person upgrades a Tivo!) and wanted to thank you guys for all that you have done. 

You guys are Saints! 

Thanks, 
Muchmore44


----------



## BobCamp1

Note that your system merely becomes unstable with "only" a 64 MB swap file. "Unstable" in the sense that the Tivo will crash very infrequently, but it will crash so hard as to be unusable. Tivo only runs mfsfix under normal conditions when the file system on the hard drive gets really screwed up. 

This usually happens when the hard drive is failing anyway, so those people simply attributed their misbehaving Tivos for a bad hard drive. 

However, since Tivo doesn't have an "off" switch, and it constantly writes to the hard drive, you're at a low risk every time you unplug the Tivo. And when the power flickers at your house, too. 

Also there is an issue of timing:

1. 100 and 120GB hard drives just became affordable enough to buy this summer. An 80GB hard drive, even when combined with a Series 2 60 GB Tivo, will not exhibit this problem.

2. Series 2 units and newer DirecTivos (with their larger factory-shipped capacity) started shipping earlier this year. 

3. MFSTools 2.0 also came out at about the same time. The -s 128 "bug" was causing a different set of problems and was adding to the confusion.

4. Power to your house (and Tivo) was flickering on and off from thunderstorms this summer. This could trigger mfsfix to run on your Tivo and expose the problem.

Basically, we were doing bad upgrade procedures the entire time. But it wasn't until this summer that a bunch of things converged to magnify the problem.


----------



## hinsdale

I think this thread might be more useful if someone were to do some more definitive testing to determine the actual upgrade capacity that will fail to recover from GSOD with 64MB Swap (taking into account 16 vs 32MB RAM) - not forumula approximations. I do not have time to do this currently but before unnecessarily concerning people with statements like "your unit will not recover from a GSOD if you are over 140GB", I believe some more testing is in order (results labeled GB or GiB). This issue is not new, and having witnessed posts, interchange, etc of thousands of upgraders adding 120GB drives to their 20, 30, 40, 60GB units without increasing swap and without widespread failure or even any pattern of failure - I am not sure this issue rises to the crisis level portrayed. I would be interested,however, in determining the actual trigger number. If I am not mistaken, my 160GB DirecTiVo with unmodified swap has recovered from GSOD, which makes me dubious of the trigger numbers being fowarded recently.


----------



## enigma2175

I may have missed this somewhere in this quite large thread, but couldn't a recovery from an unrecoverable (mfsfix crash because of lack of swap) go like this:

1. Get diagnostic prompt, append HANDCRAFT=TRUE RUNMYWORLD=FALSE to boot parameters. (assuming a bash prompt modification)

2. At bash prompt make sure current swap is valid : 
mkswap /dev/hda8
Check kernel logs to make sure swap is being enabled.

3. If mfsfix is still crashing (You have way to much space for your own good) create a swapfile on your current /var partition.
dd if=/dev/zero of=/var/SWAPFILE bs=1024 count=64000
mkswap /var/SWAPFILE

4. Add the swap to start at boot. Append 
/var/SWAPFILE swap swap defaults 0 0
to /etc/fstab

You now have 128 MB of swap without altering the partition layout. Takes some space in /var, but it should at least get you up and running.

Has this already been proposed and I just missed the post?


----------



## enigma2175

... or you could put a 32 MB swapfile in / and in /var (I'm not sure if /var is already mounted when mfsfix runs, but it most likely is).


----------



## enigma2175

Hmm, I shouldn't post before I think (hint: swap isn't much good on a read-only filesystem  ) Disregard that last idea... But the swapfile in /var should still work.


----------



## Robert S

Glad you're thinking about this issue. A bit of brain-storming never hurts.

The immediate problem with all your suggestions so far is that DTiVoes and S2's are locked down. The other problem, of course is that this procedure is actually more difficult than the rescue or the manual swap creation (got that written up at last. Thanks to angra).

If you wanted to use the space on /var for swap, wouldn't it be better to change the partition table to shrink /var and expand partition 8? (You would then run mke2fs on hdx9 and mkswap -v0 on hdx8). This should work on any TiVo.

My advice is still, expand swap if you can, try not to worry about it if you can't/didn't - just remember the rescue maneuver exists if you need it.


----------



## enigma2175

> If you wanted to use the space on /var for swap, wouldn't it be better to change the partition table to shrink /var and expand partition 8? (You would then run mke2fs on hdx9 and mkswap -v0 on hdx8). This should work on any TiVo.


I like to change my partition table as little as possible . Assuming this is an upgrade gone wrong, it is very possible there are a number of things in /var that you want to keep. Also, if you have the swap broken up into multiple partitions/files, you can have over 127 MB of swap. I don't know that anybody NEEDS more than 127 MB (with only 16MB of RAM..Yikes!) but it's nice to know that it can be done if needed. Also, if you have (had) a Bash prompt on your TiVo you do not need to take out your drive. The constant swapping of the hard drives back and forth beween the TiVo and the computer is not good for the drive. The interface and jumper pins can get bent or broken, the drive can get dropped, or the controller board can get toasted from an ESD. I prefer to keep my drive in my TiVo whenever possible.


----------



## Robert S

Fair enough. 

Merle calculated that 127Mb of swap is enough for the largest currently possible (274Gb) TiVo to recover from a GSOD, but if you're only just over the limit a small swap file on /var might do the trick.


----------



## Merle Corey

> _Originally posted by hinsdale _
> *I think this thread might be more useful if someone were to do some more definitive testing to determine the actual upgrade capacity that will fail to recover from GSOD with 64MB Swap *


On the one hand, I'm not sure I care.  My goal when I started testing was to prove one of two things - either that MFST2 was broken and to be avoided at all costs or that it worked (consistently) with the right "adjustments." That the only adjustment needed was a command line flag (and some misconceptions) was pure gravy.

On the other hand, you raise a valid point - knowing the exact "at risk" threshold could be useful.

Of course, it's been done. It's in the FAQ, in the segment on Question #7. "Around 150GB" was the result, which dovetails nicely with the predicted 140GiB result.

It's also been documented by several people that 160GB is too big.

My replacement TiVo arrives Monday - I can put this to the test then if we think it's really that important. So my questions are:

* Do we really care where, exactly, it breaks, or is our current information close enough? Is an exact value at all meaningful when it applies only to one specific hardware platform? Is it better to have a more arbitrary but safer threshold value that acts as a general rule of thumb, or to have exact breaking points on all platforms?

Personally, I think it's close enough. In fact, I'd hedge a little anyway just to play it safe (which is why I still say 140GB most of the time instead of the down to the wire 140GiB/151GB). As Robert has pointed out, that leaves the door open for less painful future upgrades. That said, I'm still willing to look into this.

Beyond that, nobody is saying there's a crisis - we're just trying to get the word out that people with >140GB configurations may experience greenscreen loops _iff_ they have filesystem errors...and let's face it, (real) filesystem errors aren't that common in non-failing equipment anyway.

It's a warning. The sky isn't falling, but it may hail later in some areas.

* If our current information isn't close enough, how close *is* close enough? The exact value? Is confirmation that 160GB is too much but that 140GB is safe good enough?

Finally, a comment on my formula: It's already proven accurate to within 5MiB on smaller (20 - 120GB) capacities and within 10MiB on larger (240GB). The only reason it's not nailed down tighter than that is that I didn't take the time to determine exact breaking points - the margin of error is the margin from my limited tests, not from the formula. If there's interest, I can also determine the exact margin of error - assuming there's a measurable one - if/when I do any further tests.

Personally, I don't think there's need for it - we know 64MiB isn't always enough, we know 127MiB is enough for all (128GiB limited) configurations. Does it matter beyond that point?

MC


----------



## gigageek

> _Originally posted by Merle Corey _
> *Personally, I don't think there's need for it - we know 64MiB isn't always enough, we know 127MiB is enough for all (128GiB limited) configurations. Does it matter beyond that point?*


Merle has the right idea, IMO: 127 is an "engineering solution". If it turns out that someone nails down a magic number of 125 (or 118 or ...) for a particular drive capacity, is anyone seriously going to suggest they *NOT* use 127?

I also think Hinsdale has a valid point that it is not a mathematical certainty that *every* >140GB configuration will "not recover" from a GSOD. (The proof, however, is "left to the student".  ) While hard drives are fairly reliable, enough of them fail that we probably would have seen more units with the GS/reboot loop if this were *guaranteed* to be a problem under all circumstances.

Perhaps Robert's second post could be softened to say:


> If you have more than 140Gb of hard drive space in your TiVo, the original 64Mb of swap space *might* not provide enough memory for the filesystem checker (mfsfix) to repair corruption to the filesystem.





> _Originally posted by Robert S _
> If you go over 140Gb and you didn't expand your swap, tape a note with the address of the Upgrade Forum inside the lid - you'll know when you need it'.


This is probably the best advice I've seen on the subject. It tells the reader, "Don't panic, remain calm, your house is probably not on fire. But you might want the phone number of the fire department handy, just in case it catches fire at a later date."


----------



## DCIFRTHS

I have been following this thread since it's inception, and there has been a lot of information. I would like to ask a very simple question:

Can I create a TiVo that contains 2 x 120 GB* hard drives using MFS Tools 2.0, and a command line to create a 127 meg swap file, that will successfully complete mfsfix if the TiVo crashes?

* Please note that when I specify 120GB drives I am going by the size listed on the Maxtor box. 

I'm going to read through the documentation, determine the correct procedure, and then post back here before I upgrade, so that if I make any mistakes, hopefully someone will spot it and point it out to me.


Thanks all !


----------



## Robert S

127Mb swap is a complete fix for all the problems this thread has addressed. It has been tested on a 240Gb TiVo and calculated for a 274Gb TiVo (the largest currently possible).

If you follow New Hinsdale, MFS Tools 2.0 will expand your swap for you (the -s 127 option).


----------



## mnc042

> If you follow New Hinsdale, MFS Tools 2.0 will expand your swap for you (the -s 127 option).


But, reading Hinsdale, if I have a DirecTiVo with a single A drive, and I want to simply add a new, 120GB B drive, isn't there that hole in the instructions that was mentioned back a ways?

i.e., the instructions basically tell you to backup your A drive, restore that backup on to your new B drive, then expand/mate that new B drive to your original A.

In this scenario, the A drive's swap is *not* expanded, and you wind up with 160gb and 64mb swap.

Or did I miss something in Hinsdale?

Thanks!
\marc


----------



## Robert S

That's right, Hinsdale's instuctions for that scenario are unhelpful. I don't have any control over what's in Hinsdale - and what he says is right, it's just some of the advice as to when to do what assumes you don't need to expand swap.

Hinsdale does describe the pipe transfer technique in a different context. Create your A drive with a pipe transfer and MFS Tools 2.0 will copy your recordings and expand your swap (you can even fill the drive and bless in your B drive in one step, if you want).

To 'fix' New Hinsdale you'd have to add probably a page of discussions of what the swap issues are and how to work around them. For the most part advising people to use -s 127 fixes the problem anyway. The problem seems to be largely theoretical - weaknees say they can't remember ever seeing a machine stuck on a green screen.

My position - oft repeated - is:

If you can expand swap when you upgrade, do so (this probably covers 90%+ of upgrades).

If this is the sort of thing that would worry you, then we have ways of adding swap in every possible upgrade scenario. They are time consuming and/or convoluted.

If you decide to 'chance it', either because you didn't understand the swap issue when you upgraded, or your upgrade profile doesn't allow you to expand swap easily, you may not hit a green screen in the lifetime of your hard drives. If you do green screen and get stuck, we have a 'rescue' maneuver that will allow your TiVo to recover if running out of swap caused the green screen to stick.


----------



## mnc042

> _Originally posted by Robert S _
> *That's right, Hinsdale's instuctions for that scenario are unhelpful. *


*

Ah okey. So maybe I should pick a different scenario, where I replace my A drive with my new 120GB drive. I notice that in this scenario, since you're doing the restore with the -s 127 option, that should work well. And, I'd do this by:




Hinsdale does describe the pipe transfer technique in a different context. Create your A drive with a pipe transfer and MFS Tools 2.0 will copy your recordings and expand your swap

Click to expand...

In this scenario, I'd either keep my old A drive as a backup on a shelf somewhere, or I could decide to re-bless it as a B drive, as in:




(you can even fill the drive and bless in your B drive in one step, if you want).

Click to expand...

This sounds like the safest option.




If you can expand swap when you upgrade, do so (this probably covers 90%+ of upgrades).

Click to expand...

Agreed, and that is the way I will go.

Thank you so much for your help!

\marc*


----------



## DCIFRTHS

> _Originally posted by Robert S _
> *127Mb swap is a complete fix for all the problems this thread has addressed. It has been tested on a 240Gb TiVo and calculated for a 274Gb TiVo (the largest currently possible).
> 
> If you follow New Hinsdale, MFS Tools 2.0 will expand your swap for you (the -s 127 option). *


I will be using two new drives, and I am not going to worry about saving recordings.


----------



## Merle Corey

<sigh>

127MiB is no longer enough for all configurations.

Jafa really is that cool.

Theoretically, with quad 200's, the universally safe value is now nuzzling 367MiB of swap. 



> _Originally posted by gigageek _
> *I also think Hinsdale has a valid point that it is not a mathematical certainty that every >140GB configuration will "not recover" from a GSOD. (The proof, however, is "left to the student".  )*


Literally, that's true.

*Warning:* More information about fsfix, MFS, and journaling ahead than anybody really cares about.

However, for every specific hardware/software combination, there _is_ a point beyond which there is a mathematical certainty that it will not recover with 64MiB of swap. On 16MiB RAM systems, it's _around_ the 151GB/140GiB mark. On 32MiB systems, it *should* be _close_ to the 182GB/170GiB mark.

fsfix requires a very specific amount of RAM per GiB being repaired; that number isn't going to change, except perhaps in small ways in the form of alterations to MFS between software versions. The bigger change is going to come from either the amount of system RAM (16MiB vs 32MiB) or the memory footprint on that version/platform.

Assuming that Tiger's -r setting is really changing the default block size (and we have at least some evidence showing that it does), it would appear that fsfix doesn't just operate by looking at the allocation table, it actually requires specific data from each block - quadrupling the block size may mean that it only has to look at one fourth as many blocks, but it also quadruples the amount of data that fsfix needs to snarf from each block. Net gain: 0.

This makes perfect sense from a journaling standpoint - it would be a bad journal, indeed, that kept the same amount of data for 1MiB and 4MiB block sizes, rendering data recovery *much* more difficult. And yes, I'm implying that the RAM fsfix requires is the amount of RAM needed to load the journal (or some specific subset thereof) into memory. This would be why GSOD looping appears fairly quickly rather than after the amount of time it would take to "process" the maximum supported space of a 64MiB swap. The formula I developed translates into 1 byte of fsfix data per 2048 bytes of filesystem data - a fairly reasonable journal, especially given that 2K of multimedia data isn't going to appear as much more than a stopple... The formula may or may not be dead on accurate, but it is *absolutely* _reasonably_ accurate. (I would suspect that it's actually 1 byte per 2047 bytes of data, but it's going to be damn hard to prove that when dealing with multi-GiB setups and MiB based swaps - I really don't care enough to nail everything down into bytes.)

At this point it looks like the only way to get fsfix to run in a significantly more efficient manner would be for it to not require that the entirety of MFS space be mapped out at once - in other words, if there were some way to get it to look at one drive - or better yet, one partition - at a time. That, however, is something that I suspect is an MFS "limitation" - if it's all one big virtual space, it probably has to be treated as such for repair purposes.

(The above is, where applicable, true about fsck as well. It's common to see fsck problems on linux systems with small amounts of RAM and very large partitions when swap is disabled/broken.)

So let's stop picking nits about swap, and go hound Nick for a release date on the quad drive hack. 

MC

Typos, typos everywhere...


----------



## hinsdale

> _Originally posted by Merle Corey _
> However, for every specific hardware/software combination, there _is_ a point beyond which there is a mathematical certainty that it will not recover with 64MiB of swap. On 16MiB RAM systems, it's _around_ the 151GB/140GiB mark. On 32MiB systems, it *should* be _close_ to the 182GB/170GiB mark.


These numbers sound more reasonable to me... and would mean that you can safely add any drive, 120GB or less (or larger in some circumstances), to any unmodified TiVo using the standard BlessTiVo or mfsadd procedure without increasing swap.

You can of course easily add any size drive and also increase swap if you dont care about your recordings or dont mind waiting a couple hours for your recordings to copy. Those with 2 drives or previously expanded drives will generally be using the swap expansion methods anyway.

And as has become evident, swap file increase only becomes required in very rare circumstances to begin with.

I will be adding some brief swap file requirement notes to the How-To's over the next week (figure out best wording without adding a page) . Just wanted to get some confirmation/concensus of more reasonable numbers (thanks merle) before unneccesarily concerning anyone.


----------



## hinsdale

> _Originally posted by mnc042 _
> *
> 
> In this scenario, the A drive's swap is not expanded, and you wind up with 160gb and 64mb swap.
> 
> *


As I stated before my 160GB DirecTiVo has recovered from GSOD with 64MB swap, and as merles numbers tend to indicate - the threshold number for a DirecTiVo is >180GB so this configuration should not pose any potential problems.


----------



## mrtickle

> _Originally posted by hinsdale _
> *
> 
> These numbers sound more reasonable to me... and would mean that you can safely add any drive, 120GB or less (or larger in some circumstances), to any unmodified TiVo using the standard BlessTiVo or mfsadd procedure without increasing swap.
> 
> *


Not "any" TiVo - all UK TiVos are 40GB to start with so you must NOT add a 120GB drive as a B drive.



> *
> I will be adding some brief swap file requirement notes to the How-To's over the next week (figure out best wording without adding a page) . Just wanted to get some confirmation/concensus of more reasonable numbers (thanks merle) before unneccesarily concerning anyone. *


Thanks! If you could make the warning simple and prominent - something like "if you are going over 140GB you must NOT just add a large 2nd drive" then that would be great.


----------



## hinsdale

> _Originally posted by mrtickle _
> *
> 
> Not "any" TiVo - all UK TiVos are 40GB to start with so you must NOT add a 120GB drive as a B drive.*


Sorry, you are correct, the Brits slipped my mind.. "any US TiVo" would have been more accurate.



> _Originally posted by mrtickle _
> *
> Thanks! If you could make the warning simple and prominent - something like "if you are going over 140GB you must NOT just add a large 2nd drive" then that would be great. *


I will not be using the 140GB number because it is inaccurate but will be adding a cautionary message basically stating that in the very rare circumstance that an mfsfix utitlity is needed, it will require an increased swap in order to complete if your series 1 standalone is >150GB or if your DirecTiVo or Series 2 unit is >180GB .


----------



## Merle Corey

> _Originally posted by hinsdale _
> *(figure out best wording without adding a page) .Just wanted to get some confirmation/concensus of more reasonable numbers (thanks merle) before unneccesarily concerning anyone. *


Ok, just to err on the side of caution, I want to make sure this clear: The 32MiB RAM TiVo swap threshold was based entirely on the assumption that it has a similar memory footprint as the 16MiB - in other words, that almost the entire amount of additional RAM (I used 15MiB for my ballpark) can be utilized for fsfix. Since your 160GB DTiVo made it through the GSOD, I'm inclined to think that my assumption was more or less valid (10ish MiB footprint/22ish MiB available for fsfix).

The entire reason I'd been avoiding making an explicit statement on 32MiB TiVo's is simply because I don't have one to test. It's a best guess on my part, and I'd feel pretty rotten if someone ended up hosed because he saw "180GB is probably safe" and ran with it. I'd be happier if someone with a DTiVo would check this out before it becomes part of the documentation.

As for phrasing, I agree with mrtickle - keep it really simple and assume that anybody who needs to follow the How-To in a verbatim, step-by-step kind of way (aka the target audience) probably shouldn't be making judgement calls on exactly where the threshold should be. If you feel it's that important to document what we know about swap and thresholds and such, do a separate bit of "advanced" doco specifically on the subject - the most interesting bits are already beyond the scope of the How-To.

In other words, let "> 140GB" be a general rule for the basic "I just want to add a drive, why are you talking about this linux stuff?" crowd, and keep 150GB & 180GB for the more technically proficient - the people who are most able to make an educated decision, especially keeping in mind _future_ upgrade scenarios. Besides, both of those values are down to the wire, and *neither* has been explicitly tested for exact accuracy. I don't know about you, but I'd feel pretty sheepish if the actual numbers were, say, 149GB and 179GB.

The bottom line is that we don't need that kind of accuracy - not to prevent leaving it to copy overnight via a pipe transfer, and *certainly* not for saving a measly 63MiB of drive space. If you're really set on listing two thresholds, at least pad 'em a bit - say, 140GB and 160GB. We *know* those are both safe.

MC


----------



## mrtickle

I still say it needs to be more hard-hitting rather than implying it's rare and doesn't affect many people. It doesn't matter how rare the GSOD is - when it happens it's fatal for people who can't create the "emergency" swap space (and they shouldn't be put in such a situation).

Far better to say bluntly: "whatever you do, do NOT add a big drive as a B drive if it will take your total above <the number you decide to use>". And then repeat the warning in the section which tells you how to add a B drive.


----------



## DCIFRTHS

> _Originally posted by mrtickle _
> *I still say it needs to be more hard-hitting rather than implying it's rare and doesn't affect many people. It doesn't matter how rare the GSOD is - when it happens it's fatal for people who can't create the "emergency" swap space (and they shouldn't be put in such a situation).
> 
> Far better to say bluntly: "whatever you do, do NOT add a big drive as a B drive if it will take your total above <the number you decide to use>". And then repeat the warning in the section which tells you how to add a B drive. *


I have a question: What you describe does not apply to a person that replaces that A and B drive with a lrger swap, does it?


----------



## Merle Corey

> _Originally posted by DCIFRTHS _
> *What you describe does not apply to a person that replaces that A and B drive with a lrger swap, does it? *


No, it doesn't apply when swap has been expanded - we're referring to situations where people keep the factory A drive (or otherwise don't expand swap) and add a large B drive.

MC


----------



## R. Kalia

After posting (in another context, elsewhere) that I had not seen a GSOD, I immediately got a GSOD. 

The instructions in the 3rd message in this thread got me back up very quickly---many thanks! 

Some idle newbie questions:

1) why is it that a disk w/o swap can have swap added, but a disk w/64mb swap cannot have swap permanently expanded?

2) What does the pdisk command "r 5 9" do and why is it needed only if the inactive partition is 4? Looking at the partition list I could see that "r 4 8" switches the functions of partitions 4 and 8, but "r 5 9" seemed to do nothing at all.

3) Once I put in the temp swap, TiVo healed itself within a few minutes. Does it actually dial in, or does it use files stored somewhere else on the disk?


----------



## Robert S

The commands you used are given as the default, the ones with /mad/ are added in parentheses with the words 'if you're using TiVoMad'. Would you like to suggest a clearer form of words for me? The TiVoMad disk doesn't need the magic incantation to boot byteswapping, but the commands are in a different place to MFS Tools.

The 'disks without swap' have an empty 128Mb partition where MFS Tools failed to create a valid swap partition. The fixes in the top post simply format this partition correctly. If your disk is already full, there's no where to put a bigger swap partition.

pdisk's r command renumbers partitions. The way it does it is a bit clunky r 7 8 swaps partitions 7 and 8 nicely, but you need two commands to swap 4 and 8 (thanks to angra for pointing that out). Although partition 4 ends up as number 8, the numbers of some of the other partitions are displaced.

I believe TiVo will dial and collect copies of files (presumably the system animations) it finds corrupt. Presumably your anims were OK and mfsfix just had to fix a small problem. Some people have reported green screens taking hours to recover.

You did back out to revert to 64Mb of swap, didn't you. (I'm worried I've created a new type of Moron here, although we've obviously not had a documented case yet).


----------



## R. Kalia

> _Originally posted by Robert S _
> *The commands you used are given as the default, the ones with /mad/ are added in parentheses with the words 'if you're using TiVoMad'. Would you like to suggest a clearer form of words for me? *


I was babbling. I confused Tivomad and MFS Tools.



> *The 'disks without swap' have an empty 128Mb partition where MFS Tools failed to create a valid swap partition. The fixes in the top post simply format this partition correctly. If your disk is already full, there's no where to put a bigger swap partition.*


In Windows, programs such as PartitionMagic will resize existing partitions and insert new ones and so forth, without losing data. I guess there's nothing like that in Unix; too bad.



> *
> You did back out to revert to 64Mb of swap, didn't you. (I'm worried I've created a new type of Moron here, although we've obviously not had a documented case yet). *


Huh? Bad idea. Who knows, I might get a GSOD again. I'm leaving it the way it is. Partition 4 hasn't been used since 10/2001 so I am sure it isn't needed for anything!


----------



## Robert S

There may be Unix tools that would let you resize Ext2 partitions, but the recordings are stored in a proprietary filing system called MFS. Although MFS Tools can create MFS partitions, it can't resize them.

I have created an new class of Moron! I wonder if they'll give me credit for it in the FAQ?

You need the inactive root for the next software update. I don't know precisely what will happed when the next software update comes in, but it'll be really, _really_ nasty - your TiVo will attempt to reformat and install the new software on the partition you're currently using for swap!


----------



## R. Kalia

> _Originally posted by Robert S _
> *I have created an new class of Moron!*


You mean, the class that is humor-impaired even when smilies are used?


----------



## Robert S

Oops!


----------



## R. Kalia

My apologies if this has been answered before in this very long thread or elsewhere...

To fix my swap problem, can I "upgrade" my 120G A drive to another 120G drive (this one properly prepared), while keeping the recordings? Or will it not work because the new drive has less free space because of the bigger swap space? (BY current drive is NOT anywhere near full with recordings.)

Obviously, I have no idea how the relevant steps actually work. 

If my proposed method works I can then re-use the old A drive to replace my current smaller B drive, so buying a second 120G drive is worth it.


----------



## Robert S

No, there's no way to resize the MFS partitions, even if you're copying them to new media. You would be able to do this with a 160Gb drive, but they're much more expensive.

Try not to worry about it - green screens are very rare and the 'rescue' maneuver at the top of this thread will recover you if you do ever see one.


----------



## Blademan007

I've read through this thread, and I understand that I'll going to need to to worry about swap. I just upgraded a DTivo with a 160GB Maxtor (137GB recognized), which then promptly started to fail. Addicted to Tivo in 1 months as I am  , I promptly picked up a 120GB WD 7200rpm drive (May as well max the ******* out since I love it  ), while waiting for the replacement Maxtor. The DTivo has 32MB and I'm entering dangerous territory with 2 drives.

So if I'm going from old 160GB Maxtor (which sporadically works for shorts periods after refrigeration) to new 120GB A + 160GB B drives in a DirecTivo, which is the ideal mfsrestore command I should use to ensure adequate swap and minimize chances of GSOD?

(assuming: mfsbackup -aqo - /dev/hdc | mfsrestore -xpi - /dev/hda /dev/hdb )

Thanks for the bandwidth, and great stuff you guys have going on here!!!


----------



## Robert S

Are you trying to take your recordings with you? I'd wouldn't have thought you'd have anything worth taking in a month. It'll take many hours (perhaps more than a day!) to copy your recordings.

To take your recordings do

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -xpi - /dev/hda /dev/hdb

(you would want the 160 to be the A drive to make room for the extra swap)

To just take your guide data, but not recordings (will take maybe 15 minutes)

mfsbackup -so - /dev/hdc | mfsrestore -s 127 -xpi - /dev/hda /dev/hdb

(Makes no difference which new drive is the A drive).


----------



## Blademan007

Robert,

Thanks for the response, and yes I do have 113hrs (per mfsbackup of recordings) that I would like to take to the new drive. I need to save to vcr...

I would prefer the 120GB 7200rpm drive as my A drive, since I notice the guide and other operations are much faster, and the 160GB as the B drive. Will the same command work for that configuration and still allow for enough swap?

Old 160GB --> New 120GB 7200rpm A + 160GB B.


----------



## Robert S

Possibly - MFS Tools does have some flexibility when it comes to laying out the MFS partitions, although I don't know if it can put A drive partitions on a B drive if it can't fit them on the A drive. You'll have to experiment a bit (you'll immediately get an error message if there's not enough room).

You don't need to be too worried about swap. Although I advise everyone to increase it if they can, green screens are very rare and the 'rescue' maneuver from the top of this thread will recover you from a green screen if you do get one.

Perhaps just print out the relevent post and tape it inside the TiVo incase you ever need it?


----------



## BobCamp1

Just wanted to let everyone know that the latest Hindsdale upgrade guide (dated Sept. 29) for MFSTools 2.0 addresses all the swap file issues covered in this thread. It now has notes warning people about the potential problem, and advises them on the correct upgrade procedure should they wish to avoid the problem.

Many thanks to Hindsdale, Robert S., Merle Corey, and everyone else for investigating and resolving the issues.

Now stop bugging these people so we can end this thread.


----------



## jimjamsgolf

Thanks everyone.

With hindsight I have left out some information but I have success. 

I am not sure I had bad blocks on the disk as such as I think the drive could read then given enough attempts. 

My hda drive was not an original but an upgraded one with 127/128Mb of swap, I'm too paranoid to try to reuse the original. 

What I did was; 

used the dd method to copy the data on hard drive suspected as being faulty to another drive (while I went to bed). Next I backuped and then restored all of the data onto the hda drive (which had/has 127 or 128Mb swap) and finally added my larger drive as hdb.

It was suggested that I could use fdisk/pdisk to play with the partitions on the hdb drive, does anyone know if fdisk/pdisk actually works on any boot cd? I think I used the turbonet boot/nic_install CD but I think I thought both pdisk and fdisk failed as the could not read the partiton table. When the kernel booted all the harddrive partitons were detailed correctly.

As an aside has anyone got a recent kernel to read the Tivo/Mac partiton table after applying the partition patch? I know it does not apply cleanly, I get the correct magic nuber but then no partition information.


Thanks


----------



## comfysofa

Right - i understood none of that lot - but i think my requirements are simple.......ive already done the large a drive upgrade (160gig) and want to put in a 120 gig as a B drive - what commands to i put in ----( i already know the one to stretch the drive over to the new b drive) but confused to the swap file bit???? + i ve already done the network bit if thats a hinderance or help???

Anyone got a walkthrough.....

regards

Andy

PS looking forward to a reply cos the 120 gig disc got delivered today and im itiching to get it installed.....


----------



## Robert S

Well, if your A drive is already a 160 and you don't want to lose your recordings, there's nothing you can do about swap. 
If you increased your swap with -s 127 when you upgraded, then you've already got enough swap for a 257Gb TiVo to recover from a green screen (it doesn't make any difference for any other function). If you didn't, there's nothing you can do about it now - just use the 'rescue' maneuver if you do ever green screen.

The network stuff is irrelevent.

Put your A and new B drive on the primary bus, boot MFS Tools 2.0 and do

mfsadd -x -r 4 /dev/hda /dev/hdb 

and you'll have a 257Gb TiVo.


----------



## comfysofa

hmmm - well if its better in the longrun then ill loose the recordings....... what would i have to do then.....


----------



## comfysofa

just as a further thought - ive still got the untouched 40 gig disc which i could use to copy from - if that helps.......ie start again.......but how would i put that s- 127 command in, and where.....?


----------



## comfysofa

actually its probably better if i dont cos it took me ages to get the web and ftp stuff working.....back to plan a:


----------



## Robert S

Wouldn't it be better to check to see how much swap you've currently got? See the first page of this thread for a post from Cpen that explains how to use the backdoors to read your logs.

To be honest, green screens are sufficiently rare that I wounldn't recommend wiping recordings you want to keep just to increase swap. If you ever do green screen, the 'rescue' maneuver seems to be working well for people.

If you want to copy the recordings on your old A drive onto your new drives (losing the current recordings, of course), put the new drives on the primary bus and the old one on secondary master and do:

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -r 4 -xpi - /dev/hda /dev/hdb


----------



## comfysofa

.......so is there a manual way of adjusting the filesystem.......ie making the swap bigger like just one command line.......im trying eventually to get to the point where i never have to open the tivo again.........(unless theres a serious error of course) - but at least as is humanly possible......


----------



## comfysofa

just out of curiosity - follow me now........ i take my original A drive and issue that command..... can i stick that on my 120 gig disc (does it need preping atall....) fdisk etc...... then put that image back on to my 160 gig disc and then stretch it out over the 120 gig disc going over that image - as i wont need it anymore.....is that right.....?


----------



## comfysofa

yep - checked the log files and mine says 6555....what ever it is - ok! - right what now.....does that mean im ok?? i dont know what im looking for....


----------



## Robert S

No, you have 65.5 million bytes of swap - 64Mb, 127Mb is about 130 million bytes.

You can see the 'rescue' maneuver in the third post of this thread. It's not trivial, but it's not too difficult - several people have used it successfully to recover from a green screen.

Like I said, green screens are very rare and I assume they're associated with failing hardware, although that may not be a particularly well founded assumption.

I would try not to worry about this - it will only be a problem if you get a green screen, all your TiVo's other functions will be fine.


----------



## comfysofa

Well - last night i did what you said and it made no difference - ie mfsbackup from original 40 gig and restore to the 2 new ones.......got up this morning - it reported no errors and said that the 2 new discs were installed but with only the same amount of time available as the first so i put them back in the tivo and nothing had changed so i put them back in the pc and used the command to stretch the image across the 2 drives......just put them back in - its working no prob but i think the swap space issue is still there - havent checked yet......well i assume that as nothing else changed from last nights overnight copy.......just out of curiosity assuming that i manage to cobble my way through a walkthough can the swapspace issue be done through the network card to avoid stripping it down again.......


----------



## Robert S

Well, if you included -s 127 in your restore options, you've now got 127Mb of swap. You've only lost 63Mb of recording space (I estimage 4 minutes of Basic or 2 minutes of High). I would definitely check your logs before you claim your swap is the same.


----------



## Jorossian

Great stuff Rob. I've copied your updated instructions for future reference. So all this crap has been caused because of using "128" instead of "127". Glad to see my Hinsdale's directions are already updated and free of that problem.

I feel a lot better about using Tiger's MFS Tools 2.0 to do this now. Unfirtunately my 120 Gig hard drive still hasn't arrived. I may have to put this off until next weekend.

Here's a new question.

If I simply move the image of my A drive to the new larger drive + expand it and keep the original A out of the unit for a while until I'm sure everything's "kosher"......... Will I lose more usable space when I eventually add the original 40 gig A drive (now B) to the new 120 A ? And does the addition of the original A count as another "upgrade" essentially putting my overall TiVo setup at 2 upgrades with possibly one more possible upgrade left?

I guess what I'm getting at is, am I better off putting in 2 new hard drives all at once NOW rather than one now and one in another month or so?


----------



## Tiger

There is no difference as to the number of upgrades of putting a drive in now or later. The number of upgrades counts each drive upgraded, so in both cases larger A + new B (Now or later) is 2 upgrades. Also the limit isn't necessarily 3, that is just worst case scenerio. You can have a total of 6 MFS sets. Standalone series 1 has 1 set in most case. Dual drive combo has 3. Single drive combo and series 2 standalone have 2. So larger A and new B gives you a chance to upgrade both drives one more time. (Though you have to do both at the same time if you want to use both upgrades, as it will need to shuffle partitions around)


----------



## Jorossian

Appreciate that Tiger. Thanks for the great software.


----------



## comfysofa

hmmmm - well because nothing happened on the first night i tried i took the discs and stretched the filesystem over the new disc which took me to 314 hours........so - assuming i still have the old swap size - (gotta wait for the wife to finish with the tivo) ill check the logs - think you need a reboot first.......can the adjustments be made from a telnet session (without the need to take it apart).......


----------



## Robert S

There's no room to add more swap. It's best to do it at the mfsrestore stage.


----------



## rdangel

Robert S:
I had a previously upgraded Phillips 20 hr. Added an 80 GB B drive using blesstivo and have been fine for a while. Recently decide to change out the 20 GB A drive for a 120GB A drive.

Did the upgrade,everything is fine. Have been using the tivo for a few days now. Read over your manually adding swap file thread and have a question. Will this creating procdure damage the married drives at all? Will I just be able to add/create/expand the swap without losing my recordings, breaking the marrying etc?

I have been noticing that the a drive locks and I keep having to run qunlock.

Any help would be appreciated.
Thanks


----------



## Robert S

The procedure for adding extra swap manually has been tested and seems to be working well for people. You need to do it between dd'ing the drive on to the new one and using mfsadd to expand the image. If you've already expanded you can't expand your swap and will have to use the 'rescue' procedure if your TiVo ever green screens.

The 'marriage' is transferred when you use dd to copy the drive. changing the swap partitions around doesn't affect the MFS partitions where your recordings are. mfsadd adds extra space without damaging the recordings already on the disks.

TiVo will relock the drive it you boot it. qunlock is only a 'permanent' unlock in the sense that it won't relock in a PC (the distinction is actually against dlgchk.exe which only unlocks the drive until you turn the power off).


----------



## rjbutler

I upgraded my DirecTivo B drive to a 160GB Maxtor some time ago and ended up with a 64M swap. Lately, I've noticed very slow responses, occassional audio drops during playback and sometimes video dropouts on recordings on days there should not be rain fade problems.

Is it likely the small swap partition is the cause of these problems or is theresomething more serious wrong?

I've scanned through this topic and I *think* I can increase the swap to 128M using option #3 in the first message:

_3. Use copy of mkswap on tools CD

Boot a TiVo boot CD (but not the MFS Tools 2.0 CD) and do

/sbin/mkswap -v0 /dev/hdc8 _

Is my interpretation correct? Will this effect my recordings?

Thanks


----------



## Robert S

Wrong on both counts, I'm afraid. The increased swap is only relevent when your TiVo undergoes a 'green screen' file system corruption error. You need relatively little swap at other times - probably less than 20Mb would be fine for normal operations. A DTiVo might even be OK with no swap at all.

You can't increase swap because you've got no where to put it - the 4 procedures in the first post assume you've got a 128MB partition that hasn't been initialised by MFS Tools 2.0 (which happens if you upgrade with -s 128 as suggested by the MFS Tools 2.0 documentation).

You will want to take note of the next post which describes how to temporarily increase swap to help your TiVo recover from a green screen of death.

Your playback problems are probably due to a failing disk. You might want to run PowerMax on your drives to see if it can identify which one has the problem.


----------



## rjbutler

I used MFS Tools 2.0 soon after it came out, before the swap issue was discovered. I don't recall if I used -s 128, I followed the Hinsdale instructions for a 2 drive DTivo, upgrading the B drive only. 

The logfile reports a 64M partition.

I guess I'll try PowerMax this weekend to see if I've got a bad drive. 

Thanks for the info.


----------



## boobili

> _Originally posted by Robert S _
> *Wrong on both counts, I'm afraid. The increased swap is only relevent when your TiVo undergoes a 'green screen' file system corruption error. You need relatively little swap at other times - probably less than 20Mb would be fine for normal operations. A DTiVo might even be OK with no swap at all.
> 
> You can't increase swap because you've got no where to put it - the 4 procedures in the first post assume you've got a 128MB partition that hasn't been initialised by MFS Tools 2.0 (which happens if you upgrade with -s 128 as suggested by the MFS Tools 2.0 documentation).
> 
> You will want to take note of the next post which describes how to temporarily increase swap to help your TiVo recover from a green screen of death.
> 
> Your playback problems are probably due to a failing disk. You might want to run PowerMax on your drives to see if it can identify which one has the problem. *


Hi Robert. I might have missed it reading thru this long post. If I had, please forgive me. In your initial post, you described how to recover from the GSD, using a working shell on the TIVO. I am in such a situation. I have the GSD that has not resolved itself for several days, yet I have a working telnet. Can you go into more detail on how to fix the GSD problem under these conditions? Thank you. B


----------



## Robert S

The fix applies only if the GSOD is running out of swap - if it reboots a few seconds after going to green, then the fix will help. If the green screen is staying up, then you already have plenty of swap.

Search back through my posts yesterday and you'll see a discussion with someone else trying to do the rescue on the TiVo. In my opinion, it would be much easier to follow the rescue plan in the third post of this thread, even though that does mean opening your TiVo and PC.


----------



## jeffster

Robert,

Which of the (#2 & 3) options mentioned at the top of the thread for rescuing DTivos is the best?

I have a SAT-T60 that was just upgraded to 220GB, and got it home to see the green-screen reboot loop.

I'm not the one doing this (I haven't used unix since grad school), so I'll need to point the directions out to someone else who's not going to scan the whole thread.

TIA,


----------



## Robert S

The four options in the first post are for repairing TiVoes with no swap (if you actually read the post, this will become clear to you). The rescue is in the third post, and there really is only one way of doing it.


----------



## jeffster

Okay, my DTive SAT-T60 with a 100+120 has been in mfsfix (green screen) recovery mode for about 3 hours now.

How long should I expect it to run?

(The green screen came up the minute I added the 120, so only the 100 actually had any video on it.)


----------



## jeffster

I had only to ask. Now it's done.

Odd thing -- I lost 40 hours of programming (now just 205 available, said 240 before the mfsfix run).


----------



## bonurn

> _Originally posted by gigageek _
> *Boy, I wish I had your instructions when I started on this.
> 
> Well, I did have these instructions, and they were fantastic. Thanks again to Robert S and gigageek for taking the time to create them.
> 
> I upgraded my SAT-T60 with two 100 GB drives. (I did this back in September.) I woke up one Sunday morning to find the infinite GSOD/Powering Up loop. I immediately jumped on the message boards and noticed some discussion about the 3.1 upgrade, specifically Deano's post. I thought that perhaps this is what caused the problem since there was no power outage overnight. Of course, there was no way to check my software version because of the GSOD.
> 
> After some searching, I came upon this fix. When I performed my upgrade, it was after the discovery of the 128 problem, so I didn't think that was it, but I figured since I was in the infinite loop, I'd give these instructions a shot. Well, so far so good. My system is back and humming. My software version is still 2.5.2, so the 3.1 upgrade sitll lurks.
> 
> Some questions remain (more informational and rhetorical than anything else):
> 
> 1) There was a Service Data Download the night of the failure. I wonder if this is the 3.1 download that hosed the system. Or could it be something else in that download?
> 
> 2) gigageek : why in your instructions did you delete the partitions then recreate them instead of just renumbering them? Just wondering.
> 
> Thanks again!
> 
> -bonurn*


----------



## Eccles

> _Originally posted by Robert S _
> *TiVo disks can not be read by a PC because the bytes are written in a different order to that expected by the PC's processor. TiVo boot disks are patched to boot in a 'byteswapped' mode that allows the TiVo data to be read.
> 
> Most people these days seem to be using the MFS Tools 2.0 CD. MFS Tools 2.0 has internal support for byteswapping so that CD boots in non-byteswapped mode by default. It offers you the option to boot byteswapped, but this doesn't work. To boot the MFS Tools 2.0 CD byteswapped at the 'boot:' prompt you must type
> 
> vmlnodma hda=bswap
> 
> If you can't get this to work, try Kazymyr's boot CD or TiVoMad's boot CD. If use a different boot disk, hda will be left unswapped. Use one of the other connectors and adjust the commands below accordingly. (We don't currently know how to do this from a floppy, one of the tools we need is only on the CDs).*


How can I (or can I at all) get the MFS Tools 2.0 boot _floppy_ to boot in byteswapped mode? I've spent the past couple of hours trying all manner of convolutions, because the lame old PC I'm using for the task cannot boot from CD and when I boot from the floppy I don't (appear to) get a chance to specify any parameters; there's no boot: prompt, it just starts loading.

From what I read here, this is not a barrier to performing a copy&expand, so I'm going to go ahead and get that going before I go to bed, but it would be nice to be able to make a backup of the old A drive at some point as well.

Is there a non-byteswapped 2.0 floppy image available anywhere?


----------



## stormsweeper

You can use MFS Tools completely in non-byteswapped mode. You only need to use byteswapping if you're modifying files (say to set up a bash terminal) on a Series 1 machine.


----------



## Eccles

> _Originally posted by stormsweeper _
> *You can use MFS Tools completely in non-byteswapped mode. You only need to use byteswapping if you're modifying files (say to set up a bash terminal) on a Series 1 machine. *


Yeah, I guess I was doing things wrong. I thought I only needed to backup my A drive since that was the only one I was expanding, but in retrospect I see I needed to mounts both A and B to create the backup. My bad. Thanks.


----------



## Robert S

You can't make the the MFS Tools 2.0 floppy boot byteswapping, but then you don't need to because MFS Tools has internal byteswapping.

If you need to boot byteswapping for some other reason, just use a Dylan or TiVoMad floppy, they have all the tools other than MFS Tools.


----------



## raiders

got a gsod reboot loop on a series 1 directivo with a 200MB configuration of 120mb maxtor disk a and 80 mb maxtor disk b

Followed Robert's instructions from the 3rd thread and the directivo is now back up. Is there a specific place in the logs to look to determine what caused the gsod. Ran the maxtor disk utilites and the drives are ok.

Is there a way to increase the 64mb swap to 127mb using the existing disks without losing recordings so that a future gsod can attempt recovery automatically?

Thanks to all who contributed to this thread and helped with the instructions on recovering from gsod


----------



## gigageek

raiders: No, there is no way to increase the 64mb swap to 127mb using the existing disks without losing recordings. There is no unused space on the disks, so they would have to be repartitioned (thus blasting all recordings) to change the size of the swap partitions after the fact.

bonurn: The reason I deleted/recreated my partitions was because I had renamed them after I renumbered them (in retrospect, this was *ENTIRELY* unnecessary); deleting/recreating the partitions was less work to get back to where I started than was renumbering & renaming them (although probably not much less work). If you just renumbered the partitions to do the GSOD fix, just renumber them to put them back the way they were.


----------



## acrobidoux

Hi Everyone,

I am looking to buy a Hughes DirecTivo 2 system and adding a large drive to it, replacing the existing single drive.

My company is going to be purchasing a Logicube Solitaire Turbo Hard Drive duplicator for me to use at work. Has anyone ever used a drive duplictor with the Tivo drives? This unit will make an exact copy bit by bit of any OS, therefore I will have the required swap file that everyone is talking about (although it will be 64MB). I did not read through this entire post, but did read that Hinsdale thinks the 64MB will be enough due to the new versions of the Tivo software. What are your thoughts on this?

Also, I am considering the Western Digital 1200JB (120 GB) hard drive that has an 8MB cache (all other drives use 2MB) and 7200 RPM Speed. This drive is fairly quiet as I have installed several in PC's at work. Has anyone used this drive? Will I see a performance gain using this drive with the Tivo? In PC land, these drives perform better because of the larger cache.

Thank You

And Sorry if I am asking a question that has been discussed before!

Andrew


----------



## gigageek

acrobidoux,

I don't know about that particular drive duplicator, but my guess is that it will hose things up unless you're duplicating your current TiVo drive onto another identical drive. (And what, exactly, might be the point of *that*?) After it faithfully copies every bit of the old drive (including partition info), what do you suppose it might put in the unused space on a larger drive? My recommendation: just use MFSTools like everyone else.

As for the WD120JB, you're wasting your money on the 8MB buffer. The original DTiVo drives (which are capable of recording 2 shows while watching a third, previously-recorded, show) are only ATA33 with 512kB buffers. The larger buffer is good for PC performance, but useless for the TiVo application (continuous streaming of data, as opposed to random file access).

I've got a WD120BB (2MB buffer) in my SA TiVo, and it works fine. It's a little bit louder than the Seagate Barracuda ATA IV (ST380021A) in my DTiVo, but Seagate didn't make a 120GB drive earlier this summer when I bought my drives. As always, YMMV.


----------



## Robert S

Why does everyone want to use some strange new tool for TiVo upgrading when there are well documented tools and procedures that work much better? I suppose I should give you some credit for not asking if you could use Norton Ghost, though 

This machine will make an exact copy of your TiVo drive on to any drive of equal or greater size. The drive will work in your TiVo, but will appear to be exactly the same size until you use MFS Tools to expand it.

If you don't expand swap, you can put no more than 180Gb of disk space in your TiVo without breaking the mfsfix filesystem repair utility.

There are circumstances where cloning a disk this way is a good idea, although you can do the same thing with dd in a PC if you don't happen to have a drive duplicator handy. 

If the TiVo is new, it would be a better idea to do an MFS Tools backup and restore to transfer the image to the new drive. (You only need to clone the drive if you want to keep your recordings). This will be much faster and allow you to expand your swap painlessly.

Once your new drive is full (ie, you're sure it's OK), you can use MFS Tools 2.0's mfsadd function to add the original A drive as a B drive if you still want more space.


----------



## acrobidoux

Thanks Robert S,

I was wondering if you would still need to expand the drives using the tools.

The tools sound like the best and only route to take, although once I get everything on a new 120GB drive I might use the duplicator machine to keep a backup on hand. This will allow me to bypass taking the drive out of the Tivo and putting it in a PC when/if the Tivo crashes.


Norton Ghost     is a joke!

Thanks Guys,

Andrew


----------



## mhubbard44

I've been following this thread hoping to read about a way to upgrade/save a dead A drive without losing all my recordings. I've been reading these threads about swapping file--is there any chance I can use a working B drive to allow Tivo to boot and possibly repair its self with a new swapping file?

Background: Sony Sat-T60, A drive: stock Quantum Fireball 40GB, B drive self upgraded Maxtor 4G120J6 (120GB). The upgrade went fine almost a year ago. One morning recently I turned the TV on and the unit said powering on. It's been stuck there ever since. I wonder if a software upgrade initiated the failure. 

Anyway I've run the Maxtor drive testing utility with both Tivo drives as the only drives connected to the PC and the Tivo A drive is not even recognized as a hard drive to run the utility against. The Tivo B ran through the basic and the advanced test with flying colors. Is there any chance anything but an a complete disk failure would cause the disk to not be recognized as a drive?

Also is there a way to save or restore the A drive with the bootable Tivo CD and some of the linux based tools? If not does anyone know if this PTVupgrade.com place can really save your recordings with their get well kit? Are there any log files on the Tivo B drive that would be helpful in diagnosing the problem? If I restore from my pre-upgrade backup to Tivo drive A do I lose all the programs on the second drive even though its already been blessed? Basically is there is anyway to save any of your recordings when you have a failed Tivo A drive?

FYI I work in the PC industry so anyone responding please give me the technical answer no need to dumb it down for me. If someone can point me in the right direction I'll do whatever possible to save my recordings. I have the entire second week of Spielberg's taken on my Tivo and I will do anything to get my movies and stuff back.

Thanks in advance


----------



## gigageek

Dude, I think you are SO screwed.   

It sounds like your A-drive has gone Tango Uniform on you; if so, there is no way to get any of your recordings off. To draw a PC analogy, the OS and FAT are on the (dead) A-drive. Two-drive TiVo units are much like a logical drive that consists of two physical drives, and you lose everything if either drive dies.

You can restore your backup onto your current B-drive (should give you ~100 hours), or buy another 120GB drive and have a really huge TiVo. This won't get your recordings back, but it will get your thumbs & season passes back to where they were when you made the backup.

You *did* make a backup when you upgraded, right?


----------



## douglasec

I have a Series2 80 hour that I'm trying to expand with (hopefully) a new 120Gb and new 100Gb drive. I have the bracket from 9thtee and the Y adapter and ATA 100 IDE cable BUT have a question about possibly ambiguous instructions in the Hinsdale FAQ. In Config #3 (single to new A&B drives), saving all recordings, it says:

"NOTE: Remove the "-s 127" from the following command lines if backing up/restoring a Series 2 80hr image (does not function with increased swap)"

The command line is given in the FAQ as: 
mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -xzpi - /dev/hda /dev/hdb

QUESTION (finally!)...does this mean remove the "-s 127" (which increases swap file size) ONLY IF RESTORING TO ORIGINAL (OR ANOTHER) 80Gb DRIVE BECAUSE IT"LL RUN OUT OF SPACE FOR THE SWAP FILE? In other words, if I'm expanding to two new LARGER drives, shouldn't I also leave in the "-s 127" command to expand the swap file- is this an ambiguity which should perhaps be reworded in the FAQ? Is there any way to ask a senior forum member what the appropriate command is (and perhaps why?) I've also seen reports that the Series2 units with extra RAM *might* not need the expanded swap to complete recovery from the GSOD (even with 220Gb?) and wondered if this might not be a reason why you WOULDN'T want to expand the swap - anyway, I'm "stuck outside of Mobile with the Ambiguity Blues again", as little Bobby Zimmerman would say...I'd like to do this once and do it right (especially saving all the recordings and the time involved with that route)...thanks for all the superior brainpower!


----------



## Websteria

because I'm thinking of doing the same thing. I'm going to take my existing 80mb drive and copy it to a new 120. In the FAQ it states:

*Note: Remove the -s 127 from the following command line if restoring image to the original TiVo A drive or if restoring a Series 2 80 hr image (reported that this unit may not create a working image with increased swap)*

Is this accurate?


----------



## douglasec

I got tired of waiting and had more time to ponder, and decided to go ahead with the -s 127. It WORKED! It took over 12 hours to transfer all the 75Gb of programs, but it just now booted right up with the new time (250 hours!) and similar noise and heat. I think my guess about not having room to increase the swap if restoring to the same drive was correct in retrospect, but bigger drives should have no problem. Even the lates FAQ now says "MAY" not work, where the earlier one said "WILL' not work if restoring an 80 hour Series2 image. Some 80s are a "little" bigger depending on brand and model, so I guess it's conceivable the extra swap might work with a new "80Gb" drive that had some room to spare compared to the 80Gb WD Performer it replaced, but a 100 or 120Gb seems like a sure thing from my experience. Go for it!


----------



## Websteria

Thanks! Post back in a few weeks and let me know if you've experienced any strangenesses with using the -s 127 flag. I'm planning on waiting at least until my warantee period is up (March, sniff snuff) to crack the box... although, if something was going to break, would you think it'd be the hard drive? Hmm...

Thanks.
Jeff


----------



## douglasec

Websteria - It's more complex but you should consider using BOTH drives - the only problem is you are asking for trouble if you just mfsadd or blesstivo to add the second drive if you DON"T add the additional swap .... though recent posts here suggest if you know the GSOD rescue routine in the first few posts of this thread is not such a big deal since chances of it happening to you are very small, so why agonize over it (like I did, of course) if it's not a widespread problem. You could just blessthe 120Gb, add it as the second drive and "voila!" - 200Gb at yourcommand!


----------



## Websteria

I might do that, but I was going to wait on purchasing the mounting bracket from 9thtee.com until I was ready for my second drive... perhaps I should do it now. 

So are you saying I'd need to expand the swap on my existing 80, or add the swap on my new secondary 120 then?

Thanks.
Jeff


----------



## douglasec

> _Originally posted by Websteria _
> *I might do that, but I was going to wait on purchasing the mounting bracket from 9thtee.com until I was ready for my second drive... perhaps I should do it now.
> 
> So are you saying I'd need to expand the swap on my existing 80, or add the swap on my new secondary 120 then?
> 
> Thanks.
> Jeff *


Possibly neither, since some higher-level posters on this thread are suggesting that it's a tempest in a teapot, since the GSOD recovery info at the top of this thread could be used in the very slim eventuality that this happens to you. Someone suggested just taping a note with the info inside your case in case it ever happened to you and you forgot what to do. If you buy into that, get the bracket and just ADD the new 120 (BlessTiVo or similar while hooked up to a PC for a minute), plug it in on the new bracket and you're done! Quick, relatively painless and mostly a question of whether you can sleep soundly at night knowing you "only" have 64Mb of swap space, which for maybe 98% of owners will be all you ever need.


----------



## Websteria

If I do add the 120, is it going to definitely cause problems if I do the -s 127 switch to add the swap space, or not.  It sounds like it's not definite that it won't cause problems if I don't... the FAQ isn't really clear on this issue.

Edit: I did read something in one of the higher posts about the TiVo needing larger swap space if you're going to expand beyond 180 gb (which I will eventually), so I think I'm going to go with copying everything onto the new 120 and then eventually buying another 120 (or 160 *grin*) and installing that one. That way I can keep my existing 80 as a secondary backup to the one MFStools makes in case something goes awry.

Thanks for all your help! I ordered the mounting bracket yesterday.


----------



## Scot

Last October I upgraded a Philips DSR6000 with one Western Digital 120 Gb drive on A, then later installed a Maxtor 120 Gb drive for B. In each case I followed Hinsdale's procedures for upgrading a single drive, but unfortunately I did not catch the part about increasing the swap space, and left it at the default 64 Mb. That error came back to bite me a couple of weeks ago when the unit started to spontaneously reboot. The reboots happen after viewing about five minutes of recorded program, or in trying to record. I should note that both drives are nearly full, within a few hours I'd guess, of programs that I have set to not delete unless I do it myself (green ball). Thinking that deleting some of the shows might help whatever the problem was, I killed about twenty hours of programming, but it was no help. 

I thought it might be a problem with the A drive (it was making a clunking sound when the spontaneous reboot started), I dd'ed the contents of the A drive onto a spare 120 Gb Samsung, then used mfsadd -x /dev/hdc /dev/hdb to marry the new A to the old B. The spontaneous rebooting continued and eventually the thing went into the GSOD loop, so I applied the trick of temporarily using the unused root partition as swap, and got the thing going again, but the spontaneous reboots continued.

While it was up, I started deleting more shows, this time starting with the most recently recorded. The time between spontaneous reboots seemed to increase as I did this, but that's not conclusive. Anyway I didn't get very far with that approach because the thing went into the GSOD loop again, and the partition swap trick doesn't seem to be working (after about three hours, anyway). I'm thinking I'll let it go all night to see if it heals itself, but I'm really hoping that I've missed something else that will get the thing working again without trashing the recorded shows. 

I'm pretty sure it's a data/software problem, as reinstalling the original drives results in a rock stable TiVo again. And I've run the manufacturers diagnostics on the upgrade Samsung and Maxtor drives, and both tested out fine. 

At this point it looks like I'll have to repeat the upgrade process, this time increasing the size of the swap partition. But I'm leary of doing it, as there seems to be something else going on that's causing the spontaneous reboot, and I'd hate to load it up with programming again only to end up in the same place. Can one of the gurus out there think of anything about the retention settings I used, perhaps interacting with the full state of the drives, that could have kicked this off? It's at 3.1.0.

Thanks in advance for any ideas...

Scot


----------



## douglasec

Scot - sorry to hear about your rebooting - I know Mac drives (as an example I know well) start getting squireelly when you leave less than about 10% free space on a drive because of increased danger of cross-linking files in little fragmented sectors left over from previous erasures; seems to both slow and mostly confuse the OS. Dunno if TiVo-nix has the same problem, but your deletions sound like a reasonable attempt. Maybe you could see on a PC the ACTUAL size in bytes of your 120s, and if the currently unused one has 64mb additional space to create the larger partition for the 128Mb swap file while transferring from the existing 120 (out of luck if it's the other way around, however)...how's your temperature? Some 120s are really toasty (especially two of them) and I know drive-related heat and/or weak power supply causes lots of reboots on Windows machines. You could upgrade to a new 160 "A" drive (adding the swap at that time) but perhaps you've already bought enough drives for this year, especially if you have a motherboard or power problem! I'm actually rather a TiVo newbie, though I've worked with Macs and Wintels for donkey's years, so get a second (third, fourth) opinion from a TiVo God first; YMMV.


----------



## Michael248363

I've been overloaded with information and options! Some of which seemed to be conflicting at times. I've read through this thread and I'm only a little bit closer to knowing what I need to do, but nowhere near close enough to be able to actually do it. I guess what I need are step-by-step instructions on what I need to do based on the units that I have. I hate asking to be spoon-fed this, but I have no experience with Linux beyond what I did for the upgrade. I've used PCs for years so working w/ hardware and command prompts don't scare me.

I've got two Phillips DSR6000 DTivo units. Both were upgraded back in July '02 using Hinsdale's instructions and MFSTools 2.0. Each unit has dual 160Gb drives (259hrs each). One of the units is currently in GSoD reboot hell. The other is operating fine. I have done no hacks, backdoors, shell access, TivoWeb, etc. to either of the machines other than the HD upgrade and S-P-S-9-S to get the time to display.

I would really prefer not to lose my season passes and everything that I've recorded. So that said, what do I need to do to fix the one that is in GsoD reboot hell and what do I need to do for the one that is currently running normally?

Thanks for the help.


----------



## Robert S

You should be able to fix the reboot loop by following the 'rescue' maneuver in the third post of this thread. I think it's sufficiently 'spoon-fed', but do let me know if you need clarification.

Do you remember what options you used for the upgrade? I assume that you didn't do -s 127 because of the reboot loop. Is it possible you did -s 128? See the first post in this thread (and Cpen's post on the first page) for instructions on how to check this.

If you did -s 128 then instead of the rescue maneuver you should manually initialise your swap as described in the first post. You can/should do this to both your TiVoes.

On the other hand, if you didn't use -s at all, then you can't permanently increase your swap, but the rescue maneuver should allow your TiVoes to recover from a green screen if it happens again.

Note that the TiVo can not take a software upgrade while it's in the 'rescue' configuration (because we're using the space required for the upgrade for swap). However, as DTiVoes do not seem to be due for a software update any time soon you can regard backing out of the rescue as non-urgent.


----------



## Michael248363

Thanks Robert. It probably is pretty straight-forward once you know which instructions to follow. 

I don't remember what the options were that I used when I did the upgrade. It could have been "-s 127", "-s 128", or nothing at all, I don't remember.

A couple of questions for clarification before I start and remove my ability to get on-line and ask questions. I apologize in advance for the quantity and of questions and their probable obvious answers. I feel a little embarassed that what seems like it should be a rather straight-forward task is causing me, and therefore you, so much grief. 

1. Both of my DTiVoes have A & B drives that are 160Gb each. Do I need to do something to both drives or only to drive A? In post #3 you talk about upgrading twin-drive TiVoes, so I got a little confused because I don't still use the original A drive. I don't think that section applies to me, but wanted to make sure.

2. Is there a way to validate, once the drive is connected, that you are working with drive A and not drive B. It seems like when I did the upgrade, I followed the instructions but the drives weren't cabled or jumpered the way I thought they would be.

3. For my DTiVo that is in the GSoD loop, I have to go through the steps to renumber the partitions in the third post of this thread. For my DTiVo that is working normal, I don't because this process just allows fsck to run. Correct?

4. After I find out which partition is the root partition do I still need to mount the drive or is that portion only if "edit_bootparms" doesn't work?

5. In step F, where I restore the original partition numbers, I use the exact same commands based on what the original inactive partition was. If the at the beginning the inactive partition was 4, then in step F, I would type:
r 8 4
r 5 9
The order or anything else doesn't change since I have renumbered partitions, correct?

So after putting the rebooting DTiVo back together and letting it fix itself (hopefully it will), I should now have two working DTiVoes. Which leads me to the steps to prevent this from happening in the future that I need to do to both machines so that I don't have to go through this again.

6. Does what I do to fix the "future" problem depend on what "-s" parameter I used? If so, which steps do I use based on what I find out from the logs? Is there one set of instructions that I can use regardless that will increase the size of the swap file and still maintain my settings & recordings?

7. How do I tell whether I used "-s 128" or didn't use "-s" at all. From what I can tell, after I enable backdoors and access the log, if I used "-s 128", I should get the error messages that CPen stated saying it was "unable to find swap-space signature" because the swap file was never created. If I didn't use "-s", I don't know what I should see. If I used "-s 127", I shouldn't be reboot looping so that's not really an option.

Thank you very much for your help.


----------



## lemketron

> _Originally posted by Michael248363 _
> *7. How do I tell whether I used "-s 128" or didn't use "-s" at all. From what I can tell, after I enable backdoors and access the log, if I used "-s 128", I should get the error messages that CPen stated saying it was "unable to find swap-space signature" because the swap file was never created.*


That sounds correct. I have seen this myself as I did several upgrades last summer with "-s 128" (before it was known that this was bad).



> *If I didn't use "-s", I don't know what I should see. If I used "-s 127", I shouldn't be reboot looping so that's not really an option.
> *


That sounds correct as well. If you did "-s 127" presumably everything would be fine. If you didn't use "-s" then I believe the upgrade process would have left the original 64MB swap partition. This (as noted) can cause problems down the road since fsck (or whatever the repair utility is that TiVo may one day run?) can't successfully run on two 160GB drives with only 64MB of swap space.

How can you tell? You'll probably have to dump the partition map and see if you can identify the swap partition. I don't recall which partition it's usually on, but if you hook up the boot drive to your PC and boot the MFSTools CD, you may be able to see the partition information displayed as the CD boots -- or maybe someone else can followup and tell you specifically how to tell whether your swap is 64MB or 128MB.

If it's 64MB, you'll want to figure out a way to make it 128MB. I don't believe you can actually do that in-place if you've already expanded your image to the full 160GB. You may have to re-do the upgrade (assuming you still have the original drive(s).)

If it's 128MB, then you need to find a way to run mkswap. I was able to easily do this via telnet on all of the stand-alone boxes I upgraded with "-s 128". I never did figure out how to do it on a DirectTiVo without going through all sorts of extra hacking tricks. There may be instructions around and if so you'll need to find them (or maybe someone can follow-up with the details).

Good luck!


----------



## wr9966

My drive A died and I had to 80GB drives floating around. I did not have a backup of the drive so I downloaded a virigin copy of a backup for a HDR112 and then RESTORED it to BOTH of my new 80GB drives using mfsrestore -s 172 blah blah blah /dev/hdc /dev/hdc

My TIVO is working and booted up with out a hitch. But I wonder if I am going to have problems with this in the future.


Thanks.


----------



## stormsweeper

> _Originally posted by wr9966 _
> *My drive A died and I had to 80GB drives floating around. I did not have a backup of the drive so I downloaded a virigin copy of a backup for a HDR112 and then RESTORED it to BOTH of my new 80GB drives using mfsrestore -s 172 blah blah blah /dev/hdc /dev/hdc
> 
> My TIVO is working and booted up with out a hitch. But I wonder if I am going to have problems with this in the future.
> 
> Thanks. *


I hope you were more careful typing that in while working than here. -s 172 won't work correctly, but -s 127 will.


----------



## Robert S

The second part of post three describes how to increase swap while upgrading the A drive of a twin drive TiVo. You aren't doing that.

All the system partitions are on the A drive, so it looks very different to the B drive (up to 16 partitions instead of just 2).

If your swap partition is already 128Mb then you can just manually initialise it as in post 1. If your swap is only 64Mb then you can't permanently increase the size of your swap because there's no spare space on the disk. You'll just have to do the rescue when needed.

The point is to find out which root partition is the active one. Mounting it isn't part of the fix itself.

To return the partitions to their original order you do exactly what you did before - the operation is self-inverse.

If you have 64Mb of swap, when you do CPen's thing to read the logs you'll see 'activating swap' and a number around 65 million.


----------



## Michael248363

The planets must be aligning against me or something.

Couple of questions:

1. What is a command that I can issue that will tell me definitively whether or not I'm looking at drive a or drive b? I connected the drive from my DTiVo that was at the end of the cable and set as master, but I think it's drive b and not drive a.

2. What is the command to show what is connected to hda, hdb, hdc, hdd?

3. Is there a command that will show me how many partitions are on a particular drive?

4. Apparently I can't access backdoors because I'm running version 3.1. So I guess the only way that I can view the log now is to mount the drive. What would be the commands to mount the necessary partition, and where is the log file located?

5. I couldn't get edit_bootparms to work, it says it can't find the file. I'm booting from the MFS Tools 2.0 CD is there anything I need to do before typing the edit_bootparms line to get it to work?

Thanks again.


----------



## Michael248363

Thanks Robert! I now have the Green Screen of Life!

I am still a bit curious about the questions I posted earlier. But now on to the next half of my problem. How can I fix the swap file problem so that this doesn't happen again?

Thanks again!


----------



## sskraly

Sorry, still a bit confused after reading this thread:

How do I upgrade from a 40+80GB unit (which was previously upgraded from a 15GB to 15+80 to 40+80, always preserving recordings) to a 40+120GB unit?

In other words, I'm upgrading the B drive, and I assume that I need to increase the swap, AND I want to preserve recordings. Most of this thread seemed to discuss replacing the A drive.

Thanks,
Sam


----------



## mrtickle

You're definitely right that you need to increase the swap.
Swap has to go on the A drive.
So, you can't have a "40+120" setup - you must make the 120 the A drive.

Use New Hinsdale UPGRADE CONFIGURATION #6 to combine everything onto a new 120GB "A" drive. 
Then use mfsadd to make the spare 40GB drive your B drive.


HTH


----------



## sskraly

Aha--brilliant! Thanks!

One other question: if my B drive has a few potential bad blocks (failed the Read Verify test in WD Data Lifeguard), is there any command line switch to add to the mfsbackup to let it coast through the errors (similar to the dd conv=noerror,sync switch when using the dd method)?

mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdc

Thanks again!


----------



## sskraly

OK, I tried Upgrade Config #6 and it's claiming that the backup won't fit on the target. I've got:

hda: 78125000 sectors (40000MB), CHS=4863/255/63
hdb: 156301488 (80026MB), CHS=9729/255/63
hdc: 240121728 (122942MB), CHS=238216/16/63

I'm running:

mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdc 


and I get this during the mfsbackup scan:

Source is 15 hours upgraded to 95 hours upgraded to 127 hours...

Uncompressed backup size: 113434MB

"Restore failed: Backup target not large enough for entire backup by itself"

Any ideas? Could it have anything to do with the 120GB drive coming up as 16 logical heads, whereas the others have 255?

Thanks in advance...


----------



## Robert S

You need to follow the second past of the third post in this thread. Use dd to clone the A drive on to the new one, follow the instructions to manually create a larger swap partition and then use mfsadd to expand to a 120+80Gb.

Or, if you /have/ to replace the 80Gb drive (faulty?), dd the 80Gb on to the new one and then use mfsadd to expand, but keep a copy of the 'rescue' maneuver (first half of post three) handy as doing this will break the TiVo's ability to recover from a green screen.


----------



## Robert S

Michael: To get any of these things to work on a Series 1 TiVo you have to boot byteswapping. If you manage that, the answers to most of your questions become obvious.

pdisk is the tool to manipulate the partition table. If you invoke pdisk -l /dev/hdX it'll list the partitions on the drive you designate. If you run pdisk without -l it'll enter an interactive mode (be careful!) where pressing p prints the partition table.

A drives have lots of different partitions, B drives have just two (or, at least, very few) MFS partitions, so the difference is obvious.

You can't fix the swap problem permanently without deleting your recordings because there's no unused space on the disk. The space used for the 'rescue' maneuver is only temporarily unused, which is why you have to back out to the original config when the TiVo recovers.


----------



## Michael248363

Thanks Robert. I ran pdisk and listed the partitions, based on what I found I've got a couple of questions. I've abbreviated to only include the relevant partitions that I reordered so that I could get past the GSoD reboot loop. I've since re-reordered the partitions so 8 is 7 and 7 is 8.

7: Swap Linux Swap [email protected] (128.0M) 
8: Ext2 Root 2 [email protected] (128.0M) 

So if I'm understanding this right, it looks like my swap file partition is 128MB, the same size as the rescue partition. If that is true, why can't I create a swap file that is 127MB in size? Is there something else on the drive that would prevent me from using the entire drive to create a 127MB swap file? If the partition is 128MB, the when I did the upgrade, did I create the partiton correctly, but just not create/initialize the swap file? If so, do I just need to run mkswap. If so, what are the parameters that I should use to get 127MB of swap file?

I just want to make sure I've exhausted all possibilities and that if I can't fix it to prevent future problems, I want to understand exactly why. Plus, I also want to understand it better. Like I said, my experience with Linux is pretty limited.

Thanks again for the help.


----------



## Robert S

It looks like you used -s 128 after all. 

I did suggest that you check for that and if you had done that you could rescue your TiVo by following the instructions in the first post to run mkswap against that partition.

Although the partition labels are messed up, you could just leave things the way they are.


----------



## Michael248363

I couldn't remember what option I ran when I did the upgrade and didn't know how to check the size of the partition earlier and since I've got 3.1, I can't enable backdoors to check the logs.

So running /sbin/mkswap -v0 /dev/hdc8 (using the right drive of course) will create the proper swap file.

I understand everything about the command except for the -v0. I saw in the help for the program that you could also do -v1. What is that option for?

Just trying to understand it better.


----------



## Robert S

They changed the way swap works after the kernel that (Series 1) TiVo uses was compiled. -v0 tells mkswap to make an old-style partition (limited to 127Mb). -v1 is the default and creates the new style partition. Unlimited size (?), but not compatible with a Series 1 TiVo.

I think Series 2 TiVoes should be able to use a new-style swap partition, but I don't have confirmation of that.


----------



## davidk

I need some advice!

I revived my DSR6000 from the GSOD by using the inactive swap partition method described by Robert at the top of this thread. I let my DirecTiVo fix itself and I swapped the partitions back. I made a backup image of my 3.1 TiVo. However, now I'm getting frequent reboots and I fear that the only way to really fix my TiVo is to clear my hard drives (160G A Drive and 120G B Drive) and restore a backup.

Here's my question: is it ok to use the 3.1 backup that I made after TiVo self-repaired from GSOD or should I go back to my original backup image (I made it back in 2/2002) with a system version that I don't remember?

Also, when I restore, I plan to use MFS 2.0 (to get increased speed in navigating menus) and increase swap to 127MB. Can I do this with the old backup image from a year ago (if that's the backup I should use)?

Thanks to everyone for all of the great advice and help! I have enjoyed a 245-hour DirecTiVo due to the efforts of those on this board.

--David


----------



## Michael248363

A couple of questions that are probably pretty basic if you understand Linux:

1. Is there any way to tell if a partition is set up correctly to use a swap file without using backdoors? I.e. commands on the MFS Tools CD that would show a directory listing of the swap file.

2. When you issue the mkswap command, does it utilize the entire partition regardless of partition size for the swap file (up to the 127MB max, of course).

I've looked at both of my DTiVoes (DSR6k, both running 3.1 software), one has a 128MB partition for the swap file, the other has a 64MB partition. I have no idea why they are different. I thought I upgraded them using the same commands, but apparently I didn't.


----------



## rfairch1

I have Series 2, 80hr, bought maxtor 120 hd, wondering if I use mfs 1.1 tools or whatever would be best, adding the 120 as a second drive, would I be affected by the swap issue?


Thanks
Roger


----------



## Robert S

The threshold for a Series 2 is 180Gb, so adding a 120Gb drive to an 80Gb one will break mfsfix without additional swap.

MFS Tools 1.x won't help you very much.

If you use mfsadd to add the drive without increasing swap, your TiVo will work, but you will have to use the 'rescue' maneuver from the third post in this thread if your TiVo green screens.


----------



## rfairch1

Robert,
Thanks for the reply.

If I increase the swap with the -s127 will that address the problem? Or is this just a risk that may/will happen if I upgrade using the original 80 and add the 120....

Or is there a method I can use / tools that will give a good result?

Thanks again.
Roger


----------



## Robert S

Normally I'd advise you to upgrade replacing the A drive with the new one, thus increasing swap with -s 127 and then add the old A drive as a B drive.

However, there have been some reports of problems increasing swap on the 80Gb S2's and I haven't been following the debate on that (the problem may not be real).

Hinsdale's How-To should have the answers you need.


----------



## weaknees

We've tested added swap on the S2s pretty fully at this point, and we don't see any problems. We thought we saw one at one point, but we couldn't confirm or recreate it.

We've been adding extra swap to all S2 upgrades that we can, and we haven't seen any problems related to it.

Michael


----------



## jeaton

I have a Sony T60 which I upgraded to have a 120GB+40GB with mfstools2 using the -s 128 option (before the problem with -s 128 became known).

My tivo recently got stuck in the green screen reboot loop. I pulled the drives, mounted them in my PC, and checked the logs to find that the swap partition was invalid, as I suspected. (I was getting the swapon: invalid argument error.)

I tried repairing the swap partition with 
*mkswap - v0 /dev/hdc8*
(with my tivo's A drive attached as hdc, obviously). This failed to fix the reboot loop. I tried it again without using the hdc=bswap option, but it still failed.

In both cases, the logs still showed swapon: invalid argument.

I then booted with hdc=bswap, and ran
*mkswap -v0 /dev/hdc8 130048* 
to tell it to use exactly 127MB of space (in my 128 MB partition) as swap. I returned the drive to my tivo, where it proceeded to boot to the green screen, sit there for about 15 minutes (running mfsfix, I presume), and then rebooted and came up just fine.

I don't know why I had to specifically pass a size to mkswap on my system, but it did seem to work.

Thanks much to everyone who contributed to this thread. The infomation provided was invaluable to me in diagnosing the problem my Tivo was having and finding a workable solution. I owe you all a beer.


----------



## Robert S

That's odd, on my system mkswap gave a warning 'Truncating to <large number>' and automatically produced a 127Mb swap partition in a 128Mb hole.


----------



## jeaton

> _Originally posted by Robert S _
> *That's odd, on my system mkswap gave a warning 'Truncating to <large number>' and automatically produced a 127Mb swap partition in a 128Mb hole. *


I also got the truncating message, but it still didn't appear to properly intitialize the swap area. After running mkswap without the size, the TiVo still logged errors about swap, and still failed to make it through mfsfix.


----------



## mrtickle

Presumably different boot CDs use different versions of linux (remember linux is running on the PC) and could be running different versions of "mkswap"?


----------



## ndwek

I am upgrading a previously upgraded Tivo and am having a problem with the pdisk command from the post, "How to fix your TiVo if it gets stuck on a green screen", the section marked "Upgrading Twin-drive Tivoes".
I previously upgraded the tivo from a 20GB single drive by adding an 80GB drive B. The original 20GB drive is starting to go so I'm replacing it with a 120GB drive and I'm preserving the recordings (upgrade configuration #4 from Hinsdale how to using MFST2).
I've done the dd and now want to fix the swap. Booting from MFST2 boot CD byteswapping is no problem. I run pdisk, "pdisk /dev/hda", also no problem. After typing "C" I am asked for the First block. I type "12p" and get an error of "Bad partition number".
Using the p command to print the partition table I see that the partition numbers only go up to 11 and have confirmed that this is the same on the original A drive.
What am I doing wrong?

Thanks,
Norman


----------



## ndwek

So I've realized that if there are 11 partitions then I can't specify 12p because it doesn't exist, hence the error. Now my problem is that no matter what I do I can't create a partition of any sort.
I've tried specifying 11p and 10p as well as adding the base and length of the last partition to come up with the next free base but no matter what I do I get the error message:
"requested base and length is not within an existing free partition"

Any idea what I'm doing wrong?


----------



## cojonesdetoro

I looked at the regular linux man pages for swapon and found that you can create swap space using a regular file on the ext2 file system and not need to create a partion. I tried this on my tivo and it seemed to work. The log messages showed the added swap space.


First I did this to create a blank 64MB file:

dd if=/dev/zero of=swapfile bs=1024 count=65536

Then I ran this command to format it as swap space:

mkswap ./swapfile

Then I did this to add it as swap space:

swapon ./swapfile

I then rebooted my tivo to undo this and started writing this post. Here are my questions:

Is this useful if put in early in the boot process or does a GSOD not even load Linux?

Could this help those that have stuttering or other performance problems?

Are there any pitfalls? It seemed to work...


----------



## Robert S

It'll work, but it isn't very useful.

For a start, on an unflashed DTiVo or any Series 2 the lock-down will revert the TiVo to its original condition.

So, assuming you have a Series 1 standalone, you could use this technique to increase swap.

swapon activates swap in the current session, not permanently. This is fine if you have a shell on your TiVo so you can run swap on manually, but the shell won't activate during a GSOD. You'd therefore have to add swapon to rc.sysinit (or, probably preferably, fstab).

The GSOD is the only thing that uses a lot of swap - if you check now, you'll find your TiVo is only using a few megs of swap. Adding more unused swap will not cure any stuttering or other performance problems you may be having.

If you run into problem with the GSOD running out of swap, then the 'rescue' maneuver described in the third post of this thread is probably a better choice than creating swap in /var.


----------



## cojonesdetoro

> _Originally posted by Robert S _
> *
> If you run into problem with the GSOD running out of swap, then the 'rescue' maneuver described in the third post of this thread is probably a better choice than creating swap in /var. *


But the rescue maneuver involves opening the Tivo and mounting the drive(s) in your PC which, for some, is logistically difficult. It would be nicer if there was an easy way to increase the amount of swap available for GSOD without having to do an mfsrestore -s 127 to a new drive.

My situation is such that I can only do it while losing recordings. My wife would kill me if I lost all the episodes of OZ and I don't have the time to download them to VHS.


----------



## mrtickle

You could use merge.tcl to join the episodes together into blocks and then run off 8 hours' worth each night while you're asleep. You should get them all off the tivo in a few days?


----------



## Robert S

OK, sure. If you have a Series 1 stand alone, with a shell on it and you upgraded it over the limit and you're worried about running out of swap, then, yes, it might be a good thing to do.

I suggest you modify /etc/fstab so the extra swap gets activated as early as possible.


----------



## dhwebb

OK. I've looked, seen one post about it and no comments about it. That is permanently swapping partition 8(swap) and 9(/var). Somebody claimed that /var is 128M. Could /var survive on the 64M partition. If so, is this a good fix.

Any problems that could arrise.

I have a S2 80hr +120G(b) on 3.2 w/64M swap.


----------



## ron_b85

> _Originally posted by dhwebb _
> *
> 
> I have a S2 80hr +120G(b) on 3.2 w/64M swap. *


Which tool(s) did you use? MFS Tools 1.1 or 2.0?
I'm looking to *just* add a 120G drive to my Sony S2's 80G, but don't
want to go through the steps of pulling the 80G out, backing up, etc...
I'd just like to "bless" the 120G and drop it in place (weaknees are able
to do this with their 'upgrade kits'...)

Thanks for any pointers!


----------



## dragon

I just finished upgrading my 40gb single drive DSR 6000 to 120gb x2 using MFStools 2.0. (TIVO version 3.1)

I thought I read everything I needed before getting started. I even stopped my upgrade at 70% after having waited 4 hrs because I realized that a swap file increase was needed. So I added the -s 128 that I was reading about and then the next day, I find this string of messages about the 128 swap file problem. DAMN!

Can I just live without this swap file?
I'm 10 hrs into this thing and am tired of it.
I may just bite the bullet and redo it with -s 127.... but this really does work right? If i do a -s 127?

By the way... any of you know why my recorder now says only 225 hrs recording time when I go to system information? I thought it would be more.

Oh yeah... where is the backdoor code for TIVO version 3.1 I tried the code I saw here for 3.0 and it didn't work.
Dave
[email protected]


----------



## Robert S

Read the first post in this thread. There are a number of options there that you can use to initialise your swap.

DTiVoes have 32Mb of RAM, so you may find it's OK with no swap. Series 1 SA's only have 16Mb of RAM and misbehave badly without swap.


----------



## ehayes

Yea, I've recovered from the green screen, using the alt boot partition temp fix!!

MANY THANKS for having this here!!!! I get my "stuff" back!! ;-) I am so Fricking Happy!!!!

So... As I need to give back the alt. boot partition.... Do I have to watch ~everything~ to get back to an empty state so I can reformat with a correct swap? I used the -128 before the swap problem was known?

Thanks guys!

-eric


----------



## Robert S

If you used -s 128, you have a 128Mb partition without a valid swap signature in it, so you can just use mkswap to initialise it instead of doing the 'rescue'. 

You can probably leave it in the 'rescue' configuration as the empty swap partition is the same size as the root partition you replaced it with.

See the first post in this thread for very detailed instructions on what to if you used -s 128, although, having done the 'rescue', it should be pretty obvious what to do.


----------



## theJakeLuck

Green screen of death... I knew what it was even before visiting this forum to find out what to do about it, and I was scared. I encountered my first GSOD today and I think I know what to do to fix it. Months ago I successfully upgraded my AT&T, series 2, v.3.0 from single 40gig to twin 120gig hds. I dd copied my entire original 40gig drive directly onto new 120gig, expanded, and married to another 120. I did not increase my swap file. I think it's still 64MB because I'm now stuck in boot up loop including GSOD. Is there a way to expand to 128mb without losing everything? I did create backup image of my original hard drive before recycling it in my PC.... however, now I can't find the backup file. It's either lost or deleted. Can anyone help me with a backup image for my particular TiVo? I think if I can restore that to my new large A drive I can then expand my swap file using -s 127 and hopefully green screen of death is gone????


----------



## Robert S

Did the 'rescue' maneuver from the third post in this thread work for you?

There's no way to expand swap permanently without losing your recordings, but you can do the 'rescue' as many times as necessary.

If the 'rescue' does save your TiVo, you can make a compressed backup from your current drive set.

It would be a good idea to run diagnostics (PowerMax, or whatever) on the disks to check this isn't a hardware problem.


----------



## theJakeLuck

I have not yet tried the 'rescue' maneuver. I'll give it a shot tonight.


----------



## ksucat90

Ok, first here is the scenario. I have a Series 1, with 14 hrs, used BlessTivo and added a 60 Gb Maxtor about 2 years ago running v 3.001100. I wanted to upgrade to a single 120Gb WD drive so, I used the MFS tools 2.0. After booting MFSTOOLS cd, I ensured all drive registered proper sizes. I made a backup of both drives using the following cmd.

mfsbackup -6so /mnt/dos/tivo.bak /dev/hdc /dev/hdb 

unmounted and rebooted and attached new 120Gb drive to hdc (Secondary Master)
Then attempted to restore to new drive using the following cmd

mfsrestore -s 127 -zpi /mnt/dos/tivo.bak /dev/hdc

I restored, but on cleanup gave me a bunch of Inode errors. I attached the new drive to my Tivo and booted, got the Almost there screen, it rebooted, gave me Almost there again and has gone to the GSOD.

So I went back and tried the restore expanding at the same time with this command.

mfsrestore -s 127 -xzpi /mnt/dos/tivo.bak /dev/hdc 

Same problem. GSOD. So question is, what have I forgot to do? The original drives still work, so I assume the backup is good. (816mb) I even did the complete process again to check myself.

Any help would be appreciated.


----------



## Robert S

Rather a strange choice of thread to post this in, but never mind.

I would think the hard drive is faulty - run the manufacturer's diagnostic utility on it before you go any further.


----------



## Davin

Given this whole discussion, what is the current consensus/advice for upgrading a Sony SVR-3000?

I've purchased a 120GB disk to add - and burned an MFS tools 2.0 CD, as per Hinsdale instructions. 

How unsafe is it to just do a mfsadd? Or should I go through one of the longer procedures, such as: make my 120GB my new single-drive first (while growing swap with -s 127), and then mfsadd my original 80Gb afterwards?

Thanks.
Davin.


----------



## Robert S

How worried are you about the Green Screen of Death? If it happens you'll have to do the rescue. That's all you need the extra swap for.


----------



## Davin

And the rescue, using the secondary root partition as temporary swap, should always work and be safe, (as long as I remember to revert it!) in case my TivO does GSOD?


----------



## Robert S

It does seem to be working well for people (I don't get lots of PM's or posts asking why it doesn't work).

mfsfix can't fix every possible problem, but the rescue does seem to allow it to run.

If you think about it, doing the rescue is functionally equivalent to increasing your swap with -s 127.


----------



## Davin

Is there no way to create a swap partition on the second (i.e. the new, being added) drive? Will the kernel not find it? (Since spreading swap partitions over multiple spindles is usually a good thing anyway.)


----------



## Robert S

Yes, but to activate the swap partition you'd need to modify /etc/fstab. The Series 2 TiVoes are locked down, and this would restore the original /etc/fstab and prevent it activating.


----------



## Davin

Thanks. That makes sense.

So I guess that I'll just go ahead and to the mfsadd upgrade, and hope that the TiVo never needs to run mfsfix. 

Thanks again.
Davin.


----------



## deek_man

I have a series 1 Phillips that that I upgraded to two 100 GB Maxtor hard drives about a year ago. Unfortunately, I upgraded before the swap problem had been found and I ended up with 64 MB swap. This morning I discovered I had the green screen reboot loop.

I used the rescue operation described by Robert S. in the third post of this thread using the newest version of MFSTools and everything seemed to go fine although when I used the r 8 7 command (my inactive root partition was 7), followed by w and y, mfstools said that it was unable to confirm (reread) to make sure the writing had been completed because the device was "busy". I assumed that this response probably wasn't a problem and that Tools had successfully renumbered the partitions.

When I returned the A drive to the Tivo, I got the green screen reboot cycle but it appeared to be rebooting even more quickly (i.e., staying on green screen for even a shorter period of time) before rebooting. Since the instructions said the reboot should be "occasional", it troubled me that the cycling of the reboot was so fast. Nevertheless, I let the machine run for a couple of hours and the fast reboot/green screen cycle still continued.
I then restored the original partitition numbers as per the Directions (F) and the reboot/green screen cycle slowed a great deal. Although the green screen said to keep the phone line plugged in, I did not do so since there was no mention of the need for that in the rescue instructions. I renumbered the partitions one more time (assumedly going through the rescue operation one more time as in instruction D) and once again got the fast reboot cycle.

I have a pretty good understanding of what the problem is but my understanding of Linux is very poor. I realize I could have a problem other than the swap problem but I sure could use some help with the following questions:

1) Does the fast reboot cycle normally happen just after the rescue operation? 

2) How long should the rescue take?

3) Is there a way to tell whether my partitions are in their original configuration or in the rescue configuration? 

4) I notice when I boot up using MFSTools, it lists the various partitions , what they're beinused for and something like sz = XXXX where XXXX is a number. Is that the size of the partition?

3) Does it matter if the phone line is plugged in?

4) Any suggestions at all would be helpful since I'm at a point where I really feel pretty lost. I suppose I could just use my backup file to recreate the A drive and start from scratch marrying the two drives, etc. with the new improved instructions but I hate to lose all my programs, season passes, etc.

Thanks in advance for any help you could give me.


----------



## Robert S

If the rescue works, then the Green Screen should stay up and fix the problem. As I said, some people have reported that their TiVo rebooted once or twice before the GSOD cleared, so there's no need to panic if the GSOD reappears after the first reboot, but it takes about 10 minutes for mfsfix to allocate all the memory it needs. If it reboots before that, then it's not doing any useful work.

With 64Mb of swap it seems to take about 4 minutes for the system to realise that it doesn't have enough memory and kill mfsfix. The fact that you're rebooting faster suggests that you do not have any swap in the rescue configuration - therefore it runs out of memory immediately.

That column does give you the size. You'll see that the swap partition is 64Mb and the kernel partitions are 128Mb.

Apparently the GSOD can download files from TiVo if it discovers that something important has become corrupted. I doubt it's important in most cases. I didn't mention it because it's a normal part of the TiVo setup, and the GSOD tells you to plug it in!

I would check the TiVo logs (you'll have to mount the /var partition and read /var/log/messages) to verify the swap situation. I would try running mkswap on partition 7 again. I would also run diagnostics on the A drive just incase there's a bad block in an awkward spot.


----------



## deek_man

Robert S., thanks lots for the quick response. I did use pdisk to list the partitions and the r 8 7 command did seem to be switching the swap from the 64 megabite swap partition 8 to partition 7 at 128 mb and vice versa. But I'll go back and do the things you suggested and then let you know what happens. Thanks again.


----------



## deek_man

I did go through the mkswap routine again and in pdisk, it did reorder the inactive root partition 7 with the swap partition 8. Partition 7 became the swap partition at 64 mb and partition 8 became the secondary root at 128. Isn't that how they should look? I still get the rapid cycling green screen and reboot and it continues indefinitely. Two quick questions:

Could you tell me more precisely how to read the message log? I was able to mount hda9 but was unsuccessful at trying to read the messages since I know so little about linux commands.

Second, I have the original TiVo hard drive that came with the machine last year along with the software upgrade it downloaded when I first used the machine. If I disconnect both of my upgraded drives and put it on as the master and the machine works, I would assume that means it's either the drive or a problem with the software or swap, wouldn't you agree?

Update: I did put the original hard drive back in the machine and it works fine.


----------



## Robert S

We're using a trick here to fool Linux into using a different partition for swap. The entry in /etc/fstab declares that partition 8 is to be mounted as swap on boot.

So the rescue involves relabeling partition 7 (or possibly 4) as partition 8 and using mkswap to make it a swap partition. As the kernel partition is larger than the original swap partition, this buys us enough extra swap for mfsfix to run.

The position you want to be in, therefore is to have a 128Mb partition 8 and a swap signature on it. Run pdisk and/or mkswap as necessary. I take it you did include the -v0 to make it use the old style of swap signature?

I did describe how to read the log in the original post that's linked in the inital post.


----------



## deek_man

Thanks. Your last post was very informative. It always is easier when you have some sense of what you're doing rather than blindly writing commands. I guess I need to take a Linux lesson.

I believe I've found my problem but not the solution. I have been using the print (p) command in pdisk to see what the partitions look like after performing the intended changes. No matter what I do, i can't seem to get 128 mb of swap in partition 8. I have been using the makeswap command in the third post: 

mkswap -v0 /dev/hda7

If I then go into pdisk and use the p command, it doesn't show partition 7 as swap but rather still as root 2. Thus, if I use the reorder command, partition 8 doesn't end up with a swap signature. Maybe that's why my reboot/green screen cycling was so quick. The software didn't see any swap in partition 8. I've also reordered first to make partition 8 the root with 128 mb and then tried to use mkswap on 8. Didn't work either. When I use mkswap, the info comes back with some reference to a program called Busybox and it appears to work as it gives no error 
messages. Can you think of any reason why my mkswap command isn't changing the partition 7 to swap? I'm using mstools2 noj as currently posted at the Hinsdale howto site.

BTW, I did look at the messages in /var and there are lots of them but I really don't know what they mean. Is there something in particular I should be looking for?


----------



## Robert S

mkswap doesn't change the label in the partition table (I don't think anything except pdisk uses those!), it writes a small amount of information into the partition itself that declares that this is so many bytes of valid swap. You would expect to see partition 7 called swap and partition 8 called Root 2 when in the rescue configuration. You may need to run mkswap on partition 8.

If your swap is broken there will be about three lines saying something like 'cannot activate swap' - it's easier to find when it's broken 'cos when it works there's only one line declaring that swap activated OK. The lines appear before the clock is set, so they'll be on the 1st of Jan 1970.

I don't know why mkswap would give problems, it's always worked fine for me. Busybox is just a container application that includes a lot of twiddly Unix commands in one file. It's a much more efficient use of disk space than having each command be its own file. Saying nothing at all when things have worked, but giving a confusing error message when something's gone wrong is typical Unix.


----------



## deek_man

Robert S., thanks so much for all of your helpful responses. I learned a great deal about Unix and hopefully, this exchange will help others trying to do the rescue operation.

Your last response about Unix pretty much saying nothing when things work and giving a confusing message when things don't work was really helpful. Also, your message about trying to get 128 mb in partition 8 as well as your message indicating that pdisk doesn't really show that as swap helped lots.

So what happened? I'm a little embarrassed to say that when I copied the third message in this thread where you explain the rescue procedure, I pasted it into a word processing program to print it and use it. The program (WordPerfect) apparently due to font differences and printer output, placed two dash marks for the large dash which is in front of the -v0 switch in the mkswap command. So, just as you suggested in one of your responses, that switch was not working since I was using two dash marks when I tried mkswap. When you pointed out that the version of mkswap could be important, I went back and looked at your original post and realized that only one dash mark should be there. (Obviously, I know nothing about Unix.) Also, your last post indicating that pdisk wouldn't show that partition as swap made me realize that I was looking for problems in the wrong place.

So, in short, your original directions produced exactly the fix they were supposed to. When I finally appropriately produced the 128 mb partition 8 with a swap signature, the machine did exactly what your directions said it would do, namely stay on green screen for extended periods and reboot a couple of times and then fix itself. Specifically, the green screen stayed on for about 10 minutes, then tried rebooting, then went to green screen for about another 10 minutes (or perhaps a bit longer) and then rebooted and everything was fixed. (I did, importantly, reorder the partitions to their original configuration after the fix.)

So, in the end, it was the problem with too small a swap partition (64 mb swap for 200 GB split between two hard drives) that caused my GSOD, and, using the right commands it was (or should have been) fairly easy to fix.

Thanks so much for your help and quick responses. I really appreciate it and I'm up and running with my entire sytem restored. Thanks from D.C. to Cabridgeshire.


----------



## deek_man

Regarding the above fix and the final step of reordering the partitions back to their original configuration. As long as pdisk now shows partition 8 as 64 mb of swap and partition 7 (my inactive root) as 128 mb of root, I should be ok at the next software download. Right?

Thanks again for your help.


----------



## Robert S

That's the original configuration. On the next software upgrade it'll format partition 7 as Ext2 and put your new software on that partition.


----------



## mutant

Hi all:
MFS 2.0.
After several tries I got to the point of adding the 14th partiton for the swap drive.
This was a problem - pdisk reported an invalid partition when I tried the 14p parameter to C.
I realized the partition table still thought the drive was 40gig rather than the current 120; so I reinitialized the partition table and reentered the partition info (reordering so it was identical to the orgional).
I then created the new swap partition with 14p and did the reordering - all seemed well.
When I try to run mfsadd it gives me lots of errors - am in byteswap mode (booted with vmlnoma hdc=bswap - hdc is the drive I am upsizing)
Second MFS drive needed: No such file or directory
Second MFS drive needed2: Illegal seek
Second MFS drive needed: No such file or directory
Second MFS drive needed3: Illegal seek
mfs_load_volume_header: Total sectors(77242368) mismatch with volume header(3363200)
mfs_volume_header: loading anyway
mfs_load_zone_map: Primary zone map corrupt, loading backup.
mfs_load_zone_map: Seconday zone map corrupt, giving up.
mfs_load_zone_map: Zone map checksum error!
Unable to open MFS drives.

I have put it back into the TIVO and it seems to be working fine.
Help!
Mark


----------



## Fuzz

I just added a 160 GB drive (as the 2nd drive) to my Series II 60 hour Tivo. I didn't realize the swap issues until I was done. I'm not too afraid of the GSOD fix, but since I only upgraded a few days ago, I am wondering if I have a chance to redo the upgrade and add the swap at the same time without losing any significant recordings. 

My plan is as follows:

1) Using the option to restore and expand (while saving recordings and increasing swap), copy my current 60 GB drive over to the 160 GB drive (and overwrite whatever is on it now)

2) Add the existing 60 GB drive as my "second" drive.

Will this work, or since I already added the 2nd drive, will something bad happen? I figure that there aren't many (if any) recordings on my 2nd drive and I don't care if I only lose a few new programs.


----------



## Robert S

The problem is that the 160 is already part of a 'married' set. If you restore a current backup to the A drive your recordings /might/ survive (if I recall correctly you do want -p for an S2, but not -s 127 or -x), but it's far from certain.

That would reverse the upgrade and then you could copy the recordings over to the new drive.

TBH, though, I wouldn't bother. Just make sure you've got a copy of the MFS Tools CD and a print-out of the rescue procedure in case you ever need it.


----------



## mutant

Got the mfsadd problem worked out - I needed to have both drives in in order to do the add. Worked flawlessly when I did this.
Anyone doing this second upgrade (40g A drive to 120G A drive when you have aleady added a 120 as B) will need to look out for the problems with not being able to dd copy the drive and then update the partition table. 
I understand there is a newer version of pdisk that will allow you to specify that to determine the drive size by means other than the partition table. Otherwise you will have to initialize the partition table and manually reeneter the data. This is a very difficult acticity to undertake!
Mark


----------



## Robert S

I'm glad you've got it working. You are the first person to report this problem with pdisk. The procedure is lifted from the TiVoMad script (it does this if you tell it your TiVo is >140Gb). I assume Trevor's version of pdisk is the same as on the MFS Tools 2.0 CD.

As ever, comments on any of the procedures at the top of this thread are welcome. The manual swap procedure is by far the least well tested (because it fixes a very specific problem). I fervently hope that manually rebuilding the partition table isn't part of most people's experience (how would I write that up?


----------



## Fuzz

Ok good point. Does anyone have any odds on the GSOD? I mean, all I can tell is that it is "rare." How rare are we talking, once in the lifetime of the Tivo, only when the hard drive is about to fail anyway, etc.?



> _Originally posted by Robert S _
> *The problem is that the 160 is already part of a 'married' set. If you restore a current backup to the A drive your recordings /might/ survive (if I recall correctly you do want -p for an S2, but not -s 127 or -x), but it's far from certain.
> 
> That would reverse the upgrade and then you could copy the recordings over to the new drive.
> 
> TBH, though, I wouldn't bother. Just make sure you've got a copy of the MFS Tools CD and a print-out of the rescue procedure in case you ever need it. *


----------



## Robert S

I don't have any numbers for you, 'rare' is the best I can do. Fixing GSOD's is not the major topic in this Forum, so given the number of TiVoes out there, I would infer that most TiVo owners will never see a GSOD.

The rescue procedure is not all that onerous. Many people have used it successfully.


----------



## aaronkn

Robert S,

Sorry if you've already posted about this somewhere (I'll keep looking), but I'm trying to do the recovery method in the 3rd post of this thread, and can't seem to get going. I'm new at working with this stuff. 

I made a boot CD with MFSTools 2.0 as directed, and connected my TiVo A drive to my computer. I accidentally swapped with my Secondary drive at first, but then switched it with my Primary drive afterward. I booted with the CD. Now I noticed that you said Series2 Tivos are NOT byteswapped, so I skipped that part.

I got a prompt on the screen that says "boot". I tried typing the first command of "edit_bootparms hda -r", but was given a "command not found" response. I then tried the "mount" command, but that was also not found. I stepped away from the computer for a minute, and then it started running some commands on its own. When it was done, I had a prompt of "/#". I tried both of the previous two commands at this prompt, but they didn't work this time either. The mount command responded with "unknown device".

Is there anything that you can tell me to help me get going?

Thanks,
Aaron


----------



## Robert S

Not sure why edit_bootparms wouldn't run. I don't have an MFS Tools 2.0 CD on hand to check it. I would guess you just mistyped the command name.

Mounting an unknown device also suggests a typo. If you try to mount an empty partition it should ask you to specify the filesystem type.

Did you have your A drive on primary master? 

Do you see the TiVo partition table printed during boot-up?


----------



## aaronkn

Ok, I'm now a little concerned that when I first plugged my Tivo drive into the Secondary place on my PC, that WinXP may have put a signature on it. I'm not sure. Anyway, I'm not sure about the partition table....but one thing I did notice is that I saw "hde" somewhere, instead of "hda". So I just tried typing "mount /dev/hde4 /mnt" and the prompt came back with no message. When I then type "ls -l /mnt", it comes back with 33 responses, all with the same date/time.


----------



## Robert S

If the drive is no longer bootable in the TiVo, you'll need MakeTiVoBootable.

hde suggests you've plugged the drive into the wrong socket. It doesn't look like it's a problem, though, just substitute hde for hda and carry on.


----------



## aaronkn

Well, I plugged the drive back into Tivo, and it goes through the same GSOD boot loop. Since that's what it was doing before, I'm guessing I'm ok as far as the WinXP signature problem?

So, how do I know which partition to mount? I tried both hde4 and hde7, and both seem to mount. When I mount hde4, "ls" gives me 33 listings. When I mount hde7, I get 31 listings. All the listings have the same date. Do I just pick one and move on the the "mkswap" step?


----------



## Robert S

How can they have the same date?

The problem is that if you pick the wrong one you'll erase your TiVo software! If you really can't get edit_bootparms to work, perhaps something like "dd if=/dev/hde count=1 | strings" would work (assume strings is on the MFS Tools disk. That should include something like root=/dev/hda4.

You can back up your root partition before you format it. Assuming you have a writable partition on /mnt (which might be tricky for you), you can do "dd if=/dev/hde4 of=/mnt/tivo4.bak"


----------



## aaronkn

Oops, sorry . . . I meant all the listings FOR THAT MOUNTING have the same date. Each of the two mounted partitions have a different date from each other. hde7 has a date of Jun 2 2002; hde4 says Apr 23, but doesn't give the year. I'm believe that was this past April....I think that's when ver 4.0 downloaded, so hde7 should be the inactive one.

I typed "mkswap -v0 /dev/hde7"...it said "mkswap: warning: truncating swap area to 130752 kB" then "Setting up swapspace version 0, size = 133885952 bytes"

Then I ran the pdisk command, and it gave me a prompt "Command:" I typed "r 8 7" <enter>, then "r 5 9" <enter>, then "w", then "y". It came back with pdisk: re-read of partition table failed (device or resource busy) Reboot your system to ensure the partition table is updated.

I'm not sure what I'm doing wrong.


----------



## Robert S

Yes, if it doesn't give the year it means this year (or even, within the past year). 

Don't know what's wrong with pdisk, can I hazard a guess that it's to do with your using the wrong disk controllers?

Anyway, did you reboot the system and check that the partition table has been updated as pdisk requested?


----------



## aaronkn

I rebooted, and if I try mounting hde7, it says "looks like swapspace - not mounted" "mount: you must specify the filesystem type"

Does this mean that it was successful in making the swapspace, and that I should now put it back in Tivo to let it try and fix itself?

Thanks


----------



## attivoplayer

I have been having a great time using mfstools 2.0 backing up and restoring configruations on my ATT Tivos however, I have found that whenever I restore (typically with):

mfsrestore -zpi /mnt/dos/tivo.bak /dev/hda

Everything works fine except, any time my tivo calls up or i force a call, I get the error:

"Failed While Preparing Data" 
after it downloads from the service. 

BTW, I have v.4.0 system

Any help appreciated!


----------



## Robert S

I don't know what's wrong there. You might want to start a thread for this to get a bit more attention.


----------



## philhu

so, since it looks like my svr-2000 will be getting no more system upgrades, is it worth while to make my hda7 (nonused system partition), a swapfile of 127meg and adding it to /etc/fstab to be mounted on startup along with the hda8 swap?


svr-2000 has only 16meg memory and crashes on some apps, so my question is whether adding 127meg more swap will stop the out of memory crashes during normal operation.


----------



## Robert S

It couldn't hurt to try. I've no idea what'll happen if it does try to take an upgrade in that config, though, so key an eye out for new updates, however unlikely.

Try it and see.


----------



## philhu

ok, so I would do a 

mkswap /dev/hda4 130752
swapon -a

The 130752 is the largest swap file allowed, correct (127.6875meg)

Also, how would I put it back to a std partition later, is there any way to do it while in the tivo? Is the 'mkfs -t ext2' command available on the tivo?

And finally, could I not just take hda4 and format it as ext2 (I used mfstools 2, so the partition is empty), then build a swapfile on it of
64meg, put that in ther fstab, so if an upgrade ever did come down, 
there would be plenty of room for the system (System uses about 40meg):

# dd if=/dev/zero of=/dev/hda4/swapfile bs=1024 count=65376
# mkswap /dev/hda4/swapfile 65376
# sync
# swapon /dev/hda4/swapfile

Even better, how about a 32 meg file on /var? I know it is 25% of the drive, and tivo can end up wiping /var if it gets full, but it never gets over 40% in my experience.

Anyone have the 'free' command compiled for Tivo?


----------



## Robert S

Why don't you try it as straight swap to see if it fixes your stability problem? I doubt it will unless you've got a memory leak (in which case scheduled restarts of the offending app would be better). 64Mb is already a 4:1 over-commit. An unmodded TiVo will only use a little bit of swap when it runs the indexer.

It's mfsfix that requires vast quantities of memory (up to 127Mb with the standard kernel).

When the software update comes in, the TiVo will reformat the inactive root partition ready for the new software (I think mke2fs is the command you're thinking of, mkfs is usually a script that knows which format utilities are installed). Similarly, mkswap will fill the partition (up to the 128Mb limit) if you don't give it a number.

A swap file on /var could work as long as there's room. Does the TiVo download a huge tarfile containing the new software into /var when it upgrades? In which case, again, your TiVo might be fine except during an upgrade cycle.

First, find out if more swap is the solution to your problem


----------



## roup1

Hi Robert:

I have a Sony SAT-T60 w/ a failed A drive. My current config is 40GB A and 80GB B. I'm planning on restoring the backup image onto a new 120GB A drive. I would also like to re-use my 80GB as the B drive.

When restoring the backup image, can I also use the '-s 127' command to increase my swap size? Also, can I use MFS 2.0 for the restore? If so, what would the command be?

Thanks for your help...


----------



## Robert S

You will need more swap for that configuration to recover from a green screen, so you'll definitely want to use -s 127. There's virtually no difference between backups made by difference versions of MFS Tools, so there's no problem using MFS Tools 2.0 for the restore (the difference is a single bit added to indicate if the backup is from a Series 1 or 2 TiVo (to deal with byteswapping issues), just incase you're curious).

You can just restore to both drives with -x and it'll make a twin-drive setup for you. MFS Tools 2.0 won't care that your old drive was once a B drive in a different configuration.

The command would be the same as in Hinsdale:

mfsrestore -s 127 -xpi /mnt/dos/tivo.bak /dev/hdc /dev/hdb


----------



## roup1

Thanks for the great info! So I use - xpi instead of - xzpi?

Thanks again...


----------



## hopefulboydy

I've been searching through this thread as I recently upgraded my previously upgraded Series 1 SA tivo by adding a second 80G drive. I have previously upgraded (6 months ago) by changing the stock 30G A drive to 80G. In my original upgrade I replaced the A drive after copying the contenst and put my original drive in a safe place. Since I already had a backup I never made a new back up but just added the new B drive to my A drive as per instructions. 

Since I saw a lot of people have been having problems with none or not enough swap space, I enabled backdoors and had a look to see if I still had the original amount of SWAP (64Meg) and I did. My worry is that now that I have a combined 160 G I have read in this thread that I need more swap space to avoid the GSOD happening later in life. I have also read in this thread that 64M should be fine. To be safe I would rather increase my swap space to 127M but cant seem to find out how to do this safely. Most fixes I see are for creating swap space when the upgrade caused it to be lost.

How do you make 64M swap into 127M ?
I am very grateful if someone can give me the bash prompt instructions to do this. Sorry if someone already covered this as I looked through this thread and had trouble finding it. Thanks.


----------



## Robert S

You don't have any free space on the drives to increase swap.

See the third post in this thread for an emergency measure that can get you through the GSOD, should you ever get one.


----------



## hopefulboydy

Thanks Robert S. I had a look through that post you mentioned and at the end it has the following:
------------------------------------------

Run pdisk and create a new partition:

pdisk /dev/hda

C
12p
128m

You'll also be asked for the partition label and partition type. "Linux Swap" and "Swap", WITH the quotes, are the 'official' answers, but TiVo doesn't check this detail.

Swap the partition labels around

r 12 8
r 9 13

Write and exit:

w
y
q

Then prepare your new swap partiton

mkswap -v0 /dev/hda8

and you can now complete the upgrade with mfsadd as normal:

mfsadd -x /dev/hda

You should now find your TiVo boots to give you extra space and report a 130 million byte swap partition in the logs.
---------------------------------------------
I was thinking that this is my best option as the post does mention that you dont have to wait for the green screen to occur before you increase the swap. I dont know if it will work for me at the minute with my two drive set up. If it doesnt, I might try taking both drives out, formatting them to start afresh, then restore to single A drive and go from there.

Any comments anyone ?

thanks.


----------



## Robert S

Yeah, but, you need to have some empty space to create that extra partition. Your drive is already full. The rescue is the only option open to you.


----------



## hopefulboydy

Robert S, I am having a problem understanding that I have no extra space as I have 160 G of drive space and dont have that many shows recorded. Could you explain what you mean , thanks,
hopefulboydy


----------



## Robert S

Although you 'don't have that many shows', the empty space in the recording regions is not available for other uses. When you ran mfsadd during the upgrade it allocated all the unused space on the drive for recordings.

The method you referred to requires you to make the new swap partition _before_ you run mfsadd, while there is still unallocated space on the drive.


----------



## hopefulboydy

Robert S,
thanks for clearing that up.
Looks like I am left with hoping I never see that green screen and dealing with it if I do
OR
start from the beginning with two clean empty drives and my back-up file (making sure I increase the swap size at the correct point this time).

thanks for pointing me in the right direction


----------



## nysteelo

> _Originally posted by Robert S _
> * There's no way to expand swap permanently without losing your recordings, but you can do the 'rescue' as many times as necessary.
> 
> *


Is this true for a Dtivo that doesn't have a GSOD? 
I upgraded my Dtivo with 2 120gb drives and I think (it's been over a year now so my memory is foggy) I added the wrong swap space at the time. I knew I would have to eventually change it but as long as my system was up and running with the increased recording space I got lazy and put it off (I know, I know........stupid  ). My tivo can show the channel guide and still play back recordings but can not display channels or change channels and just displays a black screen with a message about "call ext. xxx to subscribe" and wont let me change the channel to one that I receive normally. I'm not sure if this is a swap space problem or hardware problem. when I look into the system info it reads no programing data past the current day. When I force a call it connects and does its thing but still displays the same data message. I'm assuming this could be the hard drive going out and the partition where the channel guide info is written is going bad. Just in case I purchased 2 more new 120gb drives and I wanted to dd the recordings on to these while increasing to the correct swap space but I ran across this quote after trying to research my problem.

If someone has run across this before and figured it out.......please do tell. I have searched this forum and not run across this yet, but if I absolutely have to I'll have to just place my old backup image on the new drives and run the 2.0 util the correct way and scrub all those recordings 

Any help will be much appreciated. Thanks.


----------



## Robert S

I doubt it's related to swap. You have 32Mb of RAM plus 64Mb of swap, which is plenty for normal operations. The GSOD is the only thing I know of that take a lot of memory. You can try restarting the recorder to clear out any memory leaks if it's been running for a long time, but TiVoes seem to run happily for months without consuming their swap.

It couldn't hurt to do the rescue to see if it helps, but I think your problem relates to a hardware issue rather than swap.

If your new drives are the same size as the current ones, I don't see how you can increase swap and keep your recordings.


----------



## nysteelo

Thanks for the reply Robert S.....

Yeah, I'm leaning towards it being a hardware issue as well. 

I think I have a way to preserve my recordings or at least view them once before deleting them and reusing the drives. I have 3 Dtivos currently, 2 of which are used on a regular basis and have both been upgraded with larger drives. The third one is hardly used and I have been putting off upgrading it until now. I just thought about using the 2 120gb drives from the tivo that is acting up and putting it into the unused Dtivo temporarily so I can watch all those shows before deleting them and put the new twin drives I just bought into the Dtivo that needs to be fixed. My only concern is if this is possible without causing any conflicts with the software looking for its previous card or a chip id that is unique to the original box.

Any thoughts?


----------



## Robert S

You can't move recordings between DTiVoes because of the encryption. You have to do a 'Clear and Delete Everything' reset to make the drives work on an different mainboard.


----------



## nysteelo

Damn!.....So much for that bright idea. I guess my hardly used Dtivo is gonna gets 2 new drives and a whole lot of attention right about now.

Thanks again.


----------



## Michael248363

Ok, the commands to determine which partition is the active root partition don't work for me.

edit_bootparms can't be found so it won't run and I can't mount either of the partitions. I can however look at the disk with pdisk and see the partitions. What I need to know is from that information that I get from pdisk, how do I tell what commands I need to run?

In other words, each of the partitions has a name. How do those names correspond to the partitions that I'm working with?. I took a guess I was swapping 7 & 8 but I still get the GSOD that reboots over and over and over after just a few seconds.


----------



## Robert S

The partition labels don't change. The only thing that determines the active the partition is a single byte in the boot block. pdisk can't show this to you.

At least one of partitions 4 or 7 will be mountable.

If you just swap the partitions round without running mkswap, then you'll have no swap at all.

If you run mkswap on your active root partition you'll destroy your TiVo and have to start again from a backup (unless you make a backup file from the partition you're about to overwrite).

There's not much of a safety net here. Guessing or doing something similar to what the instructions say is not a good idea.


----------



## tjon1

Sorry beforehand if my question is a bit unlearned . . . I've spent quite a bit of time reading through this thread, but alas, I only became more confused. This morning I replaced my original Phillips (quantum fireball, 13+gig, 14hr) drive with a 160 maxtor. I used the Hinsdale instructions and MFS Tools 2.0. After completing a backup I typed: mfsbackup -aqo - /dev/hdc | mfsrestore -xpi - /dev/hda. Apparently all went well as when I placed the TIVO back in service it said that I had 148hrs of record time and seems (so far so good) to work just fine. However, reading this thread (and Robert S's original post) it seems I am living on borrowed time and that at some point I am going to have swap file problems. Is this swap file problem still a problem? Because I just did the upgrade, I don't have any new recordings. Can I fix this problem by running the above mentioned commands adding -s with 80 (half the size of the drive)? What would be the precise command? Is the 137gig barrier still a problem (actually I don't care about losing 23gigs, the drive was only 99 bucks)? As if it isn't painfully obvious, I don't have much experience with linux, so feel free to "dumb down" any responses! (and Thanks!)


----------



## Michael248363

Just a point of clarification, when trying to determine the inactive root partition in order to do the swap, the inactive root partition is the one that mounts. The one that doesn't is the current swap partition. If they both mount, then the one with the older files is the inactive root partition, right?


----------



## Robert S

tjon: actually, you're OK at the moment. You have 64Mb of swap plus about 8Mb out of the 16Mb system RAM, which gets you to about 144Gib or about 155Gb before mfsfix falls over.

There's no way to increase swap without copying your recordings again. See the end of the 160Gb thread in the Underground for a way to use the full capacity of the drive (only worth considering if you recopy).

Michael: Yes, pretty much. The partition that doesn't mount is empty (literally, all zeroes) and therefore available for conversion into swap. It's your inactive root partition. The other partition is the active root partition and holds your system software.

If both partitions mount then the inactive root partition is holding the previous version of the system software, which will have older datestamps than the current version.


----------



## Michael248363

Wait a minute. Maybe I'm reading your post backward or something. Of the two partitions, only one of them will mount, hda4. The other one comes back with an error that says that it seems to be swap space. I did this procedure last year, although it didn't give me this much trouble then.

Is 4 or 7 the inactive partition that I should be using?


----------



## tjon1

Robert, thanks for the info. I checked out Todd Millier's how-to regarding large disks,( I presume this is what you refer to) but making changes in the kernel that will be overwritten when a new OS version come out unsettles me a bit. I actually don't care much  that I don't have use of the missing 23 gigs (above 137) (btw, my unit reports 164hrs. not the 148 I wrote) and I don't mind recopying the original drive again if it will prevent problems sometime in the future. I presume that this can be done from MFSTOOLS but I am unsure of the exact command(s) that I should use. I am considering removing the drive to perform the live tv buffer upgrade to increase the buffer to an hour, so this would give me extra incentive! Again, thanks.


----------



## Robert S

Michael: Ah, partition 7 is already swap from the last time you did this. That's your inactive root partition (normally it would be blank).

Look at the partition table (pdisk -l or just read the boot print-out) and check that partition 8 is 128Mb. You might also want to read the TiVo's boot log (I linked to my original post that describes how to do this in the top post). The GSOD isn't infallible, so may be your problem isn't related to swap this time.

tjon: If you look at the end of the thread some dork managed to copy his patched kernel to the wrong partition and thus booted with the original kernel. The results are less than spectacular (the TiVo just crashes when it tries to access the out-of-range blocks). All you have to do is do the recopy under Knoppix rather than the MFS Tools bootdisk and then dd the kernel across (check out das Monkey's more detailed write-up as well as Todd's).

As I said, you're OK at the moment because you're below the 150Gb limit. If you wanted to upgrade further you would need more swap, but as long as you stay below 280Gb total you can just do the 'rescue' to recover from a GSOD.

I don't think the hacks to increase the buffer size work with the current software.


----------



## philhu

pdisk for tivo?

My tivo does not seem to have this.

Where can I get a pdisk running on tivo SA svr-2000?

Thanks


----------



## Robert S

pdisk (as an x86 binary) is on the TiVo boot CD's and floppies.


----------



## Michael248363

Well apparently either my feeble mind is not grasping the concepts listed in these 21 pages and I'm doing everything wrong or it's not a problem with swap. I'm leaning towards the former but for my sake am hopeful that it's the latter. In order to determine which it is, I need specific answers to specific questions. No interpretations of what you think I mean, no references to links in other posts, just straight answers to the questions presented. I know I'm asking to be spoon-fed this, but right now I've been trying to feed myself and I feel like I've got food everywhere except in my mouth. If this is too much to ask, then a straight answer to the last two questions will work. If I had a clue what I was doing in Linux then maybe it wouldn't be so hard, but I don't so it is.

1. How many times does the TiVo need to reboot after displaying the GSOD for 10 seconds to know that it isn't going to fix itself and I can shut it down and try something else?
2. I can't get "edit_bootparms hda -r" to work when booting from the MFS Tools CD (downloaded and burned today). If you follow the instructions to the letter in Robert's second post starting with Section A "Booting so we can read the TiVo disk", does it work for everybody else on the planet and I'm just "lucky" or is there truly a problem with the command and/or the CD?
3. If /dev/hda4 mounts and /dev/hda7 does not mount, which partition is the inactive partition that I should be using in section C?
4. If /dev/hda4 mounts and has files dating from Jan 2003, and /dev/hda7 does not mount, saying that it thinks hda7 might be swap space, is hda4 or hda7 the partion that I want to use in section C?
5. Is there a way to make the screen show more than 80 columns so that the output from pdisk is more readable and doesn't wrap around?
6. What should I be looking for in the pdisk output to verify that I'm setting the right partition? It seemed that both partition 7 & 8 were 128Mb. I'm not looking at it now, so I could be wrong. Neither one will mount however, it thinking thta both may be swap space.
7. What are the exact steps to look at the boot logs for a version 3 DTiVo while the drive is out of the TiVo and in a PC? The only thing I saw was via enabling backdoors. If I could enable backdoors, it would be working and I wouldn't be asking these questions.
8. What are the steps to find out exactly what size the swap file is? I'd like to check my other system that is working.

And lastly,
9. I have 2 DSR6000s, one originally came with only one drive the other came with two. I still have those original drives, but they are not labeled as to which machine they came out of or if they are drive A or B. I thought I labeled, apparently, I didn't. If I start over and perform the upgrade again using the original disc(s), losing all my recordings, which method is more fool-proof, the single or dual drive option and how do I tell which drives are which, single drive A, dual drive A, or dual drive B so that I can use the appropriate drives with the appropriate method?
10. Can I run dd using the A & B drives in my DTiVo that is working to the A & B drives of the one that is not and have it work? Is there anything specific to the working set of drives that will not allow me to copy them and put them in the other DTiVo and make it work?

I really do appreciate the assistance with this. The frustration you may sense is directed inward at myself not outward to anybody else.

Thanks.


----------



## Robert S

Rebooting after 10 seconds suggests that you have no swap at all (or that the problem does not relate to swap). If partitions 7&8 really are 128Mb then you upgraded with -s 128, so the original swap partition may not have a valid signature on it.

It takes several minutes for the GSOD to allocate the memory it needs, so if it reboots before 4 minutes have elapsed then it isn't doing anything useful and will never repair the TiVo.

People do seem to have problems with edit_bootparms, although no-one has explained what the problem is. Anyway, you have correctly identified partition 7 as the one to use for extra swap.

The data that pdisk displays is a sort of table of contents - it doesn't necessarily indicate what's inside the partitions. The original kernel partition will be titled Kernel 2, but if the swap and kernel partitions are the same size, it doesn't matter.

To read the logs:

mkdir /mnt/var
mount /dev/hda9 /mnt/var

more /mnt/var/log/messages

look for messages relating to swap

umount /mnt/var


The lone A drive will be 40Gb. The twin A drive will be 30Gb and its B drive will be 15Gb. The sizes should be marked on the drives.


----------



## Michael248363

Thank you Robert.

The drive sizes for the single and dual did match up. Thanks.

I've included output for some of the commands and a couple of questions at the end.

The output for edit_bootparms is:

/# edit_bootparms hda -r
sh: edit_bootparms: command not found
/#

So it seems as though the file just doesn't exist in the path. I don't know how to search for a file in Linux so I'm not much help with this one.

It looks like partitions 7&8 are both 128Mb. Here's a partial output from pdisk -l

2: Image Bootstrap 1 4096 @ 75145280 ( 2.0M)
3: Image Kernel 1 4096 @ 75149376 ( 2.0M)
4: Ext2 Root 1 262144 @ 75153472 (128.0M)
5: Image Bootstrap 2 4096 @ 75415616 ( 2.0M)
6: Image Kernel 2 4096 @ 75419712 ( 2.0M)
7: Swap Linux swap 262144 @ 75685952 (128.0M)
8: Ext2 Root 2 262144 @ 75423808 (128.0M)
9: Ext2 /var 262144 @ 75948096 (128.0M)

The boot log didn't provide me any useful information, maybe it will for somebody else. The entries related to swap were basically:

Jul 11 03:30:42 (none) Stats: Swap: 133881856 0 133881856
Jul 11 03:30:42 (none) Stats: MemTotal: 27922kB
Jul 11 03:30:42 (none) Stats: MemFree: 14820kB
Jul 11 03:30:42 (none) Stats: MemShared: 4024kB
Jul 11 03:30:42 (none) Stats: Buffers: 5080kB
Jul 11 03:30:42 (none) Stats: Cached: 5124kB
Jul 11 03:30:42 (none) Stats: SwapTotal: 130744kB
Jul 11 03:30:42 (none) Stats: SwapFree: 130744kB

Which makes it look like the swap file is large enough.

It cycles through the boot process every 6 minutes or so. It will write what look to be normal entries to the log for ~15-20 seconds and then reboot.

The lines right before and after the reboot are:

Jul 11 03:03:43 (none) Stats: lo: 0 0 0 0 0 0 0 0 0 0 0
Jan 1 00:00:32 (none) syslogd 1.3-3: restart
Jul 11 03:36:47 (none) Stats: == System startup resource statistics ==

At the very end of the log, the restart line is repeated 6 times one right after another.

So based on this, do you think it is a problem with the swap? And what do you think my next steps should be? Am I at the point of starting over with the original drives?

On a related note, and my ignorance of Linux will probably show through, but I don't really understand why the swap size can't be fixed, if the partition is 128Mb and you need 127Mb, why can't we just create a valid signature and have it work?

Thanks


----------



## Robert S

It does look like you have 128Mb of swap. Therefore, whatever the reason mfsfix is crashing, it's not running out of memory.

You appear to have misunderstood your situation. You restored with -s 128 and therefore got a corrupted swap signature on partition 8. You should have just run mkswap on that partition as described in the first post.

The rescue in the third post is intended for people who have 64Mb of working swap, but need more to recover from a GSOD.

Anyway, it looks like that's irrelevent now - if you can't figure out what's wrong, you'll have to restore from a backup.

Have you run diagnostics on the disks?


----------



## Michael248363

It doesn't surprise me that I'm confused.

I didn't think that if you used the -s 128 option that it could be fixed easily. Everything I've read states that it can't be fixed without lots of work like hacking the kernel.

I was getting reboots where it would be up for ~5 minutes and then reboot. I ran the Maxtor utilities on the drives, which showed one to be bad. I got the replacement from Maxtor and used dd to image the drive over to the new one. There were a few bad sectors, so when I went to boot up, I got the GSOD and have been trying since to get past it.

Unless you've got some ideas on what to look for, I guess I'm starting over.


----------



## Robert S

Yeah, that /was/ my bright idea. Shame.

You do need to run a different kernel to get 128Mb of swap, but if you run mkswap on a 128Mb kernel it gives you 127.3Mb. Unfortunately Tiger didn't notice this problem when he wrote MFS Tools, so although it tries to give you 128Mb or more of swap, it can only create a valid swap signature for up to 127Mb.


----------



## Michael248363

Thanks. You're *dim* ideas are much better than my *bright* ones.


----------



## tjon1

Robert S.

Just wanted to say thanks for the information (re 160gig upgrade). I gather from your remarks that as long as I don't let the disk fill up I shouldn't worry about running into swap file problems. I don't tend to watch shows over and over again so it shouldn't be a problem. Again, thanks!


----------



## Robert S

_I gather from your remarks that as long as I don't let the disk fill up I shouldn't worry about running into swap
file problems._

I think what I said was as long as you don't fill the whole drive with recording _partitions_. That is, you do the upgrade the old way for 137Gb. Doing the upgrade with an LBA-48 kernel would put you over the 155Gb threshold where you need more than the original 64Mb of swap.

However, you'll presumably use mfsrestore with -s 127 to get 127Mb of swap, which is enough for about 280Gb, so you'd be fine as long as you didn't add more than 120Gb to your 160.

The important factor is the size of the partitions. How many recordings are inside them is irrelevent as mfsfix will crash before discovering how full they are.


----------



## tjon1

Robert,

Ok, obviously I'm more than a bit confused! Again please excuse my profound ignorance of these matters.

So, I could do one of the following?:

*Plan 1*

1. Install my original tivo drive as primary master and the new 160 drive as secondary master.

2. Boot off mfstools cd.

3. Issue the following command:

mfsbackup -aqo - /dev/hdc | mfsrestore -xpi -s 127 - /dev/hda

4. Ctrl-Alt-Delete

5. shutdown, re-install 160 in Tivo

This would do the trick? Is the syntax correct?

or,

*Plan 2*

Could I backup the present 160 drive and then restore from the backup (thus saving the last few days recordings)?

Would this be the way to do it?:

1. Connect the 160 drive to the secondary master connector (assuming my c: drive is primary master and cd is either primary or secondary slave).

2. boot off the mfstools cd

3. Issue the following commands:

mkdir /mnt/dos

mount /dev/hda1 /mnt/dos

mfsbackup -6o /mnt/dos/tivo.bak /dev/hdc

mfsrestore -i -s 127 /mnt/dos/tivo.bak /dev/hdc

umount -f -a -r

4. shutdown pc

5. Remove 160 drive and re-install in TIVO.

Is this correct?

BTW, the instructions for mfstools 2.0 (on the cd) shows the following command:

mount /dev/hda /mnt/dos

I couldn't get the drive to mount or backup until I changed "hda" to "hda1". The Hinsdale instructions use the "1" but the doc file on the mfstools distribution does not. What is the significance of the "1"? If "hda1" is the proper designation, why does "hdc" not need a numeral after it?

Also the instructions in the section on restoring say:

"Take (one of) your new drive(s) and set it's jumpers to Master. Connect the drive to your secondary IDE channel to make it Secondary Slave."

Wouldn't doing this make it the secondary master?

Thanks beforehand for your help!


----------



## Robert S

Plan 1 is fine.

I keep telling people, ignore all the docs on the MFS Tools 2.0 CD and Tiger's FTP site. There are several very important mistakes. Work from the current version of Hinsdale. As you've discovered, it contains fewer errors.

/dev/hda or hdc is a pseudofile that contains the entire contents of the hard drive. As MFS Tools is reimaging a whole drive this is what it needs to access.

/dev/hda1 is a pseudofile containing the entire contents of the first partition on the hard drive. The partition contains a filing system that mount can integrate into the Unix system.

I don't know where you got 

mfsrestore -i -s 127 /mnt/dos/tivo.bak /dev/hdc

from, but it should be

mfsrestore -s 127 -i /mnt/dos/tivo.bak /dev/hdc

This will save your settings, but no recordings. If you want to copy any recordings you'll have to clone the whole drive with dd or an MFS Tools pipe.

Yes, jumpering the drive as master makes it secondary master (I assume that's fixed in the current Hinsdale too).

So, to go back to your question on swap, if you do either or those plans you'll have 127Mb of swap and 137Gb of drive space. You have enough swap to add a second 160Gb drive to give you 2x137Gb without breaking mfsfix.

There's a nice symmetry in that the maximum swap you can get from MFS Tools and the normal TiVo kernel is exactly enough to support the maximum amount of disk space you can get with the normal kernel.

If you want to use the patched kernel to go to even larger sizes then you need to make arrangements to get even more swap.


----------



## landofloons

I have been through this thread twice now and I am still confused. Here is where I am at:

Sony SAT-T60 DTivo working well as 40A + 80B, upgraded using MFSTools 2.0. I am doing a second upgrade to 120A + 80B and want to save the recordings. So far I have dd'd the 40GB drive onto the 120GB drive and put the whole works back into the Tivo. So far so good. I have not yet done an mfsadd because I have only a 64MB swap file and would like to increase it's size before I do this.

I have studied the first several posts to this thread carefully but am unable to get the pdisk instructions to work. I am using Kazymyr's Tivo boot CD and have 13 partitions to start with. I have also read stories of pdisk trashing part of the drive.

I would like to find an understandable way to increase the size of my swap before I do an mfsadd on my drive set if possible...

Thnks to everyone who has made this much information available......


----------



## deek_man

Sometime back, I posted a number of messages to this thread and got some great help (especially from Robert S.) about repairing a GSOD which needed to be performed on my Philips 112 upgraded to two 100 GB Maxtors but with only 64 mb of swap. I recovered from the GSOD (with Robert's help) but shortly thereafter, I occasionally found one of my drives repeatedly clicking which could be fixed by rebooting (i.e., unplugging, plug back in). This happened about 4 times over about 2 months only to end up with a new GSOD. Clearly this seemed to indicate a bad drive which was probably resulting in the GSOD. This time, when repairing the GSOD loop, I decided to check the drives and, sure enough, the A drive was defective. I backed up the drive (season passes, setup, etc. only) and I returned the drives to the TIVO and ordered a warranty replacement which I received. (The old drives still work even with the defective sectors, at least for a period of time.) The new drive Maxtor sent is 120 gb. I had originally planned on doing a dd from the bad A drive (since it's still operating) to the new drive but now I'm more inclined to utilize the extra space on the 120 gb replacement. Three questions (and thanks for the help in advance):

1) Can I dd the bad 100 gb A drive to the new 120 gb drive and expand it while saving all the recordings or will that foul up its association with the B drive.

2) When I expand the new A drive, can I increase the swap to the needed larger amount?

3) Or should I just blow off the recordings and restore my backup to the A drive and expand, bless the two good drives and simultaneously get the needed swap with the -127 switch?


----------



## Robert S

You probably have 13 partitions on your a drive now, so you can upgrade it once more before the partition table is full. Perhaps you'd prefer to save this option for a later upgrade to a /really/ big drive?

So either, don't expand at this point, or copy the B drive on to the new one and then copy the A drive on to the old A drive (it'll take forever, but you did ask).

If there's any spare space on the drive, then the third post of this thread explains how to manually expand the swap partition. Because the new swap partition replaces the old, this doesn't add to your partition count.


----------



## deek_man

Thanks. One more question. You said I could "So either, don't expand at this point, or copy the B drive on to the new one and then copy the A drive on to the old A drive."

I'm not sure I understand. the old A drive is defective. So should the above direction say "copy the B drive on to the new one and then copy the A drive on to the old *old B drive* ."? If I'm correct, when I copy the B drive on to the new drive, will all 120 gb be recognized? Also, how can I tell if there's room on the drive for expanded swap (or maybe that's in the post that you pointed out). Thanks again.


----------



## Robert S

Yes, old B drive. You'd have to use mfsadd to get the extra space on the B drive, but because there are no system partitions on the B drive, this doesn't hurt so much (you're limited to 6 MFS pairs in total, so there are still limits).

You couldn't expand swap permanently in this scenario unless you edit /etc/fstab to activate a swap partition on the B drive.


----------



## deek_man

As described about 4 messages back, I had a bad A drive on a Philips series 1 causing a GSOD. I first decided to blow off my recordings and get the extra swap so I backed up the previously upgraded 2 drive system to get a condensed 15 hour backup. The computer drive to which I sent the backup was the primary slave (hdb), the Tivo A drive was connected to primary master (hda) and the Tivo B drive was connected to secondary slave (hdd). (It's a long story...don't ask why.) So I backed up the previously expanded (2x100GB) hard drive system using:

mkdir /mnt/dos

mount /dev/hdb1 /mnt/dos

mfsbackup -6so /mnt/dos/tivo.bak /dev/hda /dev/hdd

Everything seemed to go just fine with the backup and also things seemed to go well when I restored my condensed backup to the new larger A drive with:

mfsrestore -s 127 -zpi /mnt/dos/tivo.bak /dev/hda
(drive with backup file on hdb, new larger A drive on hda)

However, the new larger A drive restored from the backup would not work on the Tivo and rebooted over and over. I did this a couple of times and it just didn't work so I'm assuming the defective A drive had some bad sectors right where it mattered thus producing a bad backup image. I then used dd to copy the old defective A drive to the new (larger) drive using:

dd conv=noerror,sync if=/dev/hda of=/dev/hdd bs=1024k 
(old defective A drive on hda, new larger A drive on hdd)

While several input/output errors were reported during the dd, it did finish to completion and the new A drive with the original B drive do seem to work fine together. Two questions:

1) Any thoughts on why the original restore didn't work? (I do have an older backup file from when I first upgraded but decided to just go with the dd for now.) Maybe the bad sectors on the defective A drive screwed up the latest condensed backup file?

2) Is there any way to utilize the extra 20 GB on the 120 GB A drive that I copied (with dd) from the original defective A drive?

Any help would be appreciated.


----------



## winders

> _Originally posted by mutant _
> *Got the mfsadd problem worked out - I needed to have both drives in in order to do the add. Worked flawlessly when I did this.
> Anyone doing this second upgrade (40g A drive to 120G A drive when you have aleady added a 120 as B) will need to look out for the problems with not being able to dd copy the drive and then update the partition table.
> I understand there is a newer version of pdisk that will allow you to specify that to determine the drive size by means other than the partition table. Otherwise you will have to initialize the partition table and manually reeneter the data. This is a very difficult acticity to undertake!
> Mark *


Anyone know where I can find this new version of pdisk??

Thanks,

Scott


----------



## djr195

I just successfully upgraded my SA series 1, and my PC now will only reboot using the MFStools boot CD. Windows boot discs (both floppy and CD) don't work. Please help!

PC is a PIII-500 running WinXP. The primary HD is an IBM formatted in FAT32. I followed Hinsdale's 2.0 upgrade How-to.

Thanks for any help!


----------



## mohanram

I originally had a TiVo Series 2 60Hr unit which I upgraded using Hinsdale's old instructions - I took a backup and added a 160GB HD as drive B. I have had it working for almost 18 months now. I now find that my TiVo is repeatedly rebooting after powering up and reaching the GSOD (as you folks call it). 

How do I go about solving this ( with / without losing my recordings)? This thread and other threads of interest are too long and discuss many scenarios. What do I need to do in my scenario? I also read about the swap file size. Is that the issue here? How do I fix it so that this does not occur in the future?

Thanks
Raj


----------



## Robert S

You have exceeded the 180Gb limit (for Series 2's). You need to do the 'rescue' from the third post of this thread.


----------



## philhu

well

gsod on a jam-packed 240gig tivo worked with Robert S's method (making hda7 a swap file).

It took 6 hours, but it fixed it!

svr-2000!!!!

Thanks!


----------



## Yog

Heh. Reading through this thread, it's unfortunate that Linux needs 'mkswap' at all.

Other Unix OSes, like Solaris just use whatever you point them to, be it a raw partition or file, with no need for preperation by a utility like mkswap.

You guys really had me going in this thread! The whole time I was thinking "why not just do a mkswap -v0 while the drive is in byteswap mode ??? Why wouldn't that work ???" Had me afraid for a while that MFST2.0 was really broken. I should have just skipped to the end. 

I have a Philips SA that came w/ a 15GB Quantum drive (30 or 15 hour ? I forget). Back in the days of BlessTivo and Dylans boot floppy, I bought a replacement Quantum A drive (20 GB), and a new Maxtor 80 GB B drive, and used the 'dd backup/copy onto new A drive and bless B' style upgrade, which has served me well since around Nov 2000. (Incidentally, I had the drive spin down problems, and being the lazy sort, I didn't feel like pulling the Tivo back out of the TV stand and pulling the drives out, etc. So instead I cross-compiled the 'hdparm' utility to a TiVo PPC binary, and fixed the problem by uploading it to the TiVo via console port/zmodem. I subsequently released the binary and announced it on this forum.)

Now, my 3 year old Quantum A drive is starting to have fits (verified A drive from looking at the logs). It's been through two multiple-reboot GSOD episodes thus far, but has 'recovered' from both. BTW, it seems it's somewhat normal for the GSOD to loop multiple times before recovering. I let mine go through the GSOD/reboot loop for about 3 hours before it finally came up and booted fully. Looking through the logs, it seems like it reboots every time it gets a hard error from the drive, the comes back up and restarts the fix. Not sure if it skips the bad sector or if the drive remapped it to a spare, or what.

Fearing that the A drive is likely to go completely kaput any moment now, I plan to use MFST2.0 to transfer my old A drive and B drive (about 95GB) to a new 120GB maxtor A drive, then, once the 120GBer has been verified to work, add the 80GBer back in for a 200GB Tivo .

My original plan was to use the the MFST2.0 bootable CD on my 4 IDE controller PC with this command( orig A & B on hdf & hdg, new drive on hdh):



Code:


mfstool backup  -Tao - /dev/hdf /dev/hdg | mfstool restore -r 2 -s 256 -xzpi - /dev/hdh

Then reboot in byte swap mode for hdh, and do:



Code:


mkswap -v0 /dev/hdh#   (# being standard swap partition, which I forget)

 Preparing the swap area.

I know I'll only get ~127MiB of swap, but I wanted to have the space there for a 256MiB partition if I want to use the patched kernel later.

I have a couple questions about this. First, do I need the "-s" flag in the backup command to 'divorce' the drives ? The readme for mfstool indicates that "-s" and "-a" are 'somewhat' mutually exclusive, but doesn't give a clear description of why. The Hinsdale guide option #6 shows this command without the "-s" command, so I presume this works.

Second question, has it been proven that the increased block sizes (ostensibly sacrificing some granularity/space for less mem usage/more performance) break the mfsfix program during a GSOD ? The thread seemed to think this was the case for a while, then the opinion went the opposite way (block size doesnt matter). Is the consensus now that using the block size arg is OK ? If the answer is unknown, perhaps I'll do a mfsassert after the copy and before the re-adding of the 80GB to the TiVo to see if it fails .

Of course, I'll use MFST2.0 to make a backup of the TiVo drives w/o the streams first before doing any of this, just in case . I already have a backup of my stock original drive which still has a 1.3 image on it .

- Yog


----------



## Yog

Ok.

I think I've answered my own question. I backed up my existing 2 drives with mfstools from the boot CD using the typical command.

I then took my new 120GB Maxtor and restored the backup image to it using:


Code:


mfstool restore -r 2 -s 256 -zxpi /mnt/hdf1/backup.bak /dev/hdc

After this completed, I rebooted with byte swapping enaled on the new TiVo drive, and ran pdisk and mfsinfo to make sure everything looked OK. Then I initialized the swap partition using:


Code:


mkswap -v0 /dev/hdc8

It initialized the swap (truncating the swap space to around 128MiB as expected). I then mounted up the root partition, and added a line to give me a shell on the DSS port.

I popped it back into the TiVo, and it booted up fine. Everything was there, season passes, etc. The logs all looked good. It recognized and used the swap space, etc. Now for the acid test! I ran 'mfsassert -please', and it went POOF! Rebooted, and GSOD came up. After about 10 minutes or so, it rebooted again, and came all the way up!

Here are some log entries for the curious:


Code:


Jan  1 00:00:14 (none) kernel: Activating swap partitions
Jan  1 00:00:14 (none) kernel: Adding Swap: 130744k swap-space (priority -1)

Sep 10 11:44:35 (none) kernel: Filesystem is inconsistent - cannot mount!
Sep 10 11:44:37 (none) kernel: fsfix:  mounted MFS volume, starting consistency
checks.
Sep 10 11:46:08 (none) kernel: I-Nodes:
Sep 10 11:46:09 (none) kernel: I-Node table size is 131072 entries for 100000 ac
tive nodes max.
Sep 10 11:46:09 (none) kernel: FsId high-water mark is 0x285dd6
Sep 10 11:46:11 (none) kernel: Pass 1 - scan and analyze
Sep 10 11:47:20 (none) kernel: reconstructing zone buddymaps
Sep 10 11:47:22 (none) kernel: synchronizing...
Sep 10 11:47:22 (none) kernel: volume marked as needing database cleanup
.
.
Sep 10 11:47:22 (none) kernel: volume marked as needing database cleanup
Sep 10 11:47:23 (none) kernel: scanned 54082 files, covering 13207 extents
Sep 10 11:47:23 (none) kernel: 145200 application pages in use
Sep 10 11:47:23 (none) kernel: 24635392 media pages in use
Sep 10 11:47:23 (none) kernel: Inode table collision details
Sep 10 11:47:23 (none) kernel: 28961 hash collisions in node table.
Sep 10 11:47:23 (none) kernel: 20 hash collisions in longest run.
Sep 10 11:47:23 (none) kernel: 11 hash collisions in longest busy run.
Sep 10 11:47:23 (none) kernel: 10849 files aren't in their primary hash location
s.
Sep 10 11:47:23 (none) kernel: Allocation Details
Sep 10 11:47:23 (none) kernel: 41961/53858 application inline files, 77.91%
Sep 10 11:47:23 (none) kernel: 47.60% wasted space (0 bytes) in normal applicati
on region
Sep 10 11:47:23 (none) kernel: 50.39% wasted space (0 bytes) in inlined applicat
ion region
Sep 10 11:47:23 (none) kernel: 224 media files
Sep 10 11:47:23 (none) kernel: 99.27% wasted space (0 bytes) in media region
Sep 10 11:47:23 (none) kernel: Fragmentation:
Sep 10 11:47:23 (none) kernel: average  extents/file is 0.24
Sep 10 11:47:23 (none) kernel: worst    extents/file is 18
Sep 10 11:47:23 (none) kernel: expected extents/file (approx) is 3
.
.
Sep 10 11:47:23 (none) kernel: Media region:
Sep 10 11:47:23 (none) kernel: zone contains 24776704 pages: 24373248 allocated;
 403456 free
Sep 10 11:47:23 (none) kernel: inode allocations match allocated page count
Sep 10 11:47:23 (none) kernel: buddy-map is internally consistent, 403456 pages
marked free
Sep 10 11:47:23 (none) kernel: zone contains 212959232 pages: 262144 allocated;
212697088 free
Sep 10 11:47:23 (none) kernel: inode allocations match allocated page count
Sep 10 11:47:23 (none) kernel: buddy-map is internally consistent, 212697088 pag
es marked free
Sep 10 11:47:23 (none) kernel: fsfix: 0 fatal errors, 0 warnings.
Sep 10 11:47:23 (none) kernel:
Sep 10 11:47:25 (none) kernel: mfscheck scan begins
Sep 10 11:51:08 (none) kernel: Checking reference counts
Sep 10 11:51:09 (none) kernel: All reference counts are OK.
Sep 10 11:51:09 (none) kernel: mfscheck scan ends
Sep 10 11:51:12 (none) kernel: mfscheck: 0 fatal errors, 0 severe errors, 0 warn
ings.

So it appears everything works fine as long as you initialize the swap, etc. The "-r 2" doesn't seem to have any ill effects on fsfix and mfscheck.

The next step will be copying the entire old disk set over to the new one, so I get my recordings back.

- Yog


----------



## Robert S

Yes, even the 16Mb blocks that you get with -r 4 don't affect mfsfix. The confusion was caused by embeem who reported the problem before the details of mfsfixes swap requirements had been determined (he thought -r had broken it when infact he didn't have enough swap). -r 2 is the default for mfsrestore, so there would be a lot of dead TiVoes out there by now if it was a problem.

Interesting observation on why the GSOD sometimes restarts when it does have enough swap.


----------



## Yog

Well, it's done. Seems to be working fine. After trying out my 'small' backup, and seeing it work, etc, I took the drive out of the TiVo and put it back onto the PC and did a backup/restore pipeline to copy all my streams, etc. Everything copied in about an hour (only about 80MB of stuff to back up).

I put it back into the Tivo and ran the new single drive for a few hours making sure everything was OK. Everything seemed fine, so I added the 2nd drive back in (80GB) with mfsadd, put everything back in, and voila, 252 hour TiVo.

I did have to turn off the 'auto spin down' with hdparm, which is, thankfully, included as part of the TiVo OS in 3.0 (I had to cross compile and upload it for 1.3).

There's only one problem so far. I get the odd "hitch" now and then. This is accompanied by a 'drive seek' sound. The only log entry I get when this happens (and it doesn't always generate a log entry) is:


Code:


Sep 12 06:44:36 (none) Scheduler[124]: SimAndSched:774590 [<?>] (Cnd2,Chg2,Unscd0,Scd2)
Sep 12 06:44:36 (none) TmkSink::Trace[118]: Audio out of A/V sync. Flushing and resyncing.   Diff=136127 abuf=6016
Sep 12 06:44:36 (none) TmkSink::Trace[118]:   pts=166354905, videoSTC=1168231104512
Sep 12 06:44:36 (none) TmkSink::Trace[118]:   timeInBuffer=22560, bitrate=24000

I'm hoping it's just the drive finding the 'bad sectors' and remapping them. It only happens once in a while, so it's no big deal, but is kind of annoying and worrisome. Any ideas ?

Also, looking at the hdparms args, I see an interesting one:


Code:


 -M  * set drive streaming-media mode (0/1)

This seems like something one would want to turn on, but so far, I've been afraid to try it. I have two Maxtor drives. I'm not even sure if they have this sort of capability. Is this something safe/desirable to turn on ? Should I try it ? In recent Linux's, the "-M" flag is acoustic management, not "streaming media mode". Maybe this is a TiVo specific modification ?

- Yog


----------



## ostrom

I am having a problem using MFS 2.0 (see my separate post), but also have a question about whether my overall approach will work.

MFSINFO reports that my current system is using 6 partitions, 4 on my original A drive, and 2 on my (previously added) B drive. My plan was to merge these onto a single drive, while expanding the swap space (30GB+60GB onto a 120GB drive), then add back in the 60GB drive.

Rereading this thread makes me wonder if I will be unable to add back the B drive for lack of available partitions. Is this correct? 

Thanks for all the help!

Andy Ostrom


----------



## raiders

I have a directivo dsr6000 with 2.52. I now have a P4 card to replace the P3 card so it should then update to 3.1. I only have a 64MB swap with two 120GB drives and I have had to do the GSD rescue several times. Because i may not have reverted the swap after a rescue, i'm now not sure if i have the swap partitions set up properly. I think i understand from the 1st page how to check which is the current swap, however I am confused as if my current swap partition (should it be 4,7,or 8?) is correct or i need to change it again. 

Can someone (robert  ) please provide the definitive specific partition numbers that i should verify on this system to ensure that the new 3.1 download doesn't thrash the system. 

Thanks.


----------



## caa

I had my first drive go bad on my dual 120GB tivo. I had first added a 120GB drive to it, then later with mfstools 2 replaced the original 20GB with another 120GB drive. 
I did not expand the swap at the time. 

When the drive started to go bad, it GSOD'd on me and could not fix it. I didn't know why until I found this thread. Sure enough when I mounted the drives and looked at the logs in /var, I found the fsfix was getting a sig 11. I really didn't want to do the whole change the second root partition to swap, so here's what I did.

I looked and there was only about 12 meg out of 128meg used in the root partition. So I made a 64meg swap file with 
# dd if=/dev/zero of=/mnt/swap bs=1k count=65535
then made this into a swap file with
# mkswap /mnt/swap
then edited rc.sysinit and added
'swapon /swap'
right after the swapon -a line.

Installed the drives in my tivo, rebooted and 3 hours later it was backup. With all my shows & season passes intact.

And now I have 128meg of swap
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 14278656 14147584 131072 662282240 57344 4411392
Swap: 134201344 4894720 129306624
MemTotal: 13944 kB
MemFree: 128 kB
MemShared: 646760 kB
Buffers: 56 kB
Cached: 4308 kB
SwapTotal: 131056 kB
SwapFree: 126276 kB


----------



## Robert S

Whether you regard that as easier than my version of the rescue is a personal judgement, but it achieves the same result.

However, the reasons I went with the partition-relabeling version were that it avoids editing rc.sysinit (if you get it wrong it'll leave your TiVo unbootable) and, more importantly, it will work on any TiVo whereas anything that involves modifying the root partition will run afoul of the lock-down on anything other than a Series 1 stand alone.


----------



## caa

Well I guess since I only have a SA series 1, I didn't know it wouldn't work on other tivos. 

I've done unix admin work for close to 20 years, so editing the rc.sysinit script is a lot more familiar to me than changing partitions around.

Plus if I screwed something up, all I have to do is redo the dd off the old drive (6 hours or so) and try again.

I would have liked to expand the swap partition doing the restore, but everything I found about doing this indicated I need to have another drive for the b drive even though I wasn't changing it.


----------



## Robert S

You can create a 128Mb partition and swap that for the existing swap partition before you expand the image. Doing it that way gives you a solution that will survive a software upgrade, although for us Series 1 owners, that's unlikely to be an issue any time soon.


----------



## mdhoward

I have a question about the fix for the green screen. I followed the instructions exactly on page 1 (3rd post from top) of this post. Hda4 was my inactive partition hda7 was the active one so I followed the intructions on making hda4 the active. Once I get to the end where I renumber my active partition and then I type W and then Y and it does it and returns me to my prompt what do I do next? Is there any special way I have to turn the computer off or any commands I need to type? I just turned the computer off after typing in Y (final step of D) and put the drive back into the Tivo. When I do that it STILL is stuck cycling in the green screen and then reboot every few minutes mode. Did I do something wrong? I know in step E (restoring drive in Tivo) it says to let it run and that it might continue to reboot but that it will eventually return to normal but is this same green screen I was getting before normal?


----------



## Robert S

Nothing special to before switching off - you don't have any mounted partitions in this procedure. I'd be looking at the logs (which means mounting the /var partition) and checking that the swap got activated correctly.

As I understand it (and GSOD's are so rare that I've never actually had one on my own TiVo) it takes about 4 minutes for a Series 1 TiVo to realise that it's out of swap and reboot. So if it reboots faster than that you probably have no swap at all (mkswap?). If it reboots more slowly than that then it may be that the GSOD is dealing with bad blocks and is actually doing something useful, if rather slowly.


----------



## mdhoward

Thank you for the quick reply Robert. As far as the reboot cycle... it boots and then hits the green screen and stays there for yeah about 4 or so minutes and then reboots and keeps doing this over and over. It was doing the same thing before I tried your method (3rd post) and is still doing it now.

How would I go about doing this? 

"I'd be looking at the logs (which means mounting the /var partition) and checking that the swap got activated correctly."

And what you mean by that is once I change it to hda4 I want to make sure that hda4 "got activated correctly?"

Sorry I know next to nothing about doing all this, just have been lucky with following directions on this site.


----------



## mdhoward

Ok I think I really messed up this time. I my fustration of not knowing if I did the right thing in activating hda4 I tried the mkswap... on hda7 and then followed the rest of the directions in making hda7 the partition. Well when I put the drive back in the Tivo I never could get out of the welcome screen, I didn't even get to the green screen. I then put the drive back on the computer and tried mounting both drives both coming back saying that both drives looked like swapspace or whatever it says. 

Is there anyway I get things back to the way they were before I made this goof? Meaning returning hda7 back I guess to its original state of working right?


----------



## Robert S

That won't be easy to fix. You've turned the system partitions with all your TiVo software on it into a swap partition. I wouldn't advocate using a scatter-gun approach when issuing commands to Unix. You are required to know exactly what you're doing.

The system partitions are commong between TiVoes, so if you can restore a backup to another drive you could copy the active root partition off that drive on to your A drive.


----------



## mdhoward

Yikes! Ok how would I go about doing that? I have the old original hard drive still that I could pull the needed info from. My main concern is getting the programs off this drive that I am working with now. If I can do that and then just start over fresh from the beginning and reformat this drive then I have no problem in doing that.


----------



## Robert S

As long as the old drive has the same version of the software on it (if not, put it back in and get it to upgrade itself), then boot byteswapping (Series 1) and do

dd if=/dev/hdX7 of=/dev/hdY7

and all should be well (that is to say, you'll be pulling your hair out over the GSOD that won't go away...).


----------



## mdhoward

Ok I tried that replace hdX with C which was my original drive and hdY with B my drive I have been working with and I get this 

0+0 records in
0+0 records out

I put the drive back in the Tivo and nothing...it still sets at the intro screen. Did I not do it right?


----------



## Robert S

Unix is case sensitive, so hdB and hdb are different things.

Did you boot byteswapping?


----------



## msullivan

I'm looking to upgrade my TiVo Series 2 (240040) such that it'll have the original 40 GB drive and a new 120 GB B drive. Will this cause these so-called "swap" problems? If so, is the easiest way to fix it to simply get a smaller upgrade drive? I noticed it's an easy fix if you can get a prompt on your TiVo, but after searching here I've been unable to find a way to enable backdoors on 4.0 to do that. Thanks in advance for helping me out.


----------



## Robert S

You can go to 180Gb on a Series 2 TiVo without having any problems related to swap. I'd recommend making the new drive the A drive, letting it run for a bit and then adding the old A as a B drive if you feel the need for the extra space.


----------



## mdhoward

I searched and entered this to boot byteswapping 

vmlnodma hdd=bswap

And I used lower cased letters when I was typing in hdb and hdc


----------



## Robert S

You need to swap the devices that the TiVo drives are attached to:

vmlnodma hdb=bswap hdc=bswap


----------



## NFLnut

Maybe I'm as dumb as a box of rocks, but ..

When I mount hda4, I got something like:

total 4
drwxr-xr-x 2 root root 1024 Jul 23 2001 c/
drwxr-xr-x 2 root root 1024 Jul 23 2001 d/
drwxr-xr-x 2 root root 1024 Jul 23 2001 e/
drwxr-xr-x 2 root root 1024 Jun 10 2001 tivo/

When I mount hda7, I get

drwxr-xr-x 2 root root 1024 Oct 27 07:32 bin/
drwxr-xr-x 2 root root 3072 Oct 27 07:32 dev/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 dist/
drwxr-xr-x 4 root root 1024 Oct 27 07:33 etc/
drwxr-xr-x 2 root root 1024 Oct 27 07:32 etccombo/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 initrd/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 install/
drwxr-xr-x 2 root root 1024 Oct 27 07:32 kernel/
drwxr-xr-x 3 root root 1024 Oct 27 07:32 lib/
drwxr-xr-x 2 10763632 60450406 12288 Oct 27 07:31 lost+foung/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 mnt/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 proc/
drwxr-xr-x 2 root root 1024 Oct 27 07:32 prom/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 sbin/
lrwxrwxrwx 2 root root 8 Oct 27 07:31 tmp -> /var/tmp
drwxr-xr-x 2 root root 1024 Oct 27 07:33 tvbin/
drwxr-xr-x 2 root root 1024 Oct 27 07:33 tvlib/
drwxr-xr-x 2 root root 1024 Oct 27 07:33 var/

Now I'm going to go out on a limb here and make a wild guess.. hda7 is my active partition?!?????? Can someone please confirm or tell me I'm wrong?


----------



## NFLnut

I went back and booted with MFSTools 1 and tried the same. This time, the dates on hda4 are the same as hda7 was with the MFSTools boot disc. There are 31 directories now in hda4, and the dates are Jan 2, 2003. In hda7, there are also 31 directories, with the date still reading "Oct 27 07:31"

Why is there now a difference, and which of these (hda4 or hda7) are my active partition? I'm really confused now!


----------



## Robert S

Partition 4 looks very strange, but partition 7 looks like an ordinary root partition. As October 27 is only a couple of weeks ago, I'm guessing that was the last time the TiVo took a software upgrade, so I'd be pretty confident that's the active root partition.

If you're still in doubt, try using edit_bootparms to look at the boot block.

[Now you've tried again that looks much more sensible. The TiVo would have taken an upgrade in January and another one a few days ago.]


----------



## NFLnut

I couldn't get edit_bootparms to work with either the MFSTools ver.1 or ver.2. As to the Oct 27 date, this coincides with the time that my TiVo started getting the GSOD loop!  I'm just curious as to how hda4 could show "Jun 2001" on MFSTools2 and "Jan 2003" on MFSTools1!

So, I just wanna make sure .. hda4 (the one with Jan 2, 2003) is my inactive partition? What happens if I screw up and pick the wrong partition?


----------



## NFLnut

Why does [email protected] always happen to ME?!?!

I went through the steps tomake the inactive partition active:

"mkswap -v0 /dev/hda4"

then,

"pdisk /dev/hda"

I got:

Edit /dev/hda -
Command (? for help): "r 8 4"
Command (? for help): "r 5 9"
Command (? for help): "w"
Writing the map destroys ... Is that okay? [n/y]: "y"

I then got:

"pdisk: Re-read of partition table failed (Device or resource busy)
Reboot your system to ensure the partition table is updated.
Command (? for help):"

I tried entering "w" again and got the same response. Does this have anything to do with having booted this time with MFSTools1?


----------



## Robert S

I don't know why there would be problems writing the boot block. Perhaps this disk is more broken than it appears? All you can do is reboot the system as suggested and see if the partition table has been rewritten.

As to your earlier questions, the list with c/ d/ e/ and tivo/ was not a listing of a TiVo drive, so having different dates on it is not surprising.

Perhaps the GSOD repeated the download of the system software? 

If you run mkswap on the wrong partition, you'll make the TiVo unbootable (won't get past 'welcome').


----------



## NFLnut

Well, I guess I made the 'proper' choice .. I'm still getting "powering up," "just a few seconds more," GSOD loops. I'll give it a coupla more hours, then I'm throwing in the towel and dropping a new image on the drive. I just can't spend much more time on trying to save my old recordings.


----------



## DCIFRTHS

I can't seem to locate instructions on how to increase swap for a Pioneer 57H. I'd like to use a 300 GB drive. Sorry if I missed this, but obviously I did  

Would someone please post that information here?

Thank You.


----------



## DCIFRTHS

Another question(s) (it's been a while since I've upgraded):

1) It seems that the only reason a DOS/WIN98/WIN ME etc. disk is needed is to pipe the backup to. Is this correct?

2) A WIN 2000/XP disk will corrupt the backup when it writes a signature to the disk. Correct?

2a) If yes, then couldn't I use a NON-bootable HD formatted with a FAT32 partition on it for the backup file as opposed to having a bootable HD connected?

2c) If yes, could this disk be formatted using WIN 200/XP as a FAT32 partition?

Thanks.


----------



## lemketron

> _Originally posted by DCIFRTHS _
> *Another question(s) (it's been a while since I've upgraded):
> 1) It seems that the only reason a DOS/WIN98/WIN ME etc. disk is needed is to pipe the backup to. Is this correct?*


I believe so, but note that the backup image is typically piped to a file on the disk (like "TivoBackup.tar.Z").



> *2) A WIN 2000/XP disk will corrupt the backup when it writes a signature to the disk. Correct?*


A Windows disk will NOT corrupt the backup file ("TivoBackup.tar.Z") but it WILL corrupt an actual TiVo drive if it is connected to your PC when you boot Windows.



> *2a) If yes, then couldn't I use a NON-bootable HD formatted with a FAT32 partition on it for the backup file as opposed to having a bootable HD connected?*


You should be able to write the file to any filesystem on any drive accessible (and mountable) from Linux. I believe that includes FAT32.



> *2c) If yes, could this disk be formatted using WIN 200/XP as a FAT32 partition?*


I believe so. I don't recall how my Win98 drive is formatted, but it contains several Tivo backup images.

If you're using the MFS Tools CD-ROM, then you just need to make sure that you boot this CD rather than allowing the machine to boot Windows. You can set the BIOS to check the CD first before booting the hard drive, and thus you should be able to boot the system from the CD, even if your bootable Windows drive is still connected as C: and the Tivo drive(s) are connected to the other drive connectors. That way you can upgrade, backup, restore, etc. to/from the Windows drive without fear of corrupting the TiVo drive(s). Just make sure the system is booting properly from the (MFS Tools, etc.) CD (try it once, for example) before hooking up the Tivo drives and you should be fine...
--Steve


----------



## Robert S

To get more swap you run mfsrestore with -s 150 (150Mb for 300Gb, for example - you need about 1/2000 of your disk space as swap). For values larger than 127, MFS Tools can not initialise the partition correctly, so you need to use mkswap or tpip to initialise the partition.

Any FAT32 partition is fine. You can put a small FAT partition on your 300Gb drive for the backup phase. You can use Drive Manager or FDISK+FORMAT as you prefer.

You should be able to mount your NTFS C: drive (you'll find it's read-only) if you wan to restore the backup to the 300Gb drive. You shouldn't have to have your live TiVo drive and a bootable WinXP drive connected at the same time.


----------



## DCIFRTHS

After doing a "standard" upgrade using -s 150 and Lou's "PTVupgrade LBA48 MFStools 2.0 ISO" on my Pioneer 57H, I would use option three from your post here ?

Since you say to boot using a TiVo boot CD, but NOT MFS Tools 2.0, would Lou's "PTVupgrade LBA48 MFStools 2.0 ISO" be okay?

Thanks.


----------



## Robert S

You'd think so, but using the PC version of mkswap does not seem to work for the TiVo when creating new-style swap signatures. Todd compiled mkswap for the TiVo and people have used that to initialise their swap, but that's pretty fiddly and probably out of the question for a Series 2 TiVo.

Todd saved us from those hassles with tpip, which will initialise the swap partition correctly. (It will also copy the kernel on to the disk for you).

tpip is on the PTVU CD, so you might as well use that, but I think it has internal byteswapping (never actually used it myself), so any Linux boot disk should do. Lou introduced the CD here and mentions there's documentation here.


----------



## DCIFRTHS

I missed this statement on Lou's page (every time I visited it): 


> Pioner DVR Series2 Units: This CD does not currently support creation of swap files greater than 127MB on drives built for Series2 Pioneer units. More information to follow.


I have been reading a lot the last few days because I really want to upgrade my 57H with a 300 GB disk. Unfortunately, I seem to be getting mixed opinions on increasing the swap and if it's even possible / necessary.

So what is the recommended upgrade procedure for large drives on the Pioneer? Is the additional swap a good idea?


----------



## tivoupgrade

> _Originally posted by DCIFRTHS _
> *I missed this statement on Lou's page (every time I visited it):
> 
> I have been reading a lot the last few days because I really want to upgrade my 57H with a 300 GB disk. Unfortunately, I seem to be getting mixed opinions on increasing the swap and if it's even possible / necessary.
> 
> So what is the recommended upgrade procedure for large drives on the Pioneer? Is the additional swap a good idea? *


Using TPIP (included on the LBA48 CD we released) you can initialize a swap partition of any desired size. We've not been able to come up with a deterministic method for actually having a > 127GB swap FILE created within that partition. (I've been personally successful in doing it twice, but have been unable to replicate the initialization of the swap file consistently).

We don't believe its necessary to have the greater swap file sizes in order to have a successful and reliable upgrade -- we've been offering LBA48-enabled kits for TWO YEARS now and have had ZERO issues related to GSOD and non-recovery in any situation other than that of a defective drive. So, even though we now use large swap files wherever possible, mainly because some folks are concerned about it (IMHO, OVERLY CONCERNED), we would still encourage you to recommend upgrading even if you could not build a swap file greater than 127GB.


----------



## janol

I've been reading this post for several hours now and it got me really worried. 
I recently upgraded my Series 2 Tivo from single 40GB drive to 40+120 GB

I followed the famous instructions and used option #1 (without using -s 127 option) basically adding additional space to the 40GB drive. The instructions noted that I should be OK because my total capacity is less than 180GB. 
My TiVo now reports 189Hrs of free space and I am worried that I did not expand the swap file.

What should I do??? Any help will be greatly appreciated.

Thanks,
Janol


----------



## Robert S

1Gb=1.2 Hours.


----------



## janol

I kind of figured it out, but the question is: 

What should I do with my upgrade??
Should I be worried about the swap file problem? And if yes, what are my options?


----------



## Robert S

You're OK for the moment. If you upgrade the A drive, consider increasing swap at that time. See the third post of this thread for a couple of ideas for dealing with insufficient swap.

You'll find it's a lot easier to increase swap on your first upgrade than to increase it later, but it's not necessarily a disaster if you don't increase it.


----------



## janol

Thanks for all your help. I really appreciate you answering my questions. 

As I understand, if -s 127 option was not used, 65MB swap file would be created. Would it be sufficient for 160GB of storage? Or should I rather do it now while I still do not have many things stored on my TiVo.

Is there any way to just increase the size of the swap file in my situation? 

Again, thanks for all your help Robert


----------



## Robert S

You seem to want me to keep repeating the same things. If you read the first few posts of this thread, I've tried to summarise our current thinking about how this works.

But, one more time, just for you: On a Series 2 TiVo you have 32Mb of RAM plus 64Mb of swap. This works out to be enough for just over 180Gb of disk space. 60+120Gb Series 2's have been seen recovering from GSOD's without extra swap.

There's no way to permanently increase swap without repeating the whole upgrade.

If you upgrade the A drive, that will take you over the limit and if your TiVo then GSOD'd, it would get stuck. When you upgrade the A drive you can manually create a larger swap partition before you expand the TiVo image to fill the larger drive. Or you can leave the swap alone and, in the unlikely event of a GSOD, temporarily expand the swap to allow the TiVo to recover.

Both those procedures are described in the third post of this thread.


----------



## kerkules

> _Originally posted by Merle Corey _
> *Ok, so I flubbed my guesstimate before. The magic number for getting fsfix to fail under -r 0 on a 40GB drive is 12MB of swap or less. 13MB works.
> 
> Useful trivia: If you have a TiVo that's greenscreen looping due to bad swapfile, but is otherwise of sufficient size, you can run mkswap -v0 /dev/hdX8 from the (byteswapped) boot disk and the TiVo will recognize the corrected swap, allowing fsfix to complete.
> 
> In other words, anyone who is up the creek because of having used -s 128...? It's fixable, without reimaging, even if the greenscreen loop has already begun.
> 
> (Edit: Typo fix) *


Useful trivia: If you have a TiVo that's greenscreen looping due to bad swapfile, but is otherwise of sufficient size, you can run mkswap -v0 /dev/hdX8 from the (byteswapped) boot disk and the TiVo will recognize the corrected swap, allowing fsfix to complete.

In other words, anyone who is up the creek because of having used -s 128...? It's fixable, without reimaging, even if the greenscreen loop has already begun.

Hi,

I have an SVR2000 with a 120+40 configuration that has been running for almost 2 years with no problems. Last week encountered the GSOD. It reboots several times then stays GSOD. Diagnostics on the drives have come out ok. How can I fix this? I don't have a backup image (it went down with my old computer).

I'm not very Linux-literate and was wondering how the "hdx8" part works with a dual drive system, (assuming my A Drive would be hda and the B drive is hdb). Thanks, K


----------



## Robert S

If you don't have enough memory, the GSOD will reboot endlessly and with metronomic regularity. In that case, the techniques for initialising or increasing swap in the first few posts of this thread can save your TiVo.

The GSOD seems to reboot when it his a bad block, so irregular reboots suggest that the GSOD is allocating its RAM and getting to work, but there are lots of bad blocks on the disk.

The swap partition is on the A drive, so hdX8 needs to point to the A drive. If the A drive is primary master, then it's hda8.

If you can get the GSOD to resolve, you can make a new compressed backup. Otherwise you'll have to download one.


----------



## rtivo99

As many people have pointed out. This thread is massive and I think I have confused myself.

I have a Series 2 SA that started out as a 40hr and I upgraded the drive A to a 120GB drive. I do not remember if I did the -s 127 switch or not. 

What I would like to do is add a second 120GB drive as a B drive. How do I insure that I have enough swap space to avoid the GSOD reboot problem?

I am willing to perform the upgrade again from the current 120GB A drive to the new 120GB drive with the -s 127 switch if this is what is required. Then I could perform the mfsadd command. Am I on the right track?


----------



## Robert S

There's nothing you can do now if you want to keep your recordings. All you can do is add the B drive. You can easily check whether you increased swap (you really weren't paying attention if you didn't!). When the PC boots, you'll see the partition table printed. If partition 7 (it's actually partition 8, of course, but it looks like 7) is 127Mb, then you're OK.

Even if you didn't, all you can do is hope you don't get a GSOD and if you do, use the 'rescue' from the third post of this thread.


----------



## TimTrace

Robert -

This question regards a 2x160GB HDVR2, except for the HDD upgrade it is unhacked.

I've loaded my A drive into my PC, and booted with the MFSTools CD from http://mfstools.sourceforge.net .

PDISK shows #8 at 127.0M .

Am I safe, or have I missed something?

Thanks,

Tim ==


----------



## Willin

Now that there aren't any software upgrades for S1 tivos, is there really a need to restore the inactive root partition? Why can't I leave it as a permanent swap?

I had 2 GSOD's within one week and it was a pain to do the recovery twice with the temporary swap partition.


----------



## Robert S

Yes, you only have to restore the order of the partitions before the next software upgrade comes in.

I don't know what the effect of taking a software upgrade to the smaller root partition would be. It could be that the only way to recover would be to restore a backup, which is what the rescue was trying to avoid.


----------



## lbroadfield

(First of all, thanks to Tiger, Robert S, Hinsdale, Dylan, etc. etc., without whom...)

OK, I'm running, but I goofed a little on the swap partition, and wondering if there's a way to un-goof.

I started with my 31201 which had previously (back in the days of BlessTiVo) had a 60GB "B" added to it's original 30GB "A".

Goal was to replace the original "A" with a new 120GB. I successfully dd'ed original-A to new-A, but I didn't quite grasp that I needed to follow the post#3 instructions to manually create the larger swap partition *before* using mfsadd to expand capacity.

Now I have a fully-expanded A with only a 64MB swap partition, and not enough room to create a new 128MB swap partition. Is there any way to ungoof this, or do I just to make sure to hang onto a copy of the rescue-via-inactive-root instructions forever?

(For extra credit, how do I ungoof it without losing recordings, or at least, losing a minimum of recordings?)

--Laird


----------



## Robert S

I don't think you can reverse that without losing your recordings.

I would make the following observations:

GSOD's are pretty rare, so there's no real cause for worrying about it as long as the TiVo is working.

Software development for Series 1 TiVoes has ceased, so if you were to put it in the 'rescue' configuration, there's no urgent need to return it to its current configuration.


----------



## twash

Objective: Add 160GB harddrive, as Drive B to a 112 and a 212 Phillips TiVo standalones, both of which already have working 120GB single drive upgrades, bought as plug and play from a couple of different sellers. These Phillips TiVos have been working successfully with the upgrade A drives for a couple of weeks now. 

The A Drives are both Maxtor, the new drives are to be Samsung, 7200RPM, 160GB, because the Samsungs were the cheapest ones I found available at the time of purchase.

To fix them up I will install in my XP pc (yes, I know I am not supposed to boot to windows with the Tivo drives installed) with existing TiVo A drive plugged to Secondary Master IDE connector and the new drive B to the Primary Slave IDE connector. Said drives jumpered correctly as master and slave, respectively.

Since doing this increases the TiVo recording capacity to over 150GB, I read that I should do something to increase the swap file so the GSOD will still hopefully work, if called upon to do so. Apparently, I am to NOT DO the following command: 

mfsadd -x /dev/hdc /dev/db

and am instead supposed to do a command that contains -s 127. My situation, adding a large B drive to an already existing 120GB, working, single drive Tivo, is not actually covered in the Hinsdale procedure, per say...well at least that is what appears to me to be the case. 

Given my hookup can someone give me the correct command to use in lieu of the one above?

Another question, I don't plan on doing the backup image step since the full image already exists on each Drive A at this time. Am wondering just why this is a necessary step given my possession of two TiVo's. Can't I get it off the other Tivo if I lose one of the Drive A's at some point or is this image associated with the unit itself making it not transferrable to another unit? 

Thanks in advance, ever so very much...


----------



## Robert S

As the swap is on the A drive, there's not much you can do about it if you're just adding a B drive. (Well, you could, if you were prepared to do some serious hackage, but that shouldn't be necessary).

How did you create the current A drives? If you used mfsrestore with -s 127, then you already have enough swap for the new drives.

If you didn't increase swap when you created the A drives, then you're stuck now. All you can do is hope that you don't get a GSOD and, if you do, use the 'rescue' from the third post of this thread to recover.

As for backups, yes, you can use the image from the other TiVo.


----------



## twash

Okay, I will try to find out from the guys I bought the upgrade A drives from to see if they used -s 127 and I will also save a copy of the post you refered to that says how to fix the problem if it occurs. 

In the meantime, I will continue reading this thread, bout halfway through it now...should have read it long before I ordered those new drives...grin...oh well, that is part of the fun of this stuff, seeing if I can bail myself out of dumb you-know-what predicaments.

I guess that if (-s 127) was not utilized with those A drives, I could do the full procedure with restorable backup, etc, with the new drive as Drive A and the old drive as Drive B?


----------



## Robert S

We've been telling people to use -s 127 for a couple of years now, so hopefully the drives already have 127Mb of swap.

TBH, I wouldn't go out of your way to fix it - the rescue works well enough.

You can check the swap yourself by booting in byteswapping mode and doing pdisk -l /dev/hdX


----------



## mitchsb

I am trying to put in a new b drive into my tivo. I used the how-to guide provided, but when I do the mfsadd command, it says:

mfs_load_volume_header: mfsvol_read_data: Invalid argument
Unable to open MFS drives.


----------



## rkcarter

I got an old computer for TiVo hacking. Trying to fix the GSOD problem. However, the CD drive on it is not bootable (it's an old Dell OptiPlex).

I start following instructions at the start of this thread -- but both the Dylan and the TivoMad floppies lack the "mkswap" utility. It's on the MFS Tools 2.0 floppy, but I don't see any obvious way to tell the MFS Tools 2.0 floppy to boot in byteswapped mode.

So... is there some way to get the mkswap utility off the MFS Tools 2.0 floppy running while I am booted in another of the boot disks, or some utility to add it to the other floppies or their RAM disk? I can't figure out how to mount another floppy with MFS Tools 2.0 up, nor the MFS Tools floppy with the other ones up, and even if so I imagine I'd need some way to uncompress the RAM disk.

I also have at my disposal a notebook PC so if there's anything I can do in WinXP (or booting from say the MFS Tools 2.0 CD) to make a floppy which would work, I can do it on there (where of course I can't mount the TiVo disks, this 2nd PC being a notebook PC and all).

Also, I suppose if I could mount the MFS Tools 2.0 CD while booted from one of the floppies that would work but I can't find a mount command that will work.

Thanks,

- Rick


----------



## Robert S

CD doesn't mount? That's normally pretty painless. Remember CD's don't have partitions, so there's no digit in the device node.

mkswap is on the TiVo's hard drive, so you can just rewrite rc.sysinit to run mkswap when the TiVo boots.

I wrote up the procedure for my very first post on this site. I linked to it in the first post of the Fixes thread.


----------



## tfreitas

Robert,
Great thread. I learned a lot. I've got an upgraded HDRV2 with a bad/clicking Maxtor. Previously upgraded with 120GB drive B - bad drive is original 40GB drive A. Bought a new Maxtor 80GB to replace the 40GB. Want to preserve recordings so I tried mfstools ddcopy - no luck. Then tried dd_rescue using knoppix. Got successful completion. Did mfsadd to expand and also got succesful completion. Booted in Tivo and got GSOD - recycling. Tried instructions from Post #3 of this thread - using dual disk instructions at bottom of post. I can not create a partition. Indicates "requested base and length is not within an existing free partition". Pdisk shows partition 16 "Apple_Free Extra" and a size of 3.1M. I'm trying to specify a swap partition of 128M. Am I out of space on this disk? Anything I can do to increase my swap partition? According to pdisk, my swap is 64MB, and a view of /mnt/var/log/messages shows 64MB as well. I'm hoping I'll be able to recover from GSOD if I can increase my swap size. But I'm stuck at this point.
Thanks for any help
Tim


----------



## Robert S

You do that when you upgrade the A drive. After the copy but before the expand. Your A drive is already full.

You want to do the 'rescue' from the first part of that post.


----------



## tfreitas

Robert,
Sorry to belabor this, but I think I'm close. I redid my dd_rescue and have not yet done the mfs_add. But I'm a bit confused. The first part of post #3 talks about determining the inactive root partition and making it a swap. Then it suggests that if you're upgrading a 2 drive Tivo, see details at end of post. The latter section talks only of adding a new swap partition - making it 128M. It doesn't talk at all about the inactive root partition. I do have a 2 drive Tivo - upgrading/replacing bad 40GB A drive with 80GB A drive while still preserving recordings on A and B drives(120Gb). Do I do just the latter section of post #3, or do I do the "boot in inactive partition" as well. I suspect I do only the latter part of post#3 but I'm about 30 hours in to this mess and am getting a little paranoid. Pdisk shows 13 partitions on my A drive. I tried creating 14p and it gave me "invalid partition" so I'm afraid I may have to do the laborious manual partition thing in post #7. Is that still my only choice? Thanks for any clarification.

Here's my partition table if that makes a difference ...
Partition map (with 512 byte blocks) on '/dev/hdd'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1 
2: Image Bootstrap 1 1 @ 44023824
3: Image Kernel 1 8192 @ 44023825 ( 4.0M)
4: Ext2 Root 1 262144 @ 44032017 (128.0M)
5: Image Bootstrap 2 1 @ 44294161
6: Image Kernel 2 8192 @ 44294162 ( 4.0M)
7: Ext2 Root 2 262144 @ 44302354 (128.0M)
8: Swap Linux swap 131072 @ 44564498 ( 64.0M)
9: Ext2 /var 262144 @ 44695570 (128.0M)
10: MFS MFS application region 1048576 @ 44957714 (512.0M)
11: MFS MFS media region 32988398 @ 47054866 ( 15.7G)
12: MFS MFS application region 2 1048576 @ 46006290 (512.0M)
13: MFS MFS media region 2 44023760 @ 64 ( 21.0G)

Tim


----------



## tfreitas

I manually recreated the partition table, defined the new 128m swap partition, moved it to hdx8 and moved the old to hdx15, then did the mkswap. That all seemed to work OK. Did the mfsadd and got ...

mfs_load_zone_map: Primary zone map corrupt, loading backup.
mfs_load_zone_map: Seconday zone map corrupt, giving up.
mfs_load_zone_map: Zone map checksum error!
Unable to open MFS drives.

which is what "mutant" got a year ago (6/2003) in post #365. 

My old Swap (64BM) is still in the table ...
13: MFS MFS media region 2 44023760 @ 64 ( 21.0G)
14: Swap Linux swap 131072 @ 44564498 ( 64.0M)
15: Apple_Free Extra 

Does that make sense? Should I delete the old swap partition or is that not relevent? Any other suggestions? I'm thinking I'm close but that may just be a fool's optimism.
Thanks,
Tim


----------



## Robert S

You have to run mfsadd against both drives!


----------



## tfreitas

I think I did, unless I'm missing the point. My upgraded 80GB A drive is hdb. My existing 120GB B drive is hdd. I did mfsadd -x /dev/hdb /dev/hdd.

Am I doing something wrong?

Tim


----------



## Robert S

Well, the most obvious cause of that error message is that MFS Tools only saw the A drive. I suppose the drive might be locked.

Can you get mfsinfo to work?


----------



## tfreitas

mfsinfo /dev/hdb (A drive) gives me ...
Second MFS Drive Needed: No such file or directory
Second MFS Drive Needed2: Illegal seek
Second MFS Drive Needed: No such file or directory
Second MFS Drive Needed3: Illegal seek
mfs_load_volume_header: Total sectors(79108096) mismatch with volume header (313601024)
mfs_load_volume_header: Loading anyway.
mfs_load_zone_map: Primary zone map corrupt, loading backup.
mfs_load_zone_map: Secondary zone map corrupt, giving up.
mfs_load_zone_map: Zone map checksum error!

mfsinfo /dev/hdd (B drive) gives me ...
/dev/hdd10: Success
mfs_load_volume_header: mfsvol_read_data:Input/output error

mfsinfo /dev/hdb /dev/hdd gives me ...
mfs_load_zone_map: Primary zone map corrupt, loading backup.
mfs_load_zone_map: Secondary zone map corrupt, giving up.
mfs_load_zone_map: Zone map checksum error!
Segmentation fault

I can pdisk -l either drive, so linux sees the drives.

I had done an mfsadd earlier prior to having expanded the swap file. I then redid my dd_rescue so I'm now working with a fresh copy of the A drive. Maybe the B drive was effected by the earlier mfsadd? Any limitation on how many times you do an mfsadd? 

Is it looking hopeless?

Thanks for your patience,

Tim


----------



## tfreitas

Here are the before and after partition tables, i.e., after the dd_rescue and then after I recreated it manually.

Original Table:
Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1 
2: Image Bootstrap 1 1 @ 44023824
3: Image Kernel 1 8192 @ 44023825 ( 4.0M)
4:  Ext2 Root 1 262144 @ 44032017 (128.0M)
5: Image Bootstrap 2 1 @ 44294161
6: Image Kernel 2 8192 @ 44294162 ( 4.0M)
7: Ext2 Root 2 262144 @ 44302354 (128.0M)
8: Swap Linux swap 131072 @ 44564498 ( 64.0M)
9: Ext2 /var 262144 @ 44695570 (128.0M)
10: MFS MFS application region 1048576 @ 44957714 (512.0M)
11: MFS MFS media region 32988398 @ 47054866 ( 15.7G)
12: MFS MFS application region 2 1048576 @ 46006290 (512.0M)
13: MFS MFS media region 2 44023760 @ 64 ( 21.0G)

Manually built table:
Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1 
2: Image Bootstrap 1 1 @ 44023824
3: Image Kernel 1 8192 @ 44023825 ( 4.0M)
4: Ext2 Root 1 262144 @ 44032017 (128.0M)
5: Image Bootstrap 2 1 @ 44294161
6: Image Kernel 2 8192 @ 44294162 ( 4.0M)
7: Ext2 Root 2 262144 @ 44302354 (128.0M)
8: Swap Linux Swap 262144 @ 80043264 (128.0M)
9: Ext2 /var 262144 @ 44695570 (128.0M)
10: MFS MFS application region 1048576 @ 44957714 (512.0M)
11: MFS MFS media region 32988398 @ 47054866 ( 15.7G)
12: MFS MFS application region 2 1048576 @ 46006290 (512.0M)
13: MFS MFS media region 2 44023760 @ 64 ( 21.0G)
14: Swap Linux Swap 131072 @ 44564498 ( 64.0M)
15: Apple_Free Extra 79781120 @ 80305408 ( 38.0G)


----------



## Robert S

Yes, copying the A drive back on to the new drive after mfsadd'ing was a mistake.

I suppose forcing a GSOD might fix it (either boot with just the A drive attached or using Diagnostic mode), but I wouldn't be very optimistic.


----------



## tfreitas

So I'm giving up on preserving my recordings. I'd just like to get a working tivo. I did do a backup before all this started ...

mfsbackup -f 9999 -6so /mnt/dos/tivo.bak /dev/hdb /dev/hdd (A/B drives)

I just ran the restore ...

mfsrestore -s 127 -xzpi /mnt/dos/tivo.bak /dev/hdb /dev/hdd

I get successful completion. mfsinfo looks good, telling me I have 2 more expands left and the increased time, etc.

But when I boot tivo, I'm still stuck in the boot loop. Got GSOD for a while then stuck in "powering on ..." and "almost there" loop.

I assume my image is good since I got succesful completion of all commands. Any suggestions? Swap is 127m.

Thanks again.

Tim


----------



## Robert S

That suggests a problem with the B drive. I would put an image on just the A drive and check that that works.


----------



## tfreitas

I already did that. Tried to boot off the A only first. Got GSOD then the loop. Then I mfsadd'ed the A to the B and got the same. Hmm. I wonder if my image is bad, though I thought I would have seen some indication of that during the backup, restore, mfsadd, mfsinfo, etc. 

How about this. I have another tivo with a single 160GB. Can I backup that image and restore it on an 80 or 120GB - can an image be restored on a drive smaller than the one it came from? Or is it a function of how the partition table has been built regardless of whether I'm using the space? There's little to no recordings on the 160GB and I could clear the thing if that mattered. If I can't do that, any suggestions on getting a good image? Unless you think the problem is not with the image. 

Also, would the first part of your Post#3 apply here (moving swap into inactive partition) or would that not apply since I have a 2 drive Tivo?

Thanks for all your help.


----------



## Robert S

You've got a 127Mb swap partition - that's the same size as your inactive root.

As long as the other TiVo is the same model (the first three numbers of the service number must match), then there's no problem taking a backup from that one.


----------



## tfreitas

My bad tivo is an HDVR2 (1st 3 digits 151). My new tivo is an SD-DVR40 (1st 3 digits 351). Both Hughes - the SD-DVR40 is the newer version of the HDVR2. Am I out of luck?


----------



## Robert S

Er, yes, I think that should be OK.

You might want to read the 'Moron' artical at tivo.samba.org, so you'll know what to look for.


----------



## tfreitas

Hmm. So is that your subtle way of calling me a moron for asking a dumb question or do you actually think it has a chance of working but I should be aware of possible consequences as outlined in the moron thread. I'd like to think the latter . I'm thinking I may go to Instantcake and get a $20 virgin image for an HDVR2.
Tim


----------



## Robert S

Is the difference between 'Moron' and 'moron' too subtle for you?

Like I said, I think you'll be OK - the Series 2 DTiVoes seem to cope with the Type II Moron situation better than other models and will download and successfully install the correct version.

But I would still check that this does infact happen and stop the TiVo phoning home if it doesn't. (At that point IC starts to look like an attractive proposition).


----------



## tfreitas

Kudos to Instant Cake. For $20, I get a virgin image and a working Tivo. Just have to "clear and delete all" to get things up. Thanks for all you help Robert S. I think the problems I had recovering the system all stemmed from the fact that my backup image was taken after I already had a harddrive problem. So it was all for naut. Though I learned a lot and will be in better shape next time I inevitably have HD problems.
Thanks again,
Tim


----------



## richard27

I am trying to add a 200GB HD to my RCA DirecTV Tivo (has a 40 GB in it already). I have followed all of the Hinsdale steps until step 8. The last command I used was:

mfsrestore -s 127 -zpi /mnt/dos/tivo.bak /dev/hdb

According to the steps, since my new drive is over 140 GB, I am supposed to use one of the following commands next:

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -xzpi - /dev/hda
or
mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -xzpi - /dev/hda /dev/hdb


Am I doing this correctly? Which one of these do I use? The second one assumes that I have 3 drives, but I want to keep my original tivo drive. Can I just use the mfsadd command? Also, after this step, are they ready to go back into the TIVO?

Sorry for all the questions, but I am a little lost.


----------



## Robert S

You can't increase your swap if you keep your original A drive. You could to the first pipe to copy the recordings to the new drive and then mfsadd the A drive as a B drive.

However, you don't actually need more swap at this point as your total drive capacity will be 177Gb, which is known to be OK on a DTiVo.

Having said that, if you're thinking of upgrading further in future, it's a lot easier to expand swap now than on subsequent upgrades.


----------



## Scot

I've got two pairs of 120 GB drives for a Philips Model: DSR6000R01, and twice now I've run into the GSOD problem when the drives fill up with files I've set to "Keep until I delete". The only way I've found to get things going again is to treat the drives as empty and re-do the upgrade procedure, including increasing swap space using the s -127 option in the mfsrestore command. 

Is there any way to save the data on my drives? I've let them "cook" in the TiVo overnight, hoping the GSOD repair routines would perform a miracle, but so far no joy. Mounting them in a PC and booting off the MFSTools disk wouldn't allow me to cruise the directories on the TiVo drives. My though there was that perhaps deleting some data files would let the drives work again?

Before I wipe out this set of drives and re-upgrade them, what steps can I take to make sure that the GSOD doesn't happen again? I'm following the Hinsdale instructions, upgrading two small drives to the two 120 Gb drives.

Help!

TIA,

Scot


----------



## SEC55

I just completed the upgrade to my stock Sony SVR-2000. I'm pleased to report that I now have 194 hours! I'm quite happy that I did it myself, because I'm not much for command lines and jumpers.

However, I did run into one problem. I was unable to make MFS Tools recognize the s -127 command to increase the swap file, even though I followed the Hinsdale How-To exactly. So I just did the recording capacity upgrade and I have some questions:

Is there a way to go back and increase the file? If so, how?
Does it matter?

I looked over this forum - although I didn't read all 26 pages! - and saw one post that seemed to say it wasn't that important, and others that said it was.

BTW, I unknowingly booted into Win2000 before reading (at the very END of the tutorial) that I shouldn't do that. That info should have been one of the first bits of advice given. Both drives seem to work, though.


----------



## Robert S

"s -127" or "-s 127"?

Anyway, it's a bit late to do anything now, unless you want to repeat the upgrade.

Print out the third post of this thread and keep it in a safe place.


----------



## SEC55

> _Originally posted by Robert S _
> *"s -127" or "-s 127"?
> 
> Anyway, it's a bit late to do anything now, unless you want to repeat the upgrade. *


Could I just repeat the capacity upgrade part, or would I have to start from scratch?


----------



## Robert S

You'd have to to the whole thing over.


----------



## SEC55

Well, I supposed I could redo it if it's really necessary. Two questions, however,

1. I didn't back up my recordgings, just did the capacity upgrade, so I used the line 

mfsadd -x /dev/hdc /dev/hdb

to do the upgrade. Where would I add the 127 command? I didn't know where to put it and it wouldn't go. 

2. Would it be better to use my new 7200 rpm drive as the A drive instead of the stock 5400 rpm?


----------



## Robert S

-s <number> is a parameter for mfsrestore, not mfsadd.

The swap partition is on the A drive. There's no way to affect the size of the swap allocation without altering the A drive.

If you'd wanted to increase swap, you'd have had to copy your recordings to the new drive and then (optionally) added the old A drive as a B drive.


----------



## Snorwegian

Sorry to keep asking essentially the same question Robert, but I just wanted to make sure-- I pored over this thread but couldn't find a specific response.

I have a Series 2 Samsug DirecTivo with a 100GB HD already in it (factory installed). I want to add a 120 GB HD as a B drive to it. As I understand it, I will NOT be able to increase the swap file size on my A drive without losing all my existing recordings (unless I transfer my 'A' drive to my new HD, and then using my A drive as a new B drive). Is this in face the case ?

If so, then my only real option is to simply perform the capacity upgrade without increasing swap file, and in the case of a GSOD, then I can use your instructions from the third post to try to save myself, correct? But in that case, I'd lose all my recordings anyway right?


Thanks again for all your help; you guys are the best!


----------



## Robert S

That's correct, except for the last line: The point of temporarily increasing swap is to SAVE your recordings by allowing the GSOD to complete. If you're happy to lose your recordings, you'd just reimage from a backup.


----------



## Scanman0

I origionally added and expanded a 250 GIG a drive, before MFStools 2 then used MFStools 2 to add a second 250 GIG B drive to obtain a cool half a terabyte on my series one hdr312 tivo. 
My swap situaion is:


Memory Statistics:
total: used: free: shared: buffers: cached:
Mem: 14274560 14131200 143360 65064960 49152 4120576
Swap: 314564608 1765376 312799232
MemTotal: 13940 kB
MemFree: 140 kB
MemShared: 63540 kB
Buffers: 48 kB
Cached: 4024 kB
SwapTotal: 307192 kB
SwapFree: 305468 kB

It's filling up fast, as I made "Best Quality" a nice DVD compatable recording resolution  

Also running cashecard w/512 stick.

Has anyone ever GSOD from a true MFS corruption and recovered with 500 gig's of stuff on a series 1 standalone ? If so how many DAYS did it take ?


----------



## diskus

so let me ask a question, if I am upgarading a tivo to a 120 and 200gig drive combo giving 320 total, then there is no reason to increase the swap file as it is over the maximum either way? ( 276 i believe was the figure in a earlier post)

is this correct?

thanks

MB


----------



## Robert S

274, actually.

If you're replacing the kernel, then you get the ability to use swap partitions larger than 128Mb, so you can get enough swap for the GSOD to run on really large drive sets.


----------



## HTH

I've just recovered from my first GSOD-reboot loop on my oldest upgraded TiVo. Hit it while recording an unexepcted (new?) episode of _Full Metal Challenge_.

Am I right that the only permanent solution to an insufficiently large swap is to either (a) upgrade to a larger primary drive if possible or (b) lose all recordings?

I'm already using two 120 GB drives in a Series1 and upgrading to a newer kernel to fully utilize a larger primary drive sounds just as risky on an upgrade (if one ever happens) as leaving my swap pointed at hda7.

Is there anything unsafe in having a partition in >137 GB space referenced in the partition table that can only be accessed when the drive is hooked up to a PC, say holding scratch backup space?


----------



## Robert S

You think you'll get a software upgrade before you'll have to replace those drives? 

I think TiVo have completely ruled out further software upgrades for Series 1's, so, assuming this is a stand alone model, I don't think you need to worry about that. (DTV seem to be continuing to tweak the Series 1 DTiVoes).

So, you might as well leave the swap on hda7 for now.

I suppose it might be possible to steal some space from hda7 and/or hda9. Both are contiguous with the swap partition and neither is full. It would be such a fiddly task, though, that it's probably not worth contemplating.

We have seen TiVoes with LBA-48 images and non-LBA-48 kernels. They only misbehave when they start to fill up, suggesting that the kernel only tries to look beyond the 137Gb mark when it needs to record something there, so I don't think your partitioning idea would cause a problem.


----------



## scoombs

I added a 100GB B-drive to my 30GB S1 almost 3 years ago. I just combined them to a 160GB replacement A-drive by using this command from the Hinsdale How-to:
mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdc

Since I am under the 140GB trigger, does that drive have only a 64MB swap, or was it expanded because the -s 127 option was used for the mfsrestore? That leads to my real question, that if I add a 100GB B-drive back to the system, taking the total size to 237GB, am I good to go swap-wise with just doing the following?:
mfsadd -x /dev/hdc /dev/hdb

Reading the response to twash on 7/7/04 suggests I am good to go since the A-drive image was created using the -s 127 option, but I am just trying to be cautious. 

Thanks much


----------



## HTH

> _Originally posted by Robert S _
> *You think you'll get a software upgrade before you'll have to replace those drives? *


 With TiVo's future plans in regards to premium and PPV content, I worry that their partners may demand it get an upgrade. It's a small concern, but a concern nonetheless. (I don't want to discuss that topic in this thread.)

It is a standalone.



> *I suppose it might be possible to steal some space from hda7 and/or hda9. Both are contiguous with the swap partition and neither is full. It would be such a fiddly task, though, that it's probably not worth contemplating.*


 I seem to remember way back when it was said that updated kernel and root partitions were simply dd'd into place on an upgrade. If that is the case, it may be unwise to try to steal space from another partition.



> *We have seen TiVoes with LBA-48 images and non-LBA-48 kernels. They only misbehave when they start to fill up, suggesting that the kernel only tries to look beyond the 137Gb mark when it needs to record something there, so I don't think your partitioning idea would cause a problem. *


 That settles some concerns, though I doubt tests with partitions wholly inside the LBA-48 area have been been tested. I'll consider giving it a try and will report any unexpected results when time allows.


----------



## n00blarME

Help anyone? After attempted upgrade using Hindsales How-to and PTVMFStools2 iso and weaknees bracket/powetrip/fan, my TiVo is stuck through Powering Up to Almost There then the GSOD! Pleaseeee im dying here!!!!


----------



## djliquidice

What happens if i omit the swap space parm?


----------



## Robert S

You get 64Mb of swap


----------



## djliquidice

Thanks.


----------



## janol

Hi Robert,

I hope you'll be able to help me in my situation.

I currently have a Series 2 TiVo with 2 drives in it: the original 40GB drive and the one I added about a year ago 120GB. When I was doing the upgrade, I chose the option to just do mfsadd command and only later found out that I may have a problem in the future because the swap space was not increased.

Now I have a problem. My TiVo has not GSOD'd yet, but it started experiencing "hick-ups" in video and audio and I decided to check my drives for errors. I used Maxtor PowerMax and it indicated that the original 40GB drive is failing. 

I want to move my data from the bad drive into a new one. The new one will probably be bigger. Is there any way for me to get the data out of my bad drive and increase the swap size in the process?

Any help will be greatly appreciated.


----------



## Robert S

There's no immediate problem with swap. Series 2 Tivoes have more RAM than Series 1 stand alones, so you can fit up to 180Gb without requiring extra swap.

However, that upgrade will take you over the limit.

The third post of this thread describes what to do. dd the drive on to the new one, use pdisk to create a new swap partition, initialise it and then mfsadd.


----------



## janol

Thanks Robert. I am going to give it a try. Just a couple more questions.

A while back in the posts user 'tfreitas' seamed to have the same problem I do right now and you said that this whole thing may not work because he did mfsadd during initial upgrade.

If I did mfsadd during initial upgrade will I still be able to 'marry' my new drive A and the old drive B making sure I do not loose my recordings? 

Also, what part of the post #3 I should use? It seams the situation on the bottom is the one I am facing now.

Thanks.


----------



## janol

I tried dd_rescue the drive today. Got a million errors and decided that that it would probably be more safe to just forget the recordings and restore the backup that I made during my original upgrade.

Are the following commands proper to restore the backup onto a new A drive?

mfsrestore -s 127 -xzbpi /mnt/dos/tivo.bak /dev/hdc 

Assuming new drive is Secondary Master and Windows C: drive is Primary Master.

Do I have to execute the following commands before the restore to mound DOS partition?

mkdir /mnt/dos
mount /dev/hda1 /mnt/dos

After the restore is done, do I have to run 

mfsadd -x /dev/hdc /dev/hdb

to marry the old B drive to the new A drive (assuming old B drive is Primary Slave)

Old B drive has data on it. Will I be able to see at least some of the recordings that are located completely on the B drive or will they be gone? Is it a good idea to leave the data on this drive at all or should I just restore onto both drives at the same time?

Thanks for all your help.


----------



## Robert S

You have to mount the DOS partition so you can read the backup

You can (and should) restore to both drives

mfsrestore -s 127 -xzbpi /mnt/dos/tivo.bak /dev/hdc /dev/hdb

None of your recordings will survive this, mfsrestore will wipe everything out.


----------



## janol

Thanks Robert,

I understand that I should restore to both drives, I am just curious, what would happen if I just restore to the new A drive and mfsadd the old B drive?


----------



## mbellot

Just wanted to give a big thanks to Robert and everyone else who have already "been there, done that".

My Tivo went into an endless reboot loop (green screen "severe error") earlier this week and I thought I was screwed.

After digging through the forums I found this MFSTools bug thread, although I don't think that was strictly my problem...

I recently upgraded my HDR312 to a 250GB drive (using the PTV LBA48 disk), and I had (foolishly) thought if 127MB of swap space was good that even more would be better, so I told MFSTools to reserve 300MB of swap space.

According to the instructions the swap space would be initialized when I installed the new kernel but...

After doing some reading it appears the S1 can't cope with any swap space larger than 127MB, so I effectively had nothing.

I yanked the drive out and installed it in my PC, boot the PTV CD and try to mount the /var partition (just to be sure I got my byte swapping right). Mount returned an I/O error. A quick check with pdisk confirmed that the partition table was intact (meaning byte swapping should be correct), so now I'm thinking the drive is toast.

I go and download the PowerMax utility (its a maxtor 250gb drive) and find out its only reporting 9MB of drive space!!!

More forum searching turns up the fact that the drive is probably locked and that I need to use diskutil (and NOT qunlock), so I unlock the drive and reboot into the PTV CD. This time everything goes smooth with pdisk and mounting /var so I run mkswap -v0 /dev/hdc8 130048. BTW - The PTV CD did NOT unlock the drive even though several posts claim the various boot CDs should.

Put the drive back in the Tivo boots to the green screen (severe error), but does NOT reboot (woohoo!). Fifteen minutes later the machine reboots and I'm back online. It even appears that all my recordings survived this nasty little ordeal.

So, for anyone who doesn't believe that most of the answers are already here, think again. I did everything necessary to fix the problem without asking a single question.

Again, a world of thanks to those who have already figured this out.

:up:

So now I have two questions 

1. Can anyone definitely confirm that an HDR312 will not work with more than 127MB of swap space.
2. Assuming the answer to #1 is yes (127MB limit is real) Is there any way to utilize the remaining space for other things (like tivoweb, etc) so I'm not loading up the root and var partitions?


----------



## Robert S

You should have used tpip instead of mkswap to initialise the swap.

mkswap is limited to 128Mb, although it clearly shouldn't be.

However, you have enough swap for at least 274Gb of disk space, so you're fine for now.

But if you add a B drive, run tpip at that point.


----------



## mbellot

Robert S said:


> You should have used tpip instead of mkswap to initialise the swap.
> 
> mkswap is limited to 128Mb, although it clearly shouldn't be.
> 
> However, you have enough swap for at least 274Gb of disk space, so you're fine for now.
> 
> But if you add a B drive, run tpip at that point.


Thats the odd thing.. According to PTV (I used the PTV LBA48 CD image)



> CopyKern will automatically initialize your swap partition, so the aforementioned tpip command would be unnecessary when using CopyKern.


So when I used copykern to install the LBA48 kernel I _assumed_ it was initializing the swap space.

I don't know what happened, but obviously the swap space did not get initialized.


----------



## ronsch

Robert,

I just got a used DSR6000R01 sans drive and took a backup image from a friend with the same model. I used mfs tools 2.0 to restore the image to a 160gb drive without expansion (-zpi) and all seemed to go well. Putting the drive in TiVo and powering up, I get an endless reboot loop . In all likelyhood, the original backup was made using mfs tools 1.1. Could this cause this problem or is something else wrong with this TiVo?

Update: The backup was taken two years ago so it probably was done using mfs tools 2.0.

Update : I unplugged and replugged and the unit no longer reboots. Just sits at Welcome Powering Up with regular disk activity.

Update: rejumpered the drive to Master instead of CS and replaced ide cable with a brand new one. No change.


----------



## TomTomaro

I used the hinsdale guide to upgrade to a larger disk and now get the power up screen and nothing more, using either the replacement or original drive. Any suggestions?


----------



## rkcarter

Can you hear the drive spin up? A friend once managed to catch me just in time from closing up the box without reconnecting the power supply to my new drive, for example.


----------



## TomTomaro

Great first question. Simple stuff first. Yes I can hear the drive spin.


----------



## MannyVjr

OK, here is where I get a little confused...


Robert S said:


> D. Renumber the partitions.
> 
> *pdisk /dev/hda*
> 
> On TiVoMad, pdisk is /mad/pdiska.
> 
> If your inactive root partition is 4, type:
> 
> *r 8 4
> r 5 9*
> 
> If your inactive root partition is 7, type:
> 
> *r 8 7*
> 
> *w* (write partition table)
> *y* (confirm, returns you to command prompt)
> 
> E. Restore drive to TiVo
> 
> Let the TiVo run, it may take a long time, and may reboot occasionally, but it should eventually boot up properly. *Remember, you must complete this sequence, your TiVo is not safe when it recovers from the green screen.*
> 
> F. Restore the original partition numbers
> 
> Repeat step D above.
> 
> You can now safely replace the drive in the TiVo.


On step *E* it states to replace the drive on the tivo, so as soon as I get the command prompt (from step *D*) I power down my PC and extract the drive, right?

...and I'm curious when you say it might take a long time (the TiVo running to fix itself), you mean 2-4hrs or more like 4-6hrs?


----------



## slaponte

Would it be too much to ask if somebody can resume the 19 pages of thread into an answer? <Edited to answer my own question>

A) When do you need extra swap? If total disk space will be 128Gb or more, you need more swap. If you don't, under certain conditions, your Tivo might crash and you will most likely loose all your recordings.

B) How much do you need? You need 1MB per every 2GB of total disk.

C) Sequence of commands to add the swap and or fix headers?

Use mfsrestore flag "-s" to set swap size. Up to a value of 127 it will work fine. So that covers up to 254GB total disk. If your total disk will be larger than 254Gb, then you need to

- specify new size on the mfsrestore. (Example, "-s 200" creates 200MB swap for a 400Gb disk).

- run TPIP to initialize the swap header

*tpip --version* shows the version number you have

tpip V1.1 : *tpip --swapped -s /dev/hd?*

tpip V1.2 : *tpip -1 -s /dev/hd?*

Tpip can be downloaded from the web (V1.2) and is also found (v1.1) in the PTV Upgrade ISO CD image.


----------



## Bunny

I posted this in another thread but this thread may be more appropriate... I have an hr10-250 which I upgraded a couple of months ago with 2 seagate 400gb drives. Unfortunately, at the time the whole swap file discussion had not started yet. As far as I know, I have a 127mb swap file, whereas I understand it shoul be 400mb. I have not seen the GSOD but I do suffer from the occasional stutter, which I think may be related to the swap file size. I can redo the whole procedure again but I rather not want to lose my recordings and I do not have a couple of spare masssive drives to backup to. Is there any other way to do this without doing backup and restore?

Thanks!


----------



## slaponte

That I know off, no. To change the size of the swap space you have to modify the file system and that requires a backup, then restore with new structure.

I have read (deep in this long thread) a way to use an unused partition in the file system and add it as swap. But I seriously doubt it will give you the extra 270Mb+ you need.

The low swap won't matter until you hit a GSOD that loops and loops... and then, you will probably loose anything you have recorded.


----------



## tonsa

I upgraded mine to one 160gig and one 320gig but when I was done at first with 1 drive upgrade it showed I had 200 hours instead of the 160 hours then I added another drive it added 380 hours instead of 320 hours so all in all I have 580 hours which is wrong I just added 480gig it should show 480 hours right? is there something wrong to what I am doing? I followed everything. 

Is there a way to upgrade without adding the original drive size to the upgraded drive? even though the original drive is removed?

I am confused. I use weeknees upgrade and then I tried using msftools 2.0 still the same.

someone help? I am using 2 western digital drives

thanks in advance


----------



## mvita

What is the proper tpip command to use to initialize increased swap space on a HR10-250? Earlier in this thread, the syntax (for tpip v1.2) is shown as:

*tpip -1 -s /dev/hd?*​I'm a bit confused about the "-1" argument... the tpip doc says that this means "Treat the disk as a Series 1 TiVo disk instead of letting tpip figure it out". But isn't the HR10-250 essentially a "Series2" unit? Should I be using "-2" instead?


----------



## slaponte

No. For some reason the swap header from the S1 will work.

I can't explain why. Only know that everybody who used it got it working (on S2 machines).


----------



## slaponte

Tonsa, you don't explain exactly how you are doing this, so it is hard to tell what you are doing wrong...


----------



## mvita

Okey doke. Just wanted to make sure I wasn't screwing things up.

Thanks....


----------



## tonsa

slaponte said:


> Tonsa, you don't explain exactly how you are doing this, so it is hard to tell what you are doing wrong...


Here is what did both on weekness, hinsdale and the msftools

mfsbackup -f 9999 -1so /mnt/backup.bak /dev/hdc which is the b is the original tivo

then I did this

mfsrestore -s 127 -r 4 -zxpi /mnt/backup.bak /dev/hdZ /dev/hdZZ

which is the Z is the new master drive 160gig and the ZZ is the new slave drive 320gig

it still gives me extra over 40 something gig extra on each hard drive.

Is this correct?

Thanks


----------



## azitnay

On standalone units, the hours-to-GB ratio is slightly more than 1-to-1. This is less evident on the early Series2 models, where 40, 60, and 80GB were marketed as 40, 60, and 80 hours (although in reality they could record a little more than that), but on newer models such as the 140-hour models, they're really running 120GB drives. The biggest TiVo on the market, the Humax T2500, uses a 250GB hard drive and advertises 300 hours.

Personally, both my units with 160GB show ~180 hours, and my unit with 120GB shows ~140 hours.

Drew


----------



## tonsa

Thanks alot so I have alot of hours now! I am glad its clear now. You guys are very very helpfull! I really appreciate it.

More power to you guys


----------



## lennonc

I cannot find the mkswap file that is need to perform the swap increase mkswap -v1 /dev/hdc


----------



## slaponte

mkswap is a Linux command. It would usualy be in /bin, /sbin, /usr/bin or /usr/sbin

A way to find it 

cd /
find . -print | grep mkswap

This will return to you the full path to the command.


----------



## GGTZ

I have installed a 160 GB drive sucessfully into my series 2 Tivo and it's working great. I'd now like to add my orginal 40 GB drive as drive B. I probably should have done this when I did the upgrade to the 160 GB drive but I didnt.

Can I now add this as drive B (the orginal 40 GB drive) after I have expanded drive A to 160 GB. 

Basically... I've now got a TIVO with a 160GB single drive TIVO working fine. But, now I've got the 40GB drive sitting doing nothing so I thought I'd go ahead and add it. 

What commands do I use...or that is instructions in the Hinsdale upgrade? 

The instructions for ugrade configuration #1 are indicating and "unmodifed or Expanded".


----------



## slaponte

I am not sure it is worth the effort. You would have to backup the 160 back to a "shrunk" image to come back to the 160+40 and probably loose any recordings. You can't expand an expanded drive. Or you can start over with the 40Gb image and go forward from there. In that case is easy, just restore the 40GB backup image into the "160+40" (note that you will need to set swap at 100)

Many people subscribe to the idea also that you are adding more chance of drive failure with two drives. I am not usualy very concerned about that, but hey, just info for you.


----------



## rkcarter

IMHO you may want to keep the 40 as a nice safe backup of your TiVo's original configuration, which will come in handy to throw in to see if a problem is a TiVo problem or a disk problem; also if it's still under any sort of warranty you'll want the original disk back into it I think before you take it in.


----------



## 2devnull

slaponte said:


> In that case is easy, just restore the 40GB backup image into the "160+40" (note that you will need to set swap at 100)
> 
> Many people subscribe to the idea also that you are adding more chance of drive failure with two drives. I am not usualy very concerned about that, but hey, just info for you.


If I backed up my original Tivo 80 GB drive and then want to restore it to both that original drive (80 GB) and a new 320GB drive, what will be the tpip command I would need to run using tpip 1.2?

*tpip -1 -s /dev/????*

Which drive should the tpip command be run on?


----------



## 2devnull

tonsa said:


> Here is what did both on weekness, hinsdale and the msftools
> 
> mfsbackup -f 9999 -1so /mnt/backup.bak /dev/hdc which is the b is the original tivo
> 
> then I did this
> 
> mfsrestore -s 127 -r 4 -zxpi /mnt/backup.bak /dev/hdZ /dev/hdZZ
> 
> which is the Z is the new master drive 160gig and the ZZ is the new slave drive 320gig
> 
> it still gives me extra over 40 something gig extra on each hard drive.
> 
> Is this correct?
> 
> Thanks


you only have 127 for swap? Is this working out for you?


----------



## azitnay

2devnull said:


> If I backed up my original Tivo 80 GB drive and then want to restore it to both that original drive (80 GB) and a new 320GB drive, what will be the tpip command I would need to run using tpip 1.2?
> 
> *tpip -1 -s /dev/????*
> 
> Which drive should the tpip command be run on?


Whichever drive you make the primary (A) drive.

However, as an aside, I'd recommend just using the 320, and leaving the 80 out of the equation.

Drew


----------



## 2devnull

Well, I ended up restoring with 256 MB swap to the new 320 GB drive, running tpip on it, then adding the original 80 GB drive as a B drive. Got 350 hrs now.

Everything seems to be working correct so far. Now sure why everyone is recommending against adding the orig. 80 GB drive as a B drive.


----------



## JamieP

2devnull said:


> Now sure why everyone is recommending against adding the orig. 80 GB drive as a B drive.


A two drive system has roughly double the failure rate of a single drive system. If either drive fails, you lose everything -- all recordings, etc, and will have to recover from a backup image. It might be worth it for two 400GB drives in an HDtivo, but most of us think it isn't worth it to add a small drive to a much larger one.


----------



## 2devnull

does anyone know the reason a two drive system failure rate is double? Is it cooling, processing power, bus limit etc?

As far as I know, those at ptv andweeknees who do a lot of these two drive upgrades have not agreed this to be an issue.


----------



## JamieP

2devnull said:


> does anyone know the reason a two drive system failure rate is double? Is it cooling, processing power, bus limit etc?


It derives from basic probablity. See the additivity section here.


----------



## 2devnull

What really does not make sense is that by doing two 400 GB drives, you are going to loose more since that does not change the risk of the drives failing but does potentially risk you loosing more of your recordings due to the bigger combined size.

I conclude this to be a non-issue unless there is something more substantial that would indicate why adding a second drive would actually increase risk of failure.

If we worry about the laws of probability, the world would still be primitive.


----------



## azitnay

It's not a huge issue, and I still have one two-drive TiVo running... But the bottom line remains that if you have two hard drives, each with its own chance of failing, you get roughly double the chance of at least one of them failing. Once that happens, as JamieP said, you're usually out of luck with respect to everything on the drives, since they're a married pair.

Drew


----------



## JamieP

2devnull said:


> I conclude this to be a non-issue unless there is something more substantial that would indicate why adding a second drive would actually increase risk of failure.


To put this into perspective, a typical disk has a MTBF of 1 million hours. That works out to be something like 1 failure every 100 years. With two disks the failure rate doubles to 1 failure every 50 years. That increased risk might be a non issue for you, and there is nothing wrong with that. I'm just trying to explain the rationale for the original advice you were given.



> If we worry about the laws of probability, the world would still be primitive.


Ignore probabilty at your own risk.


----------



## 2devnull

Well the thinking should be that adding a second drive just gives more space and no one should be assuming what is store there is recoverable or is separate. Basically, you view your system as a one drive system in either case.

Now, other than additivity theory, there seems to be nothing conclusive that states that adding a second drive will make failure more likely due to a technical reason. Even with a one drive system, you still risk that single drive failing in any event.

I think the whole probability thing is blown out of proportion and mis-understood. Drives these days with the proper care are not likely to fail routinely.


----------



## 2devnull

BTW - JamieP and Drew, Thanks for the discussions. Don't mean this to sound arguementative. Just wanted to find any technical reasons behind the risk that can be addressed/mitigated potentially with some modding. Thank you.


----------



## rkcarter

It won't double the overall failure rate of the TiVo, but drives seem to be the most (or maybe 2nd most behind modems on TiVo 1's but I dunno about later TiVos) failure-prone item in a TiVo. So you're putting in two of the most failure-prone item, doubling the chances of a drive failure. And of course if the modem fails, you don't lose all your recordings, and have a few days of schedule to replace it with an external modem (been there done that).


----------



## rkcarter

Oh, and you are adding heat and power consumption, so I don't know how significantly or insignificantly but that will put more strain on other components.


----------



## 2devnull

From what I have read on weaknees, adding a second drive actually makes the system run coler since an extra fan(s) is added.


----------



## rkcarter

Interesting ... when I upgraded my TiVo 1, there was nothing in the instructions about adding a fan. Do you have to cut a new ventilation hole in a TiVo 2 for the fan?


----------



## azitnay

Assuming your post wasn't meant to be sarcastic, 2devnull is probably referring to systems whose upgrade included a WeaKnees TwinBreeze bracket, which adds an internal fan among other things. Certainly not a "standard" part of any upgrade, but WeaKnees does indeed make the claim that a two-drive system with a TwinBreeze runs cooler than a one-drive system with the stock fan and bracket.

Drew


----------



## 2devnull

Drew is absolutely correct. I am using the new G2 version of the Weeknees twinbreeze.


----------



## chelman

My computer has a SATA drive and MFSTools gets stuck while booting. What can I do?


----------



## whatever

chelman said:


> My computer has a SATA drive and MFSTools gets stuck while booting. What can I do?


I think you need to be more specific on "gets stuck while booting". Are there any error messages?

I haven't tried booting mfstools (yet), but since it's just a stripped down linux distribution, I suspect that there is no SATA support in it. Typically, SATA drives are detected using SCSI emulation with linux distros. I suspect that mfstools doesn't have any SATA support built in.

You might want to try downloading a "live" linux distibution and booting to that. It will boot from a CD and not touch your existing SATA drive. You could then run mfstools from a floppy.


----------



## slaponte

It's been a while. Hi everybody!

2dev, I think the statement many make of "increased chance of failure" with two drives is missleading (one of those "you can make statistics say anything you want" things.).

The phisical fact of having two drives does not increse the chance of either one of them failing, it increases the chance that the Tivo would have a disk failure (with 2 devices you have double the chance that one might fail at any given time). Similar to this : if you don't have power windows on your car you have 0% chance of them breaking, if you add power windows you now have double the chance than before...

The problem is that if you loose one disk on a dual-disk tivo you might/will loose everything you had recorded. Now that to me is not a big deal, so I discounted the risk. If a loose a disk, well, too bad, I get to install another one and reformat and go on with my life. Statistically speaking, I had 0% of those recordings before the Tivo, so I am no worse than when I started if I loose them


----------



## 2devnull

yep. fully agree. Whether you loose the single drive or the dual drive (either drive), the net result is the same thing, you loose all your recordings. And going from 1 drive to 2 does not contribute to a failure is the point needed to be made.


----------



## rkcarter

slaponte said:


> It's been a while. Hi everybody!
> 
> 2dev, I think the statement many make of "increased chance of failure" with two drives is missleading (one of those "you can make statistics say anything you want" things.).
> 
> The phisical fact of having two drives does not increse the chance of either one of them failing, it increases the chance that the Tivo would have a disk failure (with 2 devices you have double the chance that one might fail at any given time). Similar to this : if you don't have power windows on your car you have 0% chance of them breaking, if you add power windows you now have double the chance than before...
> 
> The problem is that if you loose one disk on a dual-disk tivo you might/will loose everything you had recorded. Now that to me is not a big deal, so I discounted the risk. If a loose a disk, well, too bad, I get to install another one and reformat and go on with my life. Statistically speaking, I had 0% of those recordings before the Tivo, so I am no worse than when I started if I loose them


As one of the ones who brought up "increased chance of failure," I want to make clear that I meant EXACTLY as you said here. I certainly did not mean to say nor imply anything other than that -- 2 pieces have a greater error rate than one of the same pieces, BECAUSE there are two of them that can break, and in this case, either of them breaking causes you to lose the recordings.

I had about the same number of recordings pre-TiVo -- just more videotapes.


----------



## slaponte

I have one dual and one single. Today, my advice would be stay single.

- easier upgrado to do
- less noise and hassle (power splitter, fans, etc)
- I definetly would not miss the 40 or 80GB when you have 300Gb in there.

You DO double the chances of loosing the Tivo.

I recently re-used one of my 40Gb drives on a PC, and the 80Gb went into this nice USB enclosures they make now. You drop the IDE drive in it, and it turns into a portable USB 2.0 device. Very cool way to add some backup space to your PC.


----------



## Robertjm

Is this still a problem with the latest versions of MFStools, or has that been fixed?


----------



## slaponte

I am not aware of a newer version of MFSTools. By the threads it seems there is a recent version of MFS tools. By the threads it would seem there is a "new" version but if you pay attention to the dates that was a couple of years ago...

But I have been away from these forums a while, I could be wrong.


----------



## kevincol

I have a HR10-250 that I have had for years.

There was a power surge and my unit started to lock up.

I checked drives with SpinRite and they are both fine.

Determined that there must have been corruption on OS files.

I wanted to go to "F" release and bought InstantCake and installed "F" version.

Machine booted up fine and seemed to work. However, it was only recognizing one drive in terms of space (i.e. 30hr HD on system info).

I removed second drive and machine still booted, indicating that it wasn't really seeing second drive, though TivoWebPlus Info shows both drives present.

I took drives out and used MFSAdd to pair the drives back together. MFSAdd said it added another 300hrs of SD recording time (i.e. from 281 to 581). Did [CTRL] [ALT] [DEL] to close down session and put drives back in Tivo.

Tivo still reports 30hours HD and doesn't report drives as combined.

Pulled drives out again and used MFSAdd to bring both drives down to one drive. MFSAdd reported drive down to 281 SD hours. [CTRL] [ALT] [DEL] to close down session, come back into MFS Tools 2.0 and use MFSAdd to pair drives again. MFSAdd reports drives were paired and that I should have 581 hrs SD.

Put drives back in Tivo and still reports 30hr HD record time!

Why on earth won't the HR10-250 see the entire space.

Is it because they were paired under the baseline OS and upgrading to "F" OS release is causing problems?

I'm at a lose and outside of FDISKing the second drive, dont' know what else to try.


----------



## Robertjm

Recently I upgraded my Series 2 540 with a WDC300GB drive. I had problems when I tired creating it with -s 200 for the swapfile so I went ahead and used -s 127. The upgrade seems to have worked just fine (so far) and I haven't had any glitches (so far).

After pawing around the Tivo Underground archives I have read multiple mentions of dropping into the Green Screen of Death and basically losing everything on the drive, and the size swapfile I created was good for up to 274gb drives. Is there a way to upgrade the swapfile with all the new recordings that I've done staying intact, or should archive them to my PC first? Since 274gb is so close to 300, and I more often than not delete the recordings after watching them once, do I really need to worry about it? I have yet to get anywhere near to filling the drive up, but I expect to be putting a lot more on the drive though once the Olympics roll around this coming Friday.

Thoughts?

Robert


----------



## proxis

Hello All:

Well? I need help from on of you kind gentlemen. I'm posting here because I believe my problem is swap related.

I have a Humax T800 whose HD was starting to die (freezing, skipping). I am an IT consultant and have no problem handling hardware and Windows based stuff, but I don't know anything about LINUX, not yet anyway. (some UNIX experience though).

So I bought a new drive, a DAM10 (one of the latest ones without the problems) and I also bought the PVT Tools Universal CD because it had MFSTOOLS 2.0 and EVERYTHING on it, supposedly.

So I decided I was going to use Hinsdale's Option #3 for Single - to New Single, larger, - this is the slow option to preserve everything.

So I hooked everything up and ran it:

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -xzpi /dev/hda

except I had it hooked up wwith the above drive letters rreversed hdC being my new drive and hdA being my old drive, which I DON'T THINK should matter right? It was just easier for me to do it this way.

So the command actually looked like this:

mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -xzpi /dev/hdc

It ran OK! everything checked out I got the complete message wiwithow much more recording time I had. I was siked! It was easy.

I shut it down and popped the drive back in, flipped it on, it starting booting and then the GSOD!, it then kept rebooting and repeating.

I started reading posts and soon came across this thread and thought it had to be the swap.

So I started following the instructions for at the top of the thread, except I had no mkswap file on my disk ! (I thought it had EVERYTHING I needed, obviously NOT). I was stumped.

I read another post from a guy who used the above command WITHOUT the -s 127 switch and it worked for him. So I tried it again, and its still doing the same thing.

Some questions:

Am I doing the right thing? using the correct command?
How do I add a swap now? or do I have to do it again with the s -127 switch?
Do I need mkswap and where do I get it?

Some facts:
before doing anything, when the problem first happened, I tried doing a clear and erase everything because I was willing to start over, I don't believe it ever happened because my box would freeze as soon as I tried it. I did see it try come on the screen for a second after my second attempt (without the s -127 switch) but then it just kept rebooting.

At this point, now that I realize I may be able to save everything I want to try, but if I can't I'm not opposed to starting over. How do I do that, if its necessary?

Thanks in advance for any help. My little sons Power Ranger collection is on there and some are rare showings on TV!


----------



## slaponte

How much swap you need is based on the size of the new drive. I am not sure how big is a DAM10, but you need 1MB for every 2GB of total disk space. (so for a 300GB drive you need 150MB of swap).

After the backup/restore with the proper amount of swap, you need to use TPIP to initialize the swap.


----------



## Blackforge

chelman said:


> My computer has a SATA drive and MFSTools gets stuck while booting. What can I do?


You mean a kernel panic? I was getting this on a couple of machines trying to use weaknees LBA48 and PTVUpgrade LBA48 boot CDs.

This is on a Series 2 240..

First I downloaded a Knoppix DVD (you can use the CD version too)

I then went to:
http://mfstools.sourceforge.net/
Then downloaded the MFSTools statically linked binaries and put them on a floppy.

I also downloaded Tpip and put it on the same floppy
http://www.gratisoft.us/tivo/tpip.html

After you boot into Knoppix

cd /mnt/floppy/mfstools-2.0

./mfstool backup -Tao - /dev/hdX | ./mfstool restore -s 300 -r 4 -xzpi - /dev/hdY

I used a 300MB swap in case I add a second 300GB drive.

Then run tpip v1.2:

cd /mnt/floppy/tpip-1.2

./tpip -1 -s /dev/hdY

I'm doing this because one of my drives in my expanded pair of 120GB died. Doing this from the original drive. 80GB to a 300GB drive.

I based all this on using the following
http://www.gratisoft.us/tivo/bigdisk.html
http://www.dasmonkey.net/lba48.html
http://www.newreleasesvideo.com/hinsdale-how-to/index9.html

I'm in the middle of doing this right now so I'm not sure if it works yet. I don't see why not though...

Don't forget to turn DMA mode on your hard drives/CDs in Knoppix!

Status: Yay! It worked!


----------



## he244

I recommend the two drive system. 

If you back up your base system with season passes, etc. and extract the shows via network that you really want to save occasionally, there is minimal risk or hardship really.

Agree, disagree?


----------



## azitnay

There's no question that there's minimal risk if you keep a SP list updated and watch or transfer everything you care about, but that doesn't change the fact that two drives means double the hardship. Two drives in effect at least doubles the (admittedly low) hardship, if for no other reason than on average, you'll have to replace and restore the hard drives twice as often.

Given that we can now easily utilize more than 137GB per drive, coupled with the fact that 320GB drives are pretty dirt cheap nowadays, if 320GB is enough space for you, a single drive makes total sense. If you absolutely must have more space than that in a single TiVo, a two-drive system might make sense for cost reasons at the moment, but as larger hard drive prices come down it'll make less and less sense.

That being said, I'm not personally looking to get into a debate on the subject... Everyone has their own opinion, and no one is really wrong.

Drew


----------



## DanDrasin

Had a power outage, came home, tivo is in death loop hitting the GSOD after a couple seconds on the "just a few more minutes" screen, rebooting incessantly. Googled and found Robert S's post on swap space which sounded like the cause. (I've got a DirectTV/Tive Hughes HDVR2 with a 160GB drive from Weaknees...) So it all kinda made sense.

I followed the directions that Robert S gave and it all went smoothly except that it didn't resolve my problem. (His step E where Tivo is supposed to repair the drive). I was still stuck in the GSOD cycle (let it run for a couple of hours to see if it'd make progress...)

So, i did some more hunting - i mounted the /var partition and read some logs... the tvlog says things like:

String program fsfix
cache at 0x0x5f77dac8, array of 100 entries at 0x0x5f77db50
0.371 seconds: TOTAL for fsfix
fsfix returned non-zero exit code 0x1
fxfix failed to report errors, rebooting...


tverr has endless copies of:

Unable to initialize MFS
Non-deamon Sync() by 128
volume marked as needing database cleanup

So that sounds a lot like the problem that Robert S suggested it was. So of course, the question is "what did i do wrong?" That's probably impossible to answer... but the next question is, can i run fsfix by hand with the drive attached to my linux system?

Dan


----------



## Arcady

Two hours may not be enough time to let the GSOD fix the drive. Let it run over night.


----------



## DanDrasin

Arcady said:


> Two hours may not be enough time to let the GSOD fix the drive. Let it run over night.


It's been running ever since, no progress.
Same stuff showing up in the logs (nothing new...)
Also, contacted Weaknees - they say that the drive that they sent me (which is what was installed) was already at 127M swap size. (and actually jibes with what i think i see in the partition table - though i'm not positive...)

What about running a fsck or some other disk checker. is there a way to rewrite just the partitions that are the OS & app are (not the data) - the answer to this i'm guessing is yes based on how i think it all works, but i haven't been able to piece it together from the how-tos.

(I realize that the likelyhood is that the drive is bad, but before i replace it, i'd like to see if i can recover the data. also, before i invest in another drive, i want to rule out things like the modem, power supply, etc. that seem to also be able to cause this kind of issue (at least some pages say that...))

Any help/advice appreciated.

Dan


----------



## slaponte

I don't think you can use FSCK. The file system check for Tivo is custom. This goes back to the swap thing, if it doesn't have enough swap, it will never end. Is a particularity of the Tivo fsck... Just an opinion. Sorry, don't have hard data on this.


----------



## renatom

I am having the same problem. My tivo reboots after the "just a few minutes more.." message. I am upgrading a tivo from 80gb to seagate 400gb.

It seems a common problem and somehow others got it fixed. 

Sergio, did you change the -s parameter to create your 340hrs?

this is what I used to create the new disk.
mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -r 4 -xzpi - /dev/hdb

another question from a Newbie: When I run again the same command does it erases my target HD or I have to clean it first?

Thanks in advance


----------



## renatom

I forgot to mention: I have 7.3 version...


----------



## luan773

I DL the free MFS Tool 2.0 from Hinsdale, and burned it to CD. All good. But the very 1st command mkdir /mnt/dos gives me an error "could not find kernel image mkdir" . Why? Someone can explain, pls. Thanks. Btw, my Tivo is Series 2 TCD540040. Reason for me to upgrade harddrive is sometimes my TIVO produce bad sound, it's like when you have scratches on CD or tape, very terrible sound. I suspect HD bad and need to replace it, and I would replace it with a Maxtor 250GB. The old Tivo HD is also Maxtor. 

2nd, what if I get a new TCD540080 Tivo and swap the HD, does it keep all the config. from new Tivo to my old Tivo? Is it possible? And what if I wanna put the new 250GB HD on top of the pre-config Tivo HD, to expand space, what I have to do? I'm not Linux geek, so someone can give me a good instruction pls. Thanks very much.


----------



## Soloist64

I have a Series 2 Tivo TCD24004a The hard drive is completely dead. I have a brand new 250 GIG HD Never Used. What are the steps that I need to follow to install the operating system for tivo on this new drive. I don't think I can access the old drive and frankly, I don't want to. Any help would be appreciated.


----------



## kewashi

Soloist64 said:


> I have a Series 2 Tivo TCD24004a The hard drive is completely dead. I have a brand new 250 GIG HD Never Used. What are the steps that I need to follow to install the operating system for tivo on this new drive. I don't think I can access the old drive and frankly, I don't want to. Any help would be appreciated.


Since your old HD is dead you'll have to get a new image. Your best bet is to grab a fresh image from PTV at:

http://downloads.ptvupgrade.com/Merchant2/merchant.mvc?Screen=PROD&Product_Code=ICAKE-S2DT-62

For $20 you can download a fresh image and burn it to your new hard disk.


----------



## wmldwilly

Wow. This is way more difficult than I thought it would be. I'm stuck in the reboot-loop phase of upping the stock drive in an HR10-250 to a 500gb drive. I've used the hindsale guide and mfstools and all it's companions to get as far as:

1) prepare bootable cd.
2) pull drive, add to pc in ide positions reccomened.
3) create small backup on fat32 disk
4) restore small backup to new 500g drive
5) forget to run/not know I needed to do the tpip thing (like 98% of upgraders it seems...)
6) put the drive back in the HR10-250 w/ jumpers back to master,
7) observe reboot loop.
8) put drive back in PC, leaving it set for master after removing fat32 disk used earlier
9) run tpip.

Here's where I'm totally crapped out:

I do:
#tpip -1 -s /dev/hda

and it replies:
#initializing swap partition (version 0) @ <very long number>, Size = 127 MiB

Put it back in the tivo, still boot-loops.

I'm a little confused at why the -1 option still yields the (version 0) message. Looking closer at tpip's useage it mentions --mkswap and --swaptype={0,1}. Upon trying:

#tpip --mkswap --swaptype=1 /dev/hda

I get:
the same message as before, but with (Version 1) in there.

Put it back in the tivo, and still boot-looping.

So my triplet of questions follows - and PLEASE take pity on me - I've been gearing up for this and reading up on it for a week, and have been working on this from 8pm tonite to 5:45AM now when i'm writing this...it's kicking my arse.

q1) what command do I use to once and for all confirm or deny that the swap partition is there at all? I'm getting the impression that tpip is writing these headers to something mythical.

q2) If the swap partition isn't actually present on the drive at all, how do I actually MAKE one? I'm guessing that's going to be ugly and dangerous, and searches have led me thru threads about copying a swap partition from the CD, but it never quite sounds like what will work for me and an HR10-250.

a3) being that this is an hr10-250 running 3.1.5f, do I have to think about "byteswapping" in this whole procedure? I read in one thread that byteswapping is a series 1 thing, not a series 2 thing. I admit freely I don't completly understand what byteswapping is anyway.

Oh dear gawd please somebody...

Off to pass out,

Willy

Here's where it gets weird


----------



## sync23976

Just a thought, though it may not matter, have you tried booting the drive in the Tivo with the jumper set to Cable Select (cs)? That is the way mine came from the factory. I am anxious for you to succeed because I am most of the way through to upgrading my HR10-250 to a 500 gig drive and I created a 400 meg swap during the copying. The new drive boots but I have not tried to tpip the swap yet so I'm sure it is functioning with no working swap file, I'm not sure if the stock kernel will recognize such a large swap. I would like to have the larger swap in case it needs to do a mfscheck but maybe it's not worth the hassle.


----------



## ciper

Even though this thread is ancient I wanted to post something relevant.

My Tivo had two 200gb drives and 127mb of working swap. I stupidly did an "mfsassert -please" not knowing my swap file wasnt large enough. I got stuck in a continuous reboot cycle as fsfix / fsck crashed on every boot.

The interesting thing is that I was able to create an 80mb swapfile on my var partition using only DD for a total of 207mb of swap!
I copied from swap partition 8 and specified to only copy 80 to the file. I then modified rc.sysinit with a "swapon /var/swap" command right after var is mounted (near the beginning). My Tivo accepted this additional swap just fine and the file system check was able to continue.

If I remember right the command I used was 
*dd if=/dev/hdc8 of=/9/swap bs=1024k count=80*
hdc8 being the swap partition of my Tivo's A drive and /9/ being the temporary mount point I used for the var partition (partition 9).

Edit: Although definitely better my Tivo did reboot after staying on the GSOD for 5 hours. Im hoping this is normal and not that I ran out of swap again


----------

