Continual rebooting after upgrade attempt

[bfoote]

I have an old Series 2 140060 with the origional 60 gig drive plus a 80 gig I had added a couple of years ago. Software version 7.2. It started freezing up on occasion so I decided to replace both drives with one new 160 gig. I tried two different methods:

Hinsdale instructions/mfstools 2.0 CD - created small backup, then restored it to the 160 (which was showing up as 127 gig, which would have been fine - I don't need much space) and went on to the test phase.

Weaknees CD, copying the old drives onto the new one like this:
mfsbackup -f 9999 -so - /dev/hda /dev/hdc | mfsrestore -s 127 -r 4 -zpi - /dev/hdb

Both gave the same results - the tivo starts up, shows "Welcome. Powering up..." for a few minutes, then "Almost there. Just a few minutes more..." for a few minutes with lots of disk activity, then it reboots and starts again. It never gets past the almost there screen.

Just for fun I put the old drives back in and it starts up just fine, so it doesn't appear to be a hardware failure. I also tried using a different drive (300 gig) and it behaved the same as the 160.

Is this because I've already upgraded the thing once, or am I doing something wrong? Do I need to find a virgin image or use instantcake?

[funtoupgrade]

Try removing the -r 4 switch which is just for hard drives 400GB and larger.

[bfoote]

Try removing the -r 4 switch which is just for hard drives 400GB and larger.

Just tried it, no change. It still keeps cycling.

[HomeUser]

Should of worked with or without the -r4 flag, Put the 160 Gig drive back in the PC after failed boot.

Check the drives configuration with mfstools info /dev/hdb
Mount the var partition and Look at the log files.

mkdir /mnt/tivo
mount /dev/hdb9 /mnt/tivo
ls -lsrt /mnt/tivo/log
cat /mnt/tivo/log/filename.typ

[bfoote]

I used the 300 gig drive last, so here's the data from it. I copied this by hand so there are probably typos.

Info:
The MFS volume set contains 4 partitions
/dev/hda10
MFS Partition Size: 256MiB
/dev/hda11
MFS Partition Size: 24790MiB
/dev/hda12
MFS Partition Size: 256MiB
/dev/hda13
MFS Partition Size: 31483MiB
Total MFS volume size: 56785MiB
Estimated hours in a standalong TiVo: 57
This MFS volume may be expanded 4 more times


The following appears in the "kernel" file:
Illegal read at 000000a0
do_page_fault #2: sending signal 11 to myworld(200)
$0 : 00000000 b001b401 000000a0 10042698 000000a0 7fd7f3bo 00000000 00000000
(repeat for $8, $16, $24,
Hi: 00000000
Lo: 00000021
epc: 02a2b188 Tainted: P
Status: 8001b413
Cause: 00000008
More numbers
Scanning for phase4 repair scripts
Tmk Fatal Error: Activity TvVideoGutsActivity <200> strayed!
pc 0x2a2b188 status 0x8001b413 cause 0x000008 bva 00000000 hi 00000000 lo 0x000021
R00 to R31 (numbers)
paste the following into a shell to get a backtrace...
bt -1 /tvbin /tivoapp <<END OF BT
build b-7-2-2-mr @231480 2006.04.05-2145 release-mips [SET_7_2_2_OTHER]
pack 7.2.2b-oth-01-2
read 0x00400000 /tvbin/tivoapp
read 0x02000000 /lib/libc.so.6
read 0x02200000 /lib/libm.so.6
read 0x02400000 /lib/libpthread.so.0
read 0x02600000 /lib/libutil.so.1
read 0x02800000 /lib/libtvutil.so
read 0x02a00000 /lib/libtmk.so
read 0x02c00000 /lib/libtvstructures.so
(several more of these)
read 0x02ac8000 /lib/libcaudio.so
0x02ab188 (series of 27 more number sequences)
END_OF_BT
Tmk Fatal Error: Activity TvVideoGutsActivity<200>: unexpected signal 11
Running boot Stage G_PostApplication scripts
rc.sysinit is complete

Much of this sequence is repeated in the file "tverr" then this appears:
Activity TvVideoGutsActivity[200]: Tmk Fatal Error: Activity TvVideoGutsActivity<200>: unexpected signal 11
Activity TvVideoGutsActivity[200]: Tmk Fatal Error: Thread died due to signal 11
Activity TvVideoGutsActivity[200]: Invoking rule 834: rebooting system

[HomeUser]

Searching TiVo Community "Invoking rule 834: rebooting system" Appears to be an out of indexing memory type of error. Try adding the extra partitions by expanding the 160 or 300G drive with mfsadd. I an thinking it may have something todo with the free space calculation because the indexs to the recordings are still there (even tho the recordings are not) the total computed space used may exceed the total space. Of corse I am probably way off if this were true seems there would be more users with the problem.

[bfoote]

You rock! I used mfsadd, put the drive back in, and it booted right up. It's reporting the full recording size and everything else seems to be working.

Hopefully the new drive will also solve the freeze issue.

[HomeUser]

Congratulations, Hopefully your freeze problems are history ... If not you could threaten the 140 with transferring its's lifetime to a shinney new Series3 :)