# Slice upgrade automation tool



## Hichhiker (Apr 21, 2002)

*What is it?*

Yet another slice upgrade automation tool. I needed to upgrade a bunch of Zippered Dtivos from 6.2 to 6.2a and found that you need to either do it by hand, or buy a $20 script (Slicer from PTV). Given how little there is to do and the fact that I am pretty comfortable with script writing, I written my own and decided to share it. I am guessing this will work for many slice updates but since I only have Zippered DTivos, I can't test it. Since I wrote it, BTU came up with a simpler and arguably better way to do 6.2 to 6.2a upgrade without using slices, but I am hoping this tool may come in handy for other slice upgrades.

*What is the current status?*

BETA - i.e. it was run by me on 4 Zippered DTivos to upgrade from 6.2 to 6.2a for DST patch. and it seems to work great. But I cannot guarantee it for any other upgrade as it has not been tested yet. If you want to test it, please post your findings here. I would want to hear from a few experienced people using it before giving it a full green light for general consumption. If you are not comfortable with that, I'd suggest using BTU's script for 6.2->6.2a upgrade. It is not a slice upgrade but it is better tested way to do 6.2a it as of now.

*Pre-requisites?*

You need to have tar and patch binaries installed. Both come with busybox so if you have that installed, you are good. Superpatch is an optional add-on.

*Usage:*

Step 1: Copy files to your tivo, I created a directory under /hacks called sliceUp - but actual directory should not matter

Step 2 (optional): If you want to, edit "copylist" file - it contains list of all directories and files to move from old partition to new. If you list a directory there, all of its contents and subdirectories will be moved. If you list a file it will be picked up. Globs are acceptable too. If you are not planning to change copylist, you don't actually need it there.

Step 3 (optional): If you want to superpatch your new version find following files and put them into same dir:
* superpatch-67all-NutKase-1.2.tcl
* superpatch-1.2to1.7.diff.txt

If you dont know where to find these, google is your friend

Step 4: Run the script (./sliceUp)
The script will complain that it does not know what you want to upgrade to and show the list of available slices. This step is really just so that you can make sure the slice is there. If you know the name you can skip this. Script will not allow you to run with a slice name that is not in the system.

Step 5: Run the script again with the slice name (for example ./sliceUp 6.2a-01-2-321) and reboot

Step 6(optional): Log back in and run the superpatch - it is in the root directory (/superpatch-678all-NutKase-1.7.tcl ) and reboot again.

*When things go wrong...*

Well, if your tivo does not boot after this, its most likely you messed up the boot partition. Recover by putting the drive into a PC with a boot disk. Any MFSTools type disk should do as long as it contains bootpage tool. I use the PTV Disk I downloaded for Zipper upgrade.
_
*UPDATED based on BTU's comments:*

It has come to my attention that there are two major versions of "bootpage" binary with slightly different options. Before you begin, check what version of "bootpage" is on your CD. Do this by running "bootpage -ba /dev/hdX" (where X is your hard drive letter), if you get 4/7 or 7/4 output instead of 3/6, 6/3, use the alternative commands. If there is not alternative command, the primary one should be safe to use._

Run


```
bootpage -f /dev/hdX
```
Alternate

```
bootpage -Cf /dev/hdX
```
where X is the letter corresponding to the port you plugged in the drive as (a is primary master, b is primary slave, etc)

Run 

```
bootpage -p /dev/hdX
```
Record the output ,

Run 

```
bootpage -P "STRING" /dev/hdX
```
Alternate:

```
bootpage -CP "STRING" /dev/hdX
```
where STRING is what you got from the -p command. _The only thing you need to change in this string is the number of the root partition. if it is 4, use 7 and if it is 7, use 4_

When done, use following command to verify you are done:


```
bootpage -bp /dev/hdX
```
You should be able to now boot back into pre-update OS

NOTE: you can also do same thing via telnet or serial if your Tivo is bootable.

*Reference*

* If a kernel backup with name hacked-kernel.backup exists in same directory as the script, it will be used instead of copying the one in current boot partition.

* Only first 2MB of the kernel is copied to accommodate some 2MB boot partitions which MFS seems to create sometimes. It seems to work just fine.

* The filenames for superpatch and its patch are hardcoded for now. I will try to fic it later, but if you need something other than superpatch 1.7, you are on your own. If superpatch files are not there, the script will still run just fine

* Script forces an emergency upgrade mode, which disables some sanity checks and allows you to install the upgrade even if the system thinks its already installed. Keep that in mind. You can comment out the line that does it, its in the first few lines of the script

