PDA

View Full Version : Scripts and methods for Series2 software upgrades (split from: upgrade script debate)



AlphaWolf
03-03-2004, 05:15 PM
FWIW, we could easily have things like they were in the old days whereas you could cleanly/easily upgrade your tivos sw version with tivolator-alike distributions. (also gain some new functionality, read below)

What it would involve is somebody writing a variant of installSw.itcl that would work a bit like the following:

- dbload a given set of slices into MFS
- detect a monte configuration (if present, prepare to configure the new partition setup accordingly, if not, treat it as a prom modded tivo, or S1 tivo)
- install slices from swsystem
- detect the new kernel type, and killinitrd it appropriately
- adjust partition layout for monte
- adjust the rc.sysinit in the new root to execute rc.sysinit.author, and copy the following files/dirs from the old root to the new root (if present): /.profile, /etc/rc.d/rc.sysinit.author, /hack /tivo-bin /tivoweb-tcl (this automatically preserves all basic hacks that most people would have)
- dd over the 31u5 kernel and rootfs to the old root partitions for monte (if necessary)
- create fake SA/DVD tivo loopsets and adjust swsystem slice to match a make/model it wasn't intended for (if necessary)

Depending on how that script/suite is written, it could be distributed publicly, and be written for compatibility with just any tivo hardware/software version, for an upgrade to any software version. The slice files themselves (including a decrypted swsystem slice) could be distributed as packages on emule. For those out there who want 4.0 on their dtivo, this would also allow you to upgrade to it without losing your recordings, plus you would no longer need to find an uber sized disk image, rather instead only download a ~20 meg slice package.

I would do it myself, but I no longer have time for big projects like these :D Just planting a seed for somebody else I guess.

cobelli
03-03-2004, 05:38 PM
nice try corbelli

What the hell is that supposed to mean! Honestly guy, get over it.

- Cobelli

And while I hate playing into bought's games, I've attached what I've done just to prove I'm not full of sh*t. As I said, it's not much. It does pretty effectively detect the system setup, check if they've got hacks installed and preserve them OR reinstall them, prepare the ip address and drivers, and some other things. I had envisioned the process happening in three stages, and this would be the first sort of preparations stage of it. I've included the todo file so you can get a glimpse into my thought process, but I really don't know how helpful any of this will be, especially since, according to bought, better programs allready exist. If you have any questions about it, PM me, but as always, use at your own risk.

Sleeper
03-04-2004, 12:35 PM
I have been pondering similar solutions. A few ideas are:

a) Install the U5 fs/kernel on partitions 2/5

b) Install all the hacks on another partitions alltogether and mount it up as /usr/local or var/hack. A modified version of Alldeadhomiez' repartition tool could be used.

c) Combination of a and b. Except create/modify a larger partition (currently Apple_Free) where the romfs is currently located and store hacks there.

Having u5 fs/kernel on 2/5 would allow the natural upgrade proccess to occur without reinstalling it. The bootpage replacement/wrapper would be needed. This was discussed by embeem on alt.org a while ago. I don't know if anyone has gotten it to work.

Having the hacks on another partition also has its obvious advantages. For the meek, they are: Persistantance after upgrade process, solves the /var rebuild problem and the / rw problem.

If we can come up with a consensus on the best layout/method, I will do the implementation.

AlphaWolf
03-04-2004, 08:26 PM
<db mode>

just my $0.02 here, but do we really want the "old days" brought back?

extreme images or tivolater style updaters are only slightly more difficult than re-zipping the originals with a few updated files. that no one whining for them has managed it so far is a CLEAR indication that those with the FEW braincells required also realize it'll cause more trouble than we want from dtv/tivo

you guys have no idea how easy it would be for tivo to cause tremendous grief - security holes work both ways, yanno?

</db mode>

whew! glad to get that outta my system... :D

Well, I misworded my first post. What I mainly have in mind is a replacement to installSw.itcl; specifically one that takes monte into consideration. In other words, it wont be a "tivolater" or "xtreme" at all, rather a means of making software upgrades less of a pain in the ass with a monte configuration.

The main points are this: preserve existing hacks, and making non platform intended upgrades (e.g. upgrading to 4.0 on a Dtivo,) all without physically removing the hard disk.

