Upgrade from 6.3c to 6.3e?

[daleykd]

After reading about the restarts associated with not having 6.3e, I thought it might be time to do that (since I'm going out of town this weekend and can't afford to have the system restart mid-recording).

I looked at /SwSystem and don't see 6.3e in my MFS. I also read that it is no longer in the sat stream.

I was curious as to a couple things, and was hoping one of you could be nice enough to guide me in the correct direction:

1. Is there a way to get 6.3e since I can't find an image anywhere and don't have the slices?
2. How do I change the updatesystem flag? I've been searching all afternoon and was unable to find any reference to how to revert it back.

Thanks in advance for your help.

[bfrank4709]

I need this info too!

[PlainBill]

Have you tried forcing a call to TiVo? That often results in the system downloading the slices and scheduling a reboot to install them.

By also, this presents an excellent opportunity to capture the slices BEFORE they are loaded to mfs.

PlainBill

[daleykd]

PlainBill,

That's the very first thing I did. It did appear to download quite a bit, but I still don't see 6.3e in /SwSystem.

My friend showed me the command:
bootpage -P "root=/dev/hda4 dsscon=true console=2,115200" /dev/hda

Before, it had the updatesoftware=false there.

I'm going to try a forced call tonight. I'll let you know ASAP.

Thanks!

[SithLord]

I loaded the 6.3e slices and went from 6.3a to 6.3e, but as I feared, I've lost all my main hacks and bash access via Tera Term Pro. I tried to serial in to talk to my HR10-250, but now that doesn't seem to work. I've tried all the different baud rate settings on COM1, but if anyone has any suggestions as to what I might be able to do to get serial connectivity, I'm all ears.

Just trying to get in so I can re-do my hacks and all.

[jt1134]

Check the usual. What starts serial bash/telnet? rc.sysinit.author or the equivalent. Did you copy over your kernel correctly to avoid wiping out your hacks? or did you use a precanned script to do it? If so, I'd think that script borked your kernel copy or rc.sysinit.author copy. Pull the drive and re-hack time.

[SithLord]

Don't want to lose all my recordings, so I guess I'll have to watch them all before I do anything to the drive.

[jt1134]

Don't want to lose all my recordings, so I guess I'll have to watch them all before I do anything to the drive.
Why? Installing a hacked kernel and rc.sysinit.author won't do a thing to your recordings.

[tas3086]

I've got 6.3e in mfs, and am currently at 6.3d. Has anyone been successfull in doing a manual install of 6.3e, fixing the alternate partition, and moving to the new system? Without removing the drive?

From the sounds of the previous posts, you may need to boot on the new partition first, before 6.3e is fully installed there. Then install the fixes.

[jt1134]

I upgraded via the usual path and didn't pull the drive. There's really nothing special about the upgrade process to 6.3e. It's the same as it was for any other 6.3 flavor.

[PlainBill]

I've got 6.3e in mfs, and am currently at 6.3d. Has anyone been successfull in doing a manual install of 6.3e, fixing the alternate partition, and moving to the new system? Without removing the drive?

From the sounds of the previous posts, you may need to boot on the new partition first, before 6.3e is fully installed there. Then install the fixes.

Geeze!!!! We've been 'upgrading in place' since 3.1.1d came out the process is well documented. The 'Upgrading to 6.2' (http://www.dealdatabase.com/forum/showthread.php?t=42325) thread has the instructions, I'm sure ones for 6.3x have been linked to just about every time an update comes down.

In a nutshell, the normal upgrade process determines the active partition, installs the upgrade into the inactive partition, uses bootpage to flip the active and inactive kernel and root partitions, then reboots.

The trick is to modify installSw.itcl to exit rather than rebooting. (You also may have to patch one other line in installSw.itcl). You run installSw.itcl from telnet, then when it completes you copy a killhdinitrd kernel to the new boot partition, copy your hacks from the old to the new active partition, and copy rc.sysinit.author to the new active partition. THEN you reboot.

Once the system comes up and updates the mfs database you can run the updated Superpatch to modify tivoapp. The whole process takes about half an hour, and you don't have to pull your drive unless you screw up. All recordings are intact, your spouse thinks you are a genius, and you can wait for the next update.

PlainBill

[MonsieurEd]

I have 3 HR10's. 1 (the oldest) downloaded the 6.3e slices back in August and the other 2 never even got the slices in MFS. Is there a way to force the slices to download? Once I get them upgrading is not an issue .... I just want to stop the CBS rebooting problem. I tried the script I found here but it didn't work.

