TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Underground Playground > TiVo Upgrade Center
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 07-31-2002, 10:25 AM   #1
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
Fixes for MFSTools 2.0 problems

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.

Last edited by Robert S : 03-10-2003 at 07:56 AM.
Robert S is offline   Reply With Quote
Old 07-31-2002, 11:05 AM   #2
mtg101
Speaker for the Dead
 
Join Date: Mar 2002
Location: London, UK
Posts: 103
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?
__________________
Thomson 6023 (UK) TiVo 120GB + TurboNET + TiVoWeb + Amstrad SkyD + rf2link
Thomson 6022 (UK) TiVo 80GB + TurboNET + TiVoWeb + Panasonic SkyD + rf2link
mtg101 is offline   Reply With Quote
Old 07-31-2002, 11:27 AM   #3
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
How to fix your TiVo if it gets stuck on a green screen

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:
  1. Boot so we can read the TiVo partitions
  2. Identify the inactive root partition
  3. Prepare the inactive partition as a swap partiton
  4. Renumber the partitions
  5. Allow the TiVo to repair itself
  6. 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.
__________________
Please do not PM me asking for TiVo backups. I don't have any.

Last edited by Robert S : 03-19-2004 at 09:56 AM.
Robert S is offline   Reply With Quote
Old 07-31-2002, 12:14 PM   #4
mtg101
Speaker for the Dead
 
Join Date: Mar 2002
Location: London, UK
Posts: 103
Quote:
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?
__________________
Thomson 6023 (UK) TiVo 120GB + TurboNET + TiVoWeb + Amstrad SkyD + rf2link
Thomson 6022 (UK) TiVo 80GB + TurboNET + TiVoWeb + Panasonic SkyD + rf2link
mtg101 is offline   Reply With Quote
Old 07-31-2002, 12:38 PM   #5
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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
__________________
Please do not PM me asking for TiVo backups. I don't have any.

Last edited by Robert S : 06-17-2003 at 10:40 AM.
Robert S is offline   Reply With Quote
Old 07-31-2002, 08:20 PM   #6
ADent
Registered User
 
Join Date: Jan 2000
Location: Denver, CO
Posts: 2,103
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.
ADent is offline   Reply With Quote
Old 07-31-2002, 08:43 PM   #7
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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.
__________________
Please do not PM me asking for TiVo backups. I don't have any.

Last edited by Robert S : 07-19-2004 at 08:53 AM.
Robert S is offline   Reply With Quote
Old 07-31-2002, 09:44 PM   #8
Cpen
CPenRun
 
Join Date: Jul 2002
Location: Cambridge, MA
Posts: 50
Checked Kernel log file....

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?)?

Last edited by Cpen : 08-01-2002 at 10:23 AM.
Cpen is offline   Reply With Quote
Old 08-01-2002, 12:56 AM   #9
Bill Reeves
Lurker
 
Join Date: Jul 2002
Location: San Carlos, CA
Posts: 802
Re: Checked Kernel log file....

Quote:
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
Bill Reeves is offline   Reply With Quote
Old 08-01-2002, 04:48 AM   #10
mtg101
Speaker for the Dead
 
Join Date: Mar 2002
Location: London, UK
Posts: 103
Quote:
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
__________________
Thomson 6023 (UK) TiVo 120GB + TurboNET + TiVoWeb + Amstrad SkyD + rf2link
Thomson 6022 (UK) TiVo 80GB + TurboNET + TiVoWeb + Panasonic SkyD + rf2link
mtg101 is offline   Reply With Quote
Old 08-01-2002, 10:19 AM   #11
hinsdale
TiVo Forum Special Member
 
Join Date: Apr 2001
Location: Hinsdale, IL, US
Posts: 83
Re: Re: Checked Kernel log file....

Quote:
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.
hinsdale is offline   Reply With Quote
Old 08-01-2002, 01:37 PM   #12
muchmore44
New Member
 
Join Date: Jul 2002
Location: Dallas
Posts: 7
Re: Re: Re: Checked Kernel log file....

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

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