The main difference between this idea and the xtreme/tivolator ideas, is that they add new hacks or totally rape your current configuration through whatever means. As a developer, I really have no use for something like these.


I have been pondering similar solutions. A few ideas are:

a) Install the U5 fs/kernel on partitions 2/5


Well, I personally don't like the idea of doing this, because then you have to trash your current partition setup just to make it work (you need at least 4 megs on one of the partitions, and they are only 2 megs.)

You can safely allow the tivo to perform a normal upgrade, and before the reboot goes through, overwrite the old rootfs/kernel with the hacked U5. I've personally done it before, and it seems clean enough.

psxboy
06-14-2004, 04:47 PM
There are several approaches you can take with this, ranging from difficult to relatively easy...

The "difficult" approach is outlined in this thread (http://www.dealdatabase.com/forum/showthread.php?t=31952&page=1&pp=15) starting with this post (http://www.dealdatabase.com/forum/showthread.php?p=146821#post146821). You'll need the killinitrd from this post (http://www.dealdatabase.com/forum/showthread.php?p=169433&highlight=compiled+mips#post169433) in order to complete the process completely on the Tivo.

The "easy" approach is to put your original drive back in the Tivo, wait for it to be upgraded, then start from scratch with the Tivoscripts (Sleeper) ISO. The downside to this approach is that you'll loose everything - recordings, season passes, thumbs, etc.

I took a slightly different approach (http://www.dealdatabase.com/forum/showthread.php?p=169489#post169489)... sort of a combination of the two.

Unless you're going to go the "easy" route & start from scratch, you need to put your bootpage settings back to what the Tivo expects them to be before you let the upgrade happen on a Monte'd system:


bootpage -p /dev/hda (shows you the current boot params, including root directory)
bootpage -b /dev/hda (shows you the current boot partition (kernel))
bootpage -P "root=/dev/hdaX" (where 'X' is either 4 or 7... make it the opposite of the one from bootpage -p)
bootpage -f /dev/hda (flips the alternate & boot partition)

This will set things up so that the upgrade script will put the new partitions in the correct place. Then you modify the installSW.itcl script so that it doesn't reboot at the end and run it:


/tvbin/installSW.itcl <SwSystem Name>
(ie. /tvbin/installSW.itcl 4.0.1b-02-2-240)

That will extract the new software from the MFS database & install it on the partitions originally occupied by your 31U5 kernel & filesystem. At this point, you can shut down the Tivo, remove the drive, connect it to your PC and boot with the Tivoscripts (Sleeper) ISO. As long as you have a FAT32 drive installed as your primary master, you can connect the CD drive and the Tivo drive in whatever order is convenient and do the rest manually from an alternate console:

Mount both root partitions and copy anything you want from the old root to the new root, especially rc.sysinit.author, rc.sysinit.tpm, and the rcS.d directory. Umount the old root and 'dd' the 31U5 kernel and filesystem from the CD to the partitions previously occupied by your old kernel and root. Killinitrd the new kernel. Extract the bin utilities, busybox, tivoftpd, kmem and the misc scripts to the new root. 'Neuter' the netfilter-enable script, patch tivoapp, set your new bootparams and flip the bootpage again.

I went with this manual approach because I didn't need the Tivoscripts to do everything again... my runmontefs was still on hda16, I didn't need my rc.sysinit.author re-edited, and I had things like tivoweb and mfsftp in /var so I didn't need old versions copied to /usr again.

-psxboy

alldeadhomiez
06-16-2004, 01:29 PM
Why is it needed to modify the installSw.itcl script to not reboot at the end? you are shutting the unit down after the script runs. Isn't the essentially the same thing? Are there any negitive results by not modifying the installSw.itcl?

The installation scripts swap the strings "hda4" and "hda7" in your boot parameters. If your 3.1.U5 "decoy" filesystem is somewhere other than hda4 or hda7 (as it should be), an inadvertent boot of a new kernel with >3.1.0 signatures in the initrd will trash the decoy filesystem and make the box unbootable.

I'm not sure if TivoScripts fixes this, but I wouldn't bet on it.

psxboy
06-16-2004, 01:38 PM
If you're going to pull the drive from the Tivo immediately following the reboot (without letting it boot, obviously) then you don't need to edit out the reboot line. But what if something went horribly wrong during the installSW run...? Like maybe you forgot to munge your bootpage settings before running it?

Without the forced reboot, you still have a running Tivo with an accessable shell that you can use to fix any problems first. Just a safety measure, that's all.

-psxboy

malfunct
06-17-2004, 02:03 AM
The installation scripts swap the strings "hda4" and "hda7" in your boot parameters. If your 3.1.U5 "decoy" filesystem is somewhere other than hda4 or hda7 (as it should be), an inadvertent boot of a new kernel with >3.1.0 signatures in the initrd will trash the decoy filesystem and make the box unbootable.

I'm not sure if TivoScripts fixes this, but I wouldn't bet on it.

I flipped them before runing installsw.itcl which makes the script flip them back. The result is still not bootable however.

I have a set of steps that definitely worked for me but I won't post them to anyone unless PlainBill gives me the ok as he derived them from the steps that AlphaWolf posted.

There were some hiccups in my upgrade but I am certain I caused those myself and they didn't do any permanent damage but its another reason I don't want to post the steps I have yet.

Anyways, PlainBill, what do you think about posting the steps?

PlainBill
06-17-2004, 11:32 AM
I flipped them before runing installsw.itcl which makes the script flip them back. The result is still not bootable however.

I have a set of steps that definitely worked for me but I won't post them to anyone unless PlainBill gives me the ok as he derived them from the steps that AlphaWolf posted.

There were some hiccups in my upgrade but I am certain I caused those myself and they didn't do any permanent damage but its another reason I don't want to post the steps I have yet.

Anyways, PlainBill, what do you think about posting the steps?

I say post them, unless AlphaWolf or one of the other 'elders' object. Maybe then we can come up with an easy to follow procedure ANYONE can follow to do it without pulling the drive. :) Given the problems the S2SA owners are having with HMO, it certainly seems like this is needed.

PlainBill

malfunct
06-17-2004, 12:36 PM
I say post them, unless AlphaWolf or one of the other 'elders' object. Maybe then we can come up with an easy to follow procedure ANYONE can follow to do it without pulling the drive. :) Given the problems the S2SA owners are having with HMO, it certainly seems like this is needed.

