PDA

View Full Version : Suggestions / Wishlist for next version?



thomson
17-11-2004, 07:19 PM
Thought I would start with a possible safe way of handling palmod configuration changes and upgrades. The following is a mechanism which uses a type of "watchdog" to see if palmod has caused a crash... and if so, it will revert back to a known good configuration.

Firstly you should backup your existing configuration, as one assumes that this is a working one:


# rw
# cp /etc/palmod.conf /etc/palmod-good.conf
# cp /lib/modules/palmod.o /lib/modules/palmod-good.o
# ro


Then the following code should replace the "insmod -f /lib/modules/palmod.o `cat /etc/palmod.conf`" line in /etc/rc.d/rc.arch (somewhere near line #88):


if [ -f /var/log/palmod.watchdog ]; then
echo "Watchdog file found, using last good configuration"
/bin/rm /var/log/palmod.watchdog
sync;sync;sync
insmod -f /lib/modules/palmod-good.o `cat /etc/palmod-good.conf`
else
/bin/date >> /var/log/palmod.watchdog
sync;sync;sync
# Run palmod_config to set palmod options
insmod -f /lib/modules/palmod.o `cat /etc/palmod.conf`
fi


The watchdog flag file should be removed once we are sure everything is alright. This can be either through cron, or more simply at the end of the /etc/rc.d/rc.sysinit.author script:


# Remove palmod watchdog flag
if [ -f /var/log/palmod.watchdog ]; then
echo "Removing watchdog file"
/bin/rm /var/log/palmod.watchdog
fi


To check which configuration you are running you can either check /var/log/kernel or have a look at the output of "lsmod".

Note: if anyone does get stuck in a boot-loop due to a bad palmod.o, the easiest way of resolving it is to use a serial cable to boot into the monitor and alter the boot parameters to change TV_STD from PAL to NTSC - This will skip the palmod phase of the bootstrap. Once it has come up you will be able to telnet in and fix the problem

thomson
17-11-2004, 07:33 PM
The easiest way of adding authentication to the telnet daemon running on the TiVo is to create an authentication script containing the following, and call it /var/hack/bin/pwd_prompt.sh:


trap "exit" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
echo -e "TiVo System (3.0)\n"; sleep 1
echo -n "Login Name: "; read login; sleep 1
echo -n "Password: "; stty -echo; read password; stty echo
echo ""
[ "$login" != "oztivo" -o "$password" != "oztivo" ] && {
echo "`date` Login: $login, Passwd: $password" >> /tmp/bad_logins
exit
}
unset login password
trap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


And then place the following line at the start (very first line) of your ~/.bash_profile:


. /var/hack/bin/pwd_prompt.sh


Now whenever somebody telnets to the TiVo they will have to login as oztivo with a password of oztivo. If you wish to provide a back-door that does not require authentication then you should add the following to one of your startup scripts:


/sbin/tnlited 10023 /bin/bash &


This means that anyone telneting to port 10023 (rather than the standard 23) will go directly to a shell prompt and not run their ~/.bash_profile login script.

thomson
18-02-2005, 12:31 PM
To enable job control via serial cable connections you will need to remove the shondss.sh call in the rc.sysinit.author script, and comment out any lines that may exist near the bottom of the rc.sysinit script that look like "/bin/bash </dev/ttyS3 >& /dev/ttyS3 &", and place the following lines at the very bottom of the rc.sysinit script:



# ShellOnDDS with job-control
exec < /dev/ttyS3 >& /dev/ttyS3
while :; do
/bin/bash -login
done


After a reboot you will be able to use Ctrl-Z (background) and Ctrl-C (interrupt) when connecting via a serial cable.

thomson
20-03-2005, 08:37 AM
By inserting the following lines before additional applications are loaded by rc.sysinit.author you can ensure that all additional modules will have minimal effect on any TiVo process. This will reduce the likelyhood that poorly written modules (or those requiring a lot of CPU/MFS access) will cause glitches during playback.



# Run the following at low priority
[ -x /var/hack/bin/setpri ] && /var/hack/bin/setpri fifo 1 $$


Anything started after the call to setpri has been made will now run at a priority level of 1 (lowest) rather than the default of 25. Of course you will need the (mbm) setpri binary.

neilp
07-04-2005, 02:32 PM
I'd quite like to see a change to the order the various systems start up - I managed to get my Tivo in a knot and would have like to telnet to it to find out what was going on. Didn't have to reimage but got v close...

Maybe starting the networking & telnet/tivoweb stuff very early on would be helpful so you could see/fix the state of the box if it froze?

T1voZA
21-10-2005, 05:42 PM
I have made the request in http://minnie.tuhs.org/twiki/bin/view/Install/RequestsForNextImage as well but for completness sake I will add it here.

I know this request isn't needed by the ozTivo community but for the other communities (TivoZA, nzTivo & nlTivo) already using the ozTivo image the following changes would really be great. These changes would allow our users to use the ozTivo installation as is without needing to make any special changes to fix clock warping or access to the emulator (aside from commenting in and out in rc.sysinit.author).
In rc.sysinit.author, comment out the following line:

emuProxy2 -s 131.244.9.101 &
and replace it with (assuming you decide to use emuProxyZA):

emuProxyZA -s minnie.tuhs.org & #ozTivo emulator
#emuProxyZA -s tivoza.nanfo.com & #TivoZA emulator
#emuProxyZA -s 64.151.65.200 & #nzTivo emulator: Original
#emuProxyZA -s 210.48.107.133 & #nzTivo emulator: Orac
#emuProxyZA -s hydra.demon.nl & #nlTivo emulator
Making the above changes allows users of other emulators to easily comment out the first line and uncomment their relevant guide provider.

Adding the following lines to '/etc/postcodezones' would prevent clock warping without causing any problems for the ozTivo community:

12345 Africa/Johannesburg
54321 Africa/Johannesburg
02113 Pacific/Auckland
02115 Pacific/Auckland
01014 Europe/Amsterdam
02500 Europe/Amsterdam
02612 Europe/Amsterdam
02671 Europe/Amsterdam
08004 Europe/Amsterdam
09000 Europe/Amsterdam
I have checked the above postal codes against the existing ones in '/etc/postcodezones' and there are no conflicts.

These changes would very much be appreciated, by all 3 communities. If you have any question or would like to discuss these changes please feel free to post them on the following forum topic:
http://tivoza.nanfo.com/forum/viewtopic.php?t=14