7.2.2 tivosh flakey

[Narf54321]

Been working this weekend to update two of my TCD240 units from system software v4.0.1b to the current 7.2.2 (with the undelete folder).

After pulling my hair out trying to get NCID and even simple tools like k63's DelTivomanMenuAd.tcl (http://www.dealdatabase.com/forum/showpost.php?p=221072&postcount=22) I keep getting crash+reboots. I even stripped down a tcl script to a simple dbopen/close which normally works fine, but under v7.2.2 crashes the machine.

Even the simplest cli pass to tivosh now crashes:
4.0.1b Tivo > echo ? | tivosh
invalid command name "?"

7.2.1 tivo > echo ? | tivosh
invalid command name "?"

But, 7.2.2 crashes out with the following (on two seperate units):
7.2.2tivo > echo ? | tivosh

assert: Tmk Assertion Failure:
assert: AutoLock, line 128 ()
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 TmkAssertionFailure[324]: : (AutoLock, line 128
())
Tmk Fatal Error: Thread (null) <324> strayed!
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: Tmk Fatal Error: Thread (nul
l) <324> strayed! (block timestamp 0)
Paste the following into a shell to get a backtrace...

bt -t /tvbin/tivoapp <<END_OF_BT
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: bt -t /tvbin/tivoapp
tcd 1
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: tcd 1

hpk Series2
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: hpk Series2

read 0x00400000 /tvbin/tivoapp
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x00400000 /tvbin/tiv
oapp

read 0x02000000 /lib/libc.so.6
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x02000000 /lib/libc.
so.6

read 0x02200000 /lib/libm.so.6
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x02200000 /lib/libm.
so.6

read 0x02400000 /lib/libpthread.so.0
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x02400000 /lib/libpt
hread.so.0

read 0x02600000 /lib/libutil.so.1
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x02600000 /lib/libut
il.so.1

read 0x02800000 /lib/libtvutil.so
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x02800000 /lib/libtv
util.so

read 0x02a00000 /lib/libtmk.so
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x02a00000 /lib/libtm
k.so

read 0x02c00000 /lib/libtvstructures.so
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x02c00000 /lib/libtv
structures.so

read 0x2aaa8000 /lib/ld.so.1
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x2aaa8000 /lib/ld.so
.1

read 0x2ab04000 /lib/libhpkoss.so
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x2ab04000 /lib/libhp
koss.so

read 0x2ab50000 /platform/lib/libhpkhl.so
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x2ab50000 /platform/
lib/libhpkhl.so

read 0x2abf8000 /platform/lib/libhpkll.so
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x2abf8000 /platform/
lib/libhpkll.so

read 0x2ac3c000 /lib/libdl.so.2
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x2ac3c000 /lib/libdl
.so.2

read 0x2ac80000 /lib/libcdaudio.so
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: read 0x2ac80000 /lib/libcd
audio.so

0x02a7e85c 0x02a53060 0x02a44620 0x02a4d79c 0x02a55288 0x02a4c978 0x02a5ac58
0x02a59c08 0x00d10844 0x00d10508 0x0076b2e4 0x006fe154 0x0201455c
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: 0x02a7e85c 0x02a53060 0x02
a44620 0x02a4d79c 0x02a55288 0x02a4c978 0x02a5ac58 0x02a59c08 0x00d10844 0x00d10
508 0x0076b2e4 0x006fe154 0x0201455c
END_OF_BT

Tmk Fatal Error: Thread (null) <324>: assertion failure
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: Tmk Fatal Error: Thread (nul
l) <324>: assertion failure
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: Tmk Fatal Error: Thread died
due to signal -2
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 03:39:01 Thread (null)[324]: Invoking rule 834: rebooting
system
Logger not initialized! Logging to stdout:


I'm guessing that they took out a bunch of error-handling from tivoapp. But it works in the old 7.2.1, so its very frustrating. Anyone else having trouble with 7.2.2?

EDIT: Fixed below. I had inadvertently set TIVO_ROOT and the TiVos didn't like it.

[ocntscha]

Your example works here. You're for sure echoing it a question mark and not a single character file name right?

root@tivo:/tmp bash# echo $SwSystem
7.2.2-oth.01-2

root@tivo:/tmp bash# echo ? | tivosh
invalid command name "?"

root@tivo:/tmp bash# echo ?
?

root@tivo:/tmp bash# touch R

root@tivo:/tmp bash# echo ?
R

root@tivo:/tmp bash# rm R

[Narf54321]

OK, it s worse than I thought. Apparently any invocation of tivosh crashes my two 7.2.2 TCD240 machines.

I'm using the killhdinitrd 7.2.2 kernel with these, one unit with a superpatched 7.2.2 tivoapp, and this one with a stock tivoapp (plus just the noSCO fix).

> uname -a
Linux (none) 2.4.20 #1 Tue Feb 14 20:55:02 PST 2006 mips unknown

> echo $SwSystem
7.2.2-oth.01-2

> tivosh
assert: Tmk Assertion Failure:
assert: AutoLock, line 128 ()
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 16:07:59 TmkAssertionFailure[341]: : (AutoLock, line 128
())
Tmk Fatal Error: Thread (null) <341> strayed!
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 16:07:59 Thread (null)[341]: Tmk Fatal Error: Thread (nul
l) <341> strayed! (block timestamp 0)
Paste the following into a shell to get a backtrace...



I'm going to try with the 7.2.1 tivoapp and then possibly with the 3.1.5 killhdinitrd kernel to see if they make any difference.

[Narf54321]

Trying to jam 7.2.1 tivoapp didn't work. Machine won't finish booting. Putting 7.2.2 tivoapp back in place.

I'm going to try the 3.1.5 kernel next.

[Narf54321]