PlainBill


This is a procedure that I wrote. I based it on AlphaWolf's procedure, then modified it when I realised I didn't have the foggiest idea where Sleeper's TiVoScripts places the hacks files (all over the place, obviously). Yesterday I followed it step by step to upgrade my 'main' drive - the one I would cry over if I lost everything on it. It worked perfectly for me.

If you have any questions, or anything isn't clear, ask. I also urge you to try it on a 'test' drive first.

PlainBill

Upgrading a drive Monte'd by Sleeper's TiVoScripts using slices.

Discussion: This is a procedure for upgrading your current hacked software installation to a newer
version using slices. It assumes you used Sleeper's TiVoScripts to hack the drive. For simplicity, we will
be creating the new software in the alternate (U5) partition.

Limitations: This procedure has been tested on a Hughes HDVR2 running 3.1.1b. It is not know how
this will work on other models of DirecTiVos and other software versions.

Resources required:

Slices for the software version to be installed (3.1.1c-01-2-151)

LoadSlice

Telnet client (TeraTerm)

FTP Client (LapLinkFTP)

The computer you used to hack the drive initially.

Operation:

Set the prom password to factory [crypto -u -srp factory] (Optional)

Transfer (FTP) the slices and LoadSlice to the /var/packages directory.

Start telnet and change to that directory [cd /var/packages]

Make Loadslice executable [chmod 755 LoadSlice]

Extract the slices [gzip -d *.gz]

Load the slices [LoadSlice]

Verify the slices have been transfered sucessfully by checking MFS/SwSystem using TiVoWeb (you should see 3.1.1c-01-2-151)

Read the bootpage [bootpage -p /dev/hda]

The first /dev/hdaX indicates the active partition. X will be either 4 or 7 The following line assumes X was 4