[PlainBill]

I have 3 HR10's. 1 (the oldest) downloaded the 6.3e slices back in August and the other 2 never even got the slices in MFS. Is there a way to force the slices to download? Once I get them upgrading is not an issue .... I just want to stop the CBS rebooting problem. I tried the script I found here but it didn't work.

I would suggest forcing a call to TiVo, then watch to see if it downloads any files (IIRC, they are stored in /var/packages). You should see several files that start with GZcore, GZkernel, and swsystem, and ending with .slice.gz.
If you see them being downloaded, copy them to another directory ( /var/save) as they download. If they are downloaded, but do not appear in /SwSystem it is time to look through the logs to see what went wrong. It would be a good idea to delete all of the files in /var/log before forcing the call - the more free space and less you have to look through, the better.

PlainBill

[tas3086]

Once the system comes up and updates the mfs database you can run the updated Superpatch to modify tivoapp. The whole process takes about half an hour, and you don't have to pull your drive unless you screw up. All recordings are intact, your spouse thinks you are a genius, and you can wait for the next update.

PlainBill


Thanks, for making it clear that you update the app after you reboot. All other changes go before. I'll give it a try, unless someone says that 6.3e is no good.

[whitepelican]

Thanks, for making it clear that you update the app after you reboot. All other changes go before. I'll give it a try, unless someone says that 6.3e is no good.

That's only if you're going to run the Superpatch. If you patch tivoapp manually, you can do it before rebooting if you'd like. Although it might still be safest to make sure it comes up after a reboot before patching tivoapp, just in case you screwed something up you will narrow down the cause for debugging purposes.

[MonsieurEd]

Evidently they are now being made available again by d* via phone download to resolve the latest mess. I just checked MFS, they weren't there, then forced a dialup (network) connection and had the slices. Same for both boxes. Been trying this for 3 months. Guess D* re-released them via dialup only. I would suggest forcing a call to TiVo, then watch to see if it downloads any files (IIRC, they are stored in /var/packages). You should see several files that start with GZcore, GZkernel, and swsystem, and ending with .slice.gz.
If you see them being downloaded, copy them to another directory ( /var/save) as they download. If they are downloaded, but do not appear in /SwSystem it is time to look through the logs to see what went wrong. It would be a good idea to delete all of the files in /var/log before forcing the call - the more free space and less you have to look through, the better.

PlainBill

[rla]

After digging deeper I just punted and used slicer ... worked fine

[RonC]

I need to force a call, but it has been disabled for more than a year and I don't remember (for sure) how to "force a dialup call".
I THINK I use telnet, log on, and issue a bootpage -p , and when it gives me:

No device name given, assuming /dev/hda
root=/dev/hda4 dsscon=true console=2,115200 upgradesoftware=false

I then issue this:
bootpage -P root=/dev/hda4 dsscon=true console=2,115200

and I get:
No device name given, assuming /dev/hda
Updated boot page on /dev/hda

So I then (to verify it "took") issue a
bootpage -p

and get:
No device name given, assuming /dev/hda
root=/dev/hda4

I am on ATT Callvantage so I can't use my house for dialup, BUT my neighbor has agreed to let me drag my HR10-250 and a TV set over to his garage tomorrow morning, and have it try to dial in to get the update since he still has the good old ma bell telephone line service.

Please - what else do I need to do to "force a dialup" to get the 63e version- these reboots are KILLING me and my recordings.....)

Under system information, I have a brand 400, series 2, IRD HR10-250, with a version of 6.3d-01-2-357 .
Being in Austin, TX, my phone dial-in number is set to 586-0005, a valid number for the 512 area code/Austin, so if I can "force" it to dial, it should get 'er done.

I have searched a BOATLOAD of threads up here but cannot find a truly clear set of checklist - type items for taking a hacked (but long forgotten) machine that has been chugging away fine until these reboots started in, and making it "force a call".
Sure would appreciate any tips that would let me cart the junk over to my neighbors tomorrow morning in the dawn's early light and get verison 6.3e downloaded and then the upgrade run...
Thanks to those with the patience to answer and help me out.

[PlainBill]

You force a daily call from the menus. For 6.2 I would (hit the DirecTV button) > DirecTV Central > Messages & Setup > Settings > Phone > Connect to the DVR service now > (hit Select)

6.3 might be slightly different.

PlainBill

[tivo4mevo]

For those with HR10-250 units lacking the 6.3e slices. You can grab them here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=5714707#post5714707).

After dbloading them, you can always kick off a manual upgrade.