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

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