Update the boot parameters [bootpage -P /dev/hda7 /dev/hda

Flip the bootpage [bootpage -f /dev/hda]

Change to the tvlib directory [cd /tvlib]

Upgrade the software [installSw.itcl 3.1.1c-01-2-151]

When the upgrade completes, it will restart the system. As soon as the TV screen blanks, turn off power to the TiVo.

Remove the hard drive and insert it in the computer you used to hack it as secondary master.

Boot the computer from the TiVoScripts CD.

At the main menu switch to an alternate console [Alt-F2 Enter]

Delete the variables file [rm /cdrive/tivo/variables]

Return to the menu [Alt F1]

Start the Monte process [m]

Skip backup and restore; run Surgery and Hacks.

After the process completes, shut down the system and return the drive to your TiVo.

Turn on the TiVo, let it boot, and verify you have an updated system. Any hacks you added after running
TivoScripts the first time must be reinstalled.


One last note, especially for SA users, if you can see the version you want to upgrade to in MFS/SwSystem you don't need to do any of the "load slices" steps. Also, its not 100% necessary to have the drive you originally ran tivoscripts from. It is possible to work around the issue though it may be one of the things that caused the "trouble" I had which was just tivoscripts detecting my software on the wrong partition which I corrected by letting it mount the wrong partition, jumping to the 2nd virtual console, unmounting the wrong partition and then mounting the right partition in its place. This happened when I went through the hack's section.

BTW this method preserves any recordings you had on the machine.

Also, I take no credit for coming up with the above steps, I just know they work.

alldeadhomiez
06-17-2004, 01:26 PM
One last note, especially for SA users, if you can see the version you want to upgrade to in MFS/SwSystem you don't need to do any of the "load slices" steps. Also, its not 100% necessary to have the drive you originally ran tivoscripts from. It is possible to work around the issue though it may be one of the things that caused the "trouble" I had which was just tivoscripts detecting my software on the wrong partition which I corrected by letting it mount the wrong partition, jumping to the 2nd virtual console, unmounting the wrong partition and then mounting the right partition in its place. This happened when I went through the hack's section.

BTW this method preserves any recordings you had on the machine.

Also, I take no credit for coming up with the above steps, I just know they work.

Ok, a few observations:

First, since you can't derive the full software version number from the slice names, you can run "echo mls /SwSystem | tivosh" after inserting the slices to view the swsystem slices present in MFS. If there are unsatisfied dependencies (most likely LoopSet objects or GZ*/utils slices) you won't see a listing for the new swsystem (it will be a Pending object). The loopset dependency problem will hit you when you are using a swsystem slice for a different manufacturer or "class" of machine. I posted instructions elsewhere for transporting loopsets ("building mfs from scratch" thread).

Second, it's pretty hard to lose (unscrambled) recordings without mfstools. Since the data in partitions hda2-hda9 has no bearing on your recordings, thumbs settings, etc., it can be manipulated at will. In fact, my own personal upgrade process completely wipes out those partitions and installs them from scratch; all recordings are preserved.

Third, installSw.itcl is in /tvbin, not /tvlib. And remember to change the "fSafe" checking if you are installing a SwSystem object that has a lower server ID than the active swsystem. This is often the case when upgrading from 3.1* to 4.0.

Fourth, I believe you will want/need to set the current SwSystem version in /State/ServiceConfig, especially on a unit which does not phone home to TiVo. If this attribute does not match the active swsystem's version, you MAY see the upgrade screen on every boot and/or begin rebooting every morning.

And finally, if you are upgrading to 3.1.5, you will need to create an active ModelInformation object or Bad Things(tm) will happen. Example code:


proc create_config { db verbose } {
RetryTransaction {
try {
set a [db $db open /Config/ModelInformation/Active]
} catch errCode {
if { $verbose == 1 } {
puts "creating ModelInformation entry"
}
try {
set o [db $db create ModelInformation]
dbobj $o set ServerId 20089680
dbobj $o set ModelNumber "HDVR2"
dbobj $o set Active 1
} catch e {
if { $verbose == 1 } {
puts "ModelInformation entry not created: $e"
}
}
}
}
}

alldeadhomiez
06-17-2004, 05:23 PM
This post will first attempt to document the NORMAL upgrade process.

During the daily call or DTiVo service data download, if your unit is selected for a software update, the TiVo headend will instruct your unit to download several software upgrade slices. The number of slices varies from version to version.

Here is the slice set for software version 4.0-01-2-140:

GZbin-12244400-1.slice.gz
GZsbin-12244412-1.slice.gz
GZetc-12244402-1.slice.gz
GZtvbin-12244414-1.slice.gz
GZkernel-12244404-1.slice.gz
GZtvlib-12244416-1.slice.gz
GZlib-12244406-1.slice.gz
GZopt-12244408-1.slice.gz
swsystem-12244632-1.slice.gz
GZprom-12244410-1.slice.gz
utils-12244418-1.slice.gz

example filename:
GZtvlib-12244416-1.slice.gz

Each slice filename contains the ServerId. The ServerId is a globally unique number that identifies the "first" (or only) database object contained in the slice. The ServerId is shown in red. ServerId numbers are only assigned to database objects manufactured by TiVo. Your recordings, for instance, do not have ServerIds. Any database object with a ServerId can be accessed through the path: /Server/<serverid>. All primary database objects within a slice will have their own ServerId; secondary objects will not (since they are only referenced by their parent object). swsystem slices will contain hundreds of primary objects.

The slice filename also contains a version number. This is the same as the ServerVersion on the object. Minor changes to objects will increment the version number; for major changes (or changes which are not backward compatible), a new ServerId will be created for the new object. If you attempt to insert an object that already exists, the versions will be compared, and the new object will not be processed if it has an equal or lower version number.

The software version suffix (-140) matches the prefix of the TiVo service number of the unit the slices are intended for. For example, the service number of the unit running this release is 140-. This corresponds to a Series 2 60 hour unit.

The "core" slices, such as GZetc, GZtvbin, etc. are frequently the same (same version, same ServerId) across different "builds" of the same software version (with "build" referring to the machine it is intended for, like -140, -240, etc.). However, sometimes the utils slice (used to house the software installation scripts and such) and almost always the swsystem slice are different. Sometimes this is because the swsystem slices contain references to different loopsets, different model numbers, etc.

The GZ* and utils slices generally consist of one database object, which links to a tyFile included in the slice. This tyFile is usually a gzipped cpio archive. Thus, all of the "stock" files needed to install and populate your root filesystem and kernel partition are stored in MFS at all times.

Loopset slices are NEVER included in a software download. I have never seen a "native" loopset slice from TiVo (since they are preloaded onto your machine when it is initially imaged), but it is possible to build your own from an existing image, with a little effort.

Slices frequently have dependencies. Dependencies are based on ServerId and object type. If a dependency is missing from the database, the objects which rely on it will remain in Waiting state and will not be indexed into the MFS directory structure (at least not where they belong). The dependency problems you will generally run into will be based on missing loopsets or on missing GZ*/utils slices. The swsystem slice pretty much contains everything else it depends on. To determine whether you have all of the prerequisites, you can dump the swsystem slice with readguide. ServerIDs that are not accounted for in that slice will need to be provided some other way (unless they are already on your system).

Sometimes you will see a swsystem slice that looks like this:

swsystem-12244632-1.slice.bnd

A .slice.bnd file is encrypted, so you will not be able to use it with dbload. You will need to find a way to access the session key if you wish to decrypt it. If you have a swsystem .slice.bnd file not intended for your model, this is probably impossible.

myworld, while downloading slices or slice.bnd files from the satellite or during the daily call, will seamlessly decrypt .bnd files (if necessary) and then dbload them into the database. During the download, they may be stored in /var/packages; embeem posted a kernel module on alt.org which intercepts the unlink() operation, allowing you to capture the slices.

(continued)

alldeadhomiez
06-17-2004, 05:24 PM
After the software download has completed, myworld will update /State/ServiceConfig, attribute SwSystemName, to record the version of the new swsystem. The system will then enter a "pending restart" mode and reboot around 2am.

When the system reboots, rc.sysinit checks the upgradesoftware environment variable. If it is not equal to "false", it will invoke /etc/rc.d/finishInstall.tcl.

finishInstall.tcl then reads the SwSystemName attribute and opens /SwSystem/$name. If it finds that this swsystem (the new one) is not active (which it will not be at this point), it renders the "installing software" OSD and executes /tvbin/installSw.itcl.

installSw.itcl does a couple of sanity checks to make sure that the ServerId of the "new" software is not lower (older) than the ServerId of the active swsystem. If these checks pass, the slices are extracted from the database, copied to /var, and the install script is run.

The install script looks in /etc/fstab to find the active root partition, then initializes the alternate root partition, unpacks the GZ* slices to the new root filesystem, and installs the new kernel to the alternate kernel partition. It then exchanges "hda4" and "hda7" in the kernel command line in the bootpage, calls bootpage to flip the boot and alternate kernels, and returns to installSw.itcl so that the system can be restarted.

These scripts have an EMERGENCY_REINSTALL feature which can be used to safely recreate your installation (aside from MFS) in the case of an accident or corruption.

Now, how does a hacker exploit this process on a PROM-modded unit (some S2s, potentially all S1s)?

First, you must kill the initrd in the new kernel image. IIRC, some Series 1 images such as 25xtreme included repacked GZkernel slices in MFS, which resulted in a pre-compromised kernel being installed to the alternate partition during the software upgrade. Or, since you are in full control of installSw.itcl when you are initiating an upgrade, it can be modified so that it returns instead of rebooting; at that point you can kill the initrd in the alternate partition by hand before you reboot.

You will also want to include backdoors (network and serial console access) on the new root partition. This can be accomplished by copying over a new rc.sysinit.author file to /install/etc/rc.d/.

On a Series2 unit that uses the BASH_ENV exploit, additional steps are needed. The bootpage parameters and boot kernel may need to be fixed up so that the compromised 2.4.4-TiVo-3.0 kernel remains the boot kernel, regardless of the kernel installed from the new software package. You will also need to chain-load the new, initrd-free kernel with monte-mips.

I am attaching a small script I use during my automated upgrade process to set the SwSystemName attribute, given the filename of the new swsystem slice.

DeathLemur
06-20-2004, 05:57 AM
This is a procedure that I wrote. I based it on AlphaWolf's procedure, then modified it when I realised I didn't have the foggiest idea where Sleeper's TiVoScripts places the hacks files (all over the place, obviously). Yesterday I followed it step by step to upgrade my 'main' drive - the one I would cry over if I lost everything on it. It worked perfectly for me.


And indeed they did for me as well. SA Series 2, previously Monte'd by hand. I had the 4.0.1b-02-2-240 software already downloaded onto my system. Making things even easier, I had the same partition numbering as was in the instructions.

Fiddled with the bootpage, ran the installSw.tcl script, yanked the power cord on reboot, and stuck the drive onto the secondary master IDE port of my PC. Booted the TivoScripts 1.02 CD... here's where there was deviation: there was nothing in /cdrive -- no files, nothing mounted. I just shrugged and kept going, running the surgery and hacks scripts for the Monte.

Shutdown, plugged it back in to the Tivo, powered on, and Bob's yer uncle. Now to get all the little hacks and everything back into place. :)

Thanks for the procedure! I was getting worried about the lack of guide data (the nightly reboots were just an annoyance... :) )

