Suggestions / Wishlist for next version?

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:

Code:

---

# 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):

Code:

---

    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:

Code:

---

# 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

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:

Code:

---

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:

Code:

---

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

Code:

---

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

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:

Code:

---

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

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.

Code:

---

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

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?

I have made the request in http://minnie.tuhs.org/twiki/bin/vie...tsForNextImage 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:

Code:

---

emuProxy2 -s 131.244.9.101 &

---

and replace it with (assuming you decide to use emuProxyZA):

Code:

---

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:

Code:

---

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