Put the 7.2.2 tivoapp back in place. With the 3.1.5 kernel, the machine boots up. That's at least a good sign. Invoking tivosh still crashes, though

> uname -a
Linux (none) 2.4.20 #22 Fri Feb 20 18:19:25 PST 2004 mips unknown

> tivosh
assert: Tmk Assertion Failure:
assert: AutoLock, line 128 ()
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 16:17:22 TmkAssertionFailure[315]: : (AutoLock, line 128
())
Tmk Fatal Error: Thread (null) <315> strayed!
Logger not initialized! Logging to stdout:
TmkLogger: <129>Apr 10 16:17:22 Thread (null)[315]: Tmk Fatal Error: Thread (nul
l) <315> strayed! (block timestamp 0)
Paste the following into a shell to get a backtrace...

Since both of these units have over 300hrs of crap on them , each its going to be difficult to extricate myself from this mess. It'll take awhile.

I'm still not sure exactly what is wrong, but the fact that both of these TCD240 units 'broke' when going directly from 4.0.1b to 7.2.2 should serve as a warning to others.

[Jamie]

I've seen no problems with tivosh on 7.2.2.

Most "tivosh always crashes" problems are due to an incomplete environment. I assume you've checked that and that your tivosh's are being started in a shell that has the full environment as set by the tivo rc.sysinit scripts.

Note that the failure is in AutoLock(). Does that ring any bells? Isn't there an AutoLock feature in the tivo software; something to do with parental controls? Do you happen to have that turned on? Just grasping at straws.

[Narf54321]

Jamie, I went into parental controls, which to my knowledge weren't activated. I remember playing with them months ago but found it was too cumbersome to be useful.

Anyway, under 7.2.2 Settings -> Parental Controls I found the Parental Controls were indeed turned ON (after the software upgrade) and something called Auto Re-lock was also ON. (However, there were no Locked Channels set at all) I've turned off both and I'll try it out.

[Jamie]

Anyway, under 7.2.2 Settings -> Parental Controls I found the Parental Controls were indeed turned ON (after the software upgrade) and something called Auto Re-lock was also ON. (However, there were no Locked Channels set at all) I've turned off both and I'll try it out.I doubt that is the problem, but it doesn't hurt to try it.

References to AutoLock seem to mostly come from /lib/libtmk.so, and possibly relate to /etc/TmkLinuxMempoolInitLock.

[Narf54321]

No good, still crashes even after turning off the parental controls. Thanks anyway for the suggestion.

Most "tivosh always crashes" problems are due to an incomplete environment. I assume you've checked that and that your tivosh's are being started in a shell that has the full environment as set by the tivo rc.sysinit scripts.

Both of these machines had 300GB drives put in and were running 4.0.1b for months, despite the consequences (http://www.dealdatabase.com/forum/showthread.php?t=41782). Actually this one, dubbed Movies/Tivo2 in fact has dual 300b drives, which will be a nightmare to backup.

This current one only had 4.0.1b stored in MFS, so I had to undo the ROdata key blocks to allow Tivo Inc to send down the 7.2.2 upgrade.


I used the installSw.itcl trick to directly install 7.2.2-oth.01-2-140 from MFS storage and then put the new patched kernel and AlphaWolf's tivotools in place. Since the update came direct from Tivo, I assume its about as 'official' as it can get. I wonder if there is something in the 7.2.2 archive missing which 7.2.1 includes, and going direct from v4.0.1b to 7.2.2 misses some things.

Currently this is what I've got for Tivos (all Lifetimed as of last month):

Tivo1 TCD240: 7.2.2 superpatched with broken tivosh, upgraded direct from 4.0.1b
Tivo2 TCD240: 7.2.2 noSCO patch, also broken tivosh, upgraded direct from 4.0.1b
Tivo3 TCD240: 4.0.1b working fine, except for no guide data.
Tivo4 TCD240: 7.2.1 working fine (upgraded direct from 4.0.1b no problem).

(Oh yeah, plus a TCD540 with PROM mod running 7.2.1 but it is not plugged in right now).

The Parental Lock thing caught me by surprise. I wonder if that might have also broken the install somehow.

I'm thinking I'm going to have to go through the 7.2.1 unit with a fine-toothed comb and see what might be different. Unless somebody has some clues to look for.

[Narf54321]

Interesting...

I removed my rc.sysinit.author file and added a quick tnlited at the bottom of rc.sysinit (for access). I also noted some lock files in /var/tmp so I blew away /var completely rm -fr /var/*.

Without my rc.sysinit.author file, I can now get into the tivosh CLI. Something in there must be screwy.

Thanks ocntscha and Jamie for setting me on the right track.

[Narf54321]

I finally tracked down the problem.

Apparently at some point while putting together the new rc.sysinit.author file, I somehow managed to end up setting this environment variable:

export TIVO_ROOT=/dev/hda4

Apparently, the Tivo units do not like this variable being set this way, especially not to a device. For the time being, problem solved.

[eastwind]

I finally tracked down the problem.

Apparently at some point while putting together the new rc.sysinit.author file, I somehow managed to end up setting this environment variable:

export TIVO_ROOT=/dev/hda4

Apparently, the Tivo units do not like this variable being set this way, especially not to a device. For the time being, problem solved.
I've only used this on DTiVos, but I set TIVO_ROOT="/"

just my 2 cents worth..

ew

[Jamie]

I've only used this on DTiVos, but I set TIVO_ROOT="/"

just my 2 cents worth..

ewIt's normally set to the empty string. On 7.x, it's set in the StageA SetupCoreEnvironement startup script.

TIVO_ROOT was the first thing I thought of that might cause this problem, but when I unset it (which is what I thought might be the OP's situation), I got a different error (couldn't find init.tcl).