jbellanca
06-23-2004, 07:11 PM
Hey guys, thanks for the method for the upgrade, worked awesome! I'm now on 3.1.1c-01-2-151 on my DVR40. I have a question, though.

When I looked at swsystem in MFS, I saw (after the upgrade, before 3.1.1b was active):

3.1.1b-02-2-351 tyDb 46915 06/23/04 16:18 668
3.1.1c-01-2-101 tyDb 244564 05/28/04 02:32 668
3.1.1c-01-2-121 tyDb 244567 05/28/04 02:32 668
3.1.1c-01-2-151 tyDb 244537 06/23/04 16:18 692
3.1.1c-01-2-301 tyDb 244561 05/28/04 02:32 668
3.1.1c-01-2-321 tyDb 244558 05/28/04 02:32 668
3.1.1c-01-2-351 tyDb 244552 05/28/04 02:32 668
3.1.1c-01-2-381 tyDb 244555 05/28/04 02:32 668
3.1.1c-01-2-3F1 tyDb 244549 05/28/04 02:32 668
ACTIVE tyDb 244537 06/23/04 16:18 692

State/ServiceConfig shows SwSystemName= 3.1.1c-01-2-351 after the upgrade, and when I look for the sw version number using the Tivo menus, it shows 3.1.1c-01-2-151.