* I tried to comment the code as I wrote this, but for the most part this was a quickly written script, so it is not so polished. If there is enough interest in it, I might clean it up. I mostly posting it so people can play with it and modify it to their needs and maybe inspire more of this sort of automation.

*Known to work on*

* Zippered 6.2 to 6.2a upgrade

*Known to not work on*

* ???

Please help me to fill the last two sections up. Post your experience.

-HH

Version history:


0.93 -- Initial version

0.94 - Fixed for 2mb boot partitions

Copied BTU's solution to 2mb boot partitions

0.95 - Another fix for 2mb paritions, rw, check tools

Looks like I should not copy other's code without testing it. Reverted changes in 0.94 (they did not work) and did my own version. Successfully tested

Also changed:
1 - testing for presence of tar and patch
2 - Added force to RW root instead of assuming its done
3 - Shortened the name of script to sliceUp

0.96 - Added /etc/passwd and /etc/group to the default copylist to support cron

No other changes


----------



## kenr (Dec 26, 1999)

I won't be trying this script but it's sure interesting as an educational tutorial for what needs to be done. I suspect if you use the script, you'll end up with a "pending restart" the next time the systems tries to call home.

Try running the attached script to see if the active sw version matches the configed version.


----------



## Hichhiker (Apr 21, 2002)

kenr said:


> I won't be trying this script but it's sure interesting as an educational tutorial for what needs to be done. I suspect if you use the script, you'll end up with a "pending restart" the next time the systems tries to call home.
> 
> Try running the attached script to see if the active sw version matches the configed version.


I am not sure what you mean? The upgrade done by this script is the standard slice upgrade, so the system is aware of new software version. (which is why I had to overwrite it when testing with Emergency Upgrade mode)

If I am missing something please explain more. As my tivos are zippered, they are not calling home, so I am guessing I won't see this. I am however curious about it.

Thanks for the script, btw.

-HH

P.S., Just checked, no pending restart on my tivos.


----------



## Hichhiker (Apr 21, 2002)

Kenr, 

I've been examining your script and trying to understand the issue. 

It seems that when doing slice upgrade /State/ServiceConfig is wiped. There are a number of fields missing from there including SwSystemName.

Now, from looking at your old posts I noticed you came across this issue. 
How did you resolve it? What process populates this data? Is it as simple as writing the value in there or is it more involved?

Again, it seems to be not an issue to zippered tivos as they do not call home, but I would love to resolve this for other users of the script.

I also looked at number of threads mentioning this method and never seen any mention of this. Other than your post. :-/

Let me know.

-HH


----------



## BTUx9 (Nov 13, 2003)

As I understand it, when the tivo calls the mothership, one of the things that happens is that SwSystemName is set to the s/w version that the mothership THINKS that tivo should be running at (and possibly downloading the slices to attain it). I haven't heard of SwSystemName being CLEARED by a call... not sure what would cause that.

The "pending restart" is an indication that the value of SwSystemName isn't the same as the ACTIVE s/w version... this state results in regular reboots until the 2 are the same.


----------



## Hichhiker (Apr 21, 2002)

BTUx9 said:


> As I understand it, when the tivo calls the mothership, one of the things that happens is that SwSystemName is set to the s/w version that the mothership THINKS that tivo should be running at (and possibly downloading the slices to attain it). I haven't heard of SwSystemName being CLEARED by a call... not sure what would cause that.
> 
> The "pending restart" is an indication that the value of SwSystemName isn't the same as the ACTIVE s/w version... this state results in regular reboots until the 2 are the same.


That makes more sense. Never mind about clearing it, BTW, I forgot that I did clear-and-delete everything on the box I was testing and since it is Zippered it never made another call :-/

But just in case, I altered Kenr's script to overwrite SwSystemName to same value as active. As I have not experienced this issue and I don't know everything about it, I don't know if it will truly fix it, but it appears to.

-HH


----------



## Hichhiker (Apr 21, 2002)

Posted 0.96. Added passwd and group files to the default filelist to support cron.

If you have upgraded with sliceUp version prior to 0.96 and run into problems with cron,you can manually copy the files from old root or use this post to re-create these files. Remember to do "rw" before editing root filesystem.

-HH


----------



## kyb (5 mo ago)

BTUx9 said:


> As I understand it, when the tivo calls the mothership, one of the things that happens is that SwSystemName is set to the s/w version that the mothership THINKS that tivo should be running at (and possibly downloading the slices to attain it). I haven't heard of SwSystemName facility management being CLEARED by a call... not sure what would cause that.
> 
> The "pending restart" is an indication that the value of SwSystemName isn't the same as the ACTIVE s/w version... this state results in regular reboots until the 2 are the same.


try to restrat the system again, then reboot the swsttemname synapsis.


----------

