Separate names with a comma.
Discussion in 'TiVo Help Center' started by GrtEscGtr301, Sep 9, 2013.
According to the sys info screen:
Interesting, I wonder what would happen if put 9.3.2c directly on my rebooter?
That's the version it has now.
I have no idea when it got it, or if it was before or after I imaged it.
The image I got from you in May 2012 has 9.3.2b-01-2-540, which works fine on my 540040 until it upgrades the software.
So when TiVo bumps it up from b to c, it borks the TiVo?
I'm thinking that is a possibility. Not sure why yours upgraded successfully and myself and GrtEscGtr301 didn't though.
Did anyone happen to notice when "c" rolled out?
Was that the "expired cookie" patch?
Could it be that the TiVos aren't successfully switching over to the alternate partitions where the new software is loaded?
Could it be that there are bad sectors somewhere in the alternate partitions that haven't given trouble until now because they haven't been used in a long time?
You can use WinMFS to find out if you're set to boot from 2,3,4 or 5,6,7 and then fix boot option 1 will set it to 2,3,4 and option 2 will set it to 5,6,7 so that you can switch back to booting from the partitions that you were using before if TiVo, Inc has just recently tried to move you to the other partition set.
I'm guessing there was a "cookie" patch sent out to the S2 boxes recently like the 11.0m release on the S3 hardware, and the field upgrade of the 540040 I had running on a new disk with your backup image for about 9 months got into a reboot loop (just like GrtEscGtr301). When troubleshooting, I restored your image on a different new disk and had a working TiVo (with a different power supply) for about a day. It was working fine until the next day when a software update was downloaded and it got itself into a reboot loop again.
I haven't tried flipping the partitions back though. I basically want to keep this thing calling in occasionally since this is the lifetime box that qualifies me for the MSD discount and actually recording stuff is a secondary concern. If need be, I can restore your image every few months and let it run for a day before it borks itself again.
Let's just say that if you ever upload a 9.3.2c backup then I will be first in line to try it out (I'm guessing GrtEscGtr301 will be second in line).
If you have an at least temporarily spare hard drive as large or larger than the "problem" drive, you can use
or, my preference,
both of which are on the MFS Live cd v1.4, to "Xerox" the problem drive to the other one, see if the other one has the same problem in the TiVo, and then if so do the partition flip on it and see if that makes a difference, and we'll have another clue in our arsenal.
I restored your backup on two different space drives that pass manufacturer diags. Once the "pending restart" happens they go to reboot city.
Sorry for the radio silence, I've been on the road the past couple of days. Well, the S2 is now on life support. No matter what I do it eventually goes into the Reboot-Loop-Of-Death. I was able to get it into Kickstart mode and try KS 57, 58, all the 54 variants (all of which came up clean) and 56, (which failed with some kind of network error). I also removed the drive and did a level 4 test on SpinRite just to be sure the drive hardware was OK, which it was. No errors there.
At this point I'm at a loss. I was able to find a TiVo tech who was a bit more sympathetic and tried to be more helpful than the first guy, but with no more success. I can get the system up and running, but as soon as it phones home for a service update, back to the RLOD.
I definitely have 9.3.2b on the drive, and (as sbourgeo hinted) would be happy to test a 9.3.2c version. I'll keep puttering around and watching the board here for suggestions, but I'm about to throw in the towel. (And the Roamio sure does look purdee, don't it? ;-)
I finally pulled the logs from mine and see what is going on. Basically, everything is running fine with software version 9.3.2b-01-2-540. It then downloads the 9.3.2c-01-2-540 slices, loads them into MFS, and then installs them at the next reboot.
I see from the logs with both of the drives I tried (which both pass the long manufacturer diags) it tries to create and mount the new root file system that should be sitting on /dev/hda4 and fails trying to mount it. At that point, the old root file system (/dev/hda7) is unmountable, the new root file system (/dev/hda4) is mountable but empty, and the /var filesystem (/dev/hda9) contains all of the logs documenting this. This basically puts you in the reboot loop because there is no valid operating system on the box.
I don't have a lot of time to work on this at the moment, but I do have a couple of things I can try. First, I wonder if a bug is choking on the fact that there is no existing "old" root file system on /dev/hda4 because this disk was created from Unitron's truncated 9.3.2b backup. I'm going to try dd'ing the contents of /dev/hda7 to /dev/hda4 before I run guided setup so there is at least something on there before the eventual 9.3.2c install starts. Failing that, if I can get a killhdinitrd kernel running to get CLI on this I could try executing the upgrade script manually so I can intervene as required. Another option would be to just restore a 9.3.2c backup if we can get one, but that could mean we'd have to repeat this exercise if 9.3.2d is ever released.
I'll provide more details when I know more.
Well, I can verify that dd'ing the contents of /dev/hda7 to /dev/hda4 also results in a reboot loop Haven't had a chance to pull the disk and look at the logs yet, but I'm guessing I know what's there...
I also just figured out that the TCD540040 needs to have the prom physically replaced to use the killhdinitrd kernel. So much for that option.
It's looking like we're stuck without a 9.3.2c backup to restore. I did take a truncated backup with 9.3.2b before the call to get the 9.3.2c upgrade, so I guess I'll have to restore that every few months and have the TiVo call in to maintain my MSD. This sucks.
I have been using Unitron's 9.3.2b MFSLive image for this experimentation, so for the heck of it I tried using his WinMFS image on yet another SATA drive. Unfortunately, this also results in a reboot loop.
Does my image cause it, or is it the failure of the update from b to c?
It could be both, but it's nearly impossible to debug without CLI or the ability to add my own code (I have the stock prom). I get the same reboot loop using your virgin 9.3.2b image on multiple SATA and PATA drives that pass the long manufacturer diags when they attempt to upgrade to 9.3.2c. From the kernel log file during one of those attempts:
I'll try to find a time when I can take my 540 offline and do a new "c" backup, but I fear laundry and lawnmowing will have to take priority to keep the peace around here, so not sure how soon.
Ha, I'm about to head to Lowe's for the materials for my task list today! I was at least able to cut the grass last night.
I really appreciate the help though, I'm stuck in the water on this one.
I can confirm the exact same behavior seen on my 540040 as described in this thread, and also in [thread=508675]this thread[/thread].
The original hard drive had failed, so I had restored onto a new hard drive using unitron's image. It was fine for a year, but a couple weeks ago, it started doing this reboot loop thing. Since then, I've tried restoring it with numerous different options using mfslive and Winmfs, to no avail. As soon as the software update happens, it always starts the reboot loop again.
I'd be curious to know if everyone experiencing the problem started off with a restoration from unitron's image.
I'd also be very grateful for a "c" image, unitron.