After a phone call, it still shows "Pending Restart." Is that because it thinks there's a higher version number to upgrade to? Should I redo the process with the highest version number (3F1)? If so, can I skip all the ones in between?

Thanks,
Jim

jbellanca
06-23-2004, 08:10 PM
So, my curiosity got the better of me, and after reading alldeadhomiez's post above, I re-ran the whole thing using the 3.1.1c-01-2-351 version this time (not 3F1) since that's the version I think it wants to upgrade to, and it successfully updated to 351 and now when I force a call it says Succeeded (not Pending Restart). So, why are there the 381 and 3F1 versions? Should I upgrade to them?

MFS swsystem now says:

3.1.1b-02-2-351 tyDb 46915 06/23/04 16:18 668
3.1.1c-01-2-101 tyDb 244564 05/28/04 02:32 668
3.1.1c-01-2-121 tyDb 244567 05/28/04 02:32 668
3.1.1c-01-2-151 tyDb 244537 06/23/04 18:17 668
3.1.1c-01-2-301 tyDb 244561 05/28/04 02:32 668
3.1.1c-01-2-321 tyDb 244558 05/28/04 02:32 668
3.1.1c-01-2-351 tyDb 244552 06/23/04 18:17 692
3.1.1c-01-2-381 tyDb 244555 05/28/04 02:32 668
3.1.1c-01-2-3F1 tyDb 244549 05/28/04 02:32 668
ACTIVE tyDb 244552 06/23/04 18:17 692

Thanks!
Jim

mrblack51
06-23-2004, 10:35 PM
the last three numbers (151, 381, 3f1) indicate specific model numbers. the version is the first #-# at the beginning. Anything that is 3.1.1c-01-02-* is identical. the only difference is sometimes there are different strings or images that get loaded (or are required).

jbellanca
06-24-2004, 01:16 AM
the last three numbers (151, 381, 3f1) indicate specific model numbers. the version is the first #-# at the beginning. Anything that is 3.1.1c-01-02-* is identical. the only difference is sometimes there are different strings or images that get loaded (or are required).

So, what I should have done is looked first in MFS/State/ServiceConfig to find the correct version/model combo number and installSw'ed that one, right? (Potentially, I'm guessing, by my first install of the wrong model number I could have screwed things up, but got lucky, but then the second install with the correct model number made the unit happy...)

Thanks again everyone for all the great info here. I appreciate it.

Jim

alldeadhomiez
06-24-2004, 01:50 PM
So, what I should have done is looked first in MFS/State/ServiceConfig to find the correct version/model combo number and installSw'ed that one, right? (Potentially, I'm guessing, by my first install of the wrong model number I could have screwed things up, but got lucky, but then the second install with the correct model number made the unit happy...)

SwSystemName can be set two ways: by the daily call, or by hand. The former should happen when you're taking a "legit" upgrade, and the latter happens when you are just dbload'ing slices on your own (such as when you are upgrading from 3.x to 4.x).

You will want to upgrade to the swsystem whose suffix matches your model prefix whenever possible, since a mismatch could mean that you don't have the correct loopsets. If you don't have the correct loopsets, you will need to either spoof them or transplant them from an image that does have them, before you attempt to dbload the swsystem slice.

woracan
09-28-2009, 09:34 PM
myworld, while downloading slices or slice.bnd files from the satellite or during the daily call, will seamlessly decrypt .bnd files (if necessary) and then dbload them into the database. During the download, they may be stored in /var/packages; embeem posted a kernel module on alt.org which intercepts the unlink() operation, allowing you to capture the slices.


Could someone please post that kernel module for me? I couldn't find it at alt.org. Thanks!

jt1134
09-28-2009, 09:56 PM
http://dealdatabase.com/forum/showthread.php?p=213155&postcount=10

as adh points out in that post, you'll need to also use a custom kernel with SYS_CALL_TABLE defined to use it

mike_s
09-29-2009, 11:30 AM
It's easier to just have a cron job frequently hard link to potential slices...


* * * * * ln /var/packages/*.slice.* /var/slices/


The above will grab much more than the system slices, so clean the cruft out occasionally.