I need this info too!
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.
I need this info too!
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
There's a difference between needing help, and just being plain ole' lazy.
"You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)
HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.
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:
Before, it had the updatesoftware=false there.Code:bootpage -P "root=/dev/hda4 dsscon=true console=2,115200" /dev/hda
I'm going to try a forced call tonight. I'll let you know ASAP.
Thanks!
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.
Peace is a lie, there is only passion.
Through passion I gain strength.
Through strength I gain power.
Through power I gain victory.
Through victory my chains are broken.
The Force shall set me free.
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.
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.
Peace is a lie, there is only passion.
Through passion I gain strength.
Through strength I gain power.
Through power I gain victory.
Through victory my chains are broken.
The Force shall set me free.
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.
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.
Geeze!!!! We've been 'upgrading in place' since 3.1.1d came out the process is well documented. The 'Upgrading to 6.2' 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
There's a difference between needing help, and just being plain ole' lazy.
"You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)
HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.
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
There's a difference between needing help, and just being plain ole' lazy.
"You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)
HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.
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.