Consequences of blocking software updates on standalone units

[alldeadhomiez]

This is a well known issue but it seems that a lot of people are re-discovering it as the 7.1/7.1a comes down the pipe. So we will review the basics:

1. Blocking software updates on a SA unit (by modifying rc.sysinit, setting $upgradesoftware to false, or any other means) WILL cause issues. This happens because the mothership and the box are "out of sync" with regard to the software version they expect to be running on the system. This is generally not an issue on DTiVo boxes, since they do not need to interact with the mothership.

2. Running a version of the software that the mothership does not expect you to be running will often cause you to receive keys that do not operate correctly on your current software version. This happens because (for various reasons) the mothership sends keys based on the software version it expects you to be running, not the version that your box reports during the call. So, if you are on the 7.1 list, but still running 4.0.1b, you will receive keys for 7.1 that do not necessarily work on 4.0.1b. Daily calls also wipe out unauthorized keys in /State/Keyring, so if you are running set_mrv_name.tcl on a subscribed SA, your MRV key will disappear. You will also see nightly reboots as the machine attempts to install the new software. Patches for several versions that attempt to work around these issues can be found here.

3. Running the wrong software version will sometimes cause the mothership to refuse to send you guide data. This may happen a few weeks or months after you have been selected for the software update. If this happens, the easiest course of action is to take the update. There are other ways around this, which you may want to explore on your own.

4. If you are using a "TivoScripts" / "Sleeper ISO" partition setup, taking the upgrade will usually make the system unbootable. You should remove the TivoScripts setup at your earliest convenience to prevent this and other serious problems caused by this program. Read: 1 2

For more general information on software updates: link

[scoob8000]

Just to add my experience..

I was at 4.01b and blocked the upgrade for quite some time, I had lost my Music / Pictures menu item. Allowing the upgrade to take place fixed this..

[Player1]

I too have been blocking an upgrade from 4.01b. All of my season passes recently stopped working. Has this happened to anyone else?

[philhu]

I too have been blocking an upgrade from 4.01b. All of my season passes recently stopped working. Has this happened to anyone else?

I am ready to stop hacking my 2 series 2 tivos.

I had put sleeper (I know, gak) on them.

Can I just let 7.01 install at this point and be ok, or do I have to back sleeper out? And if so, how? Is there a step by step?

I do not want to lose my recordings.

[captain_video]

Check out this info:

http://dealdatabase.com/forum/showth...iso#post196162

[Jamie]

I do not want to lose my recordings.

If you were running a plain sleeper config with the kmem patch rather than a nocso tivoapp patch, you probably need to fix up your cso keys with csoscout or your recordings will be useless on your unhacked tivo. Near as I can recall (it's been a while since I run a stock release), nocso recordings will play fine on an unhacked box.

[CroW]

I'm running 4.01b and I've been blocking updates since before ADH created this thread.. My Tivos are Sleepered and running the No Thanks and NoCSO (I think)... Everything works fine on all 3 units.
I'm thinking about wiping out all 3 and taking the update just so i'll have something new to screw with...

[bdjohns1]

Near as I can recall (it's been a while since I run a stock release), nocso recordings will play fine on an unhacked box.

I just took an upgrade from a hacked 5.2.2 to 7.2, and nocso'd recordings are playing fine right now, although until the offset is ID'd, all new recordings are encrypted.

(edit)Offset was found, and I'm back to unencrypted recordings.

[PiZmAn]

I can not seem to locate the thread on how to do it for my 3.1.5f.

All I could find was this:

root=/dev/hda4 dsscon=true console=2,115200 upgradesoftware=false

Does anyone know if that will work?

Thanks

[Throg]

Blocking updates may be a thing of the past. I noticed yesterday that I pulled down 8.1.L##.01.2.140 (I don't remember the numbers represented by #). Of course I was going to wait for the superpatch update before taking this but I noticed some activity in my kernel log that looked like someone or something was trying to force a restart. Today my box is now hung up on Welcome. Powering up... It's apparent I'm going to have to pull the drive to get it to boot, rehack, then run superpatch. This is assuming that all of that will still be doable. I'm a little worried about this.

[Jamie]

never mind.

[Throg]

Okay. With nothing to lose, I pulled the power on the unit and let it restart. It started up normally and Last call status says: Succeeded. But the software version is still 7.3.1 and the 8.1.L4-01-2-140 is still in /SwSystem. Odd. I'm unable to start up TWP. I'm getting this response:

Warning: The last few sessions did not complete successfully
We may be in a reboot loop... abort

Telnet and bash are still functional.