__________________
Hughes DirecTivo and loving it!
120GB -> 106 hours!
muchmore44 is offline   Reply With Quote
Old 08-01-2002, 01:48 PM   #13
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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.
__________________
Please do not PM me asking for TiVo backups. I don't have any.
Robert S is offline   Reply With Quote
Old 08-01-2002, 03:24 PM   #14
DCIFRTHS
I dumped SDV / cable
 
DCIFRTHS's Avatar
 
Join Date: Jan 2000
Location: New York
Posts: 2,075
Quote:
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?
DCIFRTHS is offline   Reply With Quote
Old 08-01-2002, 04:34 PM   #15
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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.
Robert S is offline   Reply With Quote
Old 08-01-2002, 04:44 PM   #16
Cpen
CPenRun
 
Join Date: Jul 2002
Location: Cambridge, MA
Posts: 50
What else can I tell you...

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

Last edited by Cpen : 08-01-2002 at 04:51 PM.
Cpen is offline   Reply With Quote
Old 08-01-2002, 04:54 PM   #17
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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 is offline   Reply With Quote
Old 08-01-2002, 05:19 PM   #18
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
Re: What else can I tell you...

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.
Robert S is offline   Reply With Quote
Old 08-02-2002, 04:37 AM   #19
mtg101
Speaker for the Dead
 
Join Date: Mar 2002
Location: London, UK
Posts: 103
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?
__________________
Thomson 6023 (UK) TiVo 120GB + TurboNET + TiVoWeb + Amstrad SkyD + rf2link
Thomson 6022 (UK) TiVo 80GB + TurboNET + TiVoWeb + Panasonic SkyD + rf2link
mtg101 is offline   Reply With Quote
Old 08-02-2002, 06:54 AM   #20
lemketron
Senior Bit Twiddler
 
Join Date: Jun 2002
Location: Sunnyvale, CA
Posts: 73
Quote:
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
lemketron is offline   Reply With Quote
Old 08-02-2002, 08:01 AM   #21
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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.
Robert S is offline   Reply With Quote
Old 08-02-2002, 05:54 PM   #22
BareMetal
New Member
 
Join Date: Jul 2002
Posts: 4
Quote:
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.
BareMetal is offline   Reply With Quote
Old 08-02-2002, 09:04 PM   #23
sdunne
Registered User
 
Join Date: Jul 2002
Posts: 43
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

Last edited by sdunne : 08-02-2002 at 09:10 PM.
sdunne is offline   Reply With Quote
Old 08-03-2002, 08:11 AM   #24
klincoln
New Member
 
Join Date: Aug 2002
Location: Washington, DC
Posts: 3
Cool MFSTools 2.0 Success

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

Last edited by klincoln : 08-03-2002 at 09:44 AM.
klincoln is offline   Reply With Quote
Old 08-03-2002, 05:04 PM   #25
DCIFRTHS
I dumped SDV / cable
 
DCIFRTHS's Avatar
 
Join Date: Jan 2000
Location: New York
Posts: 2,075
Re: MFSTools 2.0 Success

klincoln: Very nice report. It's easy to read with great attention to details. Welcome to the forum.
DCIFRTHS is offline   Reply With Quote
Old 08-04-2002, 03:26 PM   #26
jhburke
New Member
 
Join Date: Aug 2002
Location: Darien, IL
Posts: 5
Smile

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
jhburke is offline   Reply With Quote
Old 08-04-2002, 04:15 PM   #27
klincoln
New Member
 
Join Date: Aug 2002
Location: Washington, DC
Posts: 3
Arrow MFSTools 2.0 Success...and...

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
klincoln is offline   Reply With Quote
Old 08-04-2002, 06:01 PM   #28
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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.
__________________
Please do not PM me asking for TiVo backups. I don't have any.
Robert S is offline   Reply With Quote
Old 08-04-2002, 10:20 PM   #29
jhburke
New Member
 
Join Date: Aug 2002
Location: Darien, IL
Posts: 5
Copy good 128M swap file

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
jhburke is offline   Reply With Quote
Old 08-04-2002, 10:35 PM   #30
Robert S
Registered User
 
Join Date: Jul 2002
Location: Cambridgeshire, UK
Posts: 9,725
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).
__________________
Please do not PM me asking for TiVo backups. I don't have any.
Robert S is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVo® is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 10:16